1-Gioi Thieu HTTT.ppt

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ý Manage

TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN

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.

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

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

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

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, …

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

Detail data

Unstructured problems

Structured problems

Thông tin và các cấp quản lý

Decision Support 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.

Mục đích của công nghệ phần mềm

 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)

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.

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.

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

Overwhelming complexity Undetected inconsistencies Poor testing

Subjective assessment Waterfall development Uncontrolled change Insufficient automation

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

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

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

Use Component Architectures

 Software architecture needs to be:

 Reuse or customize components

 Select from commercially

Purpose of a Component-Based Architecture

 Basis for reuse

System- specific

Business- specific

Application-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

Static Diagrams

Sequence Diagrams

Communication

Diagrams

State Machine Diagrams

Deployment Diagrams

Component Diagrams

Object Diagrams

Class Diagrams Use-Case

Diagrams

Activity Diagram – Lược đồ hoạt động

 Activity diagrams được dùng để miêu tả dòng công việc

 Ví dụ: Một lược đồ hoạt động trình bày một quy trình

nghiệp vụ đơn giản để xuất hóa đơn và thanh toán

Print Invoice

Send Invoice

Wait For Payment

Process Payment

Class Diagram

Personal Customer creditCard#

Customer name address

creditRating()

{if Order.customer.creditRating

is "poor" then Order.isPrepaid must be true}

Employee

Corporate Customer contactName

creditRating creditLimit

remind() billForMonth()

0 1

0 n 0 1

0 n sales rep

Order dateReceived isPrepaid number : String price : Money

dispatch() close()

1 n

1

1 n 1

1 0 n 10 n

Collaboration Diagram – Lược đồ cộng tác

aReorderItem : Reorder Item

:Order Entry Window

anOrder : Order

anOrderLine : Order Line

aDeliveryItem : Delivery Item

aStockItem : Stock Item 5: needsReorder := needToReorder() 1: prepare()

2: *[for all order lines]: prepare()

7: [hasStock]: new

3: hasStock := check

4: [hasStock]: remove()

6: [needsReorder]:new

Statechart Diagram – Lược đồ trạng thái

Cancelled

[All items checked &&

all items available]

Delivered

[All items checked &&

some items not in stock]

Item received

[Some items not in stock]

Item received [all items available]

Cancelled

Checking do/ check item

Waiting

Dispatching do/ initiate delivery

Cancelled [Not all items checked

/get next item

Component Diagram – Lược đồ thành phần

 Lược đồ thành phần trình bày hệ thống được tổ chức thành các thành phần cộng tác với nhau như thế nào;

 Các thành phần được xây dựng từ các đối tượng

Call Centre Interface

Order Management

Customer Management

Database Management

Continuously Verify Quality

Cost

Transition Construction

Elaboration Inception

 Cost to Repair Software

 Cost of Lost Opportunities

 Cost of Lost Customers

Software problems are

100 to 1000 times more costly

to find and repair after deployment

Testing Dimensions of Quality

Performance

Reliability

behaves consistently and predictably.

under average and peak loading.

perspective

of convenience to the end user.

Supportability

 Test the ability to maintain and support the application under production use.

Workspace Management

Process Integration

Parallel Development

Build Management

 To avoid confusion, have:

 Secure workspaces for each developer

 Automated integration/build management

 Parallel development

Manage Change (continued)

 Unified Change Management (UCM) involves:

 Management across the lifecycle

Develop Iteratively Manage Requirements Use Component Architectures

Model Visually (UML) Continuously Verify Quality

Achieving Best Practices

A Team-Based Definition of Process

A process defines Who is doing What, When, and

How, in order to reach a certain goal

New or changed

requirements

New or changed system

Software Engineering

Process

Process Structure - Lifecycle Phases

 The Rational Unified Process has four phases:

 Inception – Define the scope of the project

 Elaboration – Plan the project; specify features and baseline architecture

 Construction – Build the product

 Transition – Transition the product into the end-user community

Inception Elaboration Construction Transition

Time

Bringing It All Together: The Iterative

 Best Practices guide software engineering by addressing root causes.

 Best Practices reinforce each other.

 Process guides a team on who does what, when, and how.

 The Rational Unified Process is a means of

achieving Best Practices.