1
TỔNG QUAN VỀ HỆ
THỐNG THÔNG TIN
2
TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN

Khái niệm cơ bản về hệ thống (System)

Tổ chức (Organization)

Dữ liệu (Data) và thông tin (information)

Thông tin và các mức ra quyết định quản lý
(Management decision making)

Định nghĩa hệ thống thông tin (Information
Systems)

Phân loạI IS

Các IS phân loại theo mức quản lý tổ chức.
3
System A
Subsystem
B
Subsystem
C
Subsystem
E
Subsystem
D

Boundary
Interface
Environment
of System A
Khái niệm cơ bản về hệ thống
"Một hệ thống là một tập hợp các thành phần liên quan với
nhau và phối hợp hoạt động cùng với nhau nhằm đạt được
một mục tiêu cụ thể"
(Lee)
4
Tổ chức (Organization)

Tổ chức là một hệ thống

Tổ chức kinh tế: xí nghiệp, công ty, …

Tổ chức xã hội: bệnh viện, câu lạc bộ, …
Sales
IT
HRI
Purchasing
Training
Môi tr ng ườ
ho t đ ng ạ ộ
c a t ủ ổ
ch cứ
5
Dữ liệu và thông tin

Dữ liệu (data):

"Data is the raw input from which information is provided” (Lucey)

Là các dữ kiện, các sự kiện, các giao dịch thô, rời rạc,

Thông tin (information):
“Information is data that have been processed in such a way as to be
useful to the recipient.” (Lucey)

Thông tin là tài nguyên của tổ chức, và có vai trò quan
trọng quyết định sự thành công của tổ chức.

Thông tin được tạo ra và truy xuất ngày càng tăng

Yêu cầu quản lý thông tin hiệu quả.

Xử lý để tạo ra các thông tin mới có giá trị hơn
6
Information Systems (IS)

Một hệ thống thông tin:

Là các phương tiện có thể nhận dữ liệu (input), lưu trữ và
xử lý dữ liệu, để tạo ra thông tin (output) cho mục đích hỗ
trợ ra quyết định.

Có thể xử lý bằng tay hoặc máy tính.

Hệ thống thông tin của tổ chức gồm:

Một cơ sở thông tin (information base) mà bao gồm một

hay nhiều nguồn thông tin khác;

Một tập các xử lý mà được thực hiện bởi người hay máy để
truy xuất, cập nhập và xử lý thông tin.

Ví dụ: Một tổ chức như thư viện có cơ sở thông tin là sách,
loại sách, …; các xử lý là tìm, mượn, trả sách, …
7
Hệ thống thông tin tự động hóa

Hệ thống thông tin tự động hóa (Computerized
Information Systems) bao gồm:

Một hay nhiều cơ sở dữ liệu (databases) hay tập tin (files)
lưu trữ cở sở thông tin.

Một hay nhiều chương trình ứng dụng (Application
programs) để truy xuất và cập nhật cơ sở thông tin bằng
máy tính.

Một hay nhiều giao diện người dùng (user interface) cho
các nhóm người dùng khác nhau.
Computerized Information System = Databases +
Applications + Interfaces
8

Thông tin cần thiết cho doanh nghiệp và giúp ra quyết định ở
nhiều mức quản lý khác nhau trong tổ chức
Anthony’s Pyramid: cấu trúc quản lý của tổ chức
Operational

Tactical
Strategic
Large time
horizon
Small time
horizon
Summary
data
Detail
data
Unstructured
problems
Structured
problems
Thông tin và các cấp quản lý
9
Transaction Processing Systems
Banking
Systems
EPOS Systems
Healthcare Systems
Insurance Systems
Leisure Industry
10
Real-Time Systems
Automated Production Control
Control Systems
Security Systems
11
Management Information Systems

Decision Support
Systems
Office
Automation
Systems
Knowledge Based Systems
Executive Information
Systems
Best Practices of
Software Engineering
Objectives: Best Practices

Identify symptoms of software development
problems.

Explain the Best Practices.

Present the Rational Unified Process (RUP)
within the context of the Best Practices.
14
Mục đích của công nghệ phần mềm

Nhằm tạo ra sản phẩm phần mềm có chất lượng

Với ít nỗ lực (tiến trình phát triển dễ dàng)

Với ít chi phí và thời gian

Chất lượng phần mềm (Quality Software) bao gồm:


Tính đáng tin cậy (Reliable)

Tính dễ dùng (Reusable)

Tinh tế (Robust): có các chức năng hiệu quả

Dễ bảo trì (Maintainable)

Tính Hiệu quả (Efficient)

Thân thiện người dùng (Userfriendly)

…
15
Bản chất việc phát triển phần mềm

Phần mềm là sản phẩm của hoạt động phát triển một cách
sáng tạo của các “nghệ sĩ lành nghề”

Phần mềm được phát triển, chứ không phải sản xuất.

Ngay cả với công nghệ thành phần (Component technology), phần
mềm được xây dựng bằng cách lắp ghép các thành phần thì xử lý lắp
ghép này cũng là nghệ thuật.

Cho bất kỳ hệ thống nào, luôn cần phải tạo ra một mô hình
quan niệm của giải pháp cuối cùng thỏa mãn các yêu cầu
của khách hàng.

Đó là kết quả của nhiệm vụ phân tích yêu cầu và thiết kế hệ thống.


Độc lập với cài đặt.
16
Con người liên quan (Stakeholders)

Khách hàng (Customers): Users và System owners
Các nguyên nhân dẫn đến thất bại của dự án phần mềm liên quan
đến khách hàng:

Yêu cầu khách hàng bị hiểu sai và hay thu thập không đầy đủ

Yêu cầu khách hàng thay đổi quá thường xuyên.

Khách hàng không giao đầy đủ các tài nguyên cho dự án.

Khách hàng không hợp tác với người phát triển.

Mong đợi không thực tế của khách hàng.

Khách hàng không cần đến hệ thống nữa.

Người phát triển (Developers): Analysts, Designers,
Programmers

“Thiết kế tốt được tạo từ những nhà thiết kế tốt”
Symptoms of Software Development Problems

User or business needs not met

Requirements not addressed


Modules not integrating

Difficulties with maintenance

Late discovery of flaws

Poor quality of end-user experience

Poor performance under load

No coordinated team effort

Build-and-release issues
Trace Symptoms to Root Causes
Needs not met
Requirements churn
Modules don’t fit
Hard to maintain
Late discovery
Poor quality
Poor performance
Colliding developers
Build-and-release
Insufficient requirements
Ambiguous communications
Brittle architectures
Overwhelming complexity
Undetected inconsistencies
Poor testing

Subjective assessment
Waterfall development
Uncontrolled change
Insufficient automation
Symptoms Root Causes Best Practices

Ambiguous communications

Undetected inconsistencies





Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change



Model Visually (UML)
Continuously Verify Quality



Modules do not fit







Best Practices Reinforce Each Other
Best Practices
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
Validates architectural
decisions early on
Addresses complexity of
design/implementation incrementally
Measures quality early and often
Evolves baselines incrementally
Ensures users are involved
as requirements evolve
Develop Iteratively

Iterative development produces an executable
1. Initial
Planning
2. Planning
3. Requirements
4. Analysis & Design
5. Implementation

7. Deployment
6. Test
8. Evaluation
Management
Environment
(on-going)
Each iteration
results in an
executable release
Managing Requirements

Ensures that you

solve the right problem

build the right system

by taking a systematic approach to

eliciting

organizing

documenting

managing the changing requirements of a software
application.
Use Component Architectures

Software architecture needs to be:

Component-based Resilient

Reuse or customize components

Select from commercially
available components

Evolve existing software
incrementally

Meets current and future
requirements

Improves extensibility

Enables reuse

Encapsulates system
dependencies
Purpose of a Component-Based Architecture

Basis for reuse

Component reuse

Architecture reuse

Basis for project management

Planning


Staffing

Delivery

Intellectual control

Manage complexity

Maintain integrity
System-
software
Middleware
Business-
specific
Application-
specific
Component-based
architecture with
layers
Model Visually (UML)

Captures structure and behavior

Shows how system elements fit together

Keeps design and implementation consistent

Hides or exposes details as appropriate


Promotes unambiguous communication

The UML provides one language for all practitioners.
Visual Modeling with the Unified Modeling Language
Dynamic
Diagram
s

Multiple views

Precise syntax and semantics
Activity
Diagrams
Models
Static
Diagrams
Sequence
Diagrams
Communication
Diagrams
State Machine
Diagrams
Deployment
Diagrams
Component
Diagrams
Object
Diagrams
Class
Diagrams

Use-Case
Diagrams