Thông tin
Hỏi đáp

Lý thuyết bài giảng môn Hệ thống thông tin quản lý nội dung chương 1 "Tổng quan về phân tích và thiết kế hệ thống"

Lý thuyết bài giảng môn Hệ thống thông tin quản lý nội dung chương 1 "Tổng quan về phân tích và thiết kế hệ thống" của Đại học Ngân hàng Thành phố Hồ Chí Minh với những kiến thức và thông tin bổ ích giúp sinh viên tham khảo, ôn luyện và phục vụ nhu cầu học tập của mình cụ thể là có định hướng ôn tập, nắm vững kiến thức môn học và làm bài tốt trong những bài kiểm tra, bài tiểu luận, bài tập kết thúc học phần, từ đó học tập tốt và có kết quả cao cũng như có thể vận dụng tốt những kiến thức mình đã học vào thực tiễn cuộc sống. Mời bạn đọc đón xem!

Môn:

Hệ thống thông tin quản lý (HTTT) 4 tài liệu

Trường:

Đại học ngân hàng Thành phố Hồ Chí Minh 221 tài liệu

Thông tin:

77 trang 11 tháng trước

Tác giả:

Tiến Dũng

docx.com.vn

Bình luận

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

Lý thuyết bài giảng môn Hệ thống thông tin quản lý nội dung chương 1 "Tổng quan về phân tích và thiết kế hệ thống"

93 47 lượt tải Tải xuống

lOMoARcPSD|36667950

Chương 1: Tổng quan về phân tích và thiết kế hệ thống

1.1. Các khái niệm cơ bản về hệ thống thông tin

- Dữ liệu: các con số, văn bản, ký hiệu, … có thể lưu trữ, truyền nhận. Là nguyên

liệu thô để phân tích, xử lý tạo thành thông tin.

- Phân loại dữ liệu:

Có cấu trúc (Structured)

Ví dụ: các table trong CSDL quan hệ.

Phi cấu trúc (Unstructured data)

Vi dụ: Hình ảnh, âm thanh, file văn bản, … Trên 80% dữ liệu

trong doanh nghiệp hiện là dữ liệu phi cấu trúc

Bán cấu trúc (Semi-structured data)

Ví dụ: XML database ...

- Big Data là các tập dữ liệu có khối lượng lớn và phức tạp, mà các ứng dụng xử lý

dữ liệu truyền thống không có khả năng thu thập, và xử lý tốt.

Đặc điểm của big data

Volume (khối lượng)

Petabyte (1PB=1024TB), Exabyte (1EB=1024PB)

Variety (tính đa dạng)

Dữ liệu thu thập từ nhiều nguồn khác nhau, các dạng và kiểu dữ liệu có cấu

trúc khác nhau. Velocity (vận tốc)

Tốc độ các dữ liệu được tạo ra và xử lý

Veracity (tính xác thực)

Chất lượng của dữ liệu thu được ảnh hưởng đến sự phân tích

VD Big data: Sàn chứng khoáng, MXH, Hãng bay

- Thông tin: dữ liệu đã được xử lý, đặt trong ngữ cảnh phù hợp, có ích cho người

dùng.

Một số đặc trưng của thông tin:

Tính chính xác (Accuracy)

Tính đầy đủ (Completeness)

Tính kịp thời (Timeless)

- Hệ thống: tập hợp các phần tử (components) tác động lẫn nhau, phối hợp hoạt

động (work together) để đạt được các mục tiêu (objectives) xác định.

- Hệ thống thông tin: là tập hợp các thiết bị phần cứng, phần mềm, hệ thống

truyền thông, được tổ chức lại để xử lý dữ liệu và phân bố thông tin phục vụ cho

các mục tiêu của một đơn vị.

1.2. Các thành phần cấu thành hệ thống thông tin

- Phần cứng (Hardware)

lOMoARcPSD|36667950

- Phần mềm (Software)

- Dữ liệu (Data)

- Quy trình xử lý (Process)

- Con người (People)

- Phân tích và thiết kế HTTT là công việc được thực hiện một cách có hệ thống

nhằm xây dựng mới or phát triển HTTT đã có, sao cho việc sử dụng các tài

nguyên của HTTT một cách hiệu quả nhất.

1.3. Tổ chức quản lý trong công ty và việc ra quyết định

- Cổ đông (Stackholder).

- Internal system user: người dùng nội bộ: giám sát, quản lý cấp trung, giám đốc

điều hành, nhân viên văn phòng, nhân viên dịch vụ.

- External system users: người dùng ngoài: KH, nhà cung cấp, đối tác, nhân viên:

nv bán hàng đại diện

lOMoARcPSD|36667950

- Ra quyết định: hành động nhằm thay đổi trạng thái hiện tại trạng thái mong

muốn. Có 2 yếu tố:

Tiêu chuẩn ra qđịnh.

Dữ liệu cần thu thập & quy trình xử lý.

- Các loại quyết định:

+ Quyết định có cấu trúc: 2 yếu tố rõ ràng, lập trình được trên PC tự

động hóa cao. VD: chuỗi các thủ tục đã được xác lập trước, có tính lặp đi lặp lại và theo

thông lệ. Các qđịnh số tiền thưởng theo doanh số bán hàng của các nhân viên bán hàng, qđịnh

khen thưởng sinh viên xếp loại xuất sắc, giỏi hàng năm

+ Qđịnh phi cấu trúc: 2 không rõ. Dựa vào cảm tính, kinh nghiệm, tác động

môi trường. Có thể lượng hóa được. VD bỏ phiếu, các qđịnh bổ nhiệm cán bộ, quyết

định mở ngành đào tạo mới, thiết lập một dây chuyền sản xuất mới…

+ Qđịnh bán cấu trúc: 1 trong 2 không rõ ràng, không thể lượng hóa.

VD: tung sp mới, căn cứ lợi nhuận, mức độ rủi ro, dự báo thị trg, quyết định mức chi khen thưởng

cho cán bộ có thành tích công tác tốt, cho sinh viên đạt kết quả học tập cao.

- Quản trị viên cấp cao: + Tổng thể

+ Kế hoạch dài hạn, tính chiến lược, tồn tại phát triển cty. VD: xđ thị trg thâm nhập. +

Qđịnh: Phi, bán cấu trúc

+ Thông tin: ngoài tầm kiểm soát cty: dự báo thị trg, đổi mới công nghệ…

- Quản trị viên cấp trung:

+ Kế hoạch trung hạn, tính chiến thuật mục tiêu kd. Vd phân phối nguồn tài

nguyên trong cty.

+ Qđịnh: Bán, có cấu trúc.

+ Thông tin: trong – 1 ít ngoài, chắc chắn, cụ thể.

- Quản trị viên cấp thấp:

+ Hđ hằng ngày.

+ Qđịnh: tính tác nghiệp sdụng hiệu quả nguồn tài nguyên. Vd kiểm soát tồn

kho, tín dụng, thuê xe…

+ Thông tin: Trong, chi tiết, chắc chắn.

- Nhân viên tác nghiệp, thừa hành:

+ Thực hiện cv được giao. Vd tiếp nhận nhập số liệu vào hệ thống.

+ Yêu cầu HTTT: vận hành dễ, nhanh, chính xác.

1.4. Phân loại hệ thống thông tin

lOMoARcPSD|36667950

- Trong sì lai ghi rõ lứm.

- Vấn đề tích hợp hệ thống:

+ Các HTTT trong đơn vị phải được phối hợp hoạt động với nhau.

+ Top-down: lý tưởng xây dựng hệ thống. Cần CIO hoạch định chiến lược

xây dựng HTTT từ đầu.

+ Bottom – up: tạo thành các ốc đảo thông tin

1.5. Vai trò, vị trí, kỹ năng của phân tích viên

- Phân tích viên hệ thống (System analyst): người chịu trách nhiệm chính trong việc phân tích

các nghiệp vụ, nhận ra các cơ hội để cải tiến, thiết kế và cài đặt hệ thống thông tin (HTTT) đạt

được mục tiêu trên. Để xây dựng hệ thống thành công, PTV cần hiểu rõ phương pháp luận,

nắm vững kỹ thuật và thực hiện một cách sáng tạo các bước trong quy trình phát triển hệ

thống

- Chuyên gia tư vấn (Consultant):

Tư vấn về phần cứng, phần mềm, chức năng, cơ sở kỹ thuật,… Các tư vấn

này phải phù hợp với các yêu cầu kỹ thuật của HT sắp xây dựng.

Là một chuyên gia trợ giúp (Support Expert):

Là người trung gian giữa khách hàng và lập trình viên, PTV hệ thống phải

giải đáp mọi thắc mắc từ cả 2 phía để có thể chuyển những yêu cầu

trong thế giới thực thành HTTT hoàn chỉnh.

Là tác nhân thay đổi (Agent of Change):

PTV có khả năng tác động để thay đổi quy trình vận hành nhằm đưa CNTT vào

ứng dụng cho đơn vị

1.6. Chu kỳ phát triển hệ thống (SDLC)

lOMoARcPSD|36667950

- Các giai đoạn của SDLC

Lập kế hoạch (Planning)

Tại sao phải xây dựng hệ thống? (Why)

Phân tích (Analysis)

Hệ thống cần phải làm những gì? (What). Và các câu hỏi Who, When,

Where liên quan?

Thiết kế (Design)

Làm thế nào để hệ thống hoạt động? (How)

Thi công (Implementation)

Lập trình, thử nghiệm

Vận hành và hỗ trợ (Operation and support) Đưa hệ thống

vào vận hành

- Xây dựng hệ thống thông tin sẽ trải qua nhiều giai đoạn (phase)

Mỗi giai đoạn thường sẽ bao gồm nhiều bước thực hiện (step)

Mỗi bước sẽ sử dụng các kỹ thuật (technique) khác nhau và

tạo ra kết quả cụ thể của bước đó (các bảng thiết kế, tài liệu,

chương trình, …)

Quá trình phân tích và thiết kế hệ thống bao gồm các công việc cần hoàn thành theo

trình tự nhất định có thể bao gồm các bước sau:

+ Xác định vấn đề, các yêu cầu quản lý hệ thống.

+ Xác định mục tiêu, ưu tiên, giải pháp sơ bộ và chứng minh tính khả thi.

+ Phân tích các chức năng và dữ liệu của hệ thống.

+ Thiết kế logic: Trả lời câu hỏi làm gì ? hoặc là gì ?. Phân tích sâu hơn các chức năng,

các dữ liệu của hoạt động cũ để đưa ra mô tả hoạt động mới.

+ Thiết kế vật lý: đưa ra những biện pháp, phương tiện thực hiện, nhằm trả lời câu hỏi:

Làm như thế nào ?.

+ Cài đặt hệ thống: Lựa chọn ngôn ngữ, hệ quản trị cơ sở dữ liệu và lập trình.

+ Khai thác và bảo trì.

1.7. Các kỹ thuật và công cụ phát triển hệ thống

lOMoARcPSD|36667950

- JAD (Joint Application Development): Kỹ thuật xây dựng nhóm cộng tác trong

phát triển ứng dụng, bao gồm nhiều thành viên thuộc nhiều lĩnh vực và cấp độ

quản lý.

- AD (Rapid Application Development): Kỹ thuật phát triển nhanh ứng dụng

+ Nổi lên từ những năm 1990s

+ Nhờ sự xuất hiện các công cụ hỗ trợ (CASE tools)

+ Các ngôn ngữ lập trình trực quan (visual) ngày càng mạnh mẽ

- CASE tools – Computer- Aided System Engineering

Là các công cụ hỗ trợ cho việc phát triển hệ thống ở nhiều mức độ khác nhau

Upper CASE tools: hỗ trợ việc mô hình hóa hệ thống và tạo ra thiết kế luận lý

cho hệ thống

Lower Case Tool: giúp sinh mã nguồn chương trình (codegenerator) từ các mô

hình luận lý → đẩy nhanh tốc độ phát triển hệ thống

Tất cả các thiết kế được lưu trữ trong một kho gọi là CASE repository

- Mô hình thác nước (Waterfall model): dự án nhỏ, 1 quy trình ổn định.

- Mô hình chữ V

- Mô hình Prototype: nhìu phiên bản (bản mẫu), 1 phiên bản giải quyết 1 số yc,

vấn đề phát sinh của bản trước. Rút 45% time.

Quy trình nghiệp vụ chưa ổn định Một prototype

phải có các đặc điểm:

Làm việc được trên các dữ liệu thực

Có thể phát triển thêm để tiến tới HT cuối cùng

Tạo lập nhanh và ít tốn kém

Dùng để kiểm chứng các giả định về các nhu cầu phải đáp ứng, các lược

đồ thiết kế và logic của chương trình.

Lợi ích của prototype:

Chính xác hóa các nhu cầu phải đáp ứng

Phát hiện các sai sót trong logic chương trình Đánh giá được

hiệu năng của hệ thống.

- Mô hình Throwaway Prototype.

- Mô hình tăng trưởng: phiên bản 1 là lõi, sau mỗi phiên bản được sử dụng, các kq

feedback sdung để lập kế hoạch cho chu trình con phiên bản tiếp theo. Chức

năng dần bổ sung vào.

- Mô hình xoắn ốc.

- Mô hình RUP.

lOMoARcPSD|36667950

- Agile: Phương pháp phát triển phần mềm linh hoạt. Hướng tiếp cận cụ thể cho

qly dự án phần mềm. Gồm: qtrình làm việc tương tác & tích hợp đưa sp đến KH

càng nhanh càng tốt.

- Scrum: là framework, là mô hình thực hiện để tạo ra được trạng thái Agile. Agile

là mindset

Minh bạch

Thanh tra

Thích nghi

- Scrum: team – Waterfall: 1 mình

- Agile: thay đổi, dự án chưa rõ, rủi ro - Waterfall: ko thay đổi, nhỏ, ngắn hạn, ko rủi ro

1.8. Các phương pháp luận phát triển hệ thống

- Một số phương pháp luận:

+ Các phương pháp hệ thống:

MERISE (H.Tardieu, A.Rochfeld 1976) + Các

phương pháp chức năng hay có cấu trúc: SADT

(douglas T.Ross, 1977)

+ Phương pháp hướng sự kiện

State Charts (D.Harel, 1987)

+ Các phương pháp hướng dữ liệu:

LCP, LCS (J.D.Warnier, 1969)

+ Các phương pháp hướng đối tượng:

OOAD (G.Booch, 1992-1993)

UML + RUP + Rational Rose (G.Booch, J.Rumbaugh, I.Jacobson 1997)

lOMoARcPSD|36667950

1.9. Phương pháp phân tích thiết kế hướng đối tượng

1.9.1.Thông tin – Một nguồn tài nguyên quan trọng

- Nhiên liệu kinh doanh có thể là yếu tố quan trọng trong việc quyết định sự thành bại của kinh

doanh.

- Cần được quản lý chính xác

- Quản lý thông tin do máy tính tạo ra khác với việc xử lý dữ liệu được tạo thủ công

1.9.2.Nhu cầu phân tích & thiết kế hệ thống

- Cài đặt hệ thống mà không có kế hoạch phù hợp dẫn đến sự không hài lòng cho phần lớn người

dùng và thường gây ra hệ thống tơi vào tình trạng không dùng được.

- Phân tích và thiết kế hệ thống tạo cấu trúc cho phân tích và thiết kế HTTT

- Sự tham gia của người dùng trong suốt 1 dự án hệ thống là quan trọng cho sự phát triển thành

công của hệ thống máy tính.

1.9.3.Vai trò nhà phân tích hệ thống

- Nhà phân tích phải có khả năng làm việc với mọi người của tất cả mô tả và có kinh nghiệm làm

việc với máy tính.

- 3 vai trò chính:

+ Tư vấn (Consultant)

+ Chuyên gia hỗ trợ (Supporting Expert)

+ Tác nhân thay đổi (Agent of change)

1.9.4.Phẩm chất của nhà phân tích hệ thống

- Người giải quyết vấn đề (Problem solver)

- Người giao tiếp (Communicator)

- Đạo đức nghề nghiệp và cá nhân mạnh mẽ (Professional ethics & strong personal)

- Tự kỷ luật và năng động (Self-disciplined & self-motivated)

1.9.5.Vòng đời phát triển hệ thống SDLC

- Vòng đời phát triển hệ thống SDLC là giai đoạn tiếp cận để giải quyết vấn đề kinh doanh

- Được phát triển thông qua việc sử dụng 1 chu trình cụ thể của hoạt động của người phân tích và

người dùng

- Mỗi giao đoạn có các hoạt động người dùng duy nhất

- SDLC là quy trình phát triển phần mềm: chất lượng cao nhất, chi phí thấp nhất trong thời gian

ngắn nhất có thể.

1.9.6.Bảy giai đoạn của hệ thống

Giai đo n 1:ạ Xác định vấn đề, cơ hội, mục tiêu

- Hoạt động:

+ Phỏng vấn quản lý người dùng

+ Tổng kế kiến thức thu được

+ Ước tính phạm vi dự án

lOMoARcPSD|36667950

+ Ghi lại kết quả

- Đầu ra:

+ Báo cáo khả thi bao gồm định nghĩa vấn đề và tóm tắt khách quan mà từ đó người quản lý

có thể đưa ra quyết định về việc có nên tiếp tục dự án được đề xuất không

Giai đo n 2:ạ Xác định yêu cầu thông tin con người

- Hoạt động:

+ Phỏng vấn

+ Lấy mẫu và đầu tư dữ liệu cứng

+ Bảng câu hỏi

+ Quan sát hành vi của người ra quyết định và môi trường

+ Tạo mẫu

+ Tìm hiểu ai, cái gì, ở đâu, khi nào, như thế nào, tại sao của hệ thống hiện tại.

- Đầu ra:

+ Nhà phân tích hiểu các người dùng thực hiện công việc khi tương tác với máy tính

+ Bắt đầu biết các làm hệ thống mới hữu ích và có thể sử dụng

+ Nhà phân tích nên biết chức năng doanh nghiệp

+ Co đầy đủ thông tin về con người, mục tiêu dữ liệu và thủ tục liên quan.

Giai đo n 3:ạ Phân tích nhu cầu hệ thống

lOMoARcPSD|36667950

- Hoạt động:

+ Tạo Sơ đồ DFD

+ Hoàn thiện từ điển dữ liệu

+ Phân tích các quyết định có cấu trúc được đưa ra

+ Chuẩn bị và trình bày đề xuất hệ thống

- Đầu ra:

+ Khuyến nghị về những gì, nếu có, nên được thực hiện

Giai đo n 4:ạ Thiết kế hệ thống (được đề xuất)

- Hoạt động:

+ Thiết kế quy trình nhập liệu chính xác

+ Thiết kế giao diện người-máy tính (HCI)

+ Tập tin thiết kế và/hoặc cơ sở dữ liệu

+ Thiết kế thủ tục dự phòng

- Đầu ra:

+ Mô hình hệ thống thực tế

Giai đo n 5:ạ Phát triển & lập tài liệu phần mềm.

- Hoạt động:

+ Nhà phân tích hệ thống làm việc với các lập trình viên để phát triển bất kỳ

+ phần mềm gốc

+ Làm việc với người dùng để phát triển tài liệu hiệu quả

+ Lập trình viên thiết kế, viết mã và loại bỏ các lỗi cú pháp khỏi chương trình máy tính

+ Tài liệu phần mềm với hướng dẫn thủ tục, trợ giúp trực tuyến,

+ Các câu hỏi thường gặp (FAQ) và tệp Read Me

- Đầu ra:

+ Chương trình máy tính

+ Tài liệu hệ thống

Giai đo n 6:ạ Thử và bảo trì hệ thống

- Hoạt động:

+ Kiểm thử hệ thống

+ Bảo trì hệ thống

+ Tài liệu bảo trì

- Đầu ra:

+ Vấn đề, nếu có

+ Cập nhật chương trình

+ Tài liệu

Giai đo n 7:ạ Triển khai & đánh giá hệ thống

- Hoạt động:

+ Đào tạo người dùng

+ Lập kế hoạch chuyển hệ thống cũ sang hệ thống mới

+ Rà soát và đánh giá hệ thống Đầu ra:

lOMoARcPSD|36667950

+ Nhân sự được đào tạo

+ Hệ thống được cài đặt

1.9.7.Tác động của bảo trì

- Bảo trì được thực hiện vì 2 lý do

+ Loại bỏ lỗi phần mềm, và

+ Nâng cao phần mềm hiện có

- Tăng cường phần mềm vì 3 lý do

+ Bao gồm các tính năng bổ sung do quy trình nghiệp vụ thay đổi. + Giải quyết các thay

đổi về kinh doanh theo thời gian + Giải quyết các thay đổi về phần cứng và phần mềm.

- Tác động bảo trì

+ Theo thời gian, chi phí bảo trì liên tục sẽ tăng lớn hơn việc tạo ra một hệ thống hoàn toàn

mới

+ Tại thời điểm đó, việc thực hiện một nghiên cứu hệ thống mới trở nên khả thi hơn

- Tiêu thụ tài nguyên trong vòng đời hệ thống:

1.9.8.Tiếp cận linh hoạt (Agile)

- Cách tiếp cận linh hoạt là một sự phát triển phần mềm cách tiếp cận dựa trên

+ Giá trị

+ Nguyên tắc

+ Thực tiễn cốt lõi

- Giá trị Agile:

+ Giao tiếp +

Đơn giản

+ Phản hồi

+ Can đảm

Cách tiếp cận linh hoạt:

lOMoARcPSD|36667950

+ Tương tác

+ Gia tăng

- Thường xuyên lặp tạo ra các version mới đầy đủ hơn là điều cần thiết cho phát triển hệ thống

thành công

- 5 giao đoạn quy trình phát triển mô hình Agile:

- Thăm dò

+ tập hợp các đội nhóm

+ đánh giá kỹ năng

+ tìm công nghệ tiền năng viết

+ Thử nghiệm viết user story

+ Có thái độ vui tươi và tò mò đối với công việc môi trường, các vấn đề, công nghệ và con người

- Lập kế hoạch

+ Các quy tắc có thể giúp hình thành sự phát triển nhanh mối quan hệ của nhóm với khách

hàng doanh nghiệp của họ

+ Tối đa hóa giá trị của hệ thống được tạo ra bởi đội Agile

+ Người chơi chính là nhóm phát triển và Khách hàng doanh nghiệp

- Lặp tới bản phát hành đầu tiên

+ Lặp lại là chu kỳ của

Thử nghiệm

Nhận xét

Thay đổi

+ Một mục tiêu là chạy thử nghiệm chức năng do khách hàng viết tại cuối mỗi lần lặp

- Sản xuất

+ Sản phẩm được tung ra trong giai đoạn này

+ Có thể được cải thiện bằng cách thêm các tính năng khác

- Duy trì

+ Các tính năng mới có thể được thêm vào

+ Các đề xuất của khách hàng rủi ro hơn có thể được xem xét

+ Các thành viên trong nhóm có thể được luân chuyển vào hoặc ra khỏi nhóm

1.9.9.Phương pháp phân tích thiết kế hướng đối tượng

- Cách tiếp cận thay thế cho cách tiếp cận có cấu trúc của SDLC nhằm mục đích tạo thuận lợi

cho sự phát triển của các hệ thống phải thay đổi nhanh chóng để đáp ứng với môi trường

kinh doanh năng động

- Sử dụng Ngôn ngữ mô hình hóa thống nhất (UML) để mô hình hóa các hệ thống hướng đối

tượng

- Mỗi đối tượng là một đại diện máy tính của một số thực tế sự vật hoặc sự kiện

- Các bước quá trình phát triển UML:

- Vẽ lược đồ Use case

Viết kịch bản use case

lOMoARcPSD|36667950

- Lấy Lược đồ hoạt động Activity Diagram từ Use case

- Phát triển lược đồ trình tự Sequence Diagram

- Tạo lược đồ lớp Class Diagram (Giai đoạn phân tích)

- Vẽ lược đồ tĩnh State chart Diagram (Giai đoạn phân tích) - Sửa đổi sơ đồ và thông số kỹ thuật

đầy đủ

- Phát triển và tài liệu hệ thống:

+ Thông tin bạn cung cấp càng đầy đủ cho nhóm phát triển thông qua tài liệu và sơ đồ UML,

sự phát triển càng nhanh và hệ thống sản xuất cuối cùng càng vững chắc

1.9.10. Định nghĩa mô hình use case

- Xác định các tác nhân và các sự kiện chính do các actor khởi xướng;- Vẽ Use case diagram

- Một sơ đồ với các hình que thể hiện các diễn viên và mũi tên chỉ cách các diễn viên liên quan.

- extend: có thể có

- include: bắt buộc

1.9.11. Vẽ UML Diagram

- Bắt đầu vẽ sơ đồ UML

- Vẽ sơ đồ hoạt động, trong đó minh họa tất cả các hoạt động chính trong ca sử dụng

- Tạo một hoặc nhiều Sequence Diagram cho mỗi trường hợp sử dụng hiển thị trình tự của

- hoạt động và thời gian của họ

- Xem lại các trường hợp sử dụng, suy nghĩ lại về chúng và sửa đổi chúng nếucần thiết.

Giai đoạn thiết kế:

Sửa đổi hệ thống đang có

Sửa đổi biểu đồ được vẽ ở giai đoạn trước

Viết thông số kỹ thuật lớp cho mỗi lớp

1.9.12. Chọn phương pháp phát triển

Tiếếp c n theo SDLCậ các h thốếng đã đệ ược phát tri n và ghi l i bằằng cách s d ng SDLCể

ạ ử ụ điếằu quan tr ng là ghi l i t ng bọ ạ

ừ ước c a quá trìnhủ

qu n lý cấếp trến c m thấếy tho i mái ho c an toàn h n khi s d ng S D L Cả

ả ả ặ ơ ử ụ có đ nguốằn l c và th i

gian đ hoàn thành S D L C đấằy đủ ự ờ ể ủ thống

tn liến l c vếằ cách th c ho t đ ng c a các h thốnế g m i là quan ạ ứ ạ

ộ ủ ệ ớ tr ngọ

Tiếếp c n theo Phậ ương có m t nhà vố đ ch d án vếằ các phộ ị ự ương pháp

linh ho t trong t ch cạ ổ ứ pháp Agile các ng d ng cấnằ đứ ụ ược phát tri n

nhanh chóng đ đáp ng nhu cấằu nằng ể ể ứ

đ ngộ mối

trường

Tiếếp cấn theo

hướng đốếi tượng

m t cu c gi i c u diếễn ra (h thốnế g b lốễi và khống có th i gian đ tm ra ộ

ộ ả ứ ệ ị ờ ể nguyến nhấn đã sai)

lOMoARcPSD|36667950

khách hàng hài

lòng v i nh ng c i tếnế

gia

tằngớ

ữ ả

giám đốcế điếằu

hành và nhà phấn

tch đốằng ý v i các nguyến tằcếớ c a ủ

phương pháp nhanh các vấnế đếằ được mố hình hóa

phù h p v i các l p h cợ ớ ớ ọ m t t ch c hốễ tr h c U M

Lộ ổ ứ ợ ọ

các h thốếng có th đệ ể ược thếm dấằn dấằn, mốễi lấằn m t h

thốếng conộ ệ có th s d ng l i phấằn mếằm đã viếết trể ử ụ ạ ước đó

gi i quyếết các vấến đế ằ khó trả ước có th chấếp nh n để ậ ược

1.9.13. Mã nguồn mỡ (OSS)

- Một thay thế cho phát triển phần mềm truyền thống

- Nhiều người dùng và lập trình viên có thể nghiên cứu, chia sẻ, và sửa đổi code (mã)

- Phần mềm mã nguồn mở là phần mềm với mã nguồn được công bố, với một giấy phép sử dụng

đi kèm, cho phép bất cứ ai cũng có thể sử dụng, nghiên cứu, thay đổi cải tiến phần mềm và phân

phối phần mềm ở dạng chưa thay đổi hoặc đã thay đổi.

1.10. Trắc nghiệm

1) Open Source software (OSS): Phần mềm được phân phối miễn phí cùng mã nguồn và cho phép

bất cứ ai được thay đổi.

2) UML: cách tiếp cận hướng đối tượng sử dụng chuẩn UML để mô hình hóa các hệ thống theo

hướng đối tượng.

3) Documentation: Cho người dùng biết cách sử dụng phần mềm và phải làm gì nếu sự cố phần

mềm xảy ra.

4) SDLC: Trong giai đoạn yêu cầu thông tin của SDLC, phân tích viên cố gắng hiểu những thông tin

mà người dùng cần để thực hiện công việc của họ.

5) Agent of change (Tác nhân thay đổi): Vai trò phù hợp của phân tích viên là tác nhân thay đổi.

6) Case respository: Một bách khoa toàn thư được sử dụng để lưu trữ tất cả thông tin trong dự án.

Chương 2: Mô hình hóa hệ thống

2.1. Mục tiêu

- Hiểu tổ chức và thành viên của họ là một hệ thống và những nhà phân tích cần có quan điểm hệ

thống.

- Dự đoán đồ họa hệ thống bằng cách dùng dữ liệu cấp độ ngữ cảnh, Sơ đồ DFD và mô hình mối

quan hệ thực thể kết hợp, Use case và kịch bản use case - Nhận ra các cấp độ quản lý khác

nhau yêu cầu các hệ thống khác nhau.

- Hiểu tác động của văn hóa tổ chức lên thiết kế hệ thống

2.2. Các tổ chức như hệ thống

- Được khái niệm hóa như là một hệ thống được thiết kế để hoàn thành mục tiêu đã định trước

và mục đích/ khách quan.

- Bao gồm những hệ thống nhỏ hơn có liên quan đến nhau ohujc vụ chức năng chuyên dụng.

lOMoARcPSD|36667950

- Các chức năng đặc biệt được khôi phục lại thành một tổng thể tổ chức có hiệu quả

2.2.1.Tính tương quan & tính độc lập của hệ thống

- Tất cả hệ thống và hệ thống con có tính tương quan và tính độc lập lẫn nhau

- Tất cả các quy trình hệ thống đầu vào từ môi trường của nó

- Tất cả hệ thống được lưu trữ ởi ranh giới chia chúng với môi trường của chúng

- Phản hồi hệ thống cho lập kế hoạch và điều khiển

- Một hệ thống lý tưởng tự điều chỉnh hoặc tự điều chỉnh nó

2.2.2.Đầu ra của hệ thống đóng vai trò phản hồi, so sánh hiệu suất với mục tiêu

2.2.3.Môi trường tổ chức

- Cộng đồng : vị trí vật lý, hồ sơ nhân khẩu học (giáo dục, thu nhập)

- Kinh tế: Nhân tố thị trường, đối thủ

- Chính trị: chính quyền tiểu bang và địa phương

- Luật pháp: luật và nguyên tắc liên bang, tiểu bang, khu vục, địa phương

2.2.4. Hệ thống ảo và nhóm ảo (Virtual)

- Một tổ chức ảo có những bộ phận tổ chức ở những địa điểm khác nhau.

- Mạng lưới máy tính và công nghệ giao tiếp được sử dụng để mang lại nhóm ảo làm việc cùng

nhau trong các dự án

2.2.5.Lợi ích của tổ chức ảo và nhóm ảo (Virtual)

- Khả năng làm giảm chi phí của cơ sở vật chất

- Phản hồi nhanh chóng hơn nhu cầu khách hàng

- Giúp nhân viên ảo hoàn thành nghĩa vụ gia đình với con cái hoặc cha mẹ già

2.2.6.Một quan điểm hệ thống (viễn cảnh)

- Cho phép nhà phân tích hiểu doanh nghiệp mà họ sẽ tiếp xúc

- Quan trọng rằng các thành viên của hệ thống con nhận ra rằng họ có mối tương quan với hệ

thống con khác

- Xảy ra vấn đè khi mỗi nhà quản lý nghĩ bộ phận mình là quan trọng nhất - Vấn đề lớn hơn

có thể xảy ra khi nhà quản lý đó thăng cấp - Output này là input cái khác, ngược lại.

lOMoARcPSD|36667950

2.2.7.Hoạch định nguồn lực doanh nghiệp ERP

- Enterprise Resource Planning (ERP) là một hệ thống thông tin tổ chức tích hợp

- Phần mềm giúp luồng thông tin giữa các khu vực chức năng trong tổ chức.

- Gần đây ERP đang chuyển sang đám mây tin học

- Vấn đề khắc phục để cài đặt ERP tuyên bố là thành công thành công:

+ Tính chấp nhận người dùng

+ Tích hợp hệ thống cũ và chuỗi cung ứng

+ Nâng cấp chức năng hoặc linh hoạt của mô hình ERP

+ Tái tổ chức cuộc sống công việc của người dùng và người ra quyết định

+ Mở rộng phạm vi tiếp cận vài tổ chức

+ Chiến lược tái định vị của công ty

2.3. Đồ họa mô tả hệ thống : DFD, ERP, Use case diagram and kịch bản

- Sơ đồ dữ liệu mức ngữ cảnh DFD

1) Tập trung vào luồng dữ liệu đầu váo và ra của hệ thống và quy trình xử lí của dữ liệu.

2) Thể hiện phạm vi của hệ thống

3) Những gì bao gồm trong hệ thống

4) Thực thể ngoài nằm ngoài phạm vi hệ thống

5) Quá trình là những hành động và nhóm hành động

6) Thực thể là 1 người, nhóm, bộ phận hoặc hệ thống nhận hoặc bắt nguồn thông tin or dữ

liệu data.

7) 4 ký hiệu cơ bản:

o Quy trình xử lý (process)

Bi u diếnễ cống vi c x lý d li u trong h thốnế g (ể ệ ử ữ ệ ệ

Data processing) biếnế d ữ li u đấuằ vào input thành đấuằ ra output. ệ

Mốễi process ph i có ít nhấtế m t dòng d li u vào và 1 dòng d li u ả

ộ ữ ệ ữ ệ ra

D li u đấằu ra ph i ữ ệ ả khác n i dung ho c d ng th cộ ặ ạ

ứ c a d li u đấằu ủ ữ ệ vào

Trong DFD, process nh 1 ư h p đen, không thấấy các chi tếất x lý bến

trong.ộ ử Chi tếết x lý đử ược trình bày trong phấằn đ c t quá trình (PS –

Process ặ ả

lOMoARcPSD|36667950

Speci 昀椀 caton)

Ký hi uệ : Hình ch nh t tròn bo góc ( hình tròn) ữ ậ

+ Mốễi process có m t sốế nh n d ng ộ

ậ ạ (ID) + Tến process : bằtế

đấuằ là 1 Đ ng tộ ừ

o Dòng dữ liệu (data flow)

Bi u diếnễ để ường đi c a d li u, thành phấằn này đếến thành phấằn khác

ủ ữ ệ Ký hi u: ệ

+ Đường thằằng có mũi tến 1 đấằu (th hi n chiếằu di chuy n d li u)ể ệ

ể ữ ệ

+ Mốễi dòng d li u có 1 mã sốế nh n d ng (khi dùng CASE tool) ữ ệ ậ ạ

+ Tến dòng d li u nến là: ữ ệ Danh từ - th hi n n i dung d li u di chuy n trến

ể ệ ộ ữ ệ ể đó.

Ghi chú:

+ Ký hi u mũi tến hai đấằu ch dòng d li u có th di chuy n c 2 chiếằu, v i ệ ở ỉ

ữ ệ ể ể ả ớ cấấu trúc d li u bến trong giôấng nhauữ ệ . Điếuằ này thường ch

x y ra v i các ỉ ả ớ dòng d li u ra vào kho d li u.ữ ệ ữ ệ

+ Tến dòng d li u ữ ệ không nến đ t trùng nhauặ đ tránh nhấằm lấễn khi mố t t

ể ả ừ đi n d li u sau nàyể ữ ệ

+ Tấtế c các dòng d li u đếằu ph i có tến.ả ữ ệ ả

+ Có th khống ghi tến cho các dòng d li u ra vào kho d li u (vì n i dung ể ữ ệ

ữ ệ ộ trến các dòng này giốếng nh n i dung trong các kho)ư ộ

o Kho dữ liệu (data store)

Bi u diếễn ển i l u trơ ưữ d li u, đ các process khác nhau trong h thốếng s d ng.ữ ệ ể ệ

ử ụ

Kho d li uữ ệ sau này seễ đBi u diếnễ đốếi tểược thiếết kếế đ chuy n thành ượểng nằmằể ngoài h

thốếng. c s d li uệơ ở ữ ệ c a h thốnế gủ ệ

Ký hi u:ệ Đốếi tượng có tương tác, cung cấpế d li u, nh n kếết qu t h thốnế g.ữ ệ ậ

ả ừ ệ

Hình ch nh t m m t đấằu bến ph i (ho c 2 đữ ậTh c th ngo i: con ngựở

ểộ ạ ảười, t ch c, h thốếng khácặổ ứường song song)ệ Mốễi kho d li

u có m t sốế nh n d ng ữ ệTh c th ngo i = tác nhấn đấuằ cuốếi (ự ểộ ạ

ậ ạ (ID) Terminator)

Tến kho d li u: ữ ệ+ Th c th ngo i cung cấếp d li u: danh tự ểừ - th hi n n i dung l u tr trong khoạể

ệ ộữ ệ ư Source (nguôồn)ữ

+ Th c th ngo i nh n d li u: ự ể ạ ậ ữ ệ Sink (đích)

+ Có th v a là source và sink ể ừ

Ký hi uệ : Hình ch nh t ữ ậ

+ Tến th c th ngo iự ể ạ : Danh từ mố t đốếi tả ượng

+ Được veễ l i nhiếuằ lấằn, tránh các dòng d li u cằết nhau (dấếu g ch chéạ

ữ ệ ạ o góc ở hình ch nh t)ữ ậ

o Thực thể ngoài (external entity)

lOMoARcPSD|36667950

o Lỗi: sai về khái niệm, sai về process, sai về liên kết các thành phần.

Sai vềề khái nim

Thc th ngoi phi là các tác nhân

có kh năng trao đi d liu

(

thông tn) vi h thôống.

Process mô t

mt công vic, mt chc năng

x lý d liu, không mô

t v trí thc hin công vic đó

Dòng d liu và kho d liu mô t vềề mt

d liu (data) di chuyn và

lu tr

trong h thôống, không mô t vềề mt vt châtố (material)

lOMoARcPSD|36667950

- Các bước xây dựng Sơ đồ DFD:

1) Từ các tài liệu nghiệp vụ xác định các thực thể ngoại, các kho dữ liệu cần lưu trữ, các

chức năng của hệ thống, các dòng dữ liệu quan trọng

2) Xây dựng sơ đồ ngữ cảnh (context diagram)

- Cho ta cái nhìn tổng quát về môi trường làm việc của hệ thống → còn gọi là sơ đồ môi

trường.

Sai vềề Process

Process

ch có dòng d liu ra

, không có dòng d

liu vào → process

t phát sinh

(spontaneous genaraton)

Process

ch có dòng d liu vào

, không có dòng d liu ra

→

lôỗ đen

(black hole)

Các dòng d liu vào ca mt process

không đ

đ to các dòng d

liu ra →

lôỗ xám

(gray hole)

Sai vếằ liến kếết các thành phấằn

Không đ

c có dòng d liu trc tềpố gia

thc th ngoi và thc

th ngoi.

Không đ

c có dòng d liu trc tềpố gia

kho d liu và kho d liu

→ thềm process x lý vào gia.

Không đ

c có dòng d liu trc tềpố gia

thc th ngoi và kho d

liu

→ thềm process x lý vào

lOMoARcPSD|36667950

- Toàn bộ hệ thống được nhìn như một hộp đen → biểu diễn bằng một process (đánh số

- Tất cả các thực thể ngoại đều xuất hiện trong sơ đồ này → không được phép vẽ thêm

các thực thể ngoại mới trong các sơ đồ ở các mức sau/

- Tất cả các dòng dữ liệu trao đổi giữa hệ thống với thực thể ngoại- Trong sơ đồ ngữ

cảnh không có kho dữ liệu

- Một số quy ước:

Toàn bộ sơ đồ ngữ cảnh phải nằm trọn trên một trang giấy

Tên của process trong sơ đồ ngữ cảnh nên là tên của hệ thống Tên của thực thể

ngoại và tên các dòng dữ liệu nên ngắn gọn, dễ hiểu

Các dòng dữ liệu không được cắt nhau

3) Xây dựng sơ đồ DFD mức 0 (level 0)

- Sơ đồ mức 0 là sự phân rã của sơ đồ ngữ cảnh → là sơ đồ con (child diagram) của sơ

đồ ngữ cảnh. Để xem xét chi tiết hơn nội dung bên trong của sơ đồ ngữ cảnh.

- Trong sơ đồ mức 0 sẽ chỉ ra các quy trình xử lý chính, các dòng dữ liệu trao đổi giữa

các quy trình này, và các kho dữ liệu dùng chung giữa chúng.

- Sơ đồ mức 0 cần thể hiện lại đầy đủ các thực thể ngoại và các dòng dữ liệu đã xuất

hiện trong sơ đồ ngữ cảnh.

- Một số vấn đề cần lưu ý:

Mỗi process trong sơ đồ mức 0 sẽ được đánh số ID lần lượt là 1, 2, 3,

…

Mỗi process ở mức này tương ứng với một chức năng lớn trong hệ thống (thường

tương ứng với mức trên của sơ đồ FHD)

- Kho dữ liệu (trong mức 0): Là các kho lưu dữ liệu dùng chung cho các chức năng khác

nhau trong hệ thống.

- Các lỗi sai thường gặp:

Kho dữ liệu chỉ có dòng vào mà không có dòng ra, hoặc chỉ có dòng ra mà không có

dòng vào

Kho dữ liệu chỉ có một process sử dụng nên chuyển thành kho nội bộ của process.

- Dòng dữ liệu phân kỳ (Diverging data flow):

+ Dòng dữ liệu trên đó chứa cùng một loại dữnliệu và được chuyển đến cho nhiều vị

trí khác nhau trong sơ đồ.

+ Về nguyên tắc: không được 1 dòng dữ liệu mà dữ liệu trên đó được tách thành

nhiều dòng với các nội dung khác nhau để chuyển đến các nơi khác nhau

lOMoARcPSD|36667950

+ Ký hiệu bổ sung (có thể được dùng ở một số ng)

- Dòng dữ liệu hội tụ (converging data flow)

+ Về nguyên tắc: không có 1 dòng được tạo từ nhiều dòng.

+ Ký hiệu bổ sung (thay vì dùng process kết hợp 3 dòng)

4) Xây dựng sơ đồ DFD ở các mức chi tiết

- Chi tiết hóa các quá trình còn mang tính tổng quát, chưa thể dùng để thiết kế thành các

thành phần trong chương trình như: form, report, …

- Quy tắc:

ID của process trong sơ đồ con sẽ bao gồm ID của sơ đồ cha + số thứ tự của process

trong sơ đồ con

VD: Khi phân rã process 2, thì các process trong sơ đồ con sẽ được đánh số là 2.1, 2.2, 2.3, …

- Mỗi sơ đồ DFD (kể cả mức 0) chỉ nên có từ 7 – 9 process, và vẽ trên một trang giấy

- Tính phân mức (leveling):

+ Là quá trình tăng dần mức độ chi tiết trong các sơ đồ ở mức thấp hơn cho đến khi

đạt được mức chi tiết mong muốn, tức là tất cả các process trong sơ đồ đều là

nguyên tố (primitive process)

lOMoARcPSD|36667950

+ Process nguyên tố là process chỉ còn bao gồm một chức năng cụ thể, không thể tiếp

tục phân rã được nữa. Process này có thể chuyển giao để lập trình viên viết

chương trình.

+ Cần tổ chức sơ đồ tránh tình trạng một process phân rã quá sâu trong khi các process

khác thì việc phân rã lại dừng rất sớm.

- Tính cân bằng (balancing):

+ Khi phân rã phải đảm bảo sự nhất quán giữa các sơ đồ

+ Các dòng dữ liệu vào và dòng dữ liệu ra của sơ đồ cha phải được bảo toàn trong

sơ đồ con.

Kho dữ liệu có thể xuất hiện trong sơ đồ con mà không cần xuất hiện trước đó trong sơ

đồ cha. Đây là trường hợp các kho dữ liệu cục bộ, chỉ có các process trong sơ đồ con sử

dụng mà thôi.

5) Kiểm tra sơ đồ ở các cấp để phát hiện lỗi

6) Xây dựng sơ đồ DFD vật lý (physical DFD) từ sơ đồ DFD luận lý (logical DFD)

Đ c đi m thiếết kếếặ ể Logical (Lu n lý)ậ

Physical (V t lý)ậ

Mố hình mô tả Ho t đ ng nghi p v nh thếế

nàoạ ộ ệ

ụ ư H

thốếng seễ cài đ t / đang ệ

ặ v n hành nh thếế

nàoậ ư

Process (th hi nể ệ )Ho t đ ng nghi p vạ ộ ệ

ụChương trình, module, và

các th t c x lý th cốngủ ụ

ử ủ

Data store Các lo i d li u trong h thốếng, ạ ữ ệ ệ

Các t p tn v t lý và CSDLậ ậ

Không quan tấm cách l u trưữ

Lo i data storeạ Các d li u l u tr ữ ệ ư ữ lấu dài trong h ệ T p tn chính, t

p tn giao ậ ậ thốếng d ch,…ị

Ki m soát h ể ệ Ki m soát vếằ nghi p vể ệ ụ Ki m soát all: tnh h p l

ể ợ ệ thốếng d li u đấuằ vào, b o m t ữ ệ ả ậ

h thốếng. ệ

7) Phân hoạch (partitioning) sơ đồ DFD vật lý

- Mô hình thực thể kết hợp

+ Tập trung vào các thực thể và mối quan hệ trong hệ thống tổ chức.

+ Một cách khác thể hiện phạm vi hệ thống.

+ Mối quan hệ thể hiện cách các thực thể kết nối. 3 loại mqh: 1-1, 1-n, nn

+ Thực thể:

o Fundamental entity (Thực thể): Đối tượng dữ liệu cơ bản o Associative

entity (Liên kết): Kết hợp 2 thực thể

lOMoARcPSD|36667950

o Attributive entity (Thuộc tính): Mô tả thuộc tính, đặc biệt lặp nhóm. Thuộc

tính có thể thêm vào diagram.

+ Tạo Sơ đồ thực thể kết hợp:

o liệt kê các thực thể trong tổ chức

o chọn khóa các thực thể để hạn chế phạm vi vấn đề o nhận diện khóa chính

của thực thể o xác nhận kết qủa trên thông qua thu thập dữ liệu

- Mô hình Use case:

+ Mô hình Use case Modeling:

o Một phần của ngôn ngữ mô hình hóa thống nhất (UML) o Mô tả những gì hệ

thống làm mà không có mô tả cách thức hoạt động của hệ thống.

o Xem các yêu cầu hệ thống

o Nhà phân tích làm việc với các chuyên gia kinh doanh để phát triển

+ Use case Diagram:

o Tác nhân:

Đếằ c p t i vai trò c th ngậ ớ ụ ể ười dùng = th c th ngoài, bến ngoài h thốếng.

ự ể ở ệ Chia 2 nhóm actor:

Primary actors:

+ Cung cấpế d li u ho c nh n thống tn t h thốếng ữ ệ ặ

ậ ừ ệ

+ Cung cấpế thống tn chi tếtế vếằ vi c use case nến làm ệ

Supportng actors: Người điếằu hành b ph n help, nhà phấn tch,l p trình viếnộ

ậ ậ + Giúp duy trì ho t đ ng h thốếng ho c cung cấpế tr giúpạ

ộ ệ ặ ợ

o Ký hiệu Use case: Hình bầu dục - nhiệm vụ của use case o Đường nối: Mũi tên

và đường dùng để vẽ sơ đồ hành vi các mối quan hệ

o Use case cung cấp 3 thứ:

M t tác nhấn bắất đấồu s ki nộ ự ệ

S ki n kích ho t Use caseự ệ ạ

Use case th c hi n các hành đ ng kích ho t (trigger) b i s kiến ự ệ ộ

ạ ở ự

o Mối quan hệ Use case:

Mốếi Giao tếếp: Dùng đ kếết nốếi 1 tác nhấn v i 1 Use caseể ớ quan

hệ Bao gốmằ: Mố t tnh huốếng trong đó có 1 use case ch a hành vi ả

ứ

hành vi ph biếnế h n 1 use caseổ ơ

M r ng (ở ộ Extends): Mố t tnh huốnế g 1 Use case s h u có hành vi

ả ở ữ cho phép Use case m i đ x lý biếến th ho c ngo i l t Use case ớ

ể ử ể ặ ạ ệ ừ c b nơ ả

Khái quát hóa (generalizes): 1 cái đi n hình h n cái khácể ơ

4 lo i ạ

mqh – đường

lOMoARcPSD|36667950

Giao tếấp

M t actor kếết nốếi v i 1 use case (khống mũi tến)ộ ớ

Bao gôồm (bắất bu c

có)ộ M t Use case ch a các hành vi chung nhiếằu Use case khác,

mũi tếnộ ứ ch vào Use case chungỉ

M r ng (k bắất bu c)ở ộ

ộ M t use case khác x lý các ngo i l t Use case c b n (mũi tến

ộ ử ạ ệ ừ ơ ả t m r ng đếnế Use case gốếc/ c b n)ừ ở ộ ơ ả

khái quát hóa M t th

UML t ng quát h n 1 th khác. Mũi tến ch điếằu t ng ộ ứ ổ ơ ứ ỉ

ổ quát

o Phát triển phạm vi hệ thống

Ph m vi h thốếng xác đ nh ranh gi i c a nó:ạ ệ ị ớ ủ

▪ N i dung bến trong ho c bến ngoài h thốếngộ ặ ệ

▪ D án có ngấn sách giúp xác đ nh ph m viự ị ạ

D án có th i đi m bằết đấằu và kếết thúc▪ ự ờ ể

▪ Tác nhấn luốn nằằm ngoài ph m viạ

▪ Đường dấy liến l c là ranh gi i và xác đ nh ph m viạ ớ ị ạ

o Phát triển sơ đồ Use case

Xem xét các thông sôấ kyỹ thu tậ kinh doanh và xác đ nh các tác nhấn tham giaị

Xác đ nh các s ki n cấếp cao và phát tri n các trị ự ệ ể ường h p s d ng chính

mốợ ử ụ t các s ki n đó và cách các diếễn viến bằết đấằu chúngả ự ệ Xem l i t ng

trạ ừ ường h p s d ng chính đ xác đ nh các biếến th có th có c aợ ử ụ ể ị ể ể ủ

luốằng thống qua trường h p s d ngợ ử ụ

S đốằ DFD m c ng c nh có th ho t đ ng làm ơ ứ ữ ả ể ạ ộ đi m kh i đấồuể ở đ t o

trể ạ ường h p s d ngợ ử ụ

o Phát triển kịch bản Use case: 3 lĩnh lực chính

lOMoARcPSD|36667950

o Lợi ích dùng Use case:

Xác định tất cả các tác nhân trong miền vấn đề

Các hành động cần hoàn thành cũng được thể hiện rõ ràng trên sơ đồ Use case

▪ Kịch bản Use case đáng giá

Đơn giản và thiếu chi tiết kỹ thuật

Những lý do chính để viết các ca sử dụng là tính hiệu quả của chúng trong

Giao tiếp với người dùng và nắm bắt câu chuyện của người dùng

▪ Các Use case sử dụng truyền đạt các yêu cầu hệ thống một cách hiệu quả

bởi vì các sơ đồ được giữ đơn giản.

▪ Các Use case sử dụng cho phép mọi người kể chuyện. ▪ Câu chuyện Use case

có ý nghĩa đối với những người không có kỹ thuật.

▪ Các Use case sử dụng không phụ thuộc vào một ngôn ngữ đặc biệt.

▪ Các Use case sử dụng có thể mô tả hầu hết các yêu cầu chức năng (chẳng hạn

như tương tác giữa các tác nhân và ứng dụng). ▪ Ca sử dụng có thể mô tả các

yêu cầu phi chức năng (chẳng hạn như hiệu suất và khả năng bảo trì) thông qua

việc sử dụng khuôn mẫu.

▪ Các Use case sử dụng giúp nhà phân tích xác định ranh giới.

▪ Các Use case sử dụng có thể được theo dõi, cho phép các nhà phân tích xác

định các liên kết giữa các Use case sử dụng và các công cụ tài liệu và thiết kế

khác.

2.3.1.Phân tích bottom-up

- Một số phân tích viên sử dụng chiến lược bottom-up. nhận diện tất cả các process nguyên tố,

các kho dữ liệu, các dòng dữ liệu và các thực thể ngoại.

- Sau đó ta sẽ nhóm các thành phần có quan hệ lại với nhau để tạo thành cácsơ đồ ở mức thấp.

- Tiếp tục nhóm các sơ đồ mức thấp lại để tạo dần thành các sơ đồ mức cao hơn.

Đnh danh

và

bắất đấồu

use

case

Khu vc tếu đếằ Use Case

Có tến và ID duy nhấtế

Bao gốằm lĩnh vc ng dng

Lit kế tác nhấn

ệ

Bao gốằm các bến liến quan

Bao gốằm mc đ

Có mố t ngằến gn vếằ ca s dng

Các b

thc hin

ệ

S dng các cấu chuyn linh hot, xác đnh vấến đếằmc tếu,

ệ

i dùng hoc mt tnh nằngdanh sách

yếu cấằu ca ng

Hi vế ằnhng cống vic phi làm

ệ

Xác đnh xem có bấết kỳ s lp li hochành đng lp

Ca s dng kếết thúc khi mc tếu ca khách hàng hoàn tấết

Điếồu kin, gi

đnh, cấu hi

lOMoARcPSD|36667950

- quy trình này được tiếp tục thực hiện cho đến khi ta đạt được mức 0, rồi mức ngữ cảnh.

2.4. Kiểm soát hoạt động

- ▪ Đưa ra quyết định sử dụng các quy tắc được xác định trước có kết quả dự đoán được

- ▪ Giám sát chi tiết hoạt động của tổ chức

- Lập kế hoạch quản lý và kiểm soát

+ ▪ Lập kế hoạch và kiểm soát ngắn hạn quyết định về tài nguyên và mục tiêu tổ chức

+ ▪ Các quyết định có thể mang tính tác nghiệp một phần và một phần chiến lược

- Quản lý chiến lược:

+ ▪ Hướng ngoại từ tổ chức đến tương lai

+ ▪ Đưa ra các quyết định hướng dẫn cấp trung và quản lý hoạt động

+ ▪ Làm việc trong tình trạng ra quyết định rất không chắc chắn môi trường

+ ▪ Đối mặt với các vấn đề bán cấu trúc

+ ▪ Xác định toàn bộ tổ chức

- Các cấp quản lý: hoạt động, quản lý cấp trung, chiến lược

+ Cơ cấu tổ chức khác nhau

+ ▪ Phong cách lãnh đạo

+ ▪ Cân nhắc về công nghệ

+ ▪ Văn hóa tổ chức

+ ▪ Tương tác của con người

+ ▪ Tất cả đều mang hàm ý cho việc phân tích và thiết kế hệ thống thông tin

- Hợp tác thiết kế

+ ▪ Các bên liên quan bên ngoài và bên trong tuân theo các quy trình để chia sẻ trong việc

thiết kế một hệ thống để đáp ứng mục tiêu của họ

+ ▪ Trao quyền lực cho những người sở hữu huyên môn kỹ thuật hoặc chiến lược

2.5. Văn hóa tổ chức

- Tổ chức có văn hóa và nhóm văn hóa

- ▪ Học từ ngôn ngữ và biểu tượng phi ngôn ngữ.

- Tác động của công nghệ đến văn hóa

+ ▪ Công nghệ đang thay đổi văn hóa của tổ chức và nhóm

+ ▪ Slack là một mạng xã hội được nhà tuyển dụng chấp nhận nền tảng truyền thông hoặc

ứng dụng nhắn tin tại nơi làm việc

+ ▪ Các kênh công khai và riêng tư

+ ▪ Tin nhắn trực tiếp hoặc nhóm

Chương 3: Thu thập thông tin

3.1. Phỏng vấn

3.1.1.Chuẩn bị phỏng vấn

- Thiết lập mục tiêu phỏng vấn

- Chuẩn bị cho người được phỏng vấn

- Đọc tài liệu nền

- Quyết định ai sẽ phỏng vấn

lOMoARcPSD|36667950

- Quyết định loại câu hỏi và cấu trúc

3.1.2.Loại câu hỏi

- Câu hỏi mở: cho phép người được phỏng vấn để trả lời như thế nào họ muốn mà không cần

quan tâm chiều rộng và chiều sâu của câu trả lời Ý kiến của bạn về tình hình kinh doanh hiện tại?

kinh doanh thương mại điện tử trong công ty của bạn?

Các mục tiêu quan trọng của bộ phận của bạn là gì?

Mô tả quy trình giám sát có sẵn trực tuyến

Những thất vọng lớn nhất mà bạn đã trải qua trong quá trình chuyển đổi sang thương

mại điện tử là gì?

Một số lỗi nhập dữ liệu phổ biến được thực hiện trong bộ phận này?

Sau khi dữ liệu được gửi qua trang web, chúng được xử lý như thế nào?

+ Ưu/ nhược câu hỏi mở

Ưu đi mể Nhược đi mể

Khiếến người được ph ng vấnế c m thấếy tho i ỏ ả ả Có th dấnễ

đếnế quá nhiếằu chi tếết khống liến ể

mái quan

▪ Cho phép người ph ng vấến tếếp thu t v ngỏ ừ ự ▪ Có th mấết ki m soát cu c ph ng

vấếnể ể ộ ỏ c a ngủ ười được ph ng vấếnỏ

▪ Cung cấếp s phong phú vếằ chi tếếtự ▪ Có th mấết quá nhiếằu th i gian cho lể ờ

ượng thống tn h u ích thu đữ ược

Tiếết l nh ng hộ ữướng đ t cấu h i tếếp theo có ặ ỏ▪ Có v nh ngẻ ư

ười ph ng vấến ch a chu n b ỏ ưẩ ị

th ch a để ư ược khai thác trước

Cung cấếp thếm s quan tấm cho ngựười được ▪ Có th t o ấến tể ạượng rằằng người ph ng vấến

ỏ

ph ng vấnếỏ đang trong m t “cu c thám hi m cấu cá”ộ

ộ ể

▪ Cho phép t phát h nự ơ

- Câu hỏi đóng: thích hợp khi nhà phân tích quan tâm đến là độ rộng và độ sâu của câu trả lời

+ Giới hạn số lượng câu trả lời có thể

+ Tạo dữ liệu đáng tin cậy dễ phân tích

+ Phương pháp hiệu quả và yêu cầu 1 ít kỹ năng cho phỏng vấn để quản lý o Kho lưu trữ dự án

được cập nhật bao nhiêu lần một tuần? o ▪ Trung bình mỗi tháng tổng đài nhận

được bao nhiêu cuộc gọi? o ▪ Nguồn thông tin nào sau đây có giá trị nhất đối với

bạn? o ▪ Mẫu đơn khiếu nại của khách hàng đã hoàn thành o ▪ Gửi email khiếu

nại từ người tiêu dùng truy cập trang web o ▪ Tương tác trực tiếp với khách hàng

o ▪ Hàng bị trả lại

o ▪ Liệt kê hai ưu tiên hàng đầu của bạn để cải thiện cơ sở hạ tầng công nghệ.

Giúp cho ng

i phng vấến có th diếễn đt

ể

dếễ dàng hn

Hu ích nếếu ng

i phng vấến khống chun

b tr

lOMoARcPSD|36667950

o ▪ Ai nhận thông tin đầu vào này?

+ Ưu/ Nhược

Ưu đi mể Nhược đi mể

Tiếết ki m th i gian ph ng vấếnệ ờ ỏ Có th

gấy nhàm chán cho ngểười được ph ngỏ

vấến

Dếễ dàng so sánh các cu c ph ng vấếnộ ỏ ▪ Có th khống thu để ược

nhiếằu chi tếết

Nhanh chóng đi th ng vào vấến đếằẳ ▪ Có th b sót m t sốế ý chínhể ỏ ộ

Duy trì ki m soát cu c ph ng vấnếể ộ ỏ ▪ Có th khống xấy d ng để ự ược mốếi quan h ệ gi a ngữ

ười ph ng vấếnỏ

Bao ph m t khu v c r ng l n m t cách ủ ộ ự ộ ớ ộ

nhanh chóng

Lấyế d li u liến quanữ ệ

- Các thuộc tính của câu hỏi mở và câu hỏi đóng: độ tin cậy, hiệu

- Câu hỏi lưỡng cực: (Bipolar)

+ Trả lời với Yes / No hoặc Đồng ý / Không đồng ý

+ Dùng hạn chế

+ Dạng

- Câu hỏi thăm dò (Probes)

+ Mở ra nhiều chi tiết cho câu hỏi trước

+ Mục đích: Để có thêm ý nghĩa,

Làm rõ,

Rút ra và mở rộng quan điểm của người được phỏng vấn

+ Có thể là mở hoặc đóng

câu hỏi đóng đặc biệt

lOMoARcPSD|36667950

3.1.3.Sắp xếp câu hỏi

- Kim tự tháp:

+ Bắt đầu với câu hỏi đóng và hướng đến câu hỏi mở

+ Bắt đầu với những câu hỏi rất chi tiết, thường đóng

+ ▪ Mở rộng bằng cách cho phép các câu hỏi mở và phản ứng tổng quát hơn nữa

+ ▪ Sẽ hữu ích nếu người được phỏng vấn cần được làm quen với chủ đề hoặc có vẻ miễn

cưỡng để giải quyết chủ đề

- Ống phễu:

+ Mở -> đóng

+ Bắt đầu với những câu hỏi mở, tổng quát

+ ▪ Kết luận bằng cách thu hẹp các câu trả lời có thể sử dụng câu hỏi đóng

+ ▪ Cung cấp một cách dễ dàng, không nguy hiểm để bắt đầu một phỏng vấn

+ ▪ Hữu ích khi người được phỏng vấn cảm thấy xúc động về chủ đề

- Kim cương

+ Đóng -> mở -> đóng

+ Một cấu trúc hình kim cương bắt đầu theo một cách rất cụ thể

+ ▪ Sau đó, các vấn đề tổng quát hơn sẽ được xem xét

+ ▪ Kết luận bằng những câu hỏi cụ thể

+ ▪ Kết hợp sức mạnh của cả kim tự tháp và phễu cấu trúc

+ ▪ Mất nhiều thời gian hơn các công trình khác

3.1.4.Báo cáo phỏng vấn

- Kết thúc cuộc phỏng vấn

+ ▪ Luôn hỏi “Có điều gì khác mà bạn muốn thêm vào?"

+ ▪ Tóm tắt và cung cấp phản hồi về ấn tượng của bạn

+ ▪ Hỏi xem bạn nên nói chuyện với ai tiếp theo + ▪ Thiết lập

bất kỳ cuộc hẹn nào trong tương lai + ▪ Cảm ơn họ đã dành

thời gian và bắt tay.

- Báo cáo phỏng vấn

+ ▪ Viết càng sớm càng tốt sau cuộc phỏng vấn

+ ▪ Cung cấp tóm tắt ban đầu, sau đó chi tiết hơn

+ ▪ Xem xét báo cáo với người trả lời

3.2. Câu chuyện của người dùng

- Những câu chuyện

+ ▪ Chuyện bắt nguồn nơi công sở

+ ▪ Các câu chuyện về tổ chức được sử dụng để chuyển tiếp một số loại thông tin

+ ▪ Khi một câu chuyện được kể đi kể lại theo thời gian, nó mang hơi hướng tính thần thoại.

+ ▪ Những câu chuyện biệt lập rất tốt khi bạn đang tìm kiếm sự thật

+ ▪ Những câu chuyện lâu dài nắm bắt tất cả các khía cạnh của tổ chức và là những thứ mà một

nhà phân tích hệ thống nên tìm kiếm

- Nghe kể chuyện

+ ▪ Nghe kể chuyện không hiệu quả

+ ▪ Tốn nhiều thời gian hơn so với đặt câu hỏi phỏng vấn

lOMoARcPSD|36667950

+ ▪ Nghe kể chuyện có thể bổ ích hơn

+ ▪ Các câu chuyện dễ nhớ hơn các câu trả lời phỏng vấn

- Tất cả các câu chuyện đều có những yếu tố sau:

+ ▪ Kêu gọi phiêu lưu

+ ▪ Nhiệm vụ

+ ▪ Cuộc đấu tranh

+ ▪ Sự chuyển đổi

+ ▪ Nghị quyết

+ ▪ Đạo đức

+ ▪ Phần kết

- Lý do kể chuyện

+ ▪ Bản thân thông tin phong phú từ việc lắng nghe cẩn thận các câu chuyện đã có giá trị

+ ▪ Thông tin thu thập được từ các câu chuyện sẽ có ý nghĩa hơn và có giá trị hơn nếu được đặt

trong bối cảnh

- Câu chuyện kinh doanh có thể được chia thành 4 loại chính quan trọng:

+ ▪ Câu chuyện trải nghiệm

+ ▪ Truyện thuyết minh

+ ▪ Xác thực các câu chuyện

+ ▪ Chuyện kê đơn

- Câu chuyện và Tổ chức

+ ▪ Thu hút những người tham gia tổ chức bằng cách phản ứng lại các câu chuyện

+ ▪ Nối câu chuyện này với câu chuyện khác bằng cách kể lại cho những người tham gia khác

nghe và cộng tác với các câu chuyện

+ ▪ Đó là cách hiểu sâu sắc một số vấn đề liên quan đến hệ thống thông tin

- Có bốn mục đích để kể một câu chuyện:

+ ▪ Các câu chuyện trải nghiệm mô tả doanh nghiệp hoặc ngành đó như thế nào

+ ▪ Các câu chuyện giải thích cho biết tại sao tổ chức lại hành động theo một cách nhất định

+ ▪ Các câu chuyện xác thực được sử dụng để thuyết phục mọi người rằng tổ chức đã đưa ra

quyết định đúng đắn

+ ▪ Những câu chuyện có tính quy định cho người nghe biết cách hành động

+ ▪ Các nhà phân tích hệ thống có thể sử dụng kể chuyện để bổ sung cho các phương pháp thu

thập thông tin khác

3.3. Thiết kế ứng dụng chung (JAD)

3.3.1. Sự tham gia

- Thiết kế ứng dụng chung (JAD) có thể thay thế một loạt các cuộc phỏng vấn với cộng đồng người

dùng

- JAD là một kỹ thuật cho phép nhà phân tích thực hiện phân tích yêu cầu và thiết kế giao diện

người dùng với người dùng trong cài đặt nhóm

- Các điều kiện hỗ trợ việc sử dụng JAD

+ ▪ Người dùng bồn chồn và muốn một cái gì đó mới

+ ▪ Văn hóa tổ chức hỗ trợ các hành vi chung giải quyết vấn đề

+ ▪ Các nhà phân tích dự báo số lượng ý tưởng sử dụng JAD sẽ tăng lên

lOMoARcPSD|36667950

+ ▪ Nhân viên có thể vắng mặt trong thời gian yêu cầu

- ▪ Những người liên quan là:

+ ▪ Nhà tài trợ điều hành

+ ▪ Nhà phân tích IS

+ ▪ Người dùng

+ ▪ Trưởng phiên

+ ▪ Người quan sát

+ ▪ Người ghi chép

3.3.2. Địa điểm

- Tổ chức các cuộc họp JAD ở đâu

+ ▪ Ngoại vi

+ ▪ Môi trường xung quanh thoải mái

+ ▪ Giảm thiểu phiền nhiễu

+ ▪ Điểm danh

+ ▪ Lịch trình khi người tham gia có thể tham dự

+ ▪ Chương trình nghị sự

+ ▪ Họp định hướng

- Lợi ích/ hạn chế của JAD:

L i ích ợ H n chếếạ

Tiếết ki m th i gian so v i ph ng vấến truyếằnệ ờ ớ ỏ ▪ JAD yếu

cấằu m t kho ng th i gian l n ộ ả ờ ớ thốếng đ sằễn sàng cho tấết

cể ả

Phát tri n nhanh các h thốnế gể ệ người tham gia phiến

C i thi n quyếằn s h u c a ngả ệ ởữ ủ ười dùng đốếi

▪ Nếếu vi c chu n b ho c báo cáo tếpế ệ ẩ ịặ

v i h thốếngớ ệ theo khống đấyằ đ ,ủ

S n xuấết ý tả ưởng sáng t o đạ ược c i ả phiến có th khống thành cốngể thi nệ

3.4. Bảng câu hỏi

3.4.1.Viết câu hỏi

- Bảng câu hỏi rất hữu ích trong việc thu thập thông tin từ các thành viên chủ chốt của tổ chức về:

+ ▪ Thái độ

+ ▪ Niềm tin

+ ▪ Hành vi

+ ▪ Đặc điểm

- Lập kế hoạch sử dụng bảng câu hỏi

+ ▪ Thành viên tổ chức phân tán rộng rãi

+ ▪ Nhiều thành viên tham gia dự án

+ ▪ Công việc thăm dò là cần thiết

+ ▪ Cần giải quyết vấn đề trước khi phỏng vấn

lOMoARcPSD|36667950

- Các loại câu hỏi (2/2))

+ Câu hỏi mở

▪ Cố gắng lường trước câu trả lời mà bạn sẽ nhận được

▪ Rất thích hợp để lấy ý kiến

+ Câu hỏi đóng

▪ Sử dụng khi tất cả các tùy chọn có thể được liệt kê

▪ Khi các quyền chọn loại trừ lẫn nhau

- Đánh đổi giữa việc sử dụng câu hỏi mở và câu hỏi đóng trên bảng câu hỏi

- Ngôn ngữ bảng câu hỏi

+ ▪ Đơn giản

+ ▪ Cụ thể

+ ▪ Ngắn gọn

+ ▪ Không bề trên

+ ▪ Không thiên vị

+ ▪ Dành cho những người hiểu biết

+ ▪ Chính xác về mặt kỹ thuật

+ ▪ Phù hợp với trình độ đọc của người trả lời

3.4.2.Sử dụng thang đo

Hai hình thức thang đo lường khác nhau là:

- ▪ Thang đo Danh nghĩa

+ Thang đo danh nghĩa dùng để phân loại sự vật

+ ▪ Đây là hình thức đo lường yếu nhất

+ ▪ Dữ liệu có thể được tính tổng . Nam nữ,

B n s d ng lo i phấằn mếằm nào nhiếằu nhấết?ạ ử ụ ạ

1 = B x lý vằn b nộ ử ả

2 = B ng tnhả

3 = C s d li uơ ở ữ ệ

4 = M t chộ ương trình email

- ▪ Thang đo Khoảng thời gian

+ ▪ Thang đo khoảng được sử dụng khi các khoảng bằng nhau

+ ▪ Không có số 0 tuyệt đối

lOMoARcPSD|36667950

+ ▪ Ví dụ về thang đo quãng bao gồm Fahrenheit hoặc thang độ C.

- Tính hợp lệ và độ tin cậy:

+ Độ tin cậy của thang đo đề cập đến tính nhất quán trong phản hồi—thu được kết

quả giống nhau nếu cùng một bảng câu hỏi được thực hiện lại trong cùng điều

kiện

+ Giá trị là mức độ mà câu hỏi đo lường những gì nhà phân tích dự định đo lường

- Vấn đề với Thang đo Khoan dung (Leniency)

+ ▪ Do người đánh giá dễ dãi

+ ▪ Giải pháp là chuyển danh mục “trung bình” sang bên trái hoặc bên phải của trung tâm

Xu hướng tập trung (central tendency) o ▪ Xu hướng tập trung xảy ra khi người trả lời đánh giá

mọi thứ ở mức trung bình

o ▪ Cải thiện bằng cách thu nhỏ sự khác biệt ở hai kết thúc

o ▪ Điều chỉnh độ mạnh của các bộ mô tả o ▪ Tạo thang điểm với nhiều

điểm hơn Hiệu ứng hào quang (Halo effect)

+ Khi ấn tượng được hình thành trong một câu hỏi chuyển thành câu hỏi tiếp theo

+ Giải pháp là đặt một đặc điểm và một số mục trên mỗi trang

3.4.3.Thiết kế

- Thiết kế bảng câu hỏi

+ ▪ Cho phép có nhiều khoảng trắng

+ ▪ Dành nhiều không gian để viết hoặc nhập câu trả lời

+ ▪ Giúp người trả lời dễ dàng đánh dấu rõ ràng câu trả lời của họ

+ ▪ Nhất quán về phong cách

- Thứ tự câu hỏi

+ ▪ Đặt những câu hỏi quan trọng nhất lên đầu tiên

+ ▪ Nhóm các mục có nội dung tương tự lại với nhau

+ ▪ Giới thiệu những câu hỏi ít gây tranh cãi trước

3.4.4.Quản lý / Quản trị

- Quản lý bảng câu hỏi có hai câu hỏi chính:

+ ▪ Ai trong tổ chức sẽ nhận được bảng câu hỏi

+ ▪ Nên thực hiện bảng câu hỏi như thế nào - Thiết kế

một trang web khảo sát:

lOMoARcPSD|36667950

- Gửi bảng câu hỏi điện tử:

+ ▪ Giảm chi phí

+ ▪ Thu thập và lưu trữ kết quả điện tử

3.5. Phương pháp kín đáo

phương pháp không phô trương

Ít gây rối hơn

Phân tích văn bản để phân tích dữ liệu định tính

Không đủ khi sử dụng một mình

Tiếp cận đa phương pháp

Dùng kết hợp với các phương pháp tương tác

3.6. Lấy mẫu

- Lấy mẫu: Một quá trình lựa chọn một cách có hệ thống các yếu tố đại diện của dân số liên quan

đến 2 quyết định chính:

+ Kiểm tra gì?

+ Những người cần xem xét

+ Lấy mẫu giúp đẩy nhanh quá trình bằng cách thu thập dữ liệu được chọn thay vì tất cả dữ

liệu cho toàn bộ dân số

+ Nhà phân tích hệ thống không phải chịu gánh nặng phân tích dữ liệu từ toàn bộ dân số

- Lý do các nhà phân tích hệ thống thực hiện lấy mẫu là để

+ Kiềm chế chi phí

+ Tăng tốc độ thu thập dữ liệu

+ Nâng cao hiệu quả

lOMoARcPSD|36667950

+ Có thể giảm sai lệch thu thập dữ liệu bằng cách lấy mẫu

+ Quá tốn kém để

+ Kiểm tra từng mẩu giấy

+ Nói chuyện với mọi người

+ Đọc mọi trang Web từ tổ chức

- Hiệu quả lấy mẫu

Lấy mẫu có thể giúp nâng cao hiệu quả nếu thông tin đó là chính xác hơn có thể thu

được

Điều này được thực hiện bằng cách nói chuyện với ít nhân viên hơn nhưng hỏi họ

những câu hỏi chi tiết hơn

Nếu ít người được phỏng vấn hơn, nhà phân tích hệ thống có nhiều thời gian hơn để

theo dõi dữ liệu bị thiếu hoặc không đầy đủ

- Xu hướng lấy mẫu

+ Có thể giảm sai lệch thu thập dữ liệu bằng cách lấy mẫu

+ Khi nhà phân tích hệ thống hỏi ý kiến về một tính năng cố định của hệ thống thông tin đã

cài đặt, người điều hành được phỏng vấn có thể đưa ra đánh giá thiên vị vì có rất ít khả

năng thay đổi nó.

- Để thiết kế một mẫu tốt, nhà phân tích hệ thống phải tuân theo 4 bước:

+ Xác định dữ liệu sẽ được thu thập hoặc mô tả

+ Xác định quần thể lấy mẫu

+ Chọn loại mẫu + Quyết

định cỡ mẫu - 4 loại mẫu

chính:

Sự tiện lợi

Mẫu thuận tiện là mẫu không giới hạn, phi xác suất

Mẫu này dễ sắp xếp nhất

Mẫu không đáng tin cậy nhất

Mục đích

Mẫu có mục đích dựa trên phán đoán

Chọn một nhóm các cá nhân có vẻ hiểu biết và quan tâm đến hệ thống thông tin mới

Mẫu phi xác suất

Chỉ có độ tin cậy vừa phải

Ngẫu nhiên đơn giản

Mẫu ngẫu nhiên phức tạp: phù hợp nhất cho nhà phân tích hệ thống là

Lấy mẫu hệ thống

Lấy mẫu phân tầng

Lấy mẫu theo cụm

- Quyết định cỡ mẫu

Xác định thuộc tính

Định vị cơ sở dữ liệu hoặc báo cáo trong đó có thể tìm thấy thuộc tính

Kiểm tra thuộc tính

Đưa ra quyết định chủ quan về ước tính khoảng chấp nhận được Chọn mức độ tin cậy

Tính sai số chuẩn

lOMoARcPSD|36667950

Xác định cỡ mẫu

3.7. Phân tích tài liệu định lượng

- Điều tra: Hành động khám phá và phân tích dữ liệu - Dữ liệu cứng:

+ Định lượng

+ Định tính

- Phân tích tài liệu định lượng

+ Các báo cáo dùng để ra quyết định o Báo

cáo bán hàng o Báo cáo sản xuất o

Báo cáo tổng hợp

o Báo cáo hiệu suất cho thấy sự cải thiện

o Hoàn thành thủ công o Biên nhận thanh toán

+ Báo cáo hiệu suất

+ Hồ sơ

o Hồ sơ cung cấp thông tin cập nhật định kỳ về những gì đang diễn

ra trong doanh nghiệp

o Có một số cách để kiểm tra hồ sơ:

Kiểm tra sai sót về số tiền và tổng số

Tìm kiếm cơ hội cải tiến thiết kế biểu mẫu ghi chép

Quan sát số lượng và loại giao dịch

Theo dõi các trường hợp máy tính có thể đơn giản hóa công việc (tính toán

và thao tác dữ liệu khác)

+ Biểu mẫu thu thập dữ liệu o Thu thập các ví dụ về tất cả các biểu mẫu đang được sử

dụng o Lưu ý loại biểu mẫu o Ghi lại mô hình phân phối dự định

o So sánh mẫu phân phối dự định với người thực sự nhận

mẫu

o Biểu mẫu thu thập dữ liệu o Các câu hỏi để hỏi về Official và Bootleg o Biểu

mẫu đã được điền

Các cấu h i đ h i vếằ các bi u mấễuỏ ể ỏ ể

Bi u mấễu đã đểược điếằn đấằy đ ch a?ủ ư

Có nh ng mấễu đ n nào khống bao gi đữ ơ ờ ượ ử ục s d ng

khống?

Tấtế c các b n sao c a các bi u mấễu có đả ả

ủ ể ược chuy n ể đếến đúng người

ho c đặ ượ ộc n p m t cách thích h p ộ ợ khống?

Ki m tra quyếằn và liến kếtế bi u mấễu ho t đ ng.ể

ể ạ ộ Nh ng ngữ ười ph i truy c p các bi u mấễu tr c

tuyếến ả ậ ể ự có th làm nh v y khống?ể ư ậ

lOMoARcPSD|36667950

Nếếu có m t bi u mấễu giấếy độ ể ược cung

cấếp thay thếế cho bi u mấễu d a trến Web, hãy so sánh

t l hoàn ể ự ỷ ệ thành c a c hai.ủ ả

Các bi u mấễu “khống chính th c” có để ứ ượ ử ục s d

ng thường xuyến khống?

+ Thương mại điện tử và các giao dịch khác

3.8. Phân tích tài liệu định tính

- Phân tích tài liệu định tính

Các phép ẩn dụ chính hoặc hướng dẫn

Tâm lý người trong cuộc và người ngoài cuộc

Điều gì được coi là thiện và ác

Đồ họa, logo và biểu tượng trong các khu vực chung hoặc trang web

Có khiếu hài hướcPhân tích

Tin nhắn email

Bản ghi nhớ

Dấu hiệu hoặc áp phích trên bảng thông báo

Các trang web của công ty (lưu ý tính tương tác của các trang web)

Sách hướng dẫn

Sổ tay chính sách

Phân tích các bản ghi nhớ cung cấp cái nhìn sâu sắc về các phép ẩn dụ hướng dẫn suy nghĩ của tổ chức

3.9. Phân tích văn bản

- Phân tích văn bản

+ Phần mềm có thể phân tích dữ liệu định tính phi cấu trúc từ bất kỳ nguồn nào bao gồm:

+ Bảng điểm các cuộc phỏng vấn

+ Báo cáo bằng văn bản

+ Thông tin liên lạc của khách hàng được thu thập qua email, wiki, blog, phòng trò chuyện và các

trang mạng xã hội khác

+ Dữ liệu phi cấu trúc, định tính hoặc “mềm” được tạo ra bởi vì:

o Blog

o Các phòng chat

o Bảng câu hỏi sử dụng câu hỏi mở o Các cuộc thảo luận trực tuyến được thực hiện trên

Web o Trao đổi xảy ra trên phương tiện truyền thông xã hội

+ Phân tích văn bản cung cấp thông tin chi tiết cho các thành viên của tổ chức, những người muốn

có một cách tiếp cận nhanh chóng và trực quan nhưng mang tính chất quyết định để phân tích

dữ liệu văn bản

lOMoARcPSD|36667950

+ Một yếu tố quan trọng là thiết kế các hoạt động của con người xung quanh việc sử dụng phần

mềm phân tích văn bản

- Lợi ích: giúp, có thể nhận ra những hiểu biết có giá trị về

+ Khách hàng đang nghĩ gì về tổ chức, các giá trị và hành động của công ty

+ Động cơ của khách hàng hoặc nhà cung cấp để bắt đầu, duy trì, cải thiện hoặc chấm dứt mối quan

hệ

3.10. Quan sát

- Quan sát cung cấp cái nhìn sâu sắc về những gì các thành viên tổ chức thực sự làm

- Tận mắt chứng kiến các mối quan hệ tồn tại giữa những người ra quyết định và các thành viên

khác của tổ chức

- Cũng có thể tiết lộ những manh mối quan trọng liên quan đến HCI

- Playscript của nhà phân tích

+ Liên quan đến việc quan sát hành vi của những người ra quyết định và ghi lại hành động của họ

bằng cách sử dụng một loạt các động từ hành động + Ví dụ: o Đang nói o Lấy mẫu o Tương ứng

o Quyết định

3.11. STROBE

- STROBE: QUAN SÁT MÔI TRƯỜNG CÓ CẤU TRÚC—một kỹ thuật quan sát môi trường vật chất

của người ra quyết định.

- Thông thường, có thể quan sát các chi tiết cụ thể của môi trường xung quanh sẽ xác nhận hoặc

phủ nhận tường thuật về tổ chức

+ Còn gọi là truyện hay đối thoại

+ Thông tin được tìm thấy thông qua phỏng vấn hoặc bảng câu hỏi

- yếu tố STROBE

+ Địa điểm văn phòng

+ Vị trí bàn làm việc

+ Thiết bị văn phòng phẩm

+ Đạo cụ

+ Nguồn thông tin bên ngoài

+ Ánh sáng và màu sắc văn phòng

+ Quần áo của những người ra quyết định

- Bảy yếu tố có thể quan sát cụ thể của STROBE

lOMoARcPSD|36667950

- STROBE và đặc điểm của người ra quyết định

3.12. Áp dụng STROBE

- 5 biểu tượng được sử dụng để đánh giá cách quan sát các yếu tố của STROBE so với kết quả

phỏng vấn là:

Dấu kiểm có nghĩa là tường thuật được xác nhận

Dấu “X” có nghĩa là câu chuyện bị đảo ngược

Biểu tượng hình bầu dục hoặc hình con mắt đóng vai trò gợi ý để nhìn xa hơn

Một hình vuông có nghĩa là quan sát sửa đổi tường thuật

Hình tròn có nghĩa là câu chuyện được bổ sung bằng quan sát

Chương 4: Sơ đồ dòng dữ liệu DFD

4.1. Sơ đồ DFD

Đặc trưng bằng đồ họa các quy trình và luồng dữ liệu trong một hệ thống kinh doanh

Miêu tả:

+ Đầu vào hệ thống

lOMoARcPSD|36667950

+ Đầu ra

+ Quy trình

- Ưu điểm của phương pháp tiếp cận luồng dữ liệu

+ Tự do cam kết thực hiện kỹ thuật quá sớm

+ Hiểu biết về mối quan hệ tương hỗ của các hệ thống và hệ thống con

+ Phân tích hệ thống đề xuất

+ Truyền đạt kiến thức hệ thống hiện tại cho người dùng

- Ký hiệu cơ bản

• Một hình vuông đôi cho một thực thể bên ngoài

• Một hình chữ nhật với các góc tròn để xuất hiện một quá trình biến đổi

• Một hình chữ nhật mở cho kho lưu trữ dữ liệu

• Mũi tên để di chuyển dữ liệu từ điểm này sang điểm khác

- Thực thể bên ngoài

Đại diện cho một bộ phận khác, một doanh nghiệp, một người hoặc một cái

máy

Nguồn hoặc đích của dữ liệu, bên ngoài ranh giới của hệ thống

Nên đặt tên bằng danh từ

- Dòng dữ liệu

Biểu thị dữ liệu về một người, địa điểm hoặc sự vật

Được miêu tả bằng danh từ

Đầu mũi tên chỉ hướng dòng chảy

Hiển thị chuyển động của dữ liệu từ điểm này sang điểm khác

- Quá trình

+ Thể hiện công việc đang được thực hiện trong hệ thống + Biểu thị sự

thay đổi hoặc chuyển đổi dữ liệu + Quy ước đặt tên:

Để đặt tên cho một hệ thống con chính, hãy đính kèm từ hệ thống con theo

tên

Sử dụng dạng động từ-tính từ-danh từ cho chi tiết quy trình Gán tên của

cả hệ thống khi đặt tên cho một quy trình cấp cao

- Kho dữ liệu:

Nơi lưu trữ dữ liệu cho phép kiểm tra, bổ sung, và truy xuất dữ liệu

Đặt tên bằng danh từ, mô tả dữ liệu

Kho lưu trữ dữ liệu thường được cấp một số tham chiếu duy nhất, chẳng hạn

như D1, D2, D3 Đại diện cho:

Tủ hồ sơ

Hồ sơ vi tính hóa

Cơ sở dữ liệu

- Các bước phát triển Sơ đồ DFD

Phát triển Sơ đồ DFD bằng cách tiếp cận từ trên xuống

1. Lập danh sách các hoạt động kinh doanh và sử dụng danh sách đó để xác định các hoạt động

khác nhau

– Kho lưu trữ dữ liệu

lOMoARcPSD|36667950

– Luồng dữ liệu

– Thực thể bên ngoài

– Quy trình

2. Tạo sơ đồ ngữ cảnh hiển thị các thực thể bên ngoài và luồng dữ liệu đến vàđi từ hệ thống.

Không hiển thị bất kỳ quy trình chi tiết hoặc kho lưu trữ dữ liệu nào.

3. Vẽ Sơ đồ 0, cấp độ tiếp theo.

Hiển thị các quy trình, nhưng giữ cho chúng chung chung.

Hiển thị các kho lưu trữ dữ liệu ở cấp độ này.

4. Tạo sơ đồ con cho từng quy trình trong Sơ đồ 0.

5. Kiểm tra lỗi và đảm bảo nhãn bạn gán cho mỗi quy trình và luồng dữ liệu có ý nghĩa.

6. Xây dựng Sơ đồ DFD vật lý từ luồng dữ liệu logic biểu đồ. Phân biệt giữa các quy trình thủ

công và tự động, mô tả các tệp và báo cáo thực tế theo tên và thêm các điều khiển để cho

biết khi nào các quy trình hoàn tất hoặc xảy ra lỗi.

7. Phân vùng Sơ đồ DFD vật lý bằng cách tách hoặc nhóm cácphần của sơ đồ để thuận tiện cho

việc lập trình và triển khai.

4.2. Tạo sơ đồ ngữ cảnh

Quá trình đánh số 0

Mức cao nhất trong Sơ đồ DFD

Tất cả các thực thể bên ngoài, cũng như các luồng dữ liệu chính được thể hiện

Chỉ chứa một quy trình, đại diện cho toàn bộ hệ thống

- Quy tắc cơ bản

Kho lưu trữ dữ liệu phải được kết nối với ít nhất một quy trình

Sơ đồ DFD phải có một quy trình

Các thực thể bên ngoài không được kết nối với nhau

Không được là bất kỳ đối tượng độc lập nào

Một quy trình phải có cả luồng dữ liệu đầu vào và đầu ra

- Vẽ sơ đồ 0

Bao gồm các kho lưu trữ dữ liệu chính và tất cả các thực thể bên ngoài

Sự bùng nổ của biểu đồ ngữ cảnh

Mỗi quy trình được đánh số

Có thể bao gồm tối đa chín quy trình

Bắt đầu với luồng dữ liệu từ một thực thể ở phía đầu vào

Phân tích một quy trình được xác định rõ ràng

Kiểm tra luồng dữ liệu đến hoặc từ kho lưu trữ dữ liệu

Ghi lại bất kỳ vùng mờ nào

Làm việc ngược từ luồng dữ liệu đầu ra

lOMoARcPSD|36667950

4.3. Các mức Sơ đồ DFD

Số sơ đồ mức thấp hơn giống như số quy trình gốc.

Cấp cao nhất là cấp ngữ cảnh.

Các quy trình không tạo sơ đồ con được gọi là nguyên thủy.

Mỗi quy trình có thể bùng nổ ở mức thấp hơn.

Sơ đồ DFD được xây dựng theo lớp.

- Tạo sơ đồ con

+ Mỗi quy trình trên sơ đồ 0 có thể được tách rời để tạo ra một sơ đồ con

+ Sơ đồ con không thể tạo đầu ra hoặc nhận đầu vào, quy trình cha mẹ cũng không tạo hoặc

nhận

+ Quy trình con được cấp cùng số với quy trình cha mẹ: Quy trình 3 sẽ chuyển sang Sơ đồ 3

+ Các thực thể thường không được hiển thị trên sơ đồ con bên dưới Sơ đồ 0

+ Nếu quy trình cha có luồng dữ liệu kết nối với kho dữ liệu, sơ đồ con có thể bao gồm kho lưu

trữ dữ liệu như vậy

+ Khi một quá trình chưa bùng nổ, nó được gọi là quá trình nguyên thủy

- Sơ đồ DFD Tóm tắt lỗi

+ Kết nối trực tiếp các kho lưu trữ dữ liệu và các thực thể bên ngoài với nhau

+ Quên đưa luồng dữ liệu vào hoặc quên trỏ mũi tên vào

+ Ghi sai nhãn quy trình hoặc luồng dữ liệu

+ Tạo ra sự phân hủy (hoặc bùng nổ) không cân bằng trong

+ Bỏ qua luồng dữ liệu

+ Bao gồm hơn 9 quy trình trên một sơ đồ DFD.

+ Tạo ra sự phân hủy (hoặc bùng nổ) không cân bằng trong sơ đồ con.

4.4. Sơ đồ DFD logic và vật lý

4.4.1.Logical

- Tập trung vào công việc kinh doanh và cách thức kinh doanh vận hành

- Không quan tâm hệ thống sẽ xây dựng như thế nào

- Mô tả các sự kiện kinh doanh diễn ra và dữ liệu được yêu cầu và tạo ra bởi mỗi sự kiện

4.4.2. Physical

- Cho biết hệ thống sẽ được triển khai như thế nào

- Mô tả hệ thống

4.4.3.Các tính năng phổ biến của Biểu đồ DFD logic và vật lý

lOMoARcPSD|36667950

Sự phát triển mô hình Logic sang vật lý

4.4.4.Phát triển sơ đồ DFD logic

- Giao tiếp tốt hơn với người dùng

- Hệ thống ổn định hơn

- Các nhà phân tích hiểu rõ hơn về doanh nghiệp

- Linh hoạt và bảo trì

- Loại bỏ dư thừa và dễ dàng tạo ra các mô hình vật lý

lOMoARcPSD|36667950

4.4.5.Phát triển Sơ đồ DFD vật lý

Làm rõ quy trình nào được thực hiện bởi con người và quy trình nào được tự động hóa

Mô tả quy trình chi tiết hơn

Trình tự các quy trình phải được thực hiện theo một thứ tự cụ thể

Xác định kho lưu trữ dữ liệu tạm thời

Chỉ định tên thực của tệp và bản in

Bổ sung các biện pháp kiểm soát để đảm bảo các quy trình được thực hiện đúng cách

- Nội dung của Sơ đồ DFD vật lý (không có trên sơ đồ DFD logic)

+ Quy trình thủ công

+ Quy trình thêm, xóa, thay đổi, cập nhật hồ sơ

+ Quy trình nhập và xác minh dữ liệu

+ Quy trình xác thực để đảm bảo dữ liệu đầu vào chính xác

+ Trình tự các quy trình để sắp xếp lại thứ tự hồ sơ

+ Các quy trình để tạo ra mọi đầu ra hệ thống duy nhất

+ Kho dữ liệu trung gian

+ Tên tập tin thực tế được sử dụng để lưu trữ dữ liệu

+ Điều khiển để biểu thị việc hoàn thành nhiệm vụ hoặc tình trạng lỗi

4.5. Ma trận CRUD

- Từ viết tắt CRUD thường được sử dụng cho

+ Tạo nên

+ Đọc

+ Cập nhật

+ Xóa bỏ

Đây là những hoạt động phải có trong một hệ thống đối với mỗi tệp chính

Ma trận CRUD là một công cụ để biểu diễn nơi mỗi quá trình này xảy ra trong một hệ thống

- Mô hình sự kiện ma trận CRUD :

4.6. Mô hình sự kiện và sơ đồ DFD

Luồng đầu vào từ một thực thể bên ngoài đôi khi được gọi là yếu tố kích hoạt vì nó bắt đầu các

hoạt động của một quy trình

Các sự kiện khiến hệ thống thực hiện một hành động nào đó và hoạt động như một tác nhân

kích hoạt hệ thống

Một cách tiếp cận để tạo Sơ đồ DFD vật lý là tạo một đoạn Sơ đồ DFD cho từng sự kiện hệ thống

duy nhất.

lOMoARcPSD|36667950

4.7. Bảng phản hồi sự kiện

Bảng sự kiện được sử dụng để tạo Sơ đồ DFD bằng cách phân tích từng sự kiện và dữ liệu do sự

kiện sử dụng và tạo ra

Mỗi hàng trong bảng sự kiện đại diện cho một đoạn Sơ đồ DFD và được sử dụng để tạo một quy

trình đơn lẻ trên Sơ đồ DFD

4.8. Sơ đồ Use case và sơ đồ DFD

Mỗi ca sử dụng xác định một hoạt động và kích hoạt của nó, đầu vào và đầu ra

Cho phép nhà phân tích làm việc với người dùng để hiểu bản chất của các quy trình và hoạt

động và sau đó tạo ra một mảnh Sơ đồ DFD duy nhất

4.9. Sơ đồ DFD phân vùng

Phân vùng là quá trình kiểm tra luồng dữ liệu sơ đồ và xác định làm thế nào nó nên được chia

thành bộ sưu tập các thủ tục thủ công và các chương trình máy tính.

Một đường đứt nét được vẽ xung quanh một quá trình hoặc một nhóm các các quy trình nên

được đặt trong một chương trình máy tính duy nhất.

4.9.1.Lý do phân vùng Các nhóm

người dùng khác nhau

Thời gian

Nhiệm vụ tương tự

Hiệu quả

Tính nhất quán của dữ liệu

4.9.2.Trang web phân vùng bảo mật Cải thiện

cách con người sử dụng trang web

Cải thiện tốc độ xử lý

Dễ bảo trì trang web

Giữ giao dịch an toàn

4.10. Giao tiếp bằng Sơ đồ DFD

Sử dụng sớm Sơ đồ DFD chưa giải mã khi xác định yêu cầu thông tin

Nhãn có ý nghĩa cho tất cả các thành phần dữ liệu

CHƯƠNG 7: PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG HƯỚNG ĐỐI

TƯỢNG BẰNG UML

1. Khái niệm, chức năng

UML là ngôn ngữ mô hình hóa thống nhất bao gồm những ký hiệu hình học dùng

mô hình hóa trong phương pháp hướng đối tượng.

• UML dùng để:

lOMoARcPSD|36667950

• Trực quan hóa (Visualizing)

• Đăc tả (Specifying)

• Xây dựng (Constructing)

• Lập tài liệu (Documenting)

• UML còn được dùng làm công cụ giao tiếp giữa người dùng, nhà phân tích,nhà

thiết kế và nhà phát triển phần mềm.

2. Các sơ đồ

a) UML 1.x có 9 loại Sơ đồ:

1. Sơ đồ Use case (Use Case Diagram)

2. Sơ đồ lớp (Class Diagram)

3. Sơ đồ đối tượng (Object Diagram)

4. Sơ đồ trạng thái (State Diagram)

5. Sơ đồ trình tự (Sequence Diagram)

6. Sơ đồ cộng tác (Collaboration Diagram)

7. Sơ đồ hoạt động (Activity Diagram)

8. Sơ đồ thành phần (Component Diagram) 9. Sơ đồ triển khai (Deployment

Diagram)

b) UML 2.0 có 13 loại Sơ đồ:

Thêm các sơ đồ:

• Sơ đồ gói (Package Diagram)

• Sơ đồ cấu trúc đa hợp (Composite Structure Diagram)

lOMoARcPSD|36667950

• Sơ đồ tương tác tổng quát (interaction overview Diagram)

• Sơ đồ thời gian (Timing Diagram)

Ngoài ra:

• Sơ đồ trạng thái (statechart diagram) đổi tên thành sơ đồ máy trạng thái

(state machine diagram)

• Sơ đồ cộng tác (collaboration diagram) đổi tên lại là sơ đồ giao tiếp

(communication diagram)

c) Các sơ đồ được phân thành 2 nhóm:

Nhóm sơ đồ cấu trúc (Structure Diagram):

• Sơ đồ lớp (Class Diagram)

• Sơ đồ đối tượng (Object Diagram)

• Sơ đồ thành phần (Component Diagram)

• Sơ đồ cấu trúc đa hợp (Composite Structure

Diagram)

• Sơ đồ triển khai (Deployment Diagram)

• Sơ đồ gói (Package Diagram)

Nhóm sơ đồ hành vi (Behaviour Diagram)

• Sơ đồ Use case (Use Case Diagram)

• Sơ đồ hoạt động (Activity Diagram)• Sơ đồ máy trạng thái (State Machine

Diagram)

• Nhóm sơ đồ tượng tác (Interaction Diagram):

lOMoARcPSD|36667950

• Sơ đồ trình tự (Sequence Diagram)

• Sơ đồ giao tiếp (Comunication Diagram)

• Sơ đồ tương tác tổng quát (interaction overview Diagram)

• Sơ đồ thời gian (Timing Diagram)

3. Các góc nhìn (view) của UML

• Góc nhìn (view) chỉ ra những khía cạnh khác nhau của hệ thống cần phải

đượcmô hình hóa.

• Một góc nhìn không phải là một bản vẽ, mà là một sự trừu tượng hóa bao

gồmnhiều sơ đồ khác nhau

• Mỗi góc nhìn sẽ chỉ ra một khía cạnh riêng biệt của hệ thống, nhờ đó người

tacó thể xây dựng nên một bức tranh hoàn chỉnh về hệ thống.

• Mỗi nhóm người có liên quan đến hệ thống sẽ tập trung chú ý vào một gócnhìn

nào đó mà thôi

lOMoARcPSD|36667950

a) Góc nhìn Use case (use case view)

• Là góc nhìn từ ngoài vào hệ thống.

• Đây là góc nhìn dành cho khách hàng, nhà thiết kế, nhà phát triển, người

kiểmthử. Nó mô tả các chức năng mong đợi mà hệ thống phải đáp ứng cho

người dùng

• Được mô tả qua các sơ đồ Use case (use case diagram) và thỉnh thoảng cả cácsơ

đồ hoạt động (activity diagram).

• Góc nhìn Use case mang tính trung tâm. Hệ thống phải cung cấp các chứcnăng

mô tả trong góc nhìn này → có ảnh hưởng đến tất cả các góc nhìn khác • Góc

nhìn này còn được sử dụng để thẩm tra (verify) hệ thống xem có đúng với mong

đợi của khách hàng ( "Đây có phải là thứ bạn muốn?") cũng như có đúng với

hệ thống đã hoàn thành ("Hệ thống có hoạt động như đã đăc tả?”). b) Góc nhìn

thiết kế

• Còn gọi là góc nhìn logic (logical view)

• Chủ yếu dùng cho các nhà thiết kế và nhà phát triển.

• Đây là góc nhìn vào bên trong hệ thống. Nó chỉ ra chức năng sẽ được thiết kếbên

trong hệ thống như thế nào

• Nó mô tả cấu trúc tĩnh (lớp, đối tượng, và quan hệ) cũng như sự tương tácđộng

sẽ xảy ra khi các đối tượng gửi thông điệp cho nhau để cung cấp chức năng đã

định sẵn.

• Cấu trúc tĩnh được mô tả bằng các sơ đồ lớp (class diagram) và sơ đồ đốitượng

(object diagram).

• Cấu trúc động được mô tả trong các sơ đồ trạng thái (statechart diagram), sơđồ

trình tự (sequence diagram), sơ đồ tương tác (collaboration diagram), sơ đồ hoạt

động (activity diagram)

lOMoARcPSD|36667950

c) Góc nhìn quá trình

• Còn gọi là góc nhìn song hành (Concurrency View)

• Phản ánh các lộ trình điều khiển, các quá trình (process) thực hiện, nó chothấy

sự hoạt động song hành hay đồng bộ của hệ thống

• Góc nhìn này dành cho nhà phát triển và người tích hợp hệ thống

• Bao gồm các sơ đồ động như: sơ đồ trạng thái (statechart diagram), sơ đồ trìnhtự

(sequence diagram), sơ đồ cộng tác (collaboration diagram) và sơ đồ hoạt động

(activity diagram)

d) Góc nhìn thực thi

• Còn gọi là góc nhìn thành phần (Component view)

• Là góc nhìn đối với dạng phát hành của hệ thống vật lý, bao gồm các thànhphần

và tập tin độc lập, được lắp ráp theo các cách để tạo ra hệ thống chạy được.

• Thành phần ở đây là các module thuộc nhiều loại khác nhau, sẽ được chỉ ratrong

sơ đồ cùng với cấu trúc cũng như sự phụ thuộc của chúng.

• Nó thường được sử dụng cho nhà phát triển và thường bao gồm nhiều sơ

đồthành phần.

• Được thể hiện bằng các sơ đồ thành phần (Component diagram)

e) Góc nhìn triển khai

• Góc nhìn triển khai (Deployment View) chỉ cho chúng ta sơ đồ triển khai

vềmăt vật lý của hệ thống, ví dụ các máy tính cũng như sự liên kết giữa chúng

vớị nhau.

lOMoARcPSD|36667950

• Góc nhìn triển khai dành cho các nhà phát triển, người tích hợp cũng

nhưngười thử nghiệm hệ thống và được thể hiện bằng các sơ đồ triển khai

(deployment diagram).

• Góc nhìn này cũng bao gồm sự ánh xạ các thành phần của hệ thống vào

cấutrúc vật lý; ví dụ như chương trình nào hay đối tượng nào sẽ được thực thi

trên máy tính nào.

4) UML và chu trình phát triển phần mềm

a) Giai đoạn nghiên cứu sơ bộ:

• UML đưa ra khái niệm Use Case để nắm bắt các yêu cầu của người sử dụng.

• Sơ đồ Use case (Use Case Diagram) dùng để mô tả mối quan hệ cũng như

sựgiao tiếp với hệ thống.

• Trong sơ đồ Use case, các tác nhân (Actor) bên ngoài quan tâm đến hệ thốngsẽ

được mô hình song song với chức năng mà họ đòi hỏi từ hệ thống (tức Use case)

• Mỗi Use case trong tài liệu sẽ đăc tả yêu cầu của người dùng: người dùng chờ

đợi điều gì từ hệ thống mà không để ý đến chức năng này sẽ được thực thi ra

sao

b) Giai đoạn phân tích:

• Giai đoạn phân tích quan tâm đến việc trừu tượng hóa

• Phân tích viên tìm ra các lớp thành phần và mối quan hệ giữa chúng → mô

tảbằng sơ đồ lớp (class diagram)

• Sự cộng tác giữa các lớp nhằm thực hiện các Use case cũng sẽ được mô tả

nhờvào các mô hình động (dynamic models) của UML.

lOMoARcPSD|36667950

• Trong giai đoạn phân tích, chỉ các lớp tồn tại trong phạm vi nghiệp vụ cần

giảiquyết (lớp phân tích) là được mô hình hóa. Các lớp kỹ thuật cũng như giải

pháp trong hệ thống phần mềm, ví dụ các lớp giao diện người dùng, v.v..., chưa

cần quan tâm trong giai đoạn này.

c) Giai đoạn thiết kế:

• Kết quả của giai đoạn phân tích sẽ được mở rộng thành các giải pháp kỹ thuật.

• Các lớp thiết kế được bổ sung để tạo thành hạ tầng kỹ thuật: giao diện

ngườidùng, các chức năng để giao tiếp với các hệ thống khác, v,v....

• Giai đoạn thiết kế sẽ đưa ra kết quả là bản đăc tả chi tiết (specification) dùng



để

xây dựng hệ thống.

d) Giai đoạn xây dựng:

• Trong giai đoạn xây dựng (lập trình), các lớp của giai đoạn thiết kế sẽ

đượcchuyển thành những dòng code cụ thể trong một ngôn ngữ lập trình hướng

đối tượng cụ thể

• Khi tạo ra các mô hình phân tích và thiết kế trong UML, cần tránh việc

ngaylập tức biến đổi các mô hình này thành các dòng code.

• Trong các giai đoạn trước, mô hình được sử dụng để hiểu rõ ràng hệ thống,

dễgiao tiếp và tạo nên cấu trúc của hệ thống. Nếu vội vàng sa vào việc viết code

có thể sẽ gây trở ngại cho việc xây dựng mô hình chính xác và đầy đủ.

e) Giai đoạn kiểm thử:

• Một hệ thống thường được thử nghiệm qua nhiều giai đoạn và với nhiều

nhómthử nghiệm khác nhau

• Các nhóm sử dụng các loại sơ đồ UML khác nhau làm nền tảng cho công

việccủa mình:

lOMoARcPSD|36667950

• Kiểm thử đơn vị (unit test) sử dụng sơ đồ lớp (class diagram) và đăc tả lớp



• Kiểm thử nghiệm tích hợp (integration test) thường sử dụng sơ đồ thành phần

(component diagram) và sơ đồ cộng tác (collaboration diagram)

• Kiểm thử hệ thống (system test) sử dụng sơ đồ Use case (use case diagram)

đểđảm bảo hệ thống hoạt động đúng như đã được định nghĩa từ ban đầu

5) Sơ đồ Use case (Use Case Diagram)

• Sơ đồ Use case chỉ ra các tác nhân ngoài và mối liên hệ giữa chúng với các

Use case mà hệ thống cung cấp

• Một Use case là diễn tả một chức năng mà hệ thống có khả năng cung cấp.

• Mỗi Use case có thể được đăc tả (ngoài sơ đồ) bằng một văn bản, hay bằng



một

sơ đồ hoạt động

• Các Use case được miêu tả duy nhất theo hướng nhìn từ ngoài vào của các

tácnhân (hành vi của hệ thống theo như sự mong đợi của người sử dụng)

• Các Use case chỉ đề cập hệ thống làm gì (WHAT) chứ không mô tả chức

năngđược cung cấp sẽ hoạt động nội bộ bên trong hệ thống ra sao (HOW)

6) Sơ đồ hoạt động (Activity Diagram)

• Sơ đồ hoạt động chỉ ra luồng dịch chuyển từ hành động này sang hành

độngkhác.

• Thường sử dụng để mô tả các hoạt động được thực hiện trong một thủ tục,một

use case. Cũng có thể dùng để mô tả các dòng chảy giữa các Use case

• Sơ đồ hoạt động bao gồm các trạng thái hành động, chứa đăc tả của một hoạ

động cần phải được thực hiện (một hành động - action). Một trạng thái hành động

sẽ qua đi khi hành động được thực hiện xong

lOMoARcPSD|36667950

• Sơ đồ còn có thể chỉ ra các quyết định, các điều kiện, cũng như phần thực

thisong song của các trạng thái hành động.

• Sơ đồ còn có thể chứa đăc tả cho các thông điệp được gửi đi / nhận về giữạ

các thành phần của hành động

7) Sơ đồ lớp (Class Diagram)

• Sơ đồ lớp chỉ ra cấu trúc tĩnh của các lớp trong hệ thống.

• Vì cấu trúc được mô tả luôn luôn đúng tại bất kỳ thời điểm nào trong vòng đời

hệthống

• Lớp là đại diện cho các sự vật được xử lý trong hệ thống.

• Các lớp có thể quan hệ với nhau theo nhiều cách:

• 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ủalớp

khác)

• Đó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 sơ đồ lớp, cùng với cấu trúcbên

trong của mỗi lớp, gồm thuộc tính (attribute) và tác vụ (operation).

8) Sơ đồ đối tượng (Object Diagram)

• Giống như sơ đồ lớp. Sự khác biệt là sơ đồ đối tượng chỉ ra các đối tượng

thựcthể của lớp, thay vì các lớp.

• Sơ đồ đối tượng là một bức tranh của hệ thống ở một thời điểm nào

đó(snapshot).

lOMoARcPSD|36667950

• Sơ đồ đối tượng dùng chung các ký hiệu của sơ đồ lớp, trừ hai điểm: tên

đốitượng được gạch dưới và tất cả các kết nối cụ thể trong mối quan hệ đều được vẽ

ra • Sơ đồ đối tượng không quan trọng bằng sơ đồ lớp

• Sơ đồ đối tượng ít dùng, thường được dùng làm nền cho sơ đồ cộng

tác(collaboration / comunacation), nó chỉ ra lối ứng xử động giữa các đối tượng.

9) Sơ đồ trình tự (Sequence Diagram)

• Sơ đồ trình tự chỉ ra trình tự các thông điệp (message) được gửi giữa các

đốitượng dọc theo trục thời gian

• Sơ đồ trình tự chứa một loạt các đối tượng được biểu diễn bằng các đường

thẳngđứng.

• Trục thời gian có hướng từ trên xuống dưới trong sơ đồ, và sơ đồ chỉ ra sự

traođổi thông điệp giữa các đối tượng khi thời gian trôi qua.

• Các thông điệp được biểu diễn bằng các đường gạch ngang gắn liền với mũi

tên(biểu thị thông điệp) nối liền giữa những đường thẳng đứng thể hiện đối tượng.

10) Sơ đồ giao tiếp (communication diagram)

• Tên cũ là sơ đồ cộng tác (Collaboration Diagram)

• Chỉ ra một sự cộng tác động, tương tự như sơ đồ trình tự

• Bên cạnh việc thể hiện sự trao đổi thông điệp (được gọi là tương tác), sơ đồ cònchỉ

ra các đối tượng và quan hệ của chúng (được gọi là ngữ cảnh).

• Việc nên sử dụng sơ đồ trình tự hay sơ đồ giao tiếp thường được quyết định

theonguyên tắc chung sau:

• Nếu thời gian hay trình tự là yếu tố quan trọng nhất cần phải nhấn mạnh thì hãychọn

sơ đồ trình tự

lOMoARcPSD|36667950

• Nếu ngữ cảnh là yếu tố quan trọng hơn, chọn sơ đồ giao tiếp

• Trình tự tương tác giữa các đối tượng được thể hiện trong cả hai loại sơ đồnày.

11) Sơ đồ máy trạng thái (State Machine Diagram)

• Tên cũ là sơ đồ trạng thái (State chart Diagram)

• Sơ đồ trạng thái thường là sự bổ sung cho đăc tả của một lớp. Nó chỉ ra tất cả các



trạng thái mà đối tượng của lớp này có thể có, và những sự kiện (event) nào sẽ gây

ra sự thay đổi trạng thái

• Sự thay đổi trạng thái được gọi là dịch chuyển trạng thái (State Transition). Cóthể

có một hành động liên quan, xác định điều gì phải được thực hiện khi sự chuyển

đổi trạng thái này diễn ra.

• Sơ đồ trạng thái không cần phải vẽ cho tất cả các lớp, mà chỉ những lớp mà

đốitượng của nó có khả năng ứng xử trước các sự kiện xảy đến tùy thuộc vào trạng

thái hiện tại của nó

12) Sơ đồ thành phần (Component Diagram)

• Sơ đồ thành phần chỉ ra cấu trúc vật lý của chương trình dưới dạng các

thànhphần, và mối quan hệ giữa chúng

• Sơ đồ thành phần dùng trình bày góc nhìn thực thi của hệ thống, được sử

dụngtrong việc lập trình cụ thể

• Một thành phần có thể là một tập tin nguồn (source code), thành phần nhị

phân(binary), thực thi (executable)

• Một thành phần chứa các thông tin về các lớp logic hoăc các lớp mà nó thi

hành, như thế có nghĩa là nó tạo ra một ánh xạ từ góc nhìn logic vào góc nhìn thành

phần.

lOMoARcPSD|36667950

• Thành phần cũng có thể được mô tả với bất kỳ loại giao diện nào mà chúng

bộclộ, ví dụ giao diện OLE/COM, có thể được nhóm lại với nhau thành từng gói

(package)

13) Sơ đồ triển khai (Deployment Diagram)

• Sơ đồ triển khai trình bày kiến trúc vật lý của phần cứng cũng như phần mềmtrong

hệ thống. Nó chỉ ra từng máy tính cụ thể và từng trang thiết bị cụ thể (node) và sự

nối kết giữa chúng

• Bên trong các nút mạng (node), các thành phần thực thi được (EXE) cũng nhưcác

đối tượng sẽ được xác định vị trí để chỉ ra những phần mềm nào sẽ được thực thi

tại những nút mạng nào. Ta cũng có thể chỉ ra sự phụ thuộc giữa các thành phần.

• Sơ đồ triển khai chỉ ra góc nhìn triển khai, mô tả kiến trúc vật lý thật sự của

hệthống. Đây là góc nhìn rất khác cách mô tả duy chức năng của góc nhìn Use case

CHƯƠNG 5: TỪ ĐIỂN DỮ LIỆU

A) TỪ ĐIỂN DỮ LIỆU

1) Từ điển dữ liệu (Data Dictionary)

• Từ điển dữ liệu (DD) dùng để lưu các mô tả chi tiết về các thành phần trong cácsơ

đồ được xây dựng trong quá trình phân tích.

• Đây là kho trung tâm chứa tất cả các mô tả về hệ thống. Từ đây có thể tạo ranhiều

báo cáo hữu ích về hệ thống.

• Trong các CASE tool các mô tả này thường chứa trong một kho gọi là

datarepository.

Cần lập tài liệu cho:

• Các dòng dữ liệu

lOMoARcPSD|36667950

• Các kho dữ liệu

• Cấu trúc dữ liệu (data structure) của các mẩu tin

• Các phần tử dữ liệu (data item)

• Các quy trình xử lý

• Các thực thể ngoại

2) Từ điển dữ liệu và DFD các mức

• Các thành phần trong từ điển dữ liệu sẽ thay đổi theo mức của sơ đồ DFD tươngứng

• Từ điển dữ liệu được tạo theo cách tiếp cận từ trên xuống

• Có thể dùng để kiểm tra tính cân bằng giữa DFD mức trên và DFD mức dưới

• Trong CASE tools, từ điển dữ liệu là nơi chứa thông tin để các công cụ sinh ra

cơsở dữ liệu và các chương trình máy tính

3) Mô tả dòng dữ liệu

lOMoARcPSD|36667950

4) Mô tả kho dữ liệu

lOMoARcPSD|36667950

5) Mô tả cấu trúc dữ liệu

• Dùng để mô tả sự kết hợp của các thành phần dữ liệu trong dòng dữ liệu (hoặckho

dữ liệu)

• Mô tả dựa vào các biểu mẫu thực tế đã thu thập

• Thường dùng các ký hiệu sau:

= Bao gồm

+ Và (and)

( ) Tùy chọn (option)

{ }

Lặp lại từ m đến n lần

lOMoARcPSD|36667950

[ ] Chọn một trong các trường hợp (or)

| Dấu phân cách các chọn lựa

6) Mẫu đơn hàng

7) Mô tả thành phần dữ liệu

lOMoARcPSD|36667950

• Các ký hiệu dùng để mô tả định dạng (Format):

• X: Đại diện cho một ký tự bất kỳ

• 9: Đại diện cho một ký số

• Z: Hiển thị cả các số không ở bên trái của số

• . , / - v.v… : Các ký hiệu phân cách

• Việc mô tả cấu trúc dữ liệu của các kho dữ liệu, cũng như mô tả các thành phầndữ

liệu chính là cơ sở để ta thiết kế cơ sở dữ liệu sau này.

• Việc mô tả các dòng dữ liệu còn giúp ta kiểm tra lại tính chính xác của các lượcđồ.

Ví dụ phát hiện các lỗ xám trong sơ đồ DFD.

B) ĐẶC TẢ QUY TRÌNH XỬ LÝ

1) Đặc tả quy trình xử lý

• PS - Process Specification

• Là công cụ mô tả các quy trình xử lý bên trong của một process trong sơ đồ DFD.

lOMoARcPSD|36667950

• Mục đích của PS là mô tả chính xác về nghiệp vụ xử lý, tránh sự hiểu biết khôngrõ

ràng, không đầy đủ về một nghiệp vụ

• Có thể dùng mô tả quá trình nguyên tố cũng như các quá trình xử lý ở mức trên.

Lưu ý: không phải mọi process đều phải đặc tả PS.

Người ta có thể không đặc tả cho các process sau:

• Process chỉ thực hiện việc nhập / xuất kho dữ liệu (đọc/ghi file).

• Process chỉ thực hiện việc kiểm tra đơn giản về tính hợp lệ của dữ liệu.

• Process đã được lập trình rồi, nay chỉ sử dụng lại (gọi hàm/ thủ tục thư viện).

Ta có thể mô tả logic xử lý của các quá trình bằng các cách sau:

• Lưu đồ (Flow Chart)

lOMoARcPSD|36667950

• Tiếng Anh có cấu trúc (Structured Enghlish)

• Bảng quyết định (Decision Table)• Cây quyết định (Decision Tree)

2) Một số ký hiệu trong Flow Chart

3) Lưu đồ

lOMoARcPSD|36667950

4) Tiếng Anh có cấu trúc (Structured English)

• Tập con của tiếng Anh chuẩn: sử dụng một số từ vựng quy ước.

• Tương tự như viết mã giả (pseudo code)

• Sử dụng các cấu trúc điều khiển như:

• Cấu trúc rẽ nhánh

IF <condition> THEN

[ELSE

<statement 2>]

lOMoARcPSD|36667950

END IF

• Cấu trúc chọn

DO CASE

CASE <value 1> : <statement 1>

…

CASE <value n> : <statement n>

[ELSE <statement n+1>]

END CASE

• Cấu trúc lặp:

DO WHILE <condition>

END WHILE

5) Bảng quyết định (Decision Table)

• Cho thấy cấu trúc luận lý để ra quyết định trong trường hợp phức tạp có nhiềuđiều

kiện phối hợp.

• Tất cả các trường hợp phối hợp giữa các điều kiện đều được xác định → không

bịsót tình huống.

• Lập trình viên có thể dựa vào các mô tả này để viết chương trình.

Bảng được chia thành 4 vùng:

▪ Góc trên bên trái là các điều kiện (conditions)

▪ Góc dưới bên trái là các hành động (actions)

lOMoARcPSD|36667950

▪ Góc trên bên phải là sư phối hợp của các điều kiện, gọi là các luật (rule)

▪ Góc dưới bên phải là sự chọn lựa hành động tương ứng với các luật

6) Các bước xây dựng bảng quyết định

• B1: Xác định các điều kiện có thể có cho khối trên bên trái• B2: Xác định các hành

động có thể chọn lựa cho khối dưới bên trái

• B3: Xác định khả năng lựa chọn cho mỗi điều kiện.

• Trường hợp đơn giản, mỗi điều kiện chỉ có 2 lựa chọn: Yes hay No → có 2ncột

(luật)

• Mỗi điều kiện cũng có thể có nhiều chọn lựa

• B4: Xác định tất cả các trường hợp phối hợp giữa các điều kiện để tạo thànhcác

luật (rule), mỗi luật tương ứng với một cột ở khối trên bên phải.

• B5: Loại bỏ các luật mâu thuẫn, dư thừa, trùng lắp

• B6: Xác định cách chọn hành động cho từng luật (tương ứng từng cột)

• B7: Thu gọn bảng quyết định (nếu được)

7) Thu gọn cột bảng quyết định

• Trong trường hợp có một số cột có cùng hành động, các cột này có chung 1 số

điều kiện; một điều kiện khác lại không ảnh hưởng gì tới quyết định này → dùng

dấu '-' để đánh dấu

lOMoARcPSD|36667950

8) Thu gọn hàng bảng quyết định

Trong một số trường hợp ta có thể xác định nhiều chọn lựa cho một điều kiện

(thay vì dùng Y/N) → có thể giảm số hàng trong bảng quyết định

lOMoARcPSD|36667950

9) Cây quyết định (Decision tree)

• Biểu diễn dưới dạng đồ họa các chọn lựa để ra quyết định

• Dễ hiểu và dễ xây dựng

• Được sử dụng để đặc tả cho các quá trình có cấu trúc rẽ nhánh phức tạp, hoặcthứ

tự thực thi của các quyết định là quan trọng (bảng quyết định khó diễn tả trong

trường hợp này)

Các bước xây dựng:

• Nhận diện tất cả các điều kiện và hành động

• Sắp xếp hành động và điều kiện theo thời gian

• Bắt đầu xây dựng từ trái sang phải. Sử dụng các ký hiệu:

 : biểu diễn cho một hành động

 : biểu diễn cho một điều kiện

lOMoARcPSD|36667950

• Ở mỗi node phải xét tất cả các trường hợp có thể xảy ra trước khi xét qua nodekế

(thứ tự thực thi rất quan trọng)

10) Tổng kết về PS

Cần chọn phương pháp thích hợp xây dựng PS:

• "Structured English" thích hợp khi logic quá trình có vòng lặp hoặc sự liên hệvới

người dùng là quan trọng

• "Decision Table" thích hợp với logic có cấu trúc điều kiện phức tạp hoặc đểkiểm

soát tránh các dư thừa, mâu thuẫn.

• "Decision Tree" thích hợp khi thứ tự thực thi của các điều kiện là quan trọng.

CHƯƠNG 6: ĐẶC TẢ QUY TRÌNH XỬ LÝ

1) Logic của quyết định

Lập tài liệu và phân tích logic:

• Cấu trúc tiếng Anh

• Bảng quyết định

• Cây quyết định

• Các quyết định logic và có cấu trúc có thể phân biệt được với quyết định báncấu

trúc

• Các phương pháp phân tích quyết định có cấu trúc thúc cải thiện tính đầy

đủ,chính xác và giao tiếp

2) Chủ đề chính

- đặc tả quá trình

- quy tắc kinh doanh

- tiếng anh cấu trúc

lOMoARcPSD|36667950

- cân bằng ngang

3) Đặc tả quá trình

- Thông số kỹ thuật quy trình

- Được tạo cho quá trình nguyên thủy cũng như cho vài mức độ xử lí cao hơn

trong 1 DFD

- Được tạo 1 phương pháp lớp trong thiết kế hướng đối tượng và cho các bước

trong 1 USE CASE

4) Mục tiêu của đặc tả quy trình sản xuất

- giảm sự không rõ ràng quy trình

- Đạt được 1 mô tả chính xác

- Xác thực thiết kế hệ thống

5) Đặc tả quy trình không được tạo ra cho -

quy trình đại diện cho đầu vào ra vật lý

- quy trình đại diện cho dữ liệu xác thực đơn giản

- quy trình sử dụng cho code viết sẵn

6) thông tin định dạng đặc tả quy trình

- Số hiệu quy trình

- Tên quy trình

- Mô tả hoàn thành quy trình

- Danh sách dòng dữ liệu vào

- Dòng dữ liệu ra

- Loại quy trình

- Dùng code viết sẵn

- Mô tả logic quy trình

- Tham khảo phương pháp logic

- Liệt kê bất kỳ vấn đề chưa giải quyết a) Số hiệu quy trình

- Phải giống với ID của quy trình trong DFD

lOMoARcPSD|36667950

- cho phép nhà phân tích làm việc hoặc đánh giá bất kỳ quy trình nào và định

vị DFD chứa quy trình dễ dàng

b) Tên quy trìnhgiống như hiển thị trong biểu tượng quy

trình trong DFD

c) Mô tả của những gì quy trình đạt đượcxác định nếu

một item có sẵn cho bán hàng. Nếu nó không có sẵn, tạo

một báo cáo đơn đặt hàng restock item. Quyết định số

lượng có sẵn

d) Liệt kê đầu vào DFD- Sử dụng tên tạo trên DFD

- tên dữ liệu được dùng trong thông thường hoặc logic nên hợp với từ điển dữ

liệu, cho nhất quán và giao tiếp tốt

e) Dòng dữ liệu ra

Sử dụng tên DFD và từ điển dữ liệu

f) Loại quy trình

- Đợt, lô

- Online

+ Thiết kế màn hình hoặc trang web

- Thủ công

+ nên có quy trình rõ ràng cho nhân viên khi thực hiện nhiệm vụ quá trình

g) Sử dụng code viết sẵnbao gồm tên của chương trình con hoặc chức

năng bao gồm code

h) Mô tả logic quy trình

- nêu chính sách và quy tắc kinh doanh k phải ngôn gnuwx máy tính - mã giả

- thủ tục cho phép 1 cty điều hành hđ kinh doanh của mình

7) định dạng quy tắc kinh doanh thông thường

lOMoARcPSD|36667950

- định nghĩa thuật ngữ kinh doanh

- điều kiện và hành động kinh doanh

- ràng buộc toàn vẹn dữ liệu

- dãn xuất toán học và chức năng

- suy luận logic

- trình tự xử lý

- mqh giữa các dữ kiện về doanh nghiệp

8) tham khảo pp logic

- nếu không đủ không gian cho 1 mô tả tiếng anh cấu trúc hoàn thành bao

gồm a tham khảo cho mô tả tiếng anh cấu trúc, bảng quyết định hoặc câ dự

đoán logic

9) Danh sách bất kì vấn đề ko được giải quyết

- phần logic chưa hoàn chỉnh

- những vấn đề này tạo thành cơ sở của những câu hỏi được dùng cho các

cuộc phỏng vấn tiếp theo với người dùng hoặc chuyên gia kinh foanh mà

bạn đã thêm vtheenhosm dự án của bạn

10) Tiếng anh có cấu trúc

- được dùng khi quy trình logic liên quan đến công thức hoặc lặp lại, hoặc khi

các quyết định có cấu trúc không phức tạp

- dựa trên logic cấu trúc và câu lệnh tiếng anh đơn giản, vd như cộng nhân di

chuyển

11) Viết tiếng anh có cấu trúc

- thể hiện tất cả logic theo cấu trúc trình tự, cấu trúc quyết định, cấu trúc trường

hợp, cấu trúc lặp

- dùng và in hoa các từ khóa such as IF,THEN, ELSE, DO, and PERFORM

- Thụt lề cái khối câu lệnh để hiển thị cấu trúc phân cấp rõ ràng

- Gạch chân từ hoặc câu được định nghĩa trong từ điển dữ liệu

lOMoARcPSD|36667950

- Làm rõ nhận định logic

12) Lợi ích của Tiếng Anh có cấu trúc

- làm rõ logic và mqh đc tìm thấy trong ngôn ngữ con người

- một công cụ giao tiếp hiệu quả, nó có thể dạy và hiểu bởi người dùng trong tổ

chức

13) từ điển dữ liệu và đặc tả quá trình

- Từ điển dữ liệu là một xuất phát điểm cho tạo tiếng anh cấu trúc

lOMoARcPSD|36667950

Downloaded by Albedo Lili (albedo0208@gmail.com)

Sequence - chuỗi đơn giản các câu lệnh statements MOVE, ADD, and

SUBTRACT

- Selection –[] Mục nhập become IF … THEN...ELSE statements

- Iteration {} entries become DO WHILE, DO UNTIL, or PERFORM UNTIL

14) Bảng quyết định

Một bảng gồm các hàng và cột, được chia thành bốn góc phần tư:

- Điều kiện

- Điều kiện thay thế

- hành động cần thực hiện

- quy tắc thực hiện các hoạt đoojng

15) Phát triển bảng quyết định

- xác định đk ảnh hưởng quyết định

- hành động khả thi có thể thực hiện

- điều kiện thay thế cho từng điều kiện

- tính số cột tối đa

- điền vào đk thay thế

- hoàn thành bảng bởi thêm X nơi các quy định gợi ý hành động

- kết hợp quy định khi rõ ràng

- tình huống bất khả thi

- sắp xếp lại cho dễ hiểu

16) Phát triển bảng quyết định bước 1

- Xác định số của điều kiện có thể tác động quyết định

- kết hợp hàng trùng nhau, vd đk loại từ lẫn nhau

- số lượng điều kiện trở thành số hàng trong nửa trên bảng quyết định

lOMoARcPSD|36667950

Downloaded by Albedo Lili (albedo0208@gmail.com)

17) Phát triển bảng quyết định bước 2

- Xác định số hiệu của hành động khả thi có thể được thực hiện

Số đó trở thành số của hàng tỏng nửa dưới

18) Phát triển bảng quyết định bước 3

- Xác định đk thay thế cho mỗi điều kiện

- Định dạng đơn giản nhất của bảng quyết định, có 2 thay thế Y N cho mỗi điều

kiện

- một bảng nhập mở rộng có thể có nhiều lwuja chọn thay thế

- Đảm bảo rằng tất cả giá trị có thể có của điều kiện

19) Phát triển bảng quyết định bước 4

- tính toán số cột tối đa trong bảng quyết định bởi nhân số thay thế của lựa chọn

thay thế của mỗi diều kiện

- nếu 4 điều kiện và 2 thay thế Y N thì => 16 cột có thể có

20) Phát triển bảng quyết định bước 5

- điền vào điều kiện thay thế

21) Tính đầy đủ và chính xác - 4 vấn đề chính:

+ Không đầy đủ

+ Tình huống bất khả thi mâu thuẫn dư

+ Contradictions

+ Redundancy

22) Lợi ích của bảng quyết định

- bảo đảm sự đầy đủ

- dễ kitra lỗi

+ tính huống bất khả thi

lOMoARcPSD|36667950

Downloaded by Albedo Lili (albedo0208@gmail.com)

+ mâu thẫun

+ Dư, rườm rà

23) Cây quyết định

Cây quyết định được sử dụng khi xảy ra nhánh phức tạp trong 1 quy trình

quyết định có cấu trúc

- Những cây hữu ích khi nó cần thiết giữ 1 cái string của chuỗi các quyết định

theo một trình tự cụ thể

24) Vẽ cây quyết định

- xác định all diều kiện và hành động và thứ tự của chúng và thời gian

- bắt đầu xây dựng cây từ trái --> phải, đảm bảo bạn phải liệt kê all lựa chọn

thay thế có thể trước khi chuyển sang phải

25) Lợi ích của cây quyết định

- thứ tự của kiểm tra điều kiện và thực hiện hành động là ngay lập tức đáng chú

- điều kiện & hành động tìm thấy ơ vài nhánh

- so sánh với bảng quyết định, cây qđ dễ hiểu hơn

26) chọn một thiết bị phân tích quyết định có cấu trúc

- Sử dụng tiếng anh có cấu trúc khi có nhiều hành động lặp lại hoặc khi một

kết hợp phức tạp của điều kiện, hành động, quy tắc

- • Use decision tables when a complex combination of conditions, actions,

and rules are found or you require a method that effectively avoids

impossible situations, redundancies, and contradictions

- • Use decision trees when the sequence of conditions and actions is critical

or when not every condition is relevant to every action (the branches are

different)

Bấm Tải xuống để xem toàn bộ.

| 1/77

| | Tải xuống

Preview text:

lOMoARcPSD| 36667950 Chương 1:
Tổng quan về phân tích và thiết kế hệ thống 1.1.
Các khái niệm cơ bản về hệ thống thông tin
- Dữ liệu: các con số, văn bản, ký hiệu, … có thể lưu trữ, truyền nhận. Là nguyên
liệu thô để phân tích, xử lý tạo thành thông tin.
- Phân loại dữ liệu: Có cấu trúc (Structured)
Ví dụ: các table trong CSDL quan hệ.
Phi cấu trúc (Unstructured data)
Vi dụ: Hình ảnh, âm thanh, file văn bản, … Trên 80% dữ liệu
trong doanh nghiệp hiện là dữ liệu phi cấu trúc
Bán cấu trúc (Semi-structured data)
Ví dụ: XML database ...
- Big Data là các tập dữ liệu có khối lượng lớn và phức tạp, mà các ứng dụng xử lý
dữ liệu truyền thống không có khả năng thu thập, và xử lý tốt.
Đặc điểm của big data Volume (khối lượng)
Petabyte (1PB=1024TB), Exabyte (1EB=1024PB) Variety (tính đa dạng)
Dữ liệu thu thập từ nhiều nguồn khác nhau, các dạng và kiểu dữ liệu có cấu
trúc khác nhau. Velocity (vận tốc)
Tốc độ các dữ liệu được tạo ra và xử lý Veracity (tính xác thực)
Chất lượng của dữ liệu thu được ảnh hưởng đến sự phân tích
VD Big data: Sàn chứng khoáng, MXH, Hãng bay -
Thông tin: dữ liệu đã được xử lý, đặt trong ngữ cảnh phù hợp, có ích cho người dùng.
Một số đặc trưng của thông tin:
Tính chính xác (Accuracy)
Tính đầy đủ (Completeness)
Tính kịp thời (Timeless) -
Hệ thống: tập hợp các phần tử (components) tác động lẫn nhau, phối hợp hoạt
động (work together) để đạt được các mục tiêu (objectives) xác định. -
Hệ thống thông tin: là tập hợp các thiết bị phần cứng, phần mềm, hệ thống
truyền thông, được tổ chức lại để xử lý dữ liệu và phân bố thông tin phục vụ cho
các mục tiêu của một đơn vị. 1.2.
Các thành phần cấu thành hệ thống thông tin - Phần cứng (Hardware) lOMoARcPSD| 36667950 - Phần mềm (Software) - Dữ liệu (Data) - Quy trình xử lý (Process) - Con người (People) - -
Phân tích và thiết kế HTTT là công việc được thực hiện một cách có hệ thống
nhằm xây dựng mới or phát triển HTTT đã có, sao cho việc sử dụng các tài
nguyên của HTTT một cách hiệu quả nhất. 1.3.
Tổ chức quản lý trong công ty và việc ra quyết định - Cổ đông (Stackholder). -
Internal system user: người dùng nội bộ: giám sát, quản lý cấp trung, giám đốc
điều hành, nhân viên văn phòng, nhân viên dịch vụ. -
External system users: người dùng ngoài: KH, nhà cung cấp, đối tác, nhân viên: nv bán hàng đại diện - lOMoARcPSD| 36667950 -
Ra quyết định: hành động nhằm thay đổi trạng thái hiện tại trạng thái mong muốn. Có 2 yếu tố: Tiêu chuẩn ra qđịnh.
Dữ liệu cần thu thập & quy trình xử lý. - Các loại quyết định:
+ Quyết định có cấu trúc: 2 yếu tố rõ ràng, lập trình được trên PC tự
động hóa cao. VD: chuỗi các thủ tục đã được xác lập trước, có tính lặp đi lặp lại và theo
thông lệ. Các qđịnh số tiền thưởng theo doanh số bán hàng của các nhân viên bán hàng, qđịnh
khen thưởng sinh viên xếp loại xuất sắc, giỏi hàng năm
+ Qđịnh phi cấu trúc: 2 không rõ. Dựa vào cảm tính, kinh nghiệm, tác động
môi trường. Có thể lượng hóa được. VD bỏ phiếu, các qđịnh bổ nhiệm cán bộ, quyết
định mở ngành đào tạo mới, thiết lập một dây chuyền sản xuất mới…
+ Qđịnh bán cấu trúc: 1 trong 2 không rõ ràng, không thể lượng hóa.
VD: tung sp mới, căn cứ lợi nhuận, mức độ rủi ro, dự báo thị trg, quyết định mức chi khen thưởng
cho cán bộ có thành tích công tác tốt, cho sinh viên đạt kết quả học tập cao. -
Quản trị viên cấp cao: + Tổng thể
+ Kế hoạch dài hạn, tính chiến lược, tồn tại phát triển cty. VD: xđ thị trg thâm nhập. +
Qđịnh: Phi, bán cấu trúc
+ Thông tin: ngoài tầm kiểm soát cty: dự báo thị trg, đổi mới công nghệ…
- Quản trị viên cấp trung:
+ Kế hoạch trung hạn, tính chiến thuật mục tiêu kd. Vd phân phối nguồn tài nguyên trong cty.
+ Qđịnh: Bán, có cấu trúc.
+ Thông tin: trong – 1 ít ngoài, chắc chắn, cụ thể. -
Quản trị viên cấp thấp: + Hđ hằng ngày.
+ Qđịnh: tính tác nghiệp sdụng hiệu quả nguồn tài nguyên. Vd kiểm soát tồn
kho, tín dụng, thuê xe…
+ Thông tin: Trong, chi tiết, chắc chắn. -
Nhân viên tác nghiệp, thừa hành:
+ Thực hiện cv được giao. Vd tiếp nhận nhập số liệu vào hệ thống.
+ Yêu cầu HTTT: vận hành dễ, nhanh, chính xác. 1.4.
Phân loại hệ thống thông tin lOMoARcPSD| 36667950 - - Trong sì lai ghi rõ lứm. -
Vấn đề tích hợp hệ thống:
+ Các HTTT trong đơn vị phải được phối hợp hoạt động với nhau.
+ Top-down: lý tưởng xây dựng hệ thống. Cần CIO hoạch định chiến lược xây dựng HTTT từ đầu.
+ Bottom – up: tạo thành các ốc đảo thông tin 1.5.
Vai trò, vị trí, kỹ năng của phân tích viên -
Phân tích viên hệ thống (System analyst): người chịu trách nhiệm chính trong việc phân tích
các nghiệp vụ, nhận ra các cơ hội để cải tiến, thiết kế và cài đặt hệ thống thông tin (HTTT) đạt
được mục tiêu trên. Để xây dựng hệ thống thành công, PTV cần hiểu rõ phương pháp luận,
nắm vững kỹ thuật và thực hiện một cách sáng tạo các bước trong quy trình phát triển hệ thống -
Chuyên gia tư vấn (Consultant):
Tư vấn về phần cứng, phần mềm, chức năng, cơ sở kỹ thuật,… Các tư vấn
này phải phù hợp với các yêu cầu kỹ thuật của HT sắp xây dựng.
Là một chuyên gia trợ giúp (Support Expert):
Là người trung gian giữa khách hàng và lập trình viên, PTV hệ thống phải
giải đáp mọi thắc mắc từ cả 2 phía để có thể chuyển những yêu cầu
trong thế giới thực thành HTTT hoàn chỉnh.
Là tác nhân thay đổi (Agent of Change):
PTV có khả năng tác động để thay đổi quy trình vận hành nhằm đưa CNTT vào ứng dụng cho đơn vị 1.6.
Chu kỳ phát triển hệ thống (SDLC) lOMoARcPSD| 36667950 -
Các giai đoạn của SDLC
Lập kế hoạch (Planning)
Tại sao phải xây dựng hệ thống? (Why)
Phân tích (Analysis)
Hệ thống cần phải làm những gì? (What). Và các câu hỏi Who, When, Where liên quan? Thiết kế (Design)
Làm thế nào để hệ thống hoạt động? (How)
Thi công (Implementation) Lập trình, thử nghiệm
Vận hành và hỗ trợ (Operation and support) Đưa hệ thống vào vận hành -
Xây dựng hệ thống thông tin sẽ trải qua nhiều giai đoạn (phase)
Mỗi giai đoạn thường sẽ bao gồm nhiều bước thực hiện (step)
Mỗi bước sẽ sử dụng các kỹ thuật (technique) khác nhau và
tạo ra kết quả cụ thể của bước đó (các bảng thiết kế, tài liệu, chương trình, …)
Quá trình phân tích và thiết kế hệ thống bao gồm các công việc cần hoàn thành theo
trình tự nhất định có thể bao gồm các bước sau:
+ Xác định vấn đề, các yêu cầu quản lý hệ thống.
+ Xác định mục tiêu, ưu tiên, giải pháp sơ bộ và chứng minh tính khả thi.
+ Phân tích các chức năng và dữ liệu của hệ thống.
+ Thiết kế logic: Trả lời câu hỏi làm gì ? hoặc là gì ?. Phân tích sâu hơn các chức năng,
các dữ liệu của hoạt động cũ để đưa ra mô tả hoạt động mới.
+ Thiết kế vật lý: đưa ra những biện pháp, phương tiện thực hiện, nhằm trả lời câu hỏi: Làm như thế nào ?.
+ Cài đặt hệ thống: Lựa chọn ngôn ngữ, hệ quản trị cơ sở dữ liệu và lập trình.
+ Khai thác và bảo trì. 1.7.
Các kỹ thuật và công cụ phát triển hệ thống lOMoARcPSD| 36667950
- JAD (Joint Application Development): Kỹ thuật xây dựng nhóm cộng tác trong
phát triển ứng dụng, bao gồm nhiều thành viên thuộc nhiều lĩnh vực và cấp độ quản lý.
- AD (Rapid Application Development): Kỹ thuật phát triển nhanh ứng dụng
+ Nổi lên từ những năm 1990s
+ Nhờ sự xuất hiện các công cụ hỗ trợ (CASE tools)
+ Các ngôn ngữ lập trình trực quan (visual) ngày càng mạnh mẽ
- CASE tools – Computer- Aided System Engineering
Là các công cụ hỗ trợ cho việc phát triển hệ thống ở nhiều mức độ khác nhau
Upper CASE tools: hỗ trợ việc mô hình hóa hệ thống và tạo ra thiết kế luận lý cho hệ thống
Lower Case Tool: giúp sinh mã nguồn chương trình (codegenerator) từ các mô
hình luận lý → đẩy nhanh tốc độ phát triển hệ thống
Tất cả các thiết kế được lưu trữ trong một kho gọi là CASE repository
- Mô hình thác nước (Waterfall model): dự án nhỏ, 1 quy trình ổn định. - Mô hình chữ V
- Mô hình Prototype: nhìu phiên bản (bản mẫu), 1 phiên bản giải quyết 1 số yc,
vấn đề phát sinh của bản trước. Rút 45% time.
Quy trình nghiệp vụ chưa ổn định Một prototype
phải có các đặc điểm:
Làm việc được trên các dữ liệu thực
Có thể phát triển thêm để tiến tới HT cuối cùng
Tạo lập nhanh và ít tốn kém
Dùng để kiểm chứng các giả định về các nhu cầu phải đáp ứng, các lược
đồ thiết kế và logic của chương trình.
Lợi ích của prototype:
Chính xác hóa các nhu cầu phải đáp ứng
Phát hiện các sai sót trong logic chương trình Đánh giá được
hiệu năng của hệ thống.
- Mô hình Throwaway Prototype.
- Mô hình tăng trưởng: phiên bản 1 là lõi, sau mỗi phiên bản được sử dụng, các kq
feedback sdung để lập kế hoạch cho chu trình con phiên bản tiếp theo. Chức năng dần bổ sung vào.
- Mô hình xoắn ốc. - Mô hình RUP. lOMoARcPSD| 36667950
- Agile: Phương pháp phát triển phần mềm linh hoạt. Hướng tiếp cận cụ thể cho
qly dự án phần mềm. Gồm: qtrình làm việc tương tác & tích hợp đưa sp đến KH
càng nhanh càng tốt.
- Scrum: là framework, là mô hình thực hiện để tạo ra được trạng thái Agile. Agile là mindset Minh bạch Thanh tra Thích nghi
- Scrum: team – Waterfall: 1 mình
- Agile: thay đổi, dự án chưa rõ, rủi ro - Waterfall: ko thay đổi, nhỏ, ngắn hạn, ko rủi ro 1.8.
Các phương pháp luận phát triển hệ thống
- Một số phương pháp luận:
+ Các phương pháp hệ thống:
MERISE (H.Tardieu, A.Rochfeld 1976) + Các
phương pháp chức năng hay có cấu trúc: SADT (douglas T.Ross, 1977)
+ Phương pháp hướng sự kiện State Charts (D.Harel, 1987)
+ Các phương pháp hướng dữ liệu: LCP, LCS (J.D.Warnier, 1969)
+ Các phương pháp hướng đối tượng: OOAD (G.Booch, 1992-1993)
UML + RUP + Rational Rose (G.Booch, J.Rumbaugh, I.Jacobson 1997) lOMoARcPSD| 36667950 1.9.
Phương pháp phân tích thiết kế hướng đối tượng
1.9.1.Thông tin – Một nguồn tài nguyên quan trọng
- Nhiên liệu kinh doanh có thể là yếu tố quan trọng trong việc quyết định sự thành bại của kinh doanh.
- Cần được quản lý chính xác
- Quản lý thông tin do máy tính tạo ra khác với việc xử lý dữ liệu được tạo thủ công
1.9.2.Nhu cầu phân tích & thiết kế hệ thống
- Cài đặt hệ thống mà không có kế hoạch phù hợp dẫn đến sự không hài lòng cho phần lớn người
dùng và thường gây ra hệ thống tơi vào tình trạng không dùng được.
- Phân tích và thiết kế hệ thống tạo cấu trúc cho phân tích và thiết kế HTTT
- Sự tham gia của người dùng trong suốt 1 dự án hệ thống là quan trọng cho sự phát triển thành
công của hệ thống máy tính.
1.9.3.Vai trò nhà phân tích hệ thống
- Nhà phân tích phải có khả năng làm việc với mọi người của tất cả mô tả và có kinh nghiệm làm việc với máy tính. - 3 vai trò chính: + Tư vấn (Consultant) +
Chuyên gia hỗ trợ (Supporting Expert) +
Tác nhân thay đổi (Agent of change)
1.9.4.Phẩm chất của nhà phân tích hệ thống
- Người giải quyết vấn đề (Problem solver)
- Người giao tiếp (Communicator)
- Đạo đức nghề nghiệp và cá nhân mạnh mẽ (Professional ethics & strong personal)
- Tự kỷ luật và năng động (Self-disciplined & self-motivated)
1.9.5.Vòng đời phát triển hệ thống SDLC
- Vòng đời phát triển hệ thống SDLC là giai đoạn tiếp cận để giải quyết vấn đề kinh doanh
- Được phát triển thông qua việc sử dụng 1 chu trình cụ thể của hoạt động của người phân tích và người dùng
- Mỗi giao đoạn có các hoạt động người dùng duy nhất
- SDLC là quy trình phát triển phần mềm: chất lượng cao nhất, chi phí thấp nhất trong thời gian ngắn nhất có thể.
1.9.6.Bảy giai đoạn của hệ thống Giai đo n 1:ạ
Xác định vấn đề, cơ hội, mục tiêu - Hoạt động:
+ Phỏng vấn quản lý người dùng
+ Tổng kế kiến thức thu được
+ Ước tính phạm vi dự án lOMoARcPSD| 36667950 + Ghi lại kết quả - Đầu ra:
+ Báo cáo khả thi bao gồm định nghĩa vấn đề và tóm tắt khách quan mà từ đó người quản lý
có thể đưa ra quyết định về việc có nên tiếp tục dự án được đề xuất không Giai đo n 2:ạ
Xác định yêu cầu thông tin con người - Hoạt động: + Phỏng vấn
+ Lấy mẫu và đầu tư dữ liệu cứng + Bảng câu hỏi
+ Quan sát hành vi của người ra quyết định và môi trường + Tạo mẫu
+ Tìm hiểu ai, cái gì, ở đâu, khi nào, như thế nào, tại sao của hệ thống hiện tại. - Đầu ra:
+ Nhà phân tích hiểu các người dùng thực hiện công việc khi tương tác với máy tính
+ Bắt đầu biết các làm hệ thống mới hữu ích và có thể sử dụng
+ Nhà phân tích nên biết chức năng doanh nghiệp
+ Co đầy đủ thông tin về con người, mục tiêu dữ liệu và thủ tục liên quan. Giai đo n 3:ạ
Phân tích nhu cầu hệ thống lOMoARcPSD| 36667950 - Hoạt động: + Tạo Sơ đồ DFD
+ Hoàn thiện từ điển dữ liệu
+ Phân tích các quyết định có cấu trúc được đưa ra
+ Chuẩn bị và trình bày đề xuất hệ thống - Đầu ra:
+ Khuyến nghị về những gì, nếu có, nên được thực hiện Giai đo n 4:ạ
Thiết kế hệ thống (được đề xuất) - Hoạt động:
+ Thiết kế quy trình nhập liệu chính xác
+ Thiết kế giao diện người-máy tính (HCI)
+ Tập tin thiết kế và/hoặc cơ sở dữ liệu
+ Thiết kế thủ tục dự phòng - Đầu ra:
+ Mô hình hệ thống thực tế Giai đo n 5:ạ
Phát triển & lập tài liệu phần mềm. - Hoạt động:
+ Nhà phân tích hệ thống làm việc với các lập trình viên để phát triển bất kỳ + phần mềm gốc
+ Làm việc với người dùng để phát triển tài liệu hiệu quả
+ Lập trình viên thiết kế, viết mã và loại bỏ các lỗi cú pháp khỏi chương trình máy tính
+ Tài liệu phần mềm với hướng dẫn thủ tục, trợ giúp trực tuyến,
+ Các câu hỏi thường gặp (FAQ) và tệp Read Me - Đầu ra: + Chương trình máy tính + Tài liệu hệ thống Giai đo n 6:ạ
Thử và bảo trì hệ thống - Hoạt động: + Kiểm thử hệ thống + Bảo trì hệ thống + Tài liệu bảo trì - Đầu ra: + Vấn đề, nếu có
+ Cập nhật chương trình + Tài liệu Giai đo n 7:ạ
Triển khai & đánh giá hệ thống - Hoạt động: + Đào tạo người dùng
+ Lập kế hoạch chuyển hệ thống cũ sang hệ thống mới
+ Rà soát và đánh giá hệ thống Đầu ra: - lOMoARcPSD| 36667950
+ Nhân sự được đào tạo
+ Hệ thống được cài đặt
1.9.7.Tác động của bảo trì
- Bảo trì được thực hiện vì 2 lý do
+ Loại bỏ lỗi phần mềm, và
+ Nâng cao phần mềm hiện có
- Tăng cường phần mềm vì 3 lý do
+ Bao gồm các tính năng bổ sung do quy trình nghiệp vụ thay đổi. + Giải quyết các thay
đổi về kinh doanh theo thời gian + Giải quyết các thay đổi về phần cứng và phần mềm.
- Tác động bảo trì
+ Theo thời gian, chi phí bảo trì liên tục sẽ tăng lớn hơn việc tạo ra một hệ thống hoàn toàn mới
+ Tại thời điểm đó, việc thực hiện một nghiên cứu hệ thống mới trở nên khả thi hơn
- Tiêu thụ tài nguyên trong vòng đời hệ thống:
1.9.8.Tiếp cận linh hoạt (Agile)
- Cách tiếp cận linh hoạt là một sự phát triển phần mềm cách tiếp cận dựa trên + Giá trị + Nguyên tắc + Thực tiễn cốt lõi - Giá trị Agile: + Giao tiếp + Đơn giản + Phản hồi + Can đảm
Cách tiếp cận linh hoạt: - lOMoARcPSD| 36667950 + Tương tác + Gia tăng
- Thường xuyên lặp tạo ra các version mới đầy đủ hơn là điều cần thiết cho phát triển hệ thống thành công
- 5 giao đoạn quy trình phát triển mô hình Agile: - Thăm dò
+ tập hợp các đội nhóm + đánh giá kỹ năng
+ tìm công nghệ tiền năng viết
+ Thử nghiệm viết user story
+ Có thái độ vui tươi và tò mò đối với công việc môi trường, các vấn đề, công nghệ và con người - Lập kế hoạch
+ Các quy tắc có thể giúp hình thành sự phát triển nhanh mối quan hệ của nhóm với khách
hàng doanh nghiệp của họ
+ Tối đa hóa giá trị của hệ thống được tạo ra bởi đội Agile
+ Người chơi chính là nhóm phát triển và Khách hàng doanh nghiệp
- Lặp tới bản phát hành đầu tiên
+ Lặp lại là chu kỳ của Thử nghiệm Nhận xét Thay đổi
+ Một mục tiêu là chạy thử nghiệm chức năng do khách hàng viết tại cuối mỗi lần lặp - Sản xuất
+ Sản phẩm được tung ra trong giai đoạn này
+ Có thể được cải thiện bằng cách thêm các tính năng khác - Duy trì
+ Các tính năng mới có thể được thêm vào
+ Các đề xuất của khách hàng rủi ro hơn có thể được xem xét
+ Các thành viên trong nhóm có thể được luân chuyển vào hoặc ra khỏi nhóm
1.9.9.Phương pháp phân tích thiết kế hướng đối tượng
- Cách tiếp cận thay thế cho cách tiếp cận có cấu trúc của SDLC nhằm mục đích tạo thuận lợi
cho sự phát triển của các hệ thống phải thay đổi nhanh chóng để đáp ứng với môi trường kinh doanh năng động
- Sử dụng Ngôn ngữ mô hình hóa thống nhất (UML) để mô hình hóa các hệ thống hướng đối tượng
- Mỗi đối tượng là một đại diện máy tính của một số thực tế sự vật hoặc sự kiện
- Các bước quá trình phát triển UML:
- Vẽ lược đồ Use case Viết kịch bản use case - lOMoARcPSD| 36667950
- Lấy Lược đồ hoạt động Activity Diagram từ Use case
- Phát triển lược đồ trình tự Sequence Diagram
- Tạo lược đồ lớp Class Diagram (Giai đoạn phân tích)
- Vẽ lược đồ tĩnh State chart Diagram (Giai đoạn phân tích) - Sửa đổi sơ đồ và thông số kỹ thuật đầy đủ
- Phát triển và tài liệu hệ thống:
+ Thông tin bạn cung cấp càng đầy đủ cho nhóm phát triển thông qua tài liệu và sơ đồ UML,
sự phát triển càng nhanh và hệ thống sản xuất cuối cùng càng vững chắc 1.9.10.
Định nghĩa mô hình use case
- Xác định các tác nhân và các sự kiện chính do các actor khởi xướng;- Vẽ Use case diagram
- Một sơ đồ với các hình que thể hiện các diễn viên và mũi tên chỉ cách các diễn viên liên quan.
- extend: có thể có
- include: bắt buộc 1.9.11. Vẽ UML Diagram
- Bắt đầu vẽ sơ đồ UML
- Vẽ sơ đồ hoạt động, trong đó minh họa tất cả các hoạt động chính trong ca sử dụng
- Tạo một hoặc nhiều Sequence Diagram cho mỗi trường hợp sử dụng hiển thị trình tự của
- hoạt động và thời gian của họ
- Xem lại các trường hợp sử dụng, suy nghĩ lại về chúng và sửa đổi chúng nếucần thiết.
Giai đoạn thiết kế:
Sửa đổi hệ thống đang có
Sửa đổi biểu đồ được vẽ ở giai đoạn trước
Viết thông số kỹ thuật lớp cho mỗi lớp 1.9.12.
Chọn phương pháp phát triển Tiếếp c n theo SDLCậ các h thốếng đã đệ
ược phát tri n và ghi l i bằằng cách s d ng SDLCể ạ ử
ụ điếằu quan tr ng là ghi l i t ng bọ ạ ừ ước c a quá trìnhủ
qu n lý cấếp trến c m thấếy tho i mái ho c an toàn h n khi s d ng S D L Cả ả ả ặ ơ ử
ụ có đ nguốằn l c và th i
gian đ hoàn thành S D L C đấằy đủ ự ờ ể ủ thống
tn liến l c vếằ cách th c ho t đ ng c a các h thốnế g m i là quan ạ ứ ạ ộ ủ ệ ớ tr ngọ Tiếếp c n theo Phậ
ương có m t nhà vố đ ch d án vếằ các phộ ị ự ương pháp linh ho t trong t ch cạ ổ
ứ pháp Agile các ng d ng cấnằ đứ ụ ược phát tri n
nhanh chóng đ đáp ng nhu cấằu nằng ể ể ứ đ ngộ mối trường Tiếếp cấn theo
m t cu c gi i c u diếễn ra (h thốnế g b lốễi và khống có th i gian đ tm ra ộ hướng đốếi tượng
ộ ả ứ ệ ị ờ ể nguyến nhấn đã sai) lOMoARcPSD| 36667950 khách hàng hài
tch đốằng ý v i các nguyến tằcếớ c a ủ lòng v i nh ng c i tếnế
phương pháp nhanh các vấnế đếằ được mố hình hóa gia
phù h p v i các l p h cợ ớ ớ ọ m t t ch c hốễ tr h c U M tằngớ Lộ ổ ứ ợ ọ
các h thốếng có th đệ ể ược thếm dấằn dấằn, mốễi lấằn m t h ữ ả
thốếng conộ ệ có th s d ng l i phấằn mếằm đã viếết trể ử ụ ạ ước đó giám đốcế điếằu
gi i quyếết các vấến đế ằ khó trả ước có th chấếp nh n để ậ ược hành và nhà phấn 1.9.13.
Mã nguồn mỡ (OSS)
- Một thay thế cho phát triển phần mềm truyền thống
- Nhiều người dùng và lập trình viên có thể nghiên cứu, chia sẻ, và sửa đổi code (mã)
- Phần mềm mã nguồn mở là phần mềm với mã nguồn được công bố, với một giấy phép sử dụng
đi kèm, cho phép bất cứ ai cũng có thể sử dụng, nghiên cứu, thay đổi cải tiến phần mềm và phân
phối phần mềm ở dạng chưa thay đổi hoặc đã thay đổi. 1.10. Trắc nghiệm
1) Open Source software (OSS): Phần mềm được phân phối miễn phí cùng mã nguồn và cho phép
bất cứ ai được thay đổi.
2) UML: cách tiếp cận hướng đối tượng sử dụng chuẩn UML để mô hình hóa các hệ thống theo hướng đối tượng.
3) Documentation: Cho người dùng biết cách sử dụng phần mềm và phải làm gì nếu sự cố phần mềm xảy ra.
4) SDLC: Trong giai đoạn yêu cầu thông tin của SDLC, phân tích viên cố gắng hiểu những thông tin
mà người dùng cần để thực hiện công việc của họ.
5) Agent of change (Tác nhân thay đổi): Vai trò phù hợp của phân tích viên là tác nhân thay đổi.
6) Case respository: Một bách khoa toàn thư được sử dụng để lưu trữ tất cả thông tin trong dự án. Chương 2: Mô hình hóa hệ thống 2.1. Mục tiêu
- Hiểu tổ chức và thành viên của họ là một hệ thống và những nhà phân tích cần có quan điểm hệ thống.
- Dự đoán đồ họa hệ thống bằng cách dùng dữ liệu cấp độ ngữ cảnh, Sơ đồ DFD và mô hình mối
quan hệ thực thể kết hợp, Use case và kịch bản use case -
Nhận ra các cấp độ quản lý khác
nhau yêu cầu các hệ thống khác nhau.
- Hiểu tác động của văn hóa tổ chức lên thiết kế hệ thống 2.2.
Các tổ chức như hệ thống
- Được khái niệm hóa như là một hệ thống được thiết kế để hoàn thành mục tiêu đã định trước
và mục đích/ khách quan.
- Bao gồm những hệ thống nhỏ hơn có liên quan đến nhau ohujc vụ chức năng chuyên dụng. lOMoARcPSD| 36667950
- Các chức năng đặc biệt được khôi phục lại thành một tổng thể tổ chức có hiệu quả
2.2.1.Tính tương quan & tính độc lập của hệ thống
- Tất cả hệ thống và hệ thống con có tính tương quan và tính độc lập lẫn nhau
- Tất cả các quy trình hệ thống đầu vào từ môi trường của nó
- Tất cả hệ thống được lưu trữ ởi ranh giới chia chúng với môi trường của chúng
- Phản hồi hệ thống cho lập kế hoạch và điều khiển
- Một hệ thống lý tưởng tự điều chỉnh hoặc tự điều chỉnh nó
2.2.2.Đầu ra của hệ thống đóng vai trò phản hồi, so sánh hiệu suất với mục tiêu
2.2.3.Môi trường tổ chức
- Cộng đồng : vị trí vật lý, hồ sơ nhân khẩu học (giáo dục, thu nhập)
- Kinh tế: Nhân tố thị trường, đối thủ
- Chính trị: chính quyền tiểu bang và địa phương
- Luật pháp: luật và nguyên tắc liên bang, tiểu bang, khu vục, địa phương 2.2.4.
Hệ thống ảo và nhóm ảo (Virtual)
- Một tổ chức ảo có những bộ phận tổ chức ở những địa điểm khác nhau.
- Mạng lưới máy tính và công nghệ giao tiếp được sử dụng để mang lại nhóm ảo làm việc cùng nhau trong các dự án
2.2.5.Lợi ích của tổ chức ảo và nhóm ảo (Virtual)
- Khả năng làm giảm chi phí của cơ sở vật chất
- Phản hồi nhanh chóng hơn nhu cầu khách hàng
- Giúp nhân viên ảo hoàn thành nghĩa vụ gia đình với con cái hoặc cha mẹ già
2.2.6.Một quan điểm hệ thống (viễn cảnh)
- Cho phép nhà phân tích hiểu doanh nghiệp mà họ sẽ tiếp xúc
- Quan trọng rằng các thành viên của hệ thống con nhận ra rằng họ có mối tương quan với hệ thống con khác
- Xảy ra vấn đè khi mỗi nhà quản lý nghĩ bộ phận mình là quan trọng nhất - Vấn đề lớn hơn
có thể xảy ra khi nhà quản lý đó thăng cấp -
Output này là input cái khác, ngược lại. lOMoARcPSD| 36667950
2.2.7.Hoạch định nguồn lực doanh nghiệp ERP
- Enterprise Resource Planning (ERP) là một hệ thống thông tin tổ chức tích hợp
- Phần mềm giúp luồng thông tin giữa các khu vực chức năng trong tổ chức.
- Gần đây ERP đang chuyển sang đám mây tin học
- Vấn đề khắc phục để cài đặt ERP tuyên bố là thành công thành công:
+ Tính chấp nhận người dùng
+ Tích hợp hệ thống cũ và chuỗi cung ứng
+ Nâng cấp chức năng hoặc linh hoạt của mô hình ERP
+ Tái tổ chức cuộc sống công việc của người dùng và người ra quyết định
+ Mở rộng phạm vi tiếp cận vài tổ chức
+ Chiến lược tái định vị của công ty 2.3.
Đồ họa mô tả hệ thống : DFD, ERP, Use case diagram and kịch bản -
Sơ đồ dữ liệu mức ngữ cảnh DFD
1) Tập trung vào luồng dữ liệu đầu váo và ra của hệ thống và quy trình xử lí của dữ liệu.
2) Thể hiện phạm vi của hệ thống
3) Những gì bao gồm trong hệ thống
4) Thực thể ngoài nằm ngoài phạm vi hệ thống
5) Quá trình là những hành động và nhóm hành động
6) Thực thể là 1 người, nhóm, bộ phận hoặc hệ thống nhận hoặc bắt nguồn thông tin or dữ liệu data. 7) 4 ký hiệu cơ bản:
o Quy trình xử lý (process)
Bi u diếnễ cống vi c x lý d li u trong h thốnế g (ể ệ ử ữ ệ ệ
Data processing) biếnế d ữ li u đấuằ vào input thành đấuằ ra output. ệ
Mốễi process ph i có ít nhấtế m t dòng d li u vào và 1 dòng d li u ả ộ ữ ệ ữ ệ ra
D li u đấằu ra ph i ữ ệ ả khác n i dung ho c d ng th cộ ặ ạ
ứ c a d li u đấằu ủ ữ ệ vào Trong DFD, process nh 1 ư
h p đen, không thấấy các chi tếất x lý bến
trong.ộ ử Chi tếết x lý đử
ược trình bày trong phấằn đ c t quá trình (PS – Process ặ ả lOMoARcPSD| 36667950 Speci 昀椀 caton)
Ký hi uệ : Hình ch nh t tròn bo góc ( hình tròn) ữ ậ
+ Mốễi process có m t sốế nh n d ng ộ ậ ạ
(ID) + Tến process : bằtế
đấuằ là 1 Đ ng tộ ừ
o Dòng dữ liệu (data flow)
Bi u diếnễ để ường đi c a d li u, thành phấằn này đếến thành phấằn khác ủ ữ ệ Ký hi u: ệ
+ Đường thằằng có mũi tến 1 đấằu (th hi n chiếằu di chuy n d li u)ể ệ ể ữ ệ
+ Mốễi dòng d li u có 1 mã sốế nh n d ng (khi dùng CASE tool) ữ ệ ậ ạ
+ Tến dòng d li u nến là: ữ ệ
Danh từ - th hi n n i dung d li u di chuy n trến ể ệ ộ ữ ệ ể đó. Ghi chú:
+ Ký hi u mũi tến hai đấằu ch dòng d li u có th di chuy n c 2 chiếằu, v i ệ ở ỉ
ữ ệ ể ể ả ớ cấấu trúc d li u bến trong giôấng nhauữ ệ . Điếuằ này thường ch
x y ra v i các ỉ ả ớ dòng d li u ra vào kho d li u.ữ ệ ữ ệ
+ Tến dòng d li u ữ ệ không nến đ t trùng nhauặ đ tránh nhấằm lấễn khi mố t t
ể ả ừ đi n d li u sau nàyể ữ ệ
+ Tấtế c các dòng d li u đếằu ph i có tến.ả ữ ệ ả
+ Có th khống ghi tến cho các dòng d li u ra vào kho d li u (vì n i dung ể ữ ệ ữ ệ
ộ trến các dòng này giốếng nh n i dung trong các kho)ư ộ
o Kho dữ liệu (data store)
Bi u diếễn ển i l u trơ ưữ d li u, đ các process khác nhau trong h thốếng s d ng.ữ ệ ể ệ ử ụ
Kho d li uữ ệ sau này seễ đBi u diếnễ đốếi tểược thiếết kếế đ chuy n thành ượểng nằmằể ngoài h
thốếng. c s d li uệơ ở ữ ệ c a h thốnế gủ ệ Ký hi u:ệ
Đốếi tượng có tương tác, cung cấpế d li u, nh n kếết qu t h thốnế g.ữ ệ ậ ả ừ ệ
Hình ch nh t m m t đấằu bến ph i (ho c 2 đữ ậTh c th ngo i: con ngựở
ểộ ạ ảười, t ch c, h thốếng khácặổ ứường song song)ệ Mốễi kho d li
u có m t sốế nh n d ng ữ ệTh c th ngo i = tác nhấn đấuằ cuốếi (ự ểộ ạ
ậ ạ (ID) Terminator)
Tến kho d li u: ữ ệ+ Th c th ngo i cung cấếp d li u: danh tự ểừ - th hi n n i dung l u tr trong khoạể ệ
ộữ ệ ư Source (nguôồn)ữ
+ Th c th ngo i nh n d li u: ự ể ạ ậ ữ ệ Sink (đích)
+ Có th v a là source và sink ể ừ
Ký hi uệ : Hình ch nh t ữ ậ + Tến th c th ngo iự
ể ạ : Danh từ mố t đốếi tả ượng
+ Được veễ l i nhiếuằ lấằn, tránh các dòng d li u cằết nhau (dấếu g ch chéạ ữ ệ ạ
o góc ở hình ch nh t)ữ ậ
o Thực thể ngoài (external entity) lOMoARcPSD| 36667950
o Lỗi: sai về khái niệm, sai về process, sai về liên kết các thành phần. Sai vềề khái nim Thc t h ngoi phi là
cá c tác nhân có kh nă
ng trao đi d l iu
( thông tn) vi h thô ống.
Process mô t mt c ông vic, mt chc năng
x lý d liu, không mô t v trí thc hin
côn g vic đó
Dòng d liu và kho d liu mô t vềề mt
d liu (data) di chuyn và lu tr tr ong h thô ống , không mô t vềề mt vt
ch âtố (material) lOMoARcPSD| 36667950 Sai vềề Process
Process ch c ó dòng d liu ra , không có dòng d liu vào
→ process t ph
át sinh (spontaneous genaraton)
Process ch c ó dòng d liu vào
, không có dòng d liu ra
→ lôỗ đen (black hole)
Các dòng d liu vào ca mt proc ess
không đ đ to các dòng d liu r
a → lôỗ xám (gray hole)
Sai vếằ liến kếết các thành phấằn Không đ c c
ó dòng d liu trc tềp ố gia thc th ngo
i và t hc
th n goi. Không đ c c
ó dòng d liu trc tềp ố gia kho d liu và kho d liu
→ thềm process x lý vào gia. Không đ c c
ó dòng d liu trc tềp ố gia thc th ngo
i và k ho d
liu → thềm process x lý vào
- Các bước xây dựng Sơ đồ DFD:
1) Từ các tài liệu nghiệp vụ xác định các thực thể ngoại, các kho dữ liệu cần lưu trữ, các
chức năng của hệ thống, các dòng dữ liệu quan trọng
2) Xây dựng sơ đồ ngữ cảnh (context diagram)
- Cho ta cái nhìn tổng quát về môi trường làm việc của hệ thống → còn gọi là sơ đồ môi trường. lOMoARcPSD| 36667950
- Toàn bộ hệ thống được nhìn như một hộp đen → biểu diễn bằng một process (đánh số 0)
- Tất cả các thực thể ngoại đều xuất hiện trong sơ đồ này → không được phép vẽ thêm
các thực thể ngoại mới trong các sơ đồ ở các mức sau/
- Tất cả các dòng dữ liệu trao đổi giữa hệ thống với thực thể ngoại- Trong sơ đồ ngữ
cảnh không có kho dữ liệu
- Một số quy ước:
Toàn bộ sơ đồ ngữ cảnh phải nằm trọn trên một trang giấy
Tên của process trong sơ đồ ngữ cảnh nên là tên của hệ thống Tên của thực thể
ngoại và tên các dòng dữ liệu nên ngắn gọn, dễ hiểu
Các dòng dữ liệu không được cắt nhau
3) Xây dựng sơ đồ DFD mức 0 (level 0) -
Sơ đồ mức 0 là sự phân rã của sơ đồ ngữ cảnh → là sơ đồ con (child diagram) của sơ
đồ ngữ cảnh. Để xem xét chi tiết hơn nội dung bên trong của sơ đồ ngữ cảnh. -
Trong sơ đồ mức 0 sẽ chỉ ra các quy trình xử lý chính, các dòng dữ liệu trao đổi giữa
các quy trình này, và các kho dữ liệu dùng chung giữa chúng. -
Sơ đồ mức 0 cần thể hiện lại đầy đủ các thực thể ngoại và các dòng dữ liệu đã xuất
hiện trong sơ đồ ngữ cảnh. -
Một số vấn đề cần lưu ý:
Mỗi process trong sơ đồ mức 0 sẽ được đánh số ID lần lượt là 1, 2, 3, …
Mỗi process ở mức này tương ứng với một chức năng lớn trong hệ thống (thường
tương ứng với mức trên của sơ đồ FHD) -
Kho dữ liệu (trong mức 0): Là các kho lưu dữ liệu dùng chung cho các chức năng khác nhau trong hệ thống. -
Các lỗi sai thường gặp:
Kho dữ liệu chỉ có dòng vào mà không có dòng ra, hoặc chỉ có dòng ra mà không có dòng vào
Kho dữ liệu chỉ có một process sử dụng nên chuyển thành kho nội bộ của process. -
Dòng dữ liệu phân kỳ (Diverging data flow):
+ Dòng dữ liệu trên đó chứa cùng một loại dữnliệu và được chuyển đến cho nhiều vị
trí khác nhau trong sơ đồ.
+ Về nguyên tắc: không được 1 dòng dữ liệu mà dữ liệu trên đó được tách thành
nhiều dòng với các nội dung khác nhau để chuyển đến các nơi khác nhau lOMoARcPSD| 36667950
+ Ký hiệu bổ sung (có thể được dùng ở một số ng) -
Dòng dữ liệu hội tụ (converging data flow)
+ Về nguyên tắc: không có 1 dòng được tạo từ nhiều dòng.
+ Ký hiệu bổ sung (thay vì dùng process kết hợp 3 dòng)
4) Xây dựng sơ đồ DFD ở các mức chi tiết
- Chi tiết hóa các quá trình còn mang tính tổng quát, chưa thể dùng để thiết kế thành các
thành phần trong chương trình như: form, report, … - Quy tắc:
ID của process trong sơ đồ con sẽ bao gồm ID của sơ đồ cha + số thứ tự của process trong sơ đồ con
VD: Khi phân rã process 2, thì các process trong sơ đồ con sẽ được đánh số là 2.1, 2.2, 2.3, …
- Mỗi sơ đồ DFD (kể cả mức 0) chỉ nên có từ 7 – 9 process, và vẽ trên một trang giấy
- Tính phân mức (leveling):
+ Là quá trình tăng dần mức độ chi tiết trong các sơ đồ ở mức thấp hơn cho đến khi
đạt được mức chi tiết mong muốn, tức là tất cả các process trong sơ đồ đều là
nguyên tố (primitive process) lOMoARcPSD| 36667950
+ Process nguyên tố là process chỉ còn bao gồm một chức năng cụ thể, không thể tiếp
tục phân rã được nữa. Process này có thể chuyển giao để lập trình viên viết chương trình.
+ Cần tổ chức sơ đồ tránh tình trạng một process phân rã quá sâu trong khi các process
khác thì việc phân rã lại dừng rất sớm.
- Tính cân bằng (balancing):
+ Khi phân rã phải đảm bảo sự nhất quán giữa các sơ đồ
+ Các dòng dữ liệu vào và dòng dữ liệu ra của sơ đồ cha phải được bảo toàn trong sơ đồ con.
Kho dữ liệu có thể xuất hiện trong sơ đồ con mà không cần xuất hiện trước đó trong sơ
đồ cha. Đây là trường hợp các kho dữ liệu cục bộ, chỉ có các process trong sơ đồ con sử dụng mà thôi.
5) Kiểm tra sơ đồ ở các cấp để phát hiện lỗi
6) Xây dựng sơ đồ DFD vật lý (physical DFD) từ sơ đồ DFD luận lý (logical DFD)
Đ c đi m thiếết kếếặ ể Logical (Lu n lý)ậ Physical (V t lý)ậ Mố hình mô tả
Ho t đ ng nghi p v nh thếế nàoạ ộ ệ ụ ư H
thốếng seễ cài đ t / đang ệ ặ v n hành nh thếế nàoậ ư Process (th hi nể
ệ )Ho t đ ng nghi p vạ ộ ệ
ụChương trình, module, và
các th t c x lý th cốngủ ụ ử ủ Data store
Các lo i d li u trong h thốếng, ạ ữ ệ ệ
Các t p tn v t lý và CSDLậ ậ
Không quan tấm cách l u trưữ Lo i data storeạ Các d li u l u tr ữ ệ ư
ữ lấu dài trong h ệ T p tn chính, t p tn giao ậ ậ thốếng d ch,…ị Ki m soát h ể ệ
Ki m soát vếằ nghi p vể ệ ụ Ki m soát all: tnh h p l ể ợ ệ thốếng
d li u đấuằ vào, b o m t ữ ệ ả ậ h thốếng. ệ
7) Phân hoạch (partitioning) sơ đồ DFD vật lý
- Mô hình thực thể kết hợp
+ Tập trung vào các thực thể và mối quan hệ trong hệ thống tổ chức.
+ Một cách khác thể hiện phạm vi hệ thống.
+ Mối quan hệ thể hiện cách các thực thể kết nối. 3 loại mqh: 1-1, 1-n, nn + Thực thể:
o Fundamental entity (Thực thể): Đối tượng dữ liệu cơ bản o Associative
entity (Liên kết): Kết hợp 2 thực thể lOMoARcPSD| 36667950
o Attributive entity (Thuộc tính): Mô tả thuộc tính, đặc biệt lặp nhóm. Thuộc
tính có thể thêm vào diagram.
+ Tạo Sơ đồ thực thể kết hợp:
o liệt kê các thực thể trong tổ chức
o chọn khóa các thực thể để hạn chế phạm vi vấn đề o nhận diện khóa chính
của thực thể o xác nhận kết qủa trên thông qua thu thập dữ liệu - Mô hình Use case:
+ Mô hình Use case Modeling:
o Một phần của ngôn ngữ mô hình hóa thống nhất (UML) o Mô tả những gì hệ
thống làm mà không có mô tả cách thức hoạt động của hệ thống.
o Xem các yêu cầu hệ thống
o Nhà phân tích làm việc với các chuyên gia kinh doanh để phát triển + Use case Diagram: o Tác nhân:
Đếằ c p t i vai trò c th ngậ ớ ụ ể ười dùng = th c th ngoài, bến ngoài h thốếng.
ự ể ở ệ Chia 2 nhóm actor: Primary actors:
+ Cung cấpế d li u ho c nh n thống tn t h thốếng ữ ệ ặ ậ ừ ệ
+ Cung cấpế thống tn chi tếtế vếằ vi c use case nến làm ệ
Supportng actors: Người điếằu hành b ph n help, nhà phấn tch,l p trình viếnộ ậ
ậ + Giúp duy trì ho t đ ng h thốếng ho c cung cấpế tr giúpạ ộ ệ ặ ợ
o Ký hiệu Use case: Hình bầu dục - nhiệm vụ của use case o Đường nối: Mũi tên
và đường dùng để vẽ sơ đồ hành vi các mối quan hệ
o Use case cung cấp 3 thứ:
M t tác nhấn bắất đấồu s ki nộ ự ệ
S ki n kích ho t Use caseự ệ ạ
Use case th c hi n các hành đ ng kích ho t (trigger) b i s kiến ự ệ ộ ạ ở ự
o Mối quan hệ Use case:
Mốếi Giao tếếp: Dùng đ kếết nốếi 1 tác nhấn v i 1 Use caseể ớ quan hệ
Bao gốmằ: Mố t tnh huốếng trong đó có 1 use case ch a hành vi ả ứ
hành vi ph biếnế h n 1 use caseổ ơ
M r ng (ở ộ Extends): Mố t tnh huốnế g 1 Use case s h u có hành vi
ả ở ữ cho phép Use case m i đ x lý biếến th ho c ngo i l t Use case ớ
ể ử ể ặ ạ ệ ừ c b nơ ả
Khái quát hóa (generalizes): 1 cái đi n hình h n cái khácể ơ 4 lo i ạ mqh – đường lOMoARcPSD| 36667950 Giao tếấp
M t actor kếết nốếi v i 1 use case (khống mũi tến)ộ ớ
Bao gôồm (bắất bu c
có)ộ M t Use case ch a các hành vi chung nhiếằu Use case khác, mũi tếnộ ứ ch vào Use case chungỉ
M r ng (k bắất bu c)ở ộ
ộ M t use case khác x lý các ngo i l t Use case c b n (mũi tến
ộ ử ạ ệ ừ ơ ả t m r ng đếnế Use case gốếc/ c b n)ừ ở ộ ơ ả
khái quát hóa M t th
UML t ng quát h n 1 th khác. Mũi tến ch điếằu t ng ộ ứ ổ ơ ứ ỉ ổ quát
o Phát triển phạm vi hệ thống
Ph m vi h thốếng xác đ nh ranh gi i c a nó:ạ ệ ị ớ ủ
▪ N i dung bến trong ho c bến ngoài h thốếngộ ặ ệ
▪ D án có ngấn sách giúp xác đ nh ph m viự ị ạ
D án có th i đi m bằết đấằu và kếết thúc▪ ự ờ ể
▪ Tác nhấn luốn nằằm ngoài ph m viạ
▪ Đường dấy liến l c là ranh gi i và xác đ nh ph m viạ ớ ị ạ
o Phát triển sơ đồ Use case
Xem xét các thông sôấ kyỹ thu tậ kinh doanh và xác đ nh các tác nhấn tham giaị
Xác đ nh các s ki n cấếp cao và phát tri n các trị ự ệ ể ường h p s d ng chính
mốợ ử ụ t các s ki n đó và cách các diếễn viến bằết đấằu chúngả ự ệ Xem l i t ng
trạ ừ ường h p s d ng chính đ xác đ nh các biếến th có th có c aợ ử ụ ể ị ể ể ủ
luốằng thống qua trường h p s d ngợ ử ụ
S đốằ DFD m c ng c nh có th ho t đ ng làm ơ ứ ữ ả ể ạ ộ đi m kh i đấồuể ở đ t o
trể ạ ường h p s d ngợ ử ụ
o Phát triển kịch bản Use case: 3 lĩnh lực chính lOMoARcPSD| 36667950 Đnh danh và
Khu vc t ếu đếằ Use Case
bắất đấồ u u se case
Có tến và ID duy nhấtế Bao gốằm lĩnh vc ng dng Lit ệk ế tác nhấn
Bao gốằm các bến liến quan Bao gốằm mc đ Có
mố t ng ằến gn v ếằ ca s dn g Các b c S dn g c ác cấu chuyn lin ệ h hot, xác đ
nh vấế n đếằmc tếu, thc hi n ệ yếu cấằu ca ng i dù ng hoc m t tnh nằngdanh sách
Hi v ế ằnhng cống vic ph ệ i làm Xác đnh
xem có bấết kỳ s lp li ho chàn h đng lp Ca s dn g k
ếết thúc khi mc tế u ca khá ch hàng hoàn tấết Điếồu kin , gi đn h, cấu hi
o Lợi ích dùng Use case:
Xác định tất cả các tác nhân trong miền vấn đề
Các hành động cần hoàn thành cũng được thể hiện rõ ràng trên sơ đồ Use case
▪ Kịch bản Use case đáng giá
Đơn giản và thiếu chi tiết kỹ thuật
Những lý do chính để viết các ca sử dụng là tính hiệu quả của chúng trong
Giao tiếp với người dùng và nắm bắt câu chuyện của người dùng
▪ Các Use case sử dụng truyền đạt các yêu cầu hệ thống một cách hiệu quả
bởi vì các sơ đồ được giữ đơn giản.
▪ Các Use case sử dụng cho phép mọi người kể chuyện. ▪ Câu chuyện Use case
có ý nghĩa đối với những người không có kỹ thuật.
▪ Các Use case sử dụng không phụ thuộc vào một ngôn ngữ đặc biệt.
▪ Các Use case sử dụng có thể mô tả hầu hết các yêu cầu chức năng (chẳng hạn
như tương tác giữa các tác nhân và ứng dụng). ▪ Ca sử dụng có thể mô tả các
yêu cầu phi chức năng (chẳng hạn như hiệu suất và khả năng bảo trì) thông qua
việc sử dụng khuôn mẫu.
▪ Các Use case sử dụng giúp nhà phân tích xác định ranh giới.
▪ Các Use case sử dụng có thể được theo dõi, cho phép các nhà phân tích xác
định các liên kết giữa các Use case sử dụng và các công cụ tài liệu và thiết kế khác. 2.3.1.Phân tích bottom-up
- Một số phân tích viên sử dụng chiến lược bottom-up. nhận diện tất cả các process nguyên tố,
các kho dữ liệu, các dòng dữ liệu và các thực thể ngoại.
- Sau đó ta sẽ nhóm các thành phần có quan hệ lại với nhau để tạo thành cácsơ đồ ở mức thấp.
- Tiếp tục nhóm các sơ đồ mức thấp lại để tạo dần thành các sơ đồ mức cao hơn. lOMoARcPSD| 36667950
- quy trình này được tiếp tục thực hiện cho đến khi ta đạt được mức 0, rồi mức ngữ cảnh. 2.4. Kiểm soát hoạt động
- ▪ Đưa ra quyết định sử dụng các quy tắc được xác định trước có kết quả dự đoán được
- ▪ Giám sát chi tiết hoạt động của tổ chức
- Lập kế hoạch quản lý và kiểm soát
+ ▪ Lập kế hoạch và kiểm soát ngắn hạn quyết định về tài nguyên và mục tiêu tổ chức
+ ▪ Các quyết định có thể mang tính tác nghiệp một phần và một phần chiến lược
- Quản lý chiến lược:
+ ▪ Hướng ngoại từ tổ chức đến tương lai
+ ▪ Đưa ra các quyết định hướng dẫn cấp trung và quản lý hoạt động
+ ▪ Làm việc trong tình trạng ra quyết định rất không chắc chắn môi trường
+ ▪ Đối mặt với các vấn đề bán cấu trúc
+ ▪ Xác định toàn bộ tổ chức
- Các cấp quản lý: hoạt động, quản lý cấp trung, chiến lược
+ Cơ cấu tổ chức khác nhau
+ ▪ Phong cách lãnh đạo
+ ▪ Cân nhắc về công nghệ + ▪ Văn hóa tổ chức
+ ▪ Tương tác của con người
+ ▪ Tất cả đều mang hàm ý cho việc phân tích và thiết kế hệ thống thông tin
- Hợp tác thiết kế
+ ▪ Các bên liên quan bên ngoài và bên trong tuân theo các quy trình để chia sẻ trong việc
thiết kế một hệ thống để đáp ứng mục tiêu của họ
+ ▪ Trao quyền lực cho những người sở hữu huyên môn kỹ thuật hoặc chiến lược 2.5. Văn hóa tổ chức
- Tổ chức có văn hóa và nhóm văn hóa
- ▪ Học từ ngôn ngữ và biểu tượng phi ngôn ngữ.
- Tác động của công nghệ đến văn hóa
+ ▪ Công nghệ đang thay đổi văn hóa của tổ chức và nhóm
+ ▪ Slack là một mạng xã hội được nhà tuyển dụng chấp nhận nền tảng truyền thông hoặc
ứng dụng nhắn tin tại nơi làm việc
+ ▪ Các kênh công khai và riêng tư
+ ▪ Tin nhắn trực tiếp hoặc nhóm Chương 3: Thu thập thông tin 3.1. Phỏng vấn
3.1.1.Chuẩn bị phỏng vấn -
Thiết lập mục tiêu phỏng vấn -
Chuẩn bị cho người được phỏng vấn - Đọc tài liệu nền -
Quyết định ai sẽ phỏng vấn lOMoARcPSD| 36667950 -
Quyết định loại câu hỏi và cấu trúc 3.1.2.Loại câu hỏi
- Câu hỏi mở: cho phép người được phỏng vấn để trả lời như thế nào họ muốn mà không cần
quan tâm chiều rộng và chiều sâu của câu trả lời Ý kiến của bạn về tình hình kinh doanh hiện tại?
kinh doanh thương mại điện tử trong công ty của bạn?
Các mục tiêu quan trọng của bộ phận của bạn là gì?
Mô tả quy trình giám sát có sẵn trực tuyến
Những thất vọng lớn nhất mà bạn đã trải qua trong quá trình chuyển đổi sang thương mại điện tử là gì?
Một số lỗi nhập dữ liệu phổ biến được thực hiện trong bộ phận này?
Sau khi dữ liệu được gửi qua trang web, chúng được xử lý như thế nào?
+ Ưu/ nhược câu hỏi mở Ưu đi mể Nhược đi mể
Khiếến người được ph ng vấnế c m thấếy tho i ỏ ả ả Có th dấnễ
đếnế quá nhiếằu chi tếết khống liến ể mái quan
▪ Cho phép người ph ng vấến tếếp thu t v ngỏ ừ ự
▪ Có th mấết ki m soát cu c ph ng vấếnể ể ộ ỏ c a ngủ
ười được ph ng vấếnỏ
▪ Cung cấếp s phong phú vếằ chi tếếtự
▪ Có th mấết quá nhiếằu th i gian cho lể ờ
ượng thống tn h u ích thu đữ ược Tiếết l nh ng hộ
ữướng đ t cấu h i tếếp theo có ặ ỏ▪ Có v nh ngẻ ư
ười ph ng vấến ch a chu n b ỏ ưẩ ị th ch a để ư ược khai thác trước
Cung cấếp thếm s quan tấm cho ngựười được ▪ Có th t o ấến tể ạượng rằằng người ph ng vấến ỏ ph ng vấnếỏ
đang trong m t “cu c thám hi m cấu cá”ộ ộ ể
▪ Cho phép t phát h nự ơ Giúp cho ng i ph ng vấến có th di ể ếễn đt dếễ dàng hn Hu ích n ếếu ng i ph ng vấến khống chun b t r c
- Câu hỏi đóng: thích hợp khi nhà phân tích quan tâm đến là độ rộng và độ sâu của câu trả lời
+ Giới hạn số lượng câu trả lời có thể
+ Tạo dữ liệu đáng tin cậy dễ phân tích
+ Phương pháp hiệu quả và yêu cầu 1 ít kỹ năng cho phỏng vấn để quản lý o Kho lưu trữ dự án
được cập nhật bao nhiêu lần một tuần? o ▪ Trung bình mỗi tháng tổng đài nhận
được bao nhiêu cuộc gọi? o ▪ Nguồn thông tin nào sau đây có giá trị nhất đối với
bạn? o ▪ Mẫu đơn khiếu nại của khách hàng đã hoàn thành o ▪ Gửi email khiếu
nại từ người tiêu dùng truy cập trang web o ▪ Tương tác trực tiếp với khách hàng
o ▪ Hàng bị trả lại
o ▪ Liệt kê hai ưu tiên hàng đầu của bạn để cải thiện cơ sở hạ tầng công nghệ. lOMoARcPSD| 36667950
o ▪ Ai nhận thông tin đầu vào này? + Ưu/ Nhược Ưu đi mể Nhược đi mể
Tiếết ki m th i gian ph ng vấếnệ ờ ỏ Có th
gấy nhàm chán cho ngểười được ph ngỏ vấến
Dếễ dàng so sánh các cu c ph ng vấếnộ ỏ
▪ Có th khống thu để ược nhiếằu chi tếết
Nhanh chóng đi th ng vào vấến đếằẳ
▪ Có th b sót m t sốế ý chínhể ỏ ộ
Duy trì ki m soát cu c ph ng vấnếể ộ ỏ ▪ Có th khống xấy d ng để ự ược mốếi quan h ệ gi a ngữ ười ph ng vấếnỏ
Bao ph m t khu v c r ng l n m t cách ủ ộ ự ộ ớ ộ nhanh chóng
Lấyế d li u liến quanữ ệ
- Các thuộc tính của câu hỏi mở và câu hỏi đóng: độ tin cậy, hiệu
- Câu hỏi lưỡng cực: (Bipolar)
+ Trả lời với Yes / No hoặc Đồng ý / Không đồng ý + Dùng hạn chế + Dạng
câu hỏi đóng đặc biệt
- Câu hỏi thăm dò (Probes)
+ Mở ra nhiều chi tiết cho câu hỏi trước
+ Mục đích: Để có thêm ý nghĩa, Làm rõ,
Rút ra và mở rộng quan điểm của người được phỏng vấn
+ Có thể là mở hoặc đóng lOMoARcPSD| 36667950 3.1.3.Sắp xếp câu hỏi - Kim tự tháp:
+ Bắt đầu với câu hỏi đóng và hướng đến câu hỏi mở
+ Bắt đầu với những câu hỏi rất chi tiết, thường đóng
+ ▪ Mở rộng bằng cách cho phép các câu hỏi mở và phản ứng tổng quát hơn nữa
+ ▪ Sẽ hữu ích nếu người được phỏng vấn cần được làm quen với chủ đề hoặc có vẻ miễn
cưỡng để giải quyết chủ đề - Ống phễu: + Mở -> đóng
+ Bắt đầu với những câu hỏi mở, tổng quát
+ ▪ Kết luận bằng cách thu hẹp các câu trả lời có thể sử dụng câu hỏi đóng
+ ▪ Cung cấp một cách dễ dàng, không nguy hiểm để bắt đầu một phỏng vấn
+ ▪ Hữu ích khi người được phỏng vấn cảm thấy xúc động về chủ đề - Kim cương
+ Đóng -> mở -> đóng
+ Một cấu trúc hình kim cương bắt đầu theo một cách rất cụ thể
+ ▪ Sau đó, các vấn đề tổng quát hơn sẽ được xem xét
+ ▪ Kết luận bằng những câu hỏi cụ thể
+ ▪ Kết hợp sức mạnh của cả kim tự tháp và phễu cấu trúc
+ ▪ Mất nhiều thời gian hơn các công trình khác 3.1.4.Báo cáo phỏng vấn
- Kết thúc cuộc phỏng vấn
+ ▪ Luôn hỏi “Có điều gì khác mà bạn muốn thêm vào?"
+ ▪ Tóm tắt và cung cấp phản hồi về ấn tượng của bạn
+ ▪ Hỏi xem bạn nên nói chuyện với ai tiếp theo + ▪ Thiết lập
bất kỳ cuộc hẹn nào trong tương lai + ▪ Cảm ơn họ đã dành thời gian và bắt tay.
- Báo cáo phỏng vấn
+ ▪ Viết càng sớm càng tốt sau cuộc phỏng vấn
+ ▪ Cung cấp tóm tắt ban đầu, sau đó chi tiết hơn
+ ▪ Xem xét báo cáo với người trả lời 3.2.
Câu chuyện của người dùng
- Những câu chuyện
+ ▪ Chuyện bắt nguồn nơi công sở
+ ▪ Các câu chuyện về tổ chức được sử dụng để chuyển tiếp một số loại thông tin
+ ▪ Khi một câu chuyện được kể đi kể lại theo thời gian, nó mang hơi hướng tính thần thoại.
+ ▪ Những câu chuyện biệt lập rất tốt khi bạn đang tìm kiếm sự thật
+ ▪ Những câu chuyện lâu dài nắm bắt tất cả các khía cạnh của tổ chức và là những thứ mà một
nhà phân tích hệ thống nên tìm kiếm - Nghe kể chuyện
+ ▪ Nghe kể chuyện không hiệu quả
+ ▪ Tốn nhiều thời gian hơn so với đặt câu hỏi phỏng vấn lOMoARcPSD| 36667950
+ ▪ Nghe kể chuyện có thể bổ ích hơn
+ ▪ Các câu chuyện dễ nhớ hơn các câu trả lời phỏng vấn
- Tất cả các câu chuyện đều có những yếu tố sau: + ▪ Kêu gọi phiêu lưu + ▪ Nhiệm vụ + ▪ Cuộc đấu tranh + ▪ Sự chuyển đổi + ▪ Nghị quyết + ▪ Đạo đức + ▪ Phần kết - Lý do kể chuyện
+ ▪ Bản thân thông tin phong phú từ việc lắng nghe cẩn thận các câu chuyện đã có giá trị
+ ▪ Thông tin thu thập được từ các câu chuyện sẽ có ý nghĩa hơn và có giá trị hơn nếu được đặt trong bối cảnh
- Câu chuyện kinh doanh có thể được chia thành 4 loại chính quan trọng:
+ ▪ Câu chuyện trải nghiệm + ▪ Truyện thuyết minh
+ ▪ Xác thực các câu chuyện + ▪ Chuyện kê đơn
- Câu chuyện và Tổ chức
+ ▪ Thu hút những người tham gia tổ chức bằng cách phản ứng lại các câu chuyện
+ ▪ Nối câu chuyện này với câu chuyện khác bằng cách kể lại cho những người tham gia khác
nghe và cộng tác với các câu chuyện
+ ▪ Đó là cách hiểu sâu sắc một số vấn đề liên quan đến hệ thống thông tin
- Có bốn mục đích để kể một câu chuyện:
+ ▪ Các câu chuyện trải nghiệm mô tả doanh nghiệp hoặc ngành đó như thế nào
+ ▪ Các câu chuyện giải thích cho biết tại sao tổ chức lại hành động theo một cách nhất định
+ ▪ Các câu chuyện xác thực được sử dụng để thuyết phục mọi người rằng tổ chức đã đưa ra quyết định đúng đắn
+ ▪ Những câu chuyện có tính quy định cho người nghe biết cách hành động
+ ▪ Các nhà phân tích hệ thống có thể sử dụng kể chuyện để bổ sung cho các phương pháp thu thập thông tin khác 3.3.
Thiết kế ứng dụng chung (JAD) 3.3.1. Sự tham gia
- Thiết kế ứng dụng chung (JAD) có thể thay thế một loạt các cuộc phỏng vấn với cộng đồng người dùng
- JAD là một kỹ thuật cho phép nhà phân tích thực hiện phân tích yêu cầu và thiết kế giao diện
người dùng với người dùng trong cài đặt nhóm
- Các điều kiện hỗ trợ việc sử dụng JAD
+ ▪ Người dùng bồn chồn và muốn một cái gì đó mới
+ ▪ Văn hóa tổ chức hỗ trợ các hành vi chung giải quyết vấn đề
+ ▪ Các nhà phân tích dự báo số lượng ý tưởng sử dụng JAD sẽ tăng lên lOMoARcPSD| 36667950
+ ▪ Nhân viên có thể vắng mặt trong thời gian yêu cầu
- ▪ Những người liên quan là:
+ ▪ Nhà tài trợ điều hành + ▪ Nhà phân tích IS + ▪ Người dùng + ▪ Trưởng phiên + ▪ Người quan sát + ▪ Người ghi chép 3.3.2. Địa điểm
- Tổ chức các cuộc họp JAD ở đâu + ▪ Ngoại vi
+ ▪ Môi trường xung quanh thoải mái
+ ▪ Giảm thiểu phiền nhiễu + ▪ Điểm danh
+ ▪ Lịch trình khi người tham gia có thể tham dự
+ ▪ Chương trình nghị sự + ▪ Họp định hướng
- Lợi ích/ hạn chế của JAD: L i ích ợ H n chếếạ
Tiếết ki m th i gian so v i ph ng vấến truyếằnệ ờ ớ ỏ ▪ JAD yếu
cấằu m t kho ng th i gian l n ộ ả ờ ớ thốếng
đ sằễn sàng cho tấết cể ả
Phát tri n nhanh các h thốnế gể ệ người tham gia phiến
C i thi n quyếằn s h u c a ngả ệ
ởữ ủ ười dùng đốếi
▪ Nếếu vi c chu n b ho c báo cáo tếpế ệ ẩ ịặ v i h thốếngớ ệ
theo khống đấyằ đ ,ủ
S n xuấết ý tả ưởng sáng t o đạ ược c i ả phiến có th khống thành cốngể thi nệ 3.4. Bảng câu hỏi 3.4.1.Viết câu hỏi
- Bảng câu hỏi rất hữu ích trong việc thu thập thông tin từ các thành viên chủ chốt của tổ chức về: + ▪ Thái độ + ▪ Niềm tin + ▪ Hành vi + ▪ Đặc điểm
- Lập kế hoạch sử dụng bảng câu hỏi
+ ▪ Thành viên tổ chức phân tán rộng rãi
+ ▪ Nhiều thành viên tham gia dự án
+ ▪ Công việc thăm dò là cần thiết
+ ▪ Cần giải quyết vấn đề trước khi phỏng vấn lOMoARcPSD| 36667950
- Các loại câu hỏi (2/2)) + Câu hỏi mở
▪ Cố gắng lường trước câu trả lời mà bạn sẽ nhận được
▪ Rất thích hợp để lấy ý kiến + Câu hỏi đóng
▪ Sử dụng khi tất cả các tùy chọn có thể được liệt kê
▪ Khi các quyền chọn loại trừ lẫn nhau
- Đánh đổi giữa việc sử dụng câu hỏi mở và câu hỏi đóng trên bảng câu hỏi
- Ngôn ngữ bảng câu hỏi + ▪ Đơn giản + ▪ Cụ thể + ▪ Ngắn gọn + ▪ Không bề trên + ▪ Không thiên vị
+ ▪ Dành cho những người hiểu biết
+ ▪ Chính xác về mặt kỹ thuật
+ ▪ Phù hợp với trình độ đọc của người trả lời 3.4.2.Sử dụng thang đo
Hai hình thức thang đo lường khác nhau là: - ▪ Thang đo Danh nghĩa
+ Thang đo danh nghĩa dùng để phân loại sự vật
+ ▪ Đây là hình thức đo lường yếu nhất
+ ▪ Dữ liệu có thể được tính tổng . Nam nữ,
B n s d ng lo i phấằn mếằm nào nhiếằu nhấết?ạ ử ụ ạ 1 = B x lý vằn b nộ ử ả 2 = B ng tnhả 3 = C s d li uơ ở ữ ệ 4 = M t chộ ương trình email -
▪ Thang đo Khoảng thời gian
+ ▪ Thang đo khoảng được sử dụng khi các khoảng bằng nhau
+ ▪ Không có số 0 tuyệt đối lOMoARcPSD| 36667950
+ ▪ Ví dụ về thang đo quãng bao gồm Fahrenheit hoặc thang độ C. -
Tính hợp lệ và độ tin cậy:
+ Độ tin cậy của thang đo đề cập đến tính nhất quán trong phản hồi—thu được kết
quả giống nhau nếu cùng một bảng câu hỏi được thực hiện lại trong cùng điều kiện
+ Giá trị là mức độ mà câu hỏi đo lường những gì nhà phân tích dự định đo lường -
Vấn đề với Thang đo Khoan dung (Leniency)
+ ▪ Do người đánh giá dễ dãi
+ ▪ Giải pháp là chuyển danh mục “trung bình” sang bên trái hoặc bên phải của trung tâm
Xu hướng tập trung (central tendency) o ▪ Xu hướng tập trung xảy ra khi người trả lời đánh giá
mọi thứ ở mức trung bình
o ▪ Cải thiện bằng cách thu nhỏ sự khác biệt ở hai kết thúc
o ▪ Điều chỉnh độ mạnh của các bộ mô tả o ▪ Tạo thang điểm với nhiều
điểm hơn Hiệu ứng hào quang (Halo effect)
+ Khi ấn tượng được hình thành trong một câu hỏi chuyển thành câu hỏi tiếp theo
+ Giải pháp là đặt một đặc điểm và một số mục trên mỗi trang 3.4.3.Thiết kế
- Thiết kế bảng câu hỏi
+ ▪ Cho phép có nhiều khoảng trắng
+ ▪ Dành nhiều không gian để viết hoặc nhập câu trả lời
+ ▪ Giúp người trả lời dễ dàng đánh dấu rõ ràng câu trả lời của họ
+ ▪ Nhất quán về phong cách
- Thứ tự câu hỏi
+ ▪ Đặt những câu hỏi quan trọng nhất lên đầu tiên
+ ▪ Nhóm các mục có nội dung tương tự lại với nhau
+ ▪ Giới thiệu những câu hỏi ít gây tranh cãi trước
3.4.4.Quản lý / Quản trị
- Quản lý bảng câu hỏi có hai câu hỏi chính:
+ ▪ Ai trong tổ chức sẽ nhận được bảng câu hỏi
+ ▪ Nên thực hiện bảng câu hỏi như thế nào - Thiết kế một trang web khảo sát: lOMoARcPSD| 36667950
- Gửi bảng câu hỏi điện tử: + ▪ Giảm chi phí
+ ▪ Thu thập và lưu trữ kết quả điện tử 3.5. Phương pháp kín đáo
phương pháp không phô trương Ít gây rối hơn
Phân tích văn bản để phân tích dữ liệu định tính
Không đủ khi sử dụng một mình
Tiếp cận đa phương pháp
Dùng kết hợp với các phương pháp tương tác 3.6. Lấy mẫu
- Lấy mẫu: Một quá trình lựa chọn một cách có hệ thống các yếu tố đại diện của dân số liên quan
đến 2 quyết định chính: + Kiểm tra gì?
+ Những người cần xem xét
+ Lấy mẫu giúp đẩy nhanh quá trình bằng cách thu thập dữ liệu được chọn thay vì tất cả dữ
liệu cho toàn bộ dân số
+ Nhà phân tích hệ thống không phải chịu gánh nặng phân tích dữ liệu từ toàn bộ dân số
- Lý do các nhà phân tích hệ thống thực hiện lấy mẫu là để + Kiềm chế chi phí
+ Tăng tốc độ thu thập dữ liệu + Nâng cao hiệu quả lOMoARcPSD| 36667950
+ Có thể giảm sai lệch thu thập dữ liệu bằng cách lấy mẫu + Quá tốn kém để
+ Kiểm tra từng mẩu giấy
+ Nói chuyện với mọi người
+ Đọc mọi trang Web từ tổ chức
- Hiệu quả lấy mẫu
Lấy mẫu có thể giúp nâng cao hiệu quả nếu thông tin đó là chính xác hơn có thể thu được
Điều này được thực hiện bằng cách nói chuyện với ít nhân viên hơn nhưng hỏi họ
những câu hỏi chi tiết hơn
Nếu ít người được phỏng vấn hơn, nhà phân tích hệ thống có nhiều thời gian hơn để
theo dõi dữ liệu bị thiếu hoặc không đầy đủ
- Xu hướng lấy mẫu
+ Có thể giảm sai lệch thu thập dữ liệu bằng cách lấy mẫu
+ Khi nhà phân tích hệ thống hỏi ý kiến về một tính năng cố định của hệ thống thông tin đã
cài đặt, người điều hành được phỏng vấn có thể đưa ra đánh giá thiên vị vì có rất ít khả năng thay đổi nó.
- Để thiết kế một mẫu tốt, nhà phân tích hệ thống phải tuân theo 4 bước:
+ Xác định dữ liệu sẽ được thu thập hoặc mô tả
+ Xác định quần thể lấy mẫu
+ Chọn loại mẫu + Quyết định cỡ mẫu - 4 loại mẫu chính: Sự tiện lợi
Mẫu thuận tiện là mẫu không giới hạn, phi xác suất
Mẫu này dễ sắp xếp nhất
Mẫu không đáng tin cậy nhất Mục đích
Mẫu có mục đích dựa trên phán đoán
Chọn một nhóm các cá nhân có vẻ hiểu biết và quan tâm đến hệ thống thông tin mới Mẫu phi xác suất
Chỉ có độ tin cậy vừa phải
Ngẫu nhiên đơn giản
Mẫu ngẫu nhiên phức tạp: phù hợp nhất cho nhà phân tích hệ thống là Lấy mẫu hệ thống Lấy mẫu phân tầng Lấy mẫu theo cụm
- Quyết định cỡ mẫu Xác định thuộc tính
Định vị cơ sở dữ liệu hoặc báo cáo trong đó có thể tìm thấy thuộc tính Kiểm tra thuộc tính
Đưa ra quyết định chủ quan về ước tính khoảng chấp nhận được Chọn mức độ tin cậy Tính sai số chuẩn lOMoARcPSD| 36667950 Xác định cỡ mẫu 3.7.
Phân tích tài liệu định lượng -
Điều tra: Hành động khám phá và phân tích dữ liệu - Dữ liệu cứng: + Định lượng + Định tính -
Phân tích tài liệu định lượng
+ Các báo cáo dùng để ra quyết định o Báo
cáo bán hàng o Báo cáo sản xuất o Báo cáo tổng hợp o
Báo cáo hiệu suất cho thấy sự cải thiện o
Hoàn thành thủ công o Biên nhận thanh toán + Báo cáo hiệu suất + Hồ sơ o
Hồ sơ cung cấp thông tin cập nhật định kỳ về những gì đang diễn ra trong doanh nghiệp o
Có một số cách để kiểm tra hồ sơ:
Kiểm tra sai sót về số tiền và tổng số
Tìm kiếm cơ hội cải tiến thiết kế biểu mẫu ghi chép
Quan sát số lượng và loại giao dịch
Theo dõi các trường hợp máy tính có thể đơn giản hóa công việc (tính toán
và thao tác dữ liệu khác)
+ Biểu mẫu thu thập dữ liệu o Thu thập các ví dụ về tất cả các biểu mẫu đang được sử
dụng o Lưu ý loại biểu mẫu o Ghi lại mô hình phân phối dự định o
So sánh mẫu phân phối dự định với người thực sự nhận mẫu o
Biểu mẫu thu thập dữ liệu o Các câu hỏi để hỏi về Official và Bootleg o Biểu mẫu đã được điền
Các cấu h i đ h i vếằ các bi u mấễuỏ ể ỏ ể
Bi u mấễu đã đểược điếằn đấằy đ ch a?ủ ư
Có nh ng mấễu đ n nào khống bao gi đữ ơ ờ ượ ử ục s d ng khống?
Tấtế c các b n sao c a các bi u mấễu có đả ả ủ ể
ược chuy n ể đếến đúng người
ho c đặ ượ ộc n p m t cách thích h p ộ ợ khống?
Ki m tra quyếằn và liến kếtế bi u mấễu ho t đ ng.ể
ể ạ ộ Nh ng ngữ ười ph i truy c p các bi u mấễu tr c
tuyếến ả ậ ể ự có th làm nh v y khống?ể ư ậ lOMoARcPSD| 36667950
Nếếu có m t bi u mấễu giấếy độ ể ược cung
cấếp thay thếế cho bi u mấễu d a trến Web, hãy so sánh t l hoàn ể ự
ỷ ệ thành c a c hai.ủ ả
Các bi u mấễu “khống chính th c” có để ứ ượ ử ục s d ng thường xuyến khống?
+ Thương mại điện tử và các giao dịch khác 3.8.
Phân tích tài liệu định tính -
Phân tích tài liệu định tính
Các phép ẩn dụ chính hoặc hướng dẫn
Tâm lý người trong cuộc và người ngoài cuộc
Điều gì được coi là thiện và ác
Đồ họa, logo và biểu tượng trong các khu vực chung hoặc trang web
Có khiếu hài hướcPhân tích Tin nhắn email Bản ghi nhớ
Dấu hiệu hoặc áp phích trên bảng thông báo
Các trang web của công ty (lưu ý tính tương tác của các trang web) Sách hướng dẫn Sổ tay chính sách
Phân tích các bản ghi nhớ cung cấp cái nhìn sâu sắc về các phép ẩn dụ hướng dẫn suy nghĩ của tổ chức 3.9. Phân tích văn bản - Phân tích văn bản
+ Phần mềm có thể phân tích dữ liệu định tính phi cấu trúc từ bất kỳ nguồn nào bao gồm:
+ Bảng điểm các cuộc phỏng vấn + Báo cáo bằng văn bản
+ Thông tin liên lạc của khách hàng được thu thập qua email, wiki, blog, phòng trò chuyện và các trang mạng xã hội khác
+ Dữ liệu phi cấu trúc, định tính hoặc “mềm” được tạo ra bởi vì: o Blog o Các phòng chat
o Bảng câu hỏi sử dụng câu hỏi mở o Các cuộc thảo luận trực tuyến được thực hiện trên
Web o Trao đổi xảy ra trên phương tiện truyền thông xã hội
+ Phân tích văn bản cung cấp thông tin chi tiết cho các thành viên của tổ chức, những người muốn
có một cách tiếp cận nhanh chóng và trực quan nhưng mang tính chất quyết định để phân tích dữ liệu văn bản lOMoARcPSD| 36667950
+ Một yếu tố quan trọng là thiết kế các hoạt động của con người xung quanh việc sử dụng phần mềm phân tích văn bản -
Lợi ích: giúp, có thể nhận ra những hiểu biết có giá trị về
+ Khách hàng đang nghĩ gì về tổ chức, các giá trị và hành động của công ty
+ Động cơ của khách hàng hoặc nhà cung cấp để bắt đầu, duy trì, cải thiện hoặc chấm dứt mối quan hệ 3.10. Quan sát -
Quan sát cung cấp cái nhìn sâu sắc về những gì các thành viên tổ chức thực sự làm -
Tận mắt chứng kiến các mối quan hệ tồn tại giữa những người ra quyết định và các thành viên khác của tổ chức -
Cũng có thể tiết lộ những manh mối quan trọng liên quan đến HCI -
Playscript của nhà phân tích
+ Liên quan đến việc quan sát hành vi của những người ra quyết định và ghi lại hành động của họ
bằng cách sử dụng một loạt các động từ hành động + Ví dụ: o Đang nói o Lấy mẫu o Tương ứng o Quyết định 3.11. STROBE -
STROBE: QUAN SÁT MÔI TRƯỜNG CÓ CẤU TRÚC—một kỹ thuật quan sát môi trường vật chất
của người ra quyết định. -
Thông thường, có thể quan sát các chi tiết cụ thể của môi trường xung quanh sẽ xác nhận hoặc
phủ nhận tường thuật về tổ chức
+ Còn gọi là truyện hay đối thoại
+ Thông tin được tìm thấy thông qua phỏng vấn hoặc bảng câu hỏi - yếu tố STROBE + Địa điểm văn phòng + Vị trí bàn làm việc
+ Thiết bị văn phòng phẩm + Đạo cụ
+ Nguồn thông tin bên ngoài
+ Ánh sáng và màu sắc văn phòng
+ Quần áo của những người ra quyết định -
Bảy yếu tố có thể quan sát cụ thể của STROBE lOMoARcPSD| 36667950 -
STROBE và đặc điểm của người ra quyết định 3.12. Áp dụng STROBE -
5 biểu tượng được sử dụng để đánh giá cách quan sát các yếu tố của STROBE so với kết quả phỏng vấn là:
Dấu kiểm có nghĩa là tường thuật được xác nhận
Dấu “X” có nghĩa là câu chuyện bị đảo ngược
Biểu tượng hình bầu dục hoặc hình con mắt đóng vai trò gợi ý để nhìn xa hơn
Một hình vuông có nghĩa là quan sát sửa đổi tường thuật
Hình tròn có nghĩa là câu chuyện được bổ sung bằng quan sát Chương 4:
Sơ đồ dòng dữ liệu DFD 4.1. Sơ đồ DFD
Đặc trưng bằng đồ họa các quy trình và luồng dữ liệu trong một hệ thống kinh doanh Miêu tả: + Đầu vào hệ thống lOMoARcPSD| 36667950 + Đầu ra + Quy trình -
Ưu điểm của phương pháp tiếp cận luồng dữ liệu
+ Tự do cam kết thực hiện kỹ thuật quá sớm
+ Hiểu biết về mối quan hệ tương hỗ của các hệ thống và hệ thống con
+ Phân tích hệ thống đề xuất
+ Truyền đạt kiến thức hệ thống hiện tại cho người dùng - Ký hiệu cơ bản
• Một hình vuông đôi cho một thực thể bên ngoài
• Một hình chữ nhật với các góc tròn để xuất hiện một quá trình biến đổi
• Một hình chữ nhật mở cho kho lưu trữ dữ liệu
• Mũi tên để di chuyển dữ liệu từ điểm này sang điểm khác -
Thực thể bên ngoài
Đại diện cho một bộ phận khác, một doanh nghiệp, một người hoặc một cái máy
Nguồn hoặc đích của dữ liệu, bên ngoài ranh giới của hệ thống
Nên đặt tên bằng danh từ - Dòng dữ liệu
Biểu thị dữ liệu về một người, địa điểm hoặc sự vật
Được miêu tả bằng danh từ
Đầu mũi tên chỉ hướng dòng chảy
Hiển thị chuyển động của dữ liệu từ điểm này sang điểm khác - Quá trình
+ Thể hiện công việc đang được thực hiện trong hệ thống + Biểu thị sự
thay đổi hoặc chuyển đổi dữ liệu + Quy ước đặt tên:
Để đặt tên cho một hệ thống con chính, hãy đính kèm từ hệ thống con theo tên
Sử dụng dạng động từ-tính từ-danh từ cho chi tiết quy trình Gán tên của
cả hệ thống khi đặt tên cho một quy trình cấp cao - Kho dữ liệu:
Nơi lưu trữ dữ liệu cho phép kiểm tra, bổ sung, và truy xuất dữ liệu
Đặt tên bằng danh từ, mô tả dữ liệu
Kho lưu trữ dữ liệu thường được cấp một số tham chiếu duy nhất, chẳng hạn như D1, D2, D3 Đại diện cho: Tủ hồ sơ Hồ sơ vi tính hóa Cơ sở dữ liệu -
Các bước phát triển Sơ đồ DFD
Phát triển Sơ đồ DFD bằng cách tiếp cận từ trên xuống
1. Lập danh sách các hoạt động kinh doanh và sử dụng danh sách đó để xác định các hoạt động khác nhau
– Kho lưu trữ dữ liệu lOMoARcPSD| 36667950 – Luồng dữ liệu – Thực thể bên ngoài – Quy trình
2. Tạo sơ đồ ngữ cảnh hiển thị các thực thể bên ngoài và luồng dữ liệu đến vàđi từ hệ thống.
Không hiển thị bất kỳ quy trình chi tiết hoặc kho lưu trữ dữ liệu nào.
3. Vẽ Sơ đồ 0, cấp độ tiếp theo.
Hiển thị các quy trình, nhưng giữ cho chúng chung chung.
Hiển thị các kho lưu trữ dữ liệu ở cấp độ này.
4. Tạo sơ đồ con cho từng quy trình trong Sơ đồ 0.
5. Kiểm tra lỗi và đảm bảo nhãn bạn gán cho mỗi quy trình và luồng dữ liệu có ý nghĩa.
6. Xây dựng Sơ đồ DFD vật lý từ luồng dữ liệu logic biểu đồ. Phân biệt giữa các quy trình thủ
công và tự động, mô tả các tệp và báo cáo thực tế theo tên và thêm các điều khiển để cho
biết khi nào các quy trình hoàn tất hoặc xảy ra lỗi.
7. Phân vùng Sơ đồ DFD vật lý bằng cách tách hoặc nhóm cácphần của sơ đồ để thuận tiện cho
việc lập trình và triển khai. 4.2. Tạo sơ đồ ngữ cảnh Quá trình đánh số 0
Mức cao nhất trong Sơ đồ DFD
Tất cả các thực thể bên ngoài, cũng như các luồng dữ liệu chính được thể hiện
Chỉ chứa một quy trình, đại diện cho toàn bộ hệ thống - Quy tắc cơ bản
Kho lưu trữ dữ liệu phải được kết nối với ít nhất một quy trình
Sơ đồ DFD phải có một quy trình
Các thực thể bên ngoài không được kết nối với nhau
Không được là bất kỳ đối tượng độc lập nào
Một quy trình phải có cả luồng dữ liệu đầu vào và đầu ra - Vẽ sơ đồ 0
Bao gồm các kho lưu trữ dữ liệu chính và tất cả các thực thể bên ngoài
Sự bùng nổ của biểu đồ ngữ cảnh
Mỗi quy trình được đánh số
Có thể bao gồm tối đa chín quy trình
Bắt đầu với luồng dữ liệu từ một thực thể ở phía đầu vào
Phân tích một quy trình được xác định rõ ràng
Kiểm tra luồng dữ liệu đến hoặc từ kho lưu trữ dữ liệu
Ghi lại bất kỳ vùng mờ nào
Làm việc ngược từ luồng dữ liệu đầu ra lOMoARcPSD| 36667950 4.3. Các mức Sơ đồ DFD
Số sơ đồ mức thấp hơn giống như số quy trình gốc.
Cấp cao nhất là cấp ngữ cảnh.
Các quy trình không tạo sơ đồ con được gọi là nguyên thủy.
Mỗi quy trình có thể bùng nổ ở mức thấp hơn.
Sơ đồ DFD được xây dựng theo lớp. - Tạo sơ đồ con
+ Mỗi quy trình trên sơ đồ 0 có thể được tách rời để tạo ra một sơ đồ con
+ Sơ đồ con không thể tạo đầu ra hoặc nhận đầu vào, quy trình cha mẹ cũng không tạo hoặc nhận
+ Quy trình con được cấp cùng số với quy trình cha mẹ: Quy trình 3 sẽ chuyển sang Sơ đồ 3
+ Các thực thể thường không được hiển thị trên sơ đồ con bên dưới Sơ đồ 0
+ Nếu quy trình cha có luồng dữ liệu kết nối với kho dữ liệu, sơ đồ con có thể bao gồm kho lưu trữ dữ liệu như vậy
+ Khi một quá trình chưa bùng nổ, nó được gọi là quá trình nguyên thủy -
Sơ đồ DFD Tóm tắt lỗi
+ Kết nối trực tiếp các kho lưu trữ dữ liệu và các thực thể bên ngoài với nhau
+ Quên đưa luồng dữ liệu vào hoặc quên trỏ mũi tên vào
+ Ghi sai nhãn quy trình hoặc luồng dữ liệu
+ Tạo ra sự phân hủy (hoặc bùng nổ) không cân bằng trong
+ Bỏ qua luồng dữ liệu
+ Bao gồm hơn 9 quy trình trên một sơ đồ DFD.
+ Tạo ra sự phân hủy (hoặc bùng nổ) không cân bằng trong sơ đồ con. 4.4.
Sơ đồ DFD logic và vật lý 4.4.1.Logical -
Tập trung vào công việc kinh doanh và cách thức kinh doanh vận hành -
Không quan tâm hệ thống sẽ xây dựng như thế nào -
Mô tả các sự kiện kinh doanh diễn ra và dữ liệu được yêu cầu và tạo ra bởi mỗi sự kiện 4.4.2. Physical
- Cho biết hệ thống sẽ được triển khai như thế nào
- Mô tả hệ thống
4.4.3.Các tính năng phổ biến của Biểu đồ DFD logic và vật lý lOMoARcPSD| 36667950
Sự phát triển mô hình Logic sang vật lý
4.4.4.Phát triển sơ đồ DFD logic -
Giao tiếp tốt hơn với người dùng -
Hệ thống ổn định hơn -
Các nhà phân tích hiểu rõ hơn về doanh nghiệp - Linh hoạt và bảo trì -
Loại bỏ dư thừa và dễ dàng tạo ra các mô hình vật lý lOMoARcPSD| 36667950
4.4.5.Phát triển Sơ đồ DFD vật lý
Làm rõ quy trình nào được thực hiện bởi con người và quy trình nào được tự động hóa
Mô tả quy trình chi tiết hơn
Trình tự các quy trình phải được thực hiện theo một thứ tự cụ thể
Xác định kho lưu trữ dữ liệu tạm thời
Chỉ định tên thực của tệp và bản in
Bổ sung các biện pháp kiểm soát để đảm bảo các quy trình được thực hiện đúng cách -
Nội dung của Sơ đồ DFD vật lý (không có trên sơ đồ DFD logic) + Quy trình thủ công
+ Quy trình thêm, xóa, thay đổi, cập nhật hồ sơ
+ Quy trình nhập và xác minh dữ liệu
+ Quy trình xác thực để đảm bảo dữ liệu đầu vào chính xác
+ Trình tự các quy trình để sắp xếp lại thứ tự hồ sơ
+ Các quy trình để tạo ra mọi đầu ra hệ thống duy nhất + Kho dữ liệu trung gian
+ Tên tập tin thực tế được sử dụng để lưu trữ dữ liệu
+ Điều khiển để biểu thị việc hoàn thành nhiệm vụ hoặc tình trạng lỗi 4.5. Ma trận CRUD -
Từ viết tắt CRUD thường được sử dụng cho + Tạo nên + Đọc + Cập nhật + Xóa bỏ
Đây là những hoạt động phải có trong một hệ thống đối với mỗi tệp chính
Ma trận CRUD là một công cụ để biểu diễn nơi mỗi quá trình này xảy ra trong một hệ thống -
Mô hình sự kiện ma trận CRUD : 4.6.
Mô hình sự kiện và sơ đồ DFD
Luồng đầu vào từ một thực thể bên ngoài đôi khi được gọi là yếu tố kích hoạt vì nó bắt đầu các
hoạt động của một quy trình
Các sự kiện khiến hệ thống thực hiện một hành động nào đó và hoạt động như một tác nhân kích hoạt hệ thống
Một cách tiếp cận để tạo Sơ đồ DFD vật lý là tạo một đoạn Sơ đồ DFD cho từng sự kiện hệ thống duy nhất. lOMoARcPSD| 36667950 4.7.
Bảng phản hồi sự kiện
Bảng sự kiện được sử dụng để tạo Sơ đồ DFD bằng cách phân tích từng sự kiện và dữ liệu do sự
kiện sử dụng và tạo ra
Mỗi hàng trong bảng sự kiện đại diện cho một đoạn Sơ đồ DFD và được sử dụng để tạo một quy
trình đơn lẻ trên Sơ đồ DFD 4.8.
Sơ đồ Use case và sơ đồ DFD
Mỗi ca sử dụng xác định một hoạt động và kích hoạt của nó, đầu vào và đầu ra
Cho phép nhà phân tích làm việc với người dùng để hiểu bản chất của các quy trình và hoạt
động và sau đó tạo ra một mảnh Sơ đồ DFD duy nhất 4.9. Sơ đồ DFD phân vùng
Phân vùng là quá trình kiểm tra luồng dữ liệu sơ đồ và xác định làm thế nào nó nên được chia
thành bộ sưu tập các thủ tục thủ công và các chương trình máy tính.
Một đường đứt nét được vẽ xung quanh một quá trình hoặc một nhóm các các quy trình nên
được đặt trong một chương trình máy tính duy nhất.
4.9.1.Lý do phân vùng Các nhóm người dùng khác nhau Thời gian Nhiệm vụ tương tự Hiệu quả
Tính nhất quán của dữ liệu
4.9.2.Trang web phân vùng bảo mật Cải thiện
cách con người sử dụng trang web
Cải thiện tốc độ xử lý Dễ bảo trì trang web Giữ giao dịch an toàn 4.10.
Giao tiếp bằng Sơ đồ DFD
Sử dụng sớm Sơ đồ DFD chưa giải mã khi xác định yêu cầu thông tin
Nhãn có ý nghĩa cho tất cả các thành phần dữ liệu
CHƯƠNG 7: PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG HƯỚNG ĐỐI TƯỢNG BẰNG UML
1. Khái niệm, chức năng
UML là ngôn ngữ mô hình hóa thống nhất bao gồm những ký hiệu hình học dùng
mô hình hóa trong phương pháp hướng đối tượng. • UML dùng để: lOMoARcPSD| 36667950
• Trực quan hóa (Visualizing) • Đăc tả (Specifying)̣
• Xây dựng (Constructing)
• Lập tài liệu (Documenting)
• UML còn được dùng làm công cụ giao tiếp giữa người dùng, nhà phân tích,nhà
thiết kế và nhà phát triển phần mềm. 2. Các sơ đồ
a) UML 1.x có 9 loại Sơ đồ:
1. Sơ đồ Use case (Use Case Diagram)
2. Sơ đồ lớp (Class Diagram)
3. Sơ đồ đối tượng (Object Diagram)
4. Sơ đồ trạng thái (State Diagram)
5. Sơ đồ trình tự (Sequence Diagram)
6. Sơ đồ cộng tác (Collaboration Diagram)
7. Sơ đồ hoạt động (Activity Diagram)
8. Sơ đồ thành phần (Component Diagram) 9. Sơ đồ triển khai (Deployment Diagram)
b) UML 2.0 có 13 loại Sơ đồ: Thêm các sơ đồ:
• Sơ đồ gói (Package Diagram)
• Sơ đồ cấu trúc đa hợp (Composite Structure Diagram) lOMoARcPSD| 36667950
• Sơ đồ tương tác tổng quát (interaction overview Diagram)
• Sơ đồ thời gian (Timing Diagram) Ngoài ra:
• Sơ đồ trạng thái (statechart diagram) đổi tên thành sơ đồ máy trạng thái (state machine diagram)
• Sơ đồ cộng tác (collaboration diagram) đổi tên lại là sơ đồ giao tiếp (communication diagram)
c) Các sơ đồ được phân thành 2 nhóm:
Nhóm sơ đồ cấu trúc (Structure Diagram):
• Sơ đồ lớp (Class Diagram)
• Sơ đồ đối tượng (Object Diagram)
• Sơ đồ thành phần (Component Diagram)
• Sơ đồ cấu trúc đa hợp (Composite Structure Diagram)
• Sơ đồ triển khai (Deployment Diagram)
• Sơ đồ gói (Package Diagram)
Nhóm sơ đồ hành vi (Behaviour Diagram)
• Sơ đồ Use case (Use Case Diagram)
• Sơ đồ hoạt động (Activity Diagram)• Sơ đồ máy trạng thái (State Machine Diagram)
• Nhóm sơ đồ tượng tác (Interaction Diagram): lOMoARcPSD| 36667950
• Sơ đồ trình tự (Sequence Diagram)
• Sơ đồ giao tiếp (Comunication Diagram)
• Sơ đồ tương tác tổng quát (interaction overview Diagram)
• Sơ đồ thời gian (Timing Diagram)
3. Các góc nhìn (view) của UML
• Góc nhìn (view) chỉ ra những khía cạnh khác nhau của hệ thống cần phải đượcmô hình hóa.
• Một góc nhìn không phải là một bản vẽ, mà là một sự trừu tượng hóa bao
gồmnhiều sơ đồ khác nhau
• Mỗi góc nhìn sẽ chỉ ra một khía cạnh riêng biệt của hệ thống, nhờ đó người
tacó thể xây dựng nên một bức tranh hoàn chỉnh về hệ thống.
• Mỗi nhóm người có liên quan đến hệ thống sẽ tập trung chú ý vào một gócnhìn nào đó mà thôi lOMoARcPSD| 36667950
a) Góc nhìn Use case (use case view)
• Là góc nhìn từ ngoài vào hệ thống.
• Đây là góc nhìn dành cho khách hàng, nhà thiết kế, nhà phát triển, người
kiểmthử. Nó mô tả các chức năng mong đợi mà hệ thống phải đáp ứng cho người dùng
• Được mô tả qua các sơ đồ Use case (use case diagram) và thỉnh thoảng cả cácsơ
đồ hoạt động (activity diagram).
• Góc nhìn Use case mang tính trung tâm. Hệ thống phải cung cấp các chứcnăng
mô tả trong góc nhìn này → có ảnh hưởng đến tất cả các góc nhìn khác • Góc
nhìn này còn được sử dụng để thẩm tra (verify) hệ thống xem có đúng với mong
đợi của khách hàng ( "Đây có phải là thứ bạn muốn?") cũng như có đúng với
hệ thống đã hoàn thành ("Hệ thống có hoạt động như đã đăc tả?”).̣ b) Góc nhìn thiết kế
• Còn gọi là góc nhìn logic (logical view)
• Chủ yếu dùng cho các nhà thiết kế và nhà phát triển.
• Đây là góc nhìn vào bên trong hệ thống. Nó chỉ ra chức năng sẽ được thiết kếbên
trong hệ thống như thế nào
• Nó mô tả cấu trúc tĩnh (lớp, đối tượng, và quan hệ) cũng như sự tương tácđộng
sẽ xảy ra khi các đối tượng gửi thông điệp cho nhau để cung cấp chức năng đã định sẵn.
• Cấu trúc tĩnh được mô tả bằng các sơ đồ lớp (class diagram) và sơ đồ đốitượng (object diagram).
• Cấu trúc động được mô tả trong các sơ đồ trạng thái (statechart diagram), sơđồ
trình tự (sequence diagram), sơ đồ tương tác (collaboration diagram), sơ đồ hoạt động (activity diagram) lOMoARcPSD| 36667950
c) Góc nhìn quá trình
• Còn gọi là góc nhìn song hành (Concurrency View)
• Phản ánh các lộ trình điều khiển, các quá trình (process) thực hiện, nó chothấy
sự hoạt động song hành hay đồng bộ của hệ thống
• Góc nhìn này dành cho nhà phát triển và người tích hợp hệ thống
• Bao gồm các sơ đồ động như: sơ đồ trạng thái (statechart diagram), sơ đồ trìnhtự
(sequence diagram), sơ đồ cộng tác (collaboration diagram) và sơ đồ hoạt động (activity diagram)
d) Góc nhìn thực thi
• Còn gọi là góc nhìn thành phần (Component view)
• Là góc nhìn đối với dạng phát hành của hệ thống vật lý, bao gồm các thànhphần
và tập tin độc lập, được lắp ráp theo các cách để tạo ra hệ thống chạy được.
• Thành phần ở đây là các module thuộc nhiều loại khác nhau, sẽ được chỉ ratrong
sơ đồ cùng với cấu trúc cũng như sự phụ thuộc của chúng.
• Nó thường được sử dụng cho nhà phát triển và thường bao gồm nhiều sơ đồthành phần.
• Được thể hiện bằng các sơ đồ thành phần (Component diagram)
e) Góc nhìn triển khai
• Góc nhìn triển khai (Deployment View) chỉ cho chúng ta sơ đồ triển khai
vềmăt vật lý của hệ thống, ví dụ các máy tính cũng như sự liên kết giữa chúng vớị nhau. lOMoARcPSD| 36667950
• Góc nhìn triển khai dành cho các nhà phát triển, người tích hợp cũng
nhưngười thử nghiệm hệ thống và được thể hiện bằng các sơ đồ triển khai (deployment diagram).
• Góc nhìn này cũng bao gồm sự ánh xạ các thành phần của hệ thống vào
cấutrúc vật lý; ví dụ như chương trình nào hay đối tượng nào sẽ được thực thi trên máy tính nào.
4) UML và chu trình phát triển phần mềm
a) Giai đoạn nghiên cứu sơ bộ:
• UML đưa ra khái niệm Use Case để nắm bắt các yêu cầu của người sử dụng.
• Sơ đồ Use case (Use Case Diagram) dùng để mô tả mối quan hệ cũng như
sựgiao tiếp với hệ thống.
• Trong sơ đồ Use case, các tác nhân (Actor) bên ngoài quan tâm đến hệ thốngsẽ
được mô hình song song với chức năng mà họ đòi hỏi từ hệ thống (tức Use case)
• Mỗi Use case trong tài liệu sẽ đăc tả yêu cầu của người dùng: người dùng chợ̀
đợi điều gì từ hệ thống mà không để ý đến chức năng này sẽ được thực thi ra sao
b) Giai đoạn phân tích:
• Giai đoạn phân tích quan tâm đến việc trừu tượng hóa
• Phân tích viên tìm ra các lớp thành phần và mối quan hệ giữa chúng → mô
tảbằng sơ đồ lớp (class diagram)
• Sự cộng tác giữa các lớp nhằm thực hiện các Use case cũng sẽ được mô tả
nhờvào các mô hình động (dynamic models) của UML. lOMoARcPSD| 36667950
• Trong giai đoạn phân tích, chỉ các lớp tồn tại trong phạm vi nghiệp vụ cần
giảiquyết (lớp phân tích) là được mô hình hóa. Các lớp kỹ thuật cũng như giải
pháp trong hệ thống phần mềm, ví dụ các lớp giao diện người dùng, v.v..., chưa
cần quan tâm trong giai đoạn này.
c) Giai đoạn thiết kế:
• Kết quả của giai đoạn phân tích sẽ được mở rộng thành các giải pháp kỹ thuật.
• Các lớp thiết kế được bổ sung để tạo thành hạ tầng kỹ thuật: giao diện
ngườidùng, các chức năng để giao tiếp với các hệ thống khác, v,v....
• Giai đoạn thiết kế sẽ đưa ra kết quả là bản đăc tả chi tiết (specification) dùng ̣ để xây dựng hệ thống.
d) Giai đoạn xây dựng:
• Trong giai đoạn xây dựng (lập trình), các lớp của giai đoạn thiết kế sẽ
đượcchuyển thành những dòng code cụ thể trong một ngôn ngữ lập trình hướng đối tượng cụ thể
• Khi tạo ra các mô hình phân tích và thiết kế trong UML, cần tránh việc
ngaylập tức biến đổi các mô hình này thành các dòng code.
• Trong các giai đoạn trước, mô hình được sử dụng để hiểu rõ ràng hệ thống,
dễgiao tiếp và tạo nên cấu trúc của hệ thống. Nếu vội vàng sa vào việc viết code
có thể sẽ gây trở ngại cho việc xây dựng mô hình chính xác và đầy đủ.
e) Giai đoạn kiểm thử:
• Một hệ thống thường được thử nghiệm qua nhiều giai đoạn và với nhiều
nhómthử nghiệm khác nhau
• Các nhóm sử dụng các loại sơ đồ UML khác nhau làm nền tảng cho công việccủa mình: lOMoARcPSD| 36667950
• Kiểm thử đơn vị (unit test) sử dụng sơ đồ lớp (class diagram) và đăc tả lớp ̣
• Kiểm thử nghiệm tích hợp (integration test) thường sử dụng sơ đồ thành phần
(component diagram) và sơ đồ cộng tác (collaboration diagram)
• Kiểm thử hệ thống (system test) sử dụng sơ đồ Use case (use case diagram)
đểđảm bảo hệ thống hoạt động đúng như đã được định nghĩa từ ban đầu
5) Sơ đồ Use case (Use Case Diagram)
• Sơ đồ Use case chỉ ra các tác nhân ngoài và mối liên hệ giữa chúng với các
Use case mà hệ thống cung cấp
• Một Use case là diễn tả một chức năng mà hệ thống có khả năng cung cấp.
• Mỗi Use case có thể được đăc tả (ngoài sơ đồ) bằng một văn bản, hay bằng ̣ một sơ đồ hoạt động
• Các Use case được miêu tả duy nhất theo hướng nhìn từ ngoài vào của các
tácnhân (hành vi của hệ thống theo như sự mong đợi của người sử dụng)
• Các Use case chỉ đề cập hệ thống làm gì (WHAT) chứ không mô tả chức
năngđược cung cấp sẽ hoạt động nội bộ bên trong hệ thống ra sao (HOW)
6) Sơ đồ hoạt động (Activity Diagram)
• Sơ đồ hoạt động chỉ ra luồng dịch chuyển từ hành động này sang hành độngkhác.
• Thường sử dụng để mô tả các hoạt động được thực hiện trong một thủ tục,một
use case. Cũng có thể dùng để mô tả các dòng chảy giữa các Use case
• Sơ đồ hoạt động bao gồm các trạng thái hành động, chứa đăc tả của một hoạṭ
động cần phải được thực hiện (một hành động - action). Một trạng thái hành động
sẽ qua đi khi hành động được thực hiện xong lOMoARcPSD| 36667950
• Sơ đồ còn có thể chỉ ra các quyết định, các điều kiện, cũng như phần thực
thisong song của các trạng thái hành động.
• Sơ đồ còn có thể chứa đăc tả cho các thông điệp được gửi đi / nhận về giữạ
các thành phần của hành động
7) Sơ đồ lớp (Class Diagram)
• Sơ đồ lớp chỉ ra cấu trúc tĩnh của các lớp trong hệ thống.
• Vì cấu trúc được mô tả luôn luôn đúng tại bất kỳ thời điểm nào trong vòng đời hệthống
• Lớp là đại diện cho các sự vật được xử lý trong hệ thống.
• Các lớp có thể quan hệ với nhau theo nhiều cách:
• 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ủalớp khác)
• Đó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 sơ đồ lớp, cùng với cấu trúcbên
trong của mỗi lớp, gồm thuộc tính (attribute) và tác vụ (operation).
8) Sơ đồ đối tượng (Object Diagram) •
Giống như sơ đồ lớp. Sự khác biệt là sơ đồ đối tượng chỉ ra các đối tượng
thựcthể của lớp, thay vì các lớp. •
Sơ đồ đối tượng là một bức tranh của hệ thống ở một thời điểm nào đó(snapshot). lOMoARcPSD| 36667950 •
Sơ đồ đối tượng dùng chung các ký hiệu của sơ đồ lớp, trừ hai điểm: tên
đốitượng được gạch dưới và tất cả các kết nối cụ thể trong mối quan hệ đều được vẽ
ra • Sơ đồ đối tượng không quan trọng bằng sơ đồ lớp •
Sơ đồ đối tượng ít dùng, thường được dùng làm nền cho sơ đồ cộng
tác(collaboration / comunacation), nó chỉ ra lối ứng xử động giữa các đối tượng.
9) Sơ đồ trình tự (Sequence Diagram) •
Sơ đồ trình tự chỉ ra trình tự các thông điệp (message) được gửi giữa các
đốitượng dọc theo trục thời gian •
Sơ đồ trình tự chứa một loạt các đối tượng được biểu diễn bằng các đường thẳngđứng. •
Trục thời gian có hướng từ trên xuống dưới trong sơ đồ, và sơ đồ chỉ ra sự
traođổi thông điệp giữa các đối tượng khi thời gian trôi qua. •
Các thông điệp được biểu diễn bằng các đường gạch ngang gắn liền với mũi
tên(biểu thị thông điệp) nối liền giữa những đường thẳng đứng thể hiện đối tượng.
10) Sơ đồ giao tiếp (communication diagram)
• Tên cũ là sơ đồ cộng tác (Collaboration Diagram)
• Chỉ ra một sự cộng tác động, tương tự như sơ đồ trình tự
• Bên cạnh việc thể hiện sự trao đổi thông điệp (được gọi là tương tác), sơ đồ cònchỉ
ra các đối tượng và quan hệ của chúng (được gọi là ngữ cảnh).
• Việc nên sử dụng sơ đồ trình tự hay sơ đồ giao tiếp thường được quyết định theonguyên tắc chung sau:
• Nếu thời gian hay trình tự là yếu tố quan trọng nhất cần phải nhấn mạnh thì hãychọn sơ đồ trình tự lOMoARcPSD| 36667950
• Nếu ngữ cảnh là yếu tố quan trọng hơn, chọn sơ đồ giao tiếp
• Trình tự tương tác giữa các đối tượng được thể hiện trong cả hai loại sơ đồnày.
11) Sơ đồ máy trạng thái (State Machine Diagram)
• Tên cũ là sơ đồ trạng thái (State chart Diagram)
• Sơ đồ trạng thái thường là sự bổ sung cho đăc tả của một lớp. Nó chỉ ra tất cả các ̣
trạng thái mà đối tượng của lớp này có thể có, và những sự kiện (event) nào sẽ gây
ra sự thay đổi trạng thái
• Sự thay đổi trạng thái được gọi là dịch chuyển trạng thái (State Transition). Cóthể
có một hành động liên quan, xác định điều gì phải được thực hiện khi sự chuyển
đổi trạng thái này diễn ra.
• Sơ đồ trạng thái không cần phải vẽ cho tất cả các lớp, mà chỉ những lớp mà
đốitượng của nó có khả năng ứng xử trước các sự kiện xảy đến tùy thuộc vào trạng thái hiện tại của nó
12) Sơ đồ thành phần (Component Diagram) •
Sơ đồ thành phần chỉ ra cấu trúc vật lý của chương trình dưới dạng các
thànhphần, và mối quan hệ giữa chúng •
Sơ đồ thành phần dùng trình bày góc nhìn thực thi của hệ thống, được sử
dụngtrong việc lập trình cụ thể •
Một thành phần có thể là một tập tin nguồn (source code), thành phần nhị
phân(binary), thực thi (executable) •
Một thành phần chứa các thông tin về các lớp logic hoăc các lớp mà nó thi
hành,̣ như thế có nghĩa là nó tạo ra một ánh xạ từ góc nhìn logic vào góc nhìn thành phần. lOMoARcPSD| 36667950 •
Thành phần cũng có thể được mô tả với bất kỳ loại giao diện nào mà chúng
bộclộ, ví dụ giao diện OLE/COM, có thể được nhóm lại với nhau thành từng gói (package)
13) Sơ đồ triển khai (Deployment Diagram)
• Sơ đồ triển khai trình bày kiến trúc vật lý của phần cứng cũng như phần mềmtrong
hệ thống. Nó chỉ ra từng máy tính cụ thể và từng trang thiết bị cụ thể (node) và sự nối kết giữa chúng
• Bên trong các nút mạng (node), các thành phần thực thi được (EXE) cũng nhưcác
đối tượng sẽ được xác định vị trí để chỉ ra những phần mềm nào sẽ được thực thi
tại những nút mạng nào. Ta cũng có thể chỉ ra sự phụ thuộc giữa các thành phần.
• Sơ đồ triển khai chỉ ra góc nhìn triển khai, mô tả kiến trúc vật lý thật sự của
hệthống. Đây là góc nhìn rất khác cách mô tả duy chức năng của góc nhìn Use case
CHƯƠNG 5: TỪ ĐIỂN DỮ LIỆU
A) TỪ ĐIỂN DỮ LIỆU
1) Từ điển dữ liệu (Data Dictionary)
• Từ điển dữ liệu (DD) dùng để lưu các mô tả chi tiết về các thành phần trong cácsơ
đồ được xây dựng trong quá trình phân tích.
• Đây là kho trung tâm chứa tất cả các mô tả về hệ thống. Từ đây có thể tạo ranhiều
báo cáo hữu ích về hệ thống.
• Trong các CASE tool các mô tả này thường chứa trong một kho gọi là datarepository. Cần lập tài liệu cho: • Các dòng dữ liệu lOMoARcPSD| 36667950 • Các kho dữ liệu
• Cấu trúc dữ liệu (data structure) của các mẩu tin
• Các phần tử dữ liệu (data item) • Các quy trình xử lý • Các thực thể ngoại
2) Từ điển dữ liệu và DFD các mức
• Các thành phần trong từ điển dữ liệu sẽ thay đổi theo mức của sơ đồ DFD tươngứng
• Từ điển dữ liệu được tạo theo cách tiếp cận từ trên xuống
• Có thể dùng để kiểm tra tính cân bằng giữa DFD mức trên và DFD mức dưới
• Trong CASE tools, từ điển dữ liệu là nơi chứa thông tin để các công cụ sinh ra
cơsở dữ liệu và các chương trình máy tính
3) Mô tả dòng dữ liệu lOMoARcPSD| 36667950
4) Mô tả kho dữ liệu lOMoARcPSD| 36667950
5) Mô tả cấu trúc dữ liệu
• Dùng để mô tả sự kết hợp của các thành phần dữ liệu trong dòng dữ liệu (hoặckho dữ liệu)
• Mô tả dựa vào các biểu mẫu thực tế đã thu thập
• Thường dùng các ký hiệu sau: = Bao gồm + Và (and) ( ) Tùy chọn (option) { }
Lặp lại từ m đến n lần lOMoARcPSD| 36667950
[ ] Chọn một trong các trường hợp (or)
| Dấu phân cách các chọn lựa 6) Mẫu đơn hàng
7) Mô tả thành phần dữ liệu lOMoARcPSD| 36667950
• Các ký hiệu dùng để mô tả định dạng (Format):
• X: Đại diện cho một ký tự bất kỳ
• 9: Đại diện cho một ký số
• Z: Hiển thị cả các số không ở bên trái của số
• . , / - v.v… : Các ký hiệu phân cách
• Việc mô tả cấu trúc dữ liệu của các kho dữ liệu, cũng như mô tả các thành phầndữ
liệu chính là cơ sở để ta thiết kế cơ sở dữ liệu sau này.
• Việc mô tả các dòng dữ liệu còn giúp ta kiểm tra lại tính chính xác của các lượcđồ.
Ví dụ phát hiện các lỗ xám trong sơ đồ DFD.
B) ĐẶC TẢ QUY TRÌNH XỬ LÝ
1) Đặc tả quy trình xử lý
• PS - Process Specification
• Là công cụ mô tả các quy trình xử lý bên trong của một process trong sơ đồ DFD. lOMoARcPSD| 36667950
• Mục đích của PS là mô tả chính xác về nghiệp vụ xử lý, tránh sự hiểu biết khôngrõ
ràng, không đầy đủ về một nghiệp vụ
• Có thể dùng mô tả quá trình nguyên tố cũng như các quá trình xử lý ở mức trên.
Lưu ý: không phải mọi process đều phải đặc tả PS.
Người ta có thể không đặc tả cho các process sau:
• Process chỉ thực hiện việc nhập / xuất kho dữ liệu (đọc/ghi file).
• Process chỉ thực hiện việc kiểm tra đơn giản về tính hợp lệ của dữ liệu.
• Process đã được lập trình rồi, nay chỉ sử dụng lại (gọi hàm/ thủ tục thư viện).
Ta có thể mô tả logic xử lý của các quá trình bằng các cách sau: • Lưu đồ (Flow Chart) lOMoARcPSD| 36667950
• Tiếng Anh có cấu trúc (Structured Enghlish)
• Bảng quyết định (Decision Table)• Cây quyết định (Decision Tree)
2) Một số ký hiệu trong Flow Chart 3) Lưu đồ lOMoARcPSD| 36667950
4) Tiếng Anh có cấu trúc (Structured English)
• Tập con của tiếng Anh chuẩn: sử dụng một số từ vựng quy ước.
• Tương tự như viết mã giả (pseudo code)
• Sử dụng các cấu trúc điều khiển như: • Cấu trúc rẽ nhánh IF THEN [ELSE ] lOMoARcPSD| 36667950 END IF • Cấu trúc chọn DO CASE CASE : … CASE : [ELSE ] END CASE • Cấu trúc lặp: DO WHILE END WHILE
5) Bảng quyết định (Decision Table)
• Cho thấy cấu trúc luận lý để ra quyết định trong trường hợp phức tạp có nhiềuđiều kiện phối hợp.
• Tất cả các trường hợp phối hợp giữa các điều kiện đều được xác định → không bịsót tình huống.
• Lập trình viên có thể dựa vào các mô tả này để viết chương trình.
Bảng được chia thành 4 vùng:
▪ Góc trên bên trái là các điều kiện (conditions)
▪ Góc dưới bên trái là các hành động (actions) lOMoARcPSD| 36667950
▪ Góc trên bên phải là sư phối hợp của các điều kiện, gọi là các luật (rule)
▪ Góc dưới bên phải là sự chọn lựa hành động tương ứng với các luật
6) Các bước xây dựng bảng quyết định
• B1: Xác định các điều kiện có thể có cho khối trên bên trái• B2: Xác định các hành
động có thể chọn lựa cho khối dưới bên trái
• B3: Xác định khả năng lựa chọn cho mỗi điều kiện.
• Trường hợp đơn giản, mỗi điều kiện chỉ có 2 lựa chọn: Yes hay No → có 2ncột (luật)
• Mỗi điều kiện cũng có thể có nhiều chọn lựa
• B4: Xác định tất cả các trường hợp phối hợp giữa các điều kiện để tạo thànhcác
luật (rule), mỗi luật tương ứng với một cột ở khối trên bên phải.
• B5: Loại bỏ các luật mâu thuẫn, dư thừa, trùng lắp
• B6: Xác định cách chọn hành động cho từng luật (tương ứng từng cột)
• B7: Thu gọn bảng quyết định (nếu được)
7) Thu gọn cột bảng quyết định
• Trong trường hợp có một số cột có cùng hành động, các cột này có chung 1 số
điều kiện; một điều kiện khác lại không ảnh hưởng gì tới quyết định này → dùng dấu '-' để đánh dấu lOMoARcPSD| 36667950
8) Thu gọn hàng bảng quyết định
Trong một số trường hợp ta có thể xác định nhiều chọn lựa cho một điều kiện
(thay vì dùng Y/N) → có thể giảm số hàng trong bảng quyết định lOMoARcPSD| 36667950
9) Cây quyết định (Decision tree)
• Biểu diễn dưới dạng đồ họa các chọn lựa để ra quyết định
• Dễ hiểu và dễ xây dựng
• Được sử dụng để đặc tả cho các quá trình có cấu trúc rẽ nhánh phức tạp, hoặcthứ
tự thực thi của các quyết định là quan trọng (bảng quyết định khó diễn tả trong trường hợp này)
Các bước xây dựng:
• Nhận diện tất cả các điều kiện và hành động
• Sắp xếp hành động và điều kiện theo thời gian
• Bắt đầu xây dựng từ trái sang phải. Sử dụng các ký hiệu:
 : biểu diễn cho một hành động
 : biểu diễn cho một điều kiện lOMoARcPSD| 36667950
• Ở mỗi node phải xét tất cả các trường hợp có thể xảy ra trước khi xét qua nodekế
(thứ tự thực thi rất quan trọng) 10) Tổng kết về PS
Cần chọn phương pháp thích hợp xây dựng PS:
• "Structured English" thích hợp khi logic quá trình có vòng lặp hoặc sự liên hệvới
người dùng là quan trọng
• "Decision Table" thích hợp với logic có cấu trúc điều kiện phức tạp hoặc đểkiểm
soát tránh các dư thừa, mâu thuẫn.
• "Decision Tree" thích hợp khi thứ tự thực thi của các điều kiện là quan trọng.
CHƯƠNG 6: ĐẶC TẢ QUY TRÌNH XỬ LÝ
1) Logic của quyết định
Lập tài liệu và phân tích logic: • Cấu trúc tiếng Anh • Bảng quyết định • Cây quyết định
• Các quyết định logic và có cấu trúc có thể phân biệt được với quyết định báncấu trúc
• Các phương pháp phân tích quyết định có cấu trúc thúc cải thiện tính đầy
đủ,chính xác và giao tiếp 2) Chủ đề chính - đặc tả quá trình - quy tắc kinh doanh - tiếng anh cấu trúc lOMoARcPSD| 36667950 - cân bằng ngang 3) Đặc tả quá trình
- Thông số kỹ thuật quy trình
- Được tạo cho quá trình nguyên thủy cũng như cho vài mức độ xử lí cao hơn trong 1 DFD
- Được tạo 1 phương pháp lớp trong thiết kế hướng đối tượng và cho các bước trong 1 USE CASE
4) Mục tiêu của đặc tả quy trình sản xuất
- giảm sự không rõ ràng quy trình
- Đạt được 1 mô tả chính xác
- Xác thực thiết kế hệ thống
5) Đặc tả quy trình không được tạo ra cho -
quy trình đại diện cho đầu vào ra vật lý
- quy trình đại diện cho dữ liệu xác thực đơn giản
- quy trình sử dụng cho code viết sẵn
6) thông tin định dạng đặc tả quy trình - Số hiệu quy trình - Tên quy trình
- Mô tả hoàn thành quy trình
- Danh sách dòng dữ liệu vào - Dòng dữ liệu ra - Loại quy trình - Dùng code viết sẵn - Mô tả logic quy trình
- Tham khảo phương pháp logic
- Liệt kê bất kỳ vấn đề chưa giải quyết a) Số hiệu quy trình
- Phải giống với ID của quy trình trong DFD lOMoARcPSD| 36667950
- cho phép nhà phân tích làm việc hoặc đánh giá bất kỳ quy trình nào và định
vị DFD chứa quy trình dễ dàng
b) Tên quy trìnhgiống như hiển thị trong biểu tượng quy trình trong DFD
c) Mô tả của những gì quy trình đạt đượcxác định nếu
một item có sẵn cho bán hàng. Nếu nó không có sẵn, tạo
một báo cáo đơn đặt hàng restock item. Quyết định số lượng có sẵn
d) Liệt kê đầu vào DFD-
Sử dụng tên tạo trên DFD
- tên dữ liệu được dùng trong thông thường hoặc logic nên hợp với từ điển dữ
liệu, cho nhất quán và giao tiếp tốt e) Dòng dữ liệu ra
Sử dụng tên DFD và từ điển dữ liệu f) Loại quy trình - Đợt, lô - Online
+ Thiết kế màn hình hoặc trang web - Thủ công
+ nên có quy trình rõ ràng cho nhân viên khi thực hiện nhiệm vụ quá trình
g) Sử dụng code viết sẵnbao gồm tên của chương trình con hoặc chức năng bao gồm code h) Mô tả logic quy trình
- nêu chính sách và quy tắc kinh doanh k phải ngôn gnuwx máy tính - mã giả
- thủ tục cho phép 1 cty điều hành hđ kinh doanh của mình
7) định dạng quy tắc kinh doanh thông thường lOMoARcPSD| 36667950
- định nghĩa thuật ngữ kinh doanh
- điều kiện và hành động kinh doanh
- ràng buộc toàn vẹn dữ liệu
- dãn xuất toán học và chức năng - suy luận logic - trình tự xử lý
- mqh giữa các dữ kiện về doanh nghiệp 8) tham khảo pp logic
- nếu không đủ không gian cho 1 mô tả tiếng anh cấu trúc hoàn thành bao
gồm a tham khảo cho mô tả tiếng anh cấu trúc, bảng quyết định hoặc câ dự đoán logic
9) Danh sách bất kì vấn đề ko được giải quyết
- phần logic chưa hoàn chỉnh
- những vấn đề này tạo thành cơ sở của những câu hỏi được dùng cho các
cuộc phỏng vấn tiếp theo với người dùng hoặc chuyên gia kinh foanh mà
bạn đã thêm vtheenhosm dự án của bạn 10) Tiếng anh có cấu trúc
- được dùng khi quy trình logic liên quan đến công thức hoặc lặp lại, hoặc khi
các quyết định có cấu trúc không phức tạp
- dựa trên logic cấu trúc và câu lệnh tiếng anh đơn giản, vd như cộng nhân di chuyển 11)
Viết tiếng anh có cấu trúc
- thể hiện tất cả logic theo cấu trúc trình tự, cấu trúc quyết định, cấu trúc trường hợp, cấu trúc lặp
- dùng và in hoa các từ khóa such as IF,THEN, ELSE, DO, and PERFORM
- Thụt lề cái khối câu lệnh để hiển thị cấu trúc phân cấp rõ ràng
- Gạch chân từ hoặc câu được định nghĩa trong từ điển dữ liệu lOMoARcPSD| 36667950
- Làm rõ nhận định logic 12)
Lợi ích của Tiếng Anh có cấu trúc
- làm rõ logic và mqh đc tìm thấy trong ngôn ngữ con người
- một công cụ giao tiếp hiệu quả, nó có thể dạy và hiểu bởi người dùng trong tổ chức 13)
từ điển dữ liệu và đặc tả quá trình
- Từ điển dữ liệu là một xuất phát điểm cho tạo tiếng anh cấu trúc lOMoARcPSD| 36667950 -
Sequence - chuỗi đơn giản các câu lệnh statements MOVE, ADD, and SUBTRACT
- Selection –[] Mục nhập become IF … THEN...ELSE statements
- Iteration {} entries become DO WHILE, DO UNTIL, or PERFORM UNTIL 14) Bảng quyết định
Một bảng gồm các hàng và cột, được chia thành bốn góc phần tư: - Điều kiện - Điều kiện thay thế
- hành động cần thực hiện
- quy tắc thực hiện các hoạt đoojng 15)
Phát triển bảng quyết định
- xác định đk ảnh hưởng quyết định
- hành động khả thi có thể thực hiện
- điều kiện thay thế cho từng điều kiện - tính số cột tối đa - điền vào đk thay thế
- hoàn thành bảng bởi thêm X nơi các quy định gợi ý hành động
- kết hợp quy định khi rõ ràng
- tình huống bất khả thi
- sắp xếp lại cho dễ hiểu 16)
Phát triển bảng quyết định bước 1
- Xác định số của điều kiện có thể tác động quyết định
- kết hợp hàng trùng nhau, vd đk loại từ lẫn nhau
- số lượng điều kiện trở thành số hàng trong nửa trên bảng quyết định
Downloaded by Albedo Lili (albedo0208@gmail.com) lOMoARcPSD| 36667950 - 17)
Phát triển bảng quyết định bước 2
- Xác định số hiệu của hành động khả thi có thể được thực hiện
Số đó trở thành số của hàng tỏng nửa dưới 18)
Phát triển bảng quyết định bước 3
- Xác định đk thay thế cho mỗi điều kiện
- Định dạng đơn giản nhất của bảng quyết định, có 2 thay thế Y N cho mỗi điều kiện
- một bảng nhập mở rộng có thể có nhiều lwuja chọn thay thế
- Đảm bảo rằng tất cả giá trị có thể có của điều kiện 19)
Phát triển bảng quyết định bước 4
- tính toán số cột tối đa trong bảng quyết định bởi nhân số thay thế của lựa chọn
thay thế của mỗi diều kiện
- nếu 4 điều kiện và 2 thay thế Y N thì => 16 cột có thể có 20)
Phát triển bảng quyết định bước 5
- điền vào điều kiện thay thế - 21)
Tính đầy đủ và chính xác - 4 vấn đề chính: + Không đầy đủ
+ Tình huống bất khả thi mâu thuẫn dư + Contradictions + Redundancy 22)
Lợi ích của bảng quyết định
- bảo đảm sự đầy đủ - dễ kitra lỗi
+ tính huống bất khả thi
Downloaded by Albedo Lili (albedo0208@gmail.com) lOMoARcPSD| 36667950 - + mâu thẫun + Dư, rườm rà 23) Cây quyết định
Cây quyết định được sử dụng khi xảy ra nhánh phức tạp trong 1 quy trình
quyết định có cấu trúc
- Những cây hữu ích khi nó cần thiết giữ 1 cái string của chuỗi các quyết định
theo một trình tự cụ thể 24) Vẽ cây quyết định
- xác định all diều kiện và hành động và thứ tự của chúng và thời gian
- bắt đầu xây dựng cây từ trái --> phải, đảm bảo bạn phải liệt kê all lựa chọn
thay thế có thể trước khi chuyển sang phải 25)
Lợi ích của cây quyết định
- thứ tự của kiểm tra điều kiện và thực hiện hành động là ngay lập tức đáng chú ý
- điều kiện & hành động tìm thấy ơ vài nhánh
- so sánh với bảng quyết định, cây qđ dễ hiểu hơn 26)
chọn một thiết bị phân tích quyết định có cấu trúc
- Sử dụng tiếng anh có cấu trúc khi có nhiều hành động lặp lại hoặc khi một
kết hợp phức tạp của điều kiện, hành động, quy tắc
- • Use decision tables when a complex combination of conditions, actions,
and rules are found or you require a method that effectively avoids
impossible situations, redundancies, and contradictions
- • Use decision trees when the sequence of conditions and actions is critical
or when not every condition is relevant to every action (the branches are different)
Downloaded by Albedo Lili (albedo0208@gmail.com)