1 gioi thieu httt

11

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

22

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.

33

System A

Subsystem B

SubsystemC

SubsystemE

SubsystemD

BoundaryInterface

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)

44

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

HRIPurchasing

TrainingMôi trường hoạt động của tổ chức

55

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

66

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 hệ thống 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, …

77

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

88

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ýấ ả

99

Transaction Processing Systems

BankingSystems EPOS Systems

Healthcare Systems

Insurance SystemsLeisure Industry

1010

Real-Time Systems

Automated Production Control

Control Systems

Security Systems

1111

Management Information Systems

0

10

20

30

40

50

60

70

80

90

1st Qtr 2nd Qtr 3rd Qtr 4th Qtr

East

West

North

Decision Support Systems

OfficeAutomationSystems

Knowledge Based Systems

Executive Information Systems

12

Best Practices of Software Engineering

13

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.

1414

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

1515

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.

1616

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”

17

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

18

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



Modules do not fit

19

Best Practices Reinforce Each Other

Best PracticesBest Practices

Develop Iteratively

Manage Requirements




Manage Change

Develop Iteratively

Manage Requirements




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

20

Practice 1: Develop Iteratively

Best PracticesProcess Made Practical


Develop IterativelyManage Requirements


Model Visually (UML)Continuously Verify Quality

Manage Change




Manage Change

21

Waterfall Development Characteristics Delays confirmation of

critical risk resolution. Measures progress by

assessing work-products that are poor predictors of time-to-completion.

Delays and aggregates integration and testing.

Precludes early deployment.

Frequently results in major unplanned iterations.

Code and Test

Design

Subsystem Integration

System Test

Waterfall Process

Requirements

Analysis

Planning

22

Iterative Development Characteristics Resolves major risks before making large investments. Enables early user feedback. Makes testing and integration continuous. Focuses project short-term objective milestones. Makes possible deployment of partial implementations.

T I M ET I M E

Iteration 1 Iteration 2 Iteration 3 P

RD

CI

T

PR

DC

IT

PR

DC

IT

23

Develop Iteratively Iterative development produces an executable

1. InitialPlanning

2. Planning

3. Requirements4. Analysis & Design

5. Implementation

7. Deployment

6. Test

8. Evaluation

ManagementEnvironment

(on-going)

Each iteration results in an executable release

24

Risk Profiles

TimeTime

Ris

k

Waterfall Risk

Iterative Risk

Risk ReductionRisk Reduction

25

Practice 2: Manage Requirements






Manage Change




Manage Change

26

Managing Requirements Ensures that you

solve the right problem build the right system

by taking a systematic approach to Understanding the problem. Eliciting, organizing, and documenting

the requirements. Managing the changing requirements of a

software application.

27

Practice 3: Use Component Architectures




Use Component ArchitecturesModel Visually (UML)

Continuously Verify QualityManage Change


Use Component ArchitecturesModel Visually (UML)

Continuously Verify QualityManage Change

28

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

29

Purpose of a Component-Based Architecture Basis for reuse

Component Architecture

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

30

Practice 4: Model Visually (UML)






Manage Change




Manage Change

31

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.

32

Visual Modeling with the Unified Modeling Language

Dynamic Diagrams

Multiple viewsPrecise syntax and semantics

ActivityDiagrams

Models

Static Diagrams

SequenceDiagrams

CommunicationDiagrams

State MachineDiagrams

DeploymentDiagrams

ComponentDiagrams

ObjectDiagrams

ClassDiagramsUse-Case

Diagrams

3333

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

3434

Use Case Diagram

Use Case

Actor

Use Case Diagram

B

<<extend>>

A

<<include>>

a1

Generalization

3535

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

10..n 10..n

Product

Order Line

quantity : Integer

price : Money

isSatisfied : Boolean

1..n

1

1..n

1

10..n 10..n

3636

Sequence Diagram – L c đ tu n tượ ồ ầ ựOrder Entry

windowOrder Order Line Stock Item Reorder Item Delivery Item

prepare()

*prepare()hasStock:=check()

[hasStock]remove()

needsReorder:=needsToReorder()

[needsReorder]new

[hasStock] new

X

3737

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

3838

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

3939

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

40

Practice 5: Continuously Verify Quality






Manage Change




Manage Change

41


CostCost

TransitionConstructionElaborationInception

Cost to Repair Software Cost of Lost Opportunities Cost of Lost Customers

Software problems are100 to 1000 times more costly

to find and repair after deployment

42

Test Dimensions of Quality

ReliabilityReliabilityTest the application Test the application for consistent and for consistent and predictable behavior.predictable behavior.

PerformancePerformanceTest online response Test online response

under average and under average and peak loading.peak loading.

FunctionalityFunctionalityTest the accurate Test the accurate workings of each workings of each usage scenario.usage scenario.

UsabilityUsabilityTest the application Test the application

from the from the perspective of perspective of convenience to convenience to

end-user.end-user.

SupportabilitySupportabilityTest the ability to Test the ability to

maintain and support maintain and support the application under the application under

production use.production use.

43

UML Model and

Implementation

Tests

Iteration 1Iteration 1

Test Suite 1Test Suite 1





Test Each Iteration



44

Practice 6: Manage Change






Manage Change




Manage Change

45

Change requests come from many sources throughout the product lifecycle.

Change Request Management Concepts

Help DeskUser input

Coders inputTesters input

Customer andUser input

Marketing

New Feature

NewRequirement

Bug

ApprovedDecisionProcessChange

Control Board(CCB)

Single Channel for Approval

ChangeRequest (CR)

Reqt

Design

Code

Test

Maint

Weinberg, ‘95

46

WorkspaceManagement

Process Integration

Parallel Development

Build Management

Configuration Management is more than just check-in and check-out

Manage Change To avoid confusion, have:

Secure workspaces for each developer Automated integration/build management Parallel development

47

Manage Change (continued) Unified Change Management (UCM) involves:

Management across the lifecycle System Project management

Activity-based management Tasks Defects Enhancements

Progress tracking Charts Reports

48

Develop Iteratively

Manage Requirements




Manage Change

Rational Unified Process Implements Best Practices


49

Achieving Best Practices Iterative approach Guidance for

activities and artifacts

Process focus on architecture

Use cases that drive design and implementation

Models that abstract the system

50

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 EngineeringProcess

51

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

52

Bringing It All Together: The Iterative Approach

Disciplines group activities logically.

In an iteration, you walk through all disciplines.

53

Summary 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.

Education

1 gioi thieu httt