View
85
Download
3
Category
Preview:
DESCRIPTION
TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN. 1. 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) - PowerPoint PPT Presentation
Citation preview
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
Model Visually (UML)
Continuously Verify Quality
Modules do not fit
19
Best Practices Reinforce Each Other
Best PracticesBest 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
20
Practice 1: Develop Iteratively
Best PracticesProcess Made Practical
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
Manage Change
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
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
Best PracticesProcess Made Practical
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
Manage Change
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
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
Best PracticesProcess Made Practical
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component ArchitecturesModel Visually (UML)
Continuously Verify QualityManage Change
Develop IterativelyManage Requirements
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)
Best PracticesProcess Made Practical
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
Manage Change
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
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
Best PracticesProcess Made Practical
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
Manage Change
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
Manage Change
41
Continuously Verify Quality
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
Iteration 2Iteration 2
Test Suite 2Test Suite 2
Iteration 3Iteration 3
Test Suite 3Test Suite 3
Test Each Iteration
Test Suite 4Test Suite 4
Iteration 4Iteration 4
44
Practice 6: Manage Change
Best PracticesProcess Made Practical
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
Manage Change
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
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
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
Rational Unified Process Implements Best Practices
Best PracticesProcess Made Practical
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.
Recommended