SlideShare une entreprise Scribd logo
1  sur  53
Télécharger pour lire hors ligne
TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN
TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Khái niệm cơ bản về hệ thống ,[object Object],System A Subsystem  B Subsystem C Subsystem E Subsystem D Boundary Interface Environment  of  System A
Tổ chức (Organization) ,[object Object],[object Object],[object Object],Môi trường hoạt động của tổ chức Sales IT HRI Purchasing Training
Dữ liệu và thông tin ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Information Systems (IS) ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Hệ thống thông tin tự động hóa  ,[object Object],[object Object],[object Object],[object Object],[object Object]
[object Object],Thông tin và các cấp quản lý 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
Transaction Processing Systems Banking Systems EPOS Systems Healthcare Systems Insurance Systems Leisure Industry
Real-Time Systems Automated Production Control Control Systems Security Systems
Management Information Systems Decision Support Systems Office Automation Systems Knowledge Based Systems Executive Information Systems
Best Practices of Software Engineering
Objectives: Best Practices ,[object Object],[object Object],[object Object]
Mục đích của công nghệ phần mềm ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Bản chất việc phát triển phần mềm ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Con người liên quan (Stakeholders) ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Symptoms of Software Development Problems ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
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 Model Visually (UML) Continuously Verify Quality
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
Practice 1: Develop Iteratively Best Practices Process Made Practical   Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
Waterfall Development Characteristics ,[object Object],[object Object],[object Object],[object Object],[object Object],Code and Test Design Subsystem  Integration System Test Waterfall Process Requirements  Analysis Planning
Iterative Development Characteristics ,[object Object],[object Object],[object Object],[object Object],[object Object],T  I  M  E Iteration 1  Iteration 2  Iteration 3  P R D C I T P R D C I T P R D C I T
Develop Iteratively ,[object Object],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
Risk Profiles Time Risk Waterfall Risk Iterative Risk Risk Reduction
Practice 2: Manage Requirements Best Practices Process Made Practical   Develop   Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
Managing Requirements ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Practice 3: Use Component Architectures Best Practices Process Made Practical   Develop   Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
Use Component Architectures  ,[object Object],Component-based Resilient ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Purpose of a Component-Based Architecture ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],System- software Middleware Business- specific Application- specific Component-based architecture with  layers
Practice 4: Model Visually (UML) Best Practices Process Made Practical   Develop   Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
Model Visually (UML) ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Visual Modeling with the Unified Modeling Language Dynamic Diagrams 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
Activity Diagram – Lược đồ hoạt động  ,[object Object],[object Object]
Use Case Diagram Use Case Actor Use Case Diagram B <<extend>> A <<include>> a1 Generalization
Class Diagram Personal Customer creditCard# Customer name address creditRating() {if Order.customer.creditRating is &quot;poor&quot; 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 0..n 1 0..n Product Order Line quantity : Integer price : Money isSatisfied : Boolean 1..n 1 1..n 1 1 0..n 1 0..n
Sequence Diagram – Lược đồ tuần tự
Collaboration Diagram – Lược đồ cộng tác
Statechart Diagram – Lược đồ trạng thái
Component Diagram – Lược đồ thành phần ,[object Object],[object Object],Call Centre  Interface Order  Management Customer  Management Database  Management
Practice 5: Continuously Verify Quality Best Practices Process Made Practical  Develop   Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
Continuously Verify Quality Cost Transition Construction Elaboration Inception ,[object Object],[object Object],[object Object],Software problems are 100 to 1000 times more costly to find and repair after deployment
Test Dimensions of Quality Reliability Test the application for consistent and predictable behavior. Performance Test online response under average and peak loading. Functionality Test the accurate workings of each usage scenario. Usability Test the application from the perspective of convenience to end-user. Supportability Test the ability to maintain and support the application under production use.
Test Each Iteration UML Model  and  Implementation Tests Iteration 1 Test Suite 1 Iteration 2 Test Suite 2 Iteration 3 Test Suite 3 Test Suite 4 Iteration 4
Practice 6: Manage Change  Best Practices Process Made Practical   Develop   Iteratively Manage Requirements Use Component Architectures Model Visually   (UML) Continuously Verify Quality Manage Change
Change Request Management Concepts Change requests come from many sources throughout the product lifecycle. Help Desk User input Coders input Testers input Customer and User input Marketing New  Feature New Requirement Bug Approved Decision Process Change  Control Board (CCB) Single Channel  for Approval Change Request (CR) Reqt Design Code Test Maint Weinberg, ‘95
Manage Change ,[object Object],[object Object],[object Object],[object Object],Workspace Management Process  Integration Parallel  Development Build  Management Configuration Management is more than just check-in  and check-out
Manage Change (continued) ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Rational Unified Process Implements Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change   Best Practices Process Made Practical
Achieving Best Practices ,[object Object],[object Object],[object Object],[object Object],[object Object]
A Team-Based Definition of Process ,[object Object],New or changed requirements New or changed  system Software Engineering Process
Process Structure - Lifecycle Phases ,[object Object],[object Object],[object Object],[object Object],[object Object],Time Inception Elaboration Construction Transition
Bringing It All Together: The Iterative Approach Disciplines group activities logically. In an iteration, you walk through all disciplines.
Summary ,[object Object],[object Object],[object Object],[object Object]

Contenu connexe

Tendances

Quản trị dự án công nghệ thông tin
Quản trị dự án công nghệ thông tinQuản trị dự án công nghệ thông tin
Quản trị dự án công nghệ thông tinAnh Dam
 
Bài 1 Đại cương về Quản trị học.pptx
Bài 1 Đại cương về Quản trị học.pptxBài 1 Đại cương về Quản trị học.pptx
Bài 1 Đại cương về Quản trị học.pptxTrnhThKiuL1
 
Giáo trình phân tích thiết kế hệ thống thông tin
Giáo trình phân tích thiết kế hệ thống thông tinGiáo trình phân tích thiết kế hệ thống thông tin
Giáo trình phân tích thiết kế hệ thống thông tinVõ Phúc
 
Mẫu free ppt template quy trình, các bước thực hiện chuyên nghiệp
Mẫu free ppt template quy trình, các bước thực hiện chuyên nghiệpMẫu free ppt template quy trình, các bước thực hiện chuyên nghiệp
Mẫu free ppt template quy trình, các bước thực hiện chuyên nghiệpVo Linh Truong
 
NÂNG CAO NĂNG LỰC SẢN XUẤT THÔNG QUA ÁP DỤNG MÔ HÌNH DUY TRÌ NĂNG SUẤT TỔN...
NÂNG CAO NĂNG LỰC SẢN  XUẤT THÔNG QUA ÁP DỤNG  MÔ HÌNH DUY TRÌ NĂNG  SUẤT TỔN...NÂNG CAO NĂNG LỰC SẢN  XUẤT THÔNG QUA ÁP DỤNG  MÔ HÌNH DUY TRÌ NĂNG  SUẤT TỔN...
NÂNG CAO NĂNG LỰC SẢN XUẤT THÔNG QUA ÁP DỤNG MÔ HÌNH DUY TRÌ NĂNG SUẤT TỔN...Le Nguyen Truong Giang
 
Kiem thu phan mem
Kiem thu phan memKiem thu phan mem
Kiem thu phan memTIen Le
 
Giáo trình quản lý dự án
Giáo trình quản lý dự ánGiáo trình quản lý dự án
Giáo trình quản lý dự ánKim Thanh
 
bài giảng phân tích thiết kệ thống thông tin (hutech)
bài giảng phân tích thiết kệ thống thông tin (hutech)bài giảng phân tích thiết kệ thống thông tin (hutech)
bài giảng phân tích thiết kệ thống thông tin (hutech)truong le hung
 
Systems thinking - Tư duy hệ thống
Systems thinking - Tư duy hệ thốngSystems thinking - Tư duy hệ thống
Systems thinking - Tư duy hệ thốngThe Tai Dang
 
Chg 2 uml va ccptht
Chg 2 uml va ccpthtChg 2 uml va ccptht
Chg 2 uml va ccpthtHeo Mọi
 
Bài 1. phân tích đặc tả dự án quản lý sinh viên howkteam.com
Bài 1. phân tích đặc tả dự án quản lý sinh viên howkteam.comBài 1. phân tích đặc tả dự án quản lý sinh viên howkteam.com
Bài 1. phân tích đặc tả dự án quản lý sinh viên howkteam.comthai
 
Phan tich thiet ke he thong thong tin
Phan tich thiet ke he thong thong tinPhan tich thiet ke he thong thong tin
Phan tich thiet ke he thong thong tinNguyễn Duy Hưng
 
Hệ thống quản lý bán hàng online
Hệ thống quản lý bán hàng onlineHệ thống quản lý bán hàng online
Hệ thống quản lý bán hàng onlineHan Nguyen
 
Giáo trình phân tích thiết kế hệ thống ICTU
Giáo trình phân tích thiết kế hệ thống ICTUGiáo trình phân tích thiết kế hệ thống ICTU
Giáo trình phân tích thiết kế hệ thống ICTUNgô Doãn Tình
 
PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG DÙNG UML
PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG DÙNG UMLPHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG DÙNG UML
PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG DÙNG UMLDang Tuan
 
Slide 5 s & kaizen
Slide 5 s & kaizenSlide 5 s & kaizen
Slide 5 s & kaizenRTho
 

Tendances (20)

Quản trị dự án công nghệ thông tin
Quản trị dự án công nghệ thông tinQuản trị dự án công nghệ thông tin
Quản trị dự án công nghệ thông tin
 
Đề tài: Nhận dạng đối tượng sử dụng thuật toán AdaBoost, HOT
Đề tài: Nhận dạng đối tượng sử dụng thuật toán AdaBoost, HOTĐề tài: Nhận dạng đối tượng sử dụng thuật toán AdaBoost, HOT
Đề tài: Nhận dạng đối tượng sử dụng thuật toán AdaBoost, HOT
 
Bài 1 Đại cương về Quản trị học.pptx
Bài 1 Đại cương về Quản trị học.pptxBài 1 Đại cương về Quản trị học.pptx
Bài 1 Đại cương về Quản trị học.pptx
 
Giáo trình phân tích thiết kế hệ thống thông tin
Giáo trình phân tích thiết kế hệ thống thông tinGiáo trình phân tích thiết kế hệ thống thông tin
Giáo trình phân tích thiết kế hệ thống thông tin
 
Mẫu free ppt template quy trình, các bước thực hiện chuyên nghiệp
Mẫu free ppt template quy trình, các bước thực hiện chuyên nghiệpMẫu free ppt template quy trình, các bước thực hiện chuyên nghiệp
Mẫu free ppt template quy trình, các bước thực hiện chuyên nghiệp
 
NÂNG CAO NĂNG LỰC SẢN XUẤT THÔNG QUA ÁP DỤNG MÔ HÌNH DUY TRÌ NĂNG SUẤT TỔN...
NÂNG CAO NĂNG LỰC SẢN  XUẤT THÔNG QUA ÁP DỤNG  MÔ HÌNH DUY TRÌ NĂNG  SUẤT TỔN...NÂNG CAO NĂNG LỰC SẢN  XUẤT THÔNG QUA ÁP DỤNG  MÔ HÌNH DUY TRÌ NĂNG  SUẤT TỔN...
NÂNG CAO NĂNG LỰC SẢN XUẤT THÔNG QUA ÁP DỤNG MÔ HÌNH DUY TRÌ NĂNG SUẤT TỔN...
 
Đề tài: Xây dựng công cụ kiểm thử tự động cho chương trình C
Đề tài: Xây dựng công cụ kiểm thử tự động cho chương trình CĐề tài: Xây dựng công cụ kiểm thử tự động cho chương trình C
Đề tài: Xây dựng công cụ kiểm thử tự động cho chương trình C
 
Kiem thu phan mem
Kiem thu phan memKiem thu phan mem
Kiem thu phan mem
 
Giáo trình quản lý dự án
Giáo trình quản lý dự ánGiáo trình quản lý dự án
Giáo trình quản lý dự án
 
bài giảng phân tích thiết kệ thống thông tin (hutech)
bài giảng phân tích thiết kệ thống thông tin (hutech)bài giảng phân tích thiết kệ thống thông tin (hutech)
bài giảng phân tích thiết kệ thống thông tin (hutech)
 
Systems thinking - Tư duy hệ thống
Systems thinking - Tư duy hệ thốngSystems thinking - Tư duy hệ thống
Systems thinking - Tư duy hệ thống
 
Chg 2 uml va ccptht
Chg 2 uml va ccpthtChg 2 uml va ccptht
Chg 2 uml va ccptht
 
Bài 1. phân tích đặc tả dự án quản lý sinh viên howkteam.com
Bài 1. phân tích đặc tả dự án quản lý sinh viên howkteam.comBài 1. phân tích đặc tả dự án quản lý sinh viên howkteam.com
Bài 1. phân tích đặc tả dự án quản lý sinh viên howkteam.com
 
Phan tich thiet ke he thong thong tin
Phan tich thiet ke he thong thong tinPhan tich thiet ke he thong thong tin
Phan tich thiet ke he thong thong tin
 
Hệ thống quản lý bán hàng online
Hệ thống quản lý bán hàng onlineHệ thống quản lý bán hàng online
Hệ thống quản lý bán hàng online
 
Giáo trình phân tích thiết kế hệ thống ICTU
Giáo trình phân tích thiết kế hệ thống ICTUGiáo trình phân tích thiết kế hệ thống ICTU
Giáo trình phân tích thiết kế hệ thống ICTU
 
Đề tài: Quản lí kho, HAY
Đề tài: Quản lí kho, HAYĐề tài: Quản lí kho, HAY
Đề tài: Quản lí kho, HAY
 
PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG DÙNG UML
PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG DÙNG UMLPHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG DÙNG UML
PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG DÙNG UML
 
Slide 5 s & kaizen
Slide 5 s & kaizenSlide 5 s & kaizen
Slide 5 s & kaizen
 
Mau bao cao project 1
Mau bao cao project 1Mau bao cao project 1
Mau bao cao project 1
 

Similaire à 1 gioi thieu httt

Nhập môn công nghệ phần mềm
Nhập môn công nghệ phần mềmNhập môn công nghệ phần mềm
Nhập môn công nghệ phần mềmTrần Gia Bảo
 
01.1-Quy trinh phat trien phan mem.pptx
01.1-Quy trinh phat trien phan mem.pptx01.1-Quy trinh phat trien phan mem.pptx
01.1-Quy trinh phat trien phan mem.pptxTunTrung15
 
Bài 1: Tổng quan về phân tích thiết kế HTTT & Nguồn phần mềm - Giáo trình FPT
Bài 1: Tổng quan về phân tích thiết kế HTTT & Nguồn phần mềm - Giáo trình FPTBài 1: Tổng quan về phân tích thiết kế HTTT & Nguồn phần mềm - Giáo trình FPT
Bài 1: Tổng quan về phân tích thiết kế HTTT & Nguồn phần mềm - Giáo trình FPTMasterCode.vn
 
C01_TongQuanPTTKHT.pdf
C01_TongQuanPTTKHT.pdfC01_TongQuanPTTKHT.pdf
C01_TongQuanPTTKHT.pdfSnMinhThun
 
Giải Ngân Hàng Đảm Bảo Chất Lượng Phần Mềm PTIT - SQA
Giải Ngân Hàng Đảm Bảo Chất Lượng Phần Mềm PTIT - SQAGiải Ngân Hàng Đảm Bảo Chất Lượng Phần Mềm PTIT - SQA
Giải Ngân Hàng Đảm Bảo Chất Lượng Phần Mềm PTIT - SQAPopping Khiem - Funky Dance Crew PTIT
 
Hướng dẫn-cài-đặt-để-sữ-dụng-enterprise-architect-để-thiết-kế-các-mô-hình
Hướng dẫn-cài-đặt-để-sữ-dụng-enterprise-architect-để-thiết-kế-các-mô-hìnhHướng dẫn-cài-đặt-để-sữ-dụng-enterprise-architect-để-thiết-kế-các-mô-hình
Hướng dẫn-cài-đặt-để-sữ-dụng-enterprise-architect-để-thiết-kế-các-mô-hìnhkey Pham
 
Hệ thống thông tin quản lý - Bài 7 Phát triển hệ thống thông tin (phần 2)
Hệ thống thông tin quản lý - Bài 7 Phát triển hệ thống thông tin (phần 2)Hệ thống thông tin quản lý - Bài 7 Phát triển hệ thống thông tin (phần 2)
Hệ thống thông tin quản lý - Bài 7 Phát triển hệ thống thông tin (phần 2)MasterCode.vn
 
Bai ii khai quat ha tang co so
Bai ii   khai quat ha tang co soBai ii   khai quat ha tang co so
Bai ii khai quat ha tang co soGiang Nguyễn
 
Vai trò của Jenkins trong mô hình phát triển phần mềm Agile
Vai trò của Jenkins trong mô hình phát triển phần mềm AgileVai trò của Jenkins trong mô hình phát triển phần mềm Agile
Vai trò của Jenkins trong mô hình phát triển phần mềm AgileMinh Tri Lam
 
Jenkins (Continuous Integration System with Jenkins)
Jenkins (Continuous Integration System with Jenkins)Jenkins (Continuous Integration System with Jenkins)
Jenkins (Continuous Integration System with Jenkins)Minh Tri Lam
 
Tvtma erp presentation
Tvtma erp presentationTvtma erp presentation
Tvtma erp presentationDavid Tran
 
Giao trinh phan tich thiet ke he thong.pdf
Giao trinh phan tich thiet ke he thong.pdfGiao trinh phan tich thiet ke he thong.pdf
Giao trinh phan tich thiet ke he thong.pdfTuyenKieu5
 
Phan Tich Httt Bang Uml
Phan Tich Httt Bang UmlPhan Tich Httt Bang Uml
Phan Tich Httt Bang Umlhbgfd
 
Kĩ thuật bảo trì phần mềm
Kĩ thuật bảo trì phần mềmKĩ thuật bảo trì phần mềm
Kĩ thuật bảo trì phần mềmPhạm Trung Đức
 

Similaire à 1 gioi thieu httt (20)

Nhập môn công nghệ phần mềm
Nhập môn công nghệ phần mềmNhập môn công nghệ phần mềm
Nhập môn công nghệ phần mềm
 
Hệ thống thông tin quản lý trong doanh nghiệp và kế toán tiền mặt
Hệ thống thông tin quản lý trong doanh nghiệp và kế toán tiền mặtHệ thống thông tin quản lý trong doanh nghiệp và kế toán tiền mặt
Hệ thống thông tin quản lý trong doanh nghiệp và kế toán tiền mặt
 
C1
C1C1
C1
 
01.1-Quy trinh phat trien phan mem.pptx
01.1-Quy trinh phat trien phan mem.pptx01.1-Quy trinh phat trien phan mem.pptx
01.1-Quy trinh phat trien phan mem.pptx
 
Bài 1: Tổng quan về phân tích thiết kế HTTT & Nguồn phần mềm - Giáo trình FPT
Bài 1: Tổng quan về phân tích thiết kế HTTT & Nguồn phần mềm - Giáo trình FPTBài 1: Tổng quan về phân tích thiết kế HTTT & Nguồn phần mềm - Giáo trình FPT
Bài 1: Tổng quan về phân tích thiết kế HTTT & Nguồn phần mềm - Giáo trình FPT
 
C01_TongQuanPTTKHT.pdf
C01_TongQuanPTTKHT.pdfC01_TongQuanPTTKHT.pdf
C01_TongQuanPTTKHT.pdf
 
Giải Ngân Hàng Đảm Bảo Chất Lượng Phần Mềm PTIT - SQA
Giải Ngân Hàng Đảm Bảo Chất Lượng Phần Mềm PTIT - SQAGiải Ngân Hàng Đảm Bảo Chất Lượng Phần Mềm PTIT - SQA
Giải Ngân Hàng Đảm Bảo Chất Lượng Phần Mềm PTIT - SQA
 
Hướng dẫn-cài-đặt-để-sữ-dụng-enterprise-architect-để-thiết-kế-các-mô-hình
Hướng dẫn-cài-đặt-để-sữ-dụng-enterprise-architect-để-thiết-kế-các-mô-hìnhHướng dẫn-cài-đặt-để-sữ-dụng-enterprise-architect-để-thiết-kế-các-mô-hình
Hướng dẫn-cài-đặt-để-sữ-dụng-enterprise-architect-để-thiết-kế-các-mô-hình
 
Hệ thống thông tin quản lý - Bài 7 Phát triển hệ thống thông tin (phần 2)
Hệ thống thông tin quản lý - Bài 7 Phát triển hệ thống thông tin (phần 2)Hệ thống thông tin quản lý - Bài 7 Phát triển hệ thống thông tin (phần 2)
Hệ thống thông tin quản lý - Bài 7 Phát triển hệ thống thông tin (phần 2)
 
Đề tài: Thiết kế hệ thống thông tin phân hệ kế toán tiền lương, 9đ
Đề tài: Thiết kế hệ thống thông tin phân hệ kế toán tiền lương, 9đĐề tài: Thiết kế hệ thống thông tin phân hệ kế toán tiền lương, 9đ
Đề tài: Thiết kế hệ thống thông tin phân hệ kế toán tiền lương, 9đ
 
Bai ii khai quat ha tang co so
Bai ii   khai quat ha tang co soBai ii   khai quat ha tang co so
Bai ii khai quat ha tang co so
 
Luận văn: Nghiên cứu và ứng dụng mẫu thiết kế trong phương pháp hướng đối tượng
Luận văn: Nghiên cứu và ứng dụng mẫu thiết kế trong phương pháp hướng đối tượngLuận văn: Nghiên cứu và ứng dụng mẫu thiết kế trong phương pháp hướng đối tượng
Luận văn: Nghiên cứu và ứng dụng mẫu thiết kế trong phương pháp hướng đối tượng
 
Gt pttk he_thong_thong_tin
Gt pttk he_thong_thong_tinGt pttk he_thong_thong_tin
Gt pttk he_thong_thong_tin
 
Vai trò của Jenkins trong mô hình phát triển phần mềm Agile
Vai trò của Jenkins trong mô hình phát triển phần mềm AgileVai trò của Jenkins trong mô hình phát triển phần mềm Agile
Vai trò của Jenkins trong mô hình phát triển phần mềm Agile
 
Jenkins (Continuous Integration System with Jenkins)
Jenkins (Continuous Integration System with Jenkins)Jenkins (Continuous Integration System with Jenkins)
Jenkins (Continuous Integration System with Jenkins)
 
Ứng dụng mạng Nơ-ron nhân tạo phát triển phần mềm theo Agile
Ứng dụng mạng Nơ-ron nhân tạo phát triển phần mềm theo AgileỨng dụng mạng Nơ-ron nhân tạo phát triển phần mềm theo Agile
Ứng dụng mạng Nơ-ron nhân tạo phát triển phần mềm theo Agile
 
Tvtma erp presentation
Tvtma erp presentationTvtma erp presentation
Tvtma erp presentation
 
Giao trinh phan tich thiet ke he thong.pdf
Giao trinh phan tich thiet ke he thong.pdfGiao trinh phan tich thiet ke he thong.pdf
Giao trinh phan tich thiet ke he thong.pdf
 
Phan Tich Httt Bang Uml
Phan Tich Httt Bang UmlPhan Tich Httt Bang Uml
Phan Tich Httt Bang Uml
 
Kĩ thuật bảo trì phần mềm
Kĩ thuật bảo trì phần mềmKĩ thuật bảo trì phần mềm
Kĩ thuật bảo trì phần mềm
 

Plus de Châu Thanh Chương (20)

Lecture19
Lecture19Lecture19
Lecture19
 
Lecture18
Lecture18Lecture18
Lecture18
 
Lecture17
Lecture17Lecture17
Lecture17
 
Lecture16
Lecture16Lecture16
Lecture16
 
Lecture15
Lecture15Lecture15
Lecture15
 
Lecture14
Lecture14Lecture14
Lecture14
 
Lecture13
Lecture13Lecture13
Lecture13
 
Lecture12
Lecture12Lecture12
Lecture12
 
Lecture11
Lecture11Lecture11
Lecture11
 
Lecture10
Lecture10Lecture10
Lecture10
 
Lecture9
Lecture9Lecture9
Lecture9
 
Lecture8
Lecture8Lecture8
Lecture8
 
Lecture7 pattern
Lecture7 patternLecture7 pattern
Lecture7 pattern
 
Lecture6
Lecture6Lecture6
Lecture6
 
Lecture5
Lecture5Lecture5
Lecture5
 
Lecture4
Lecture4Lecture4
Lecture4
 
Lecture3
Lecture3Lecture3
Lecture3
 
Lecture2
Lecture2Lecture2
Lecture2
 
Lecture1
Lecture1Lecture1
Lecture1
 
Lecture19
Lecture19Lecture19
Lecture19
 

Dernier

CHUYÊN ĐỀ DẠY THÊM HÓA HỌC LỚP 11 CHUNG 3 BỘ SÁCH NĂM 2024 HỆ THỐNG BÀI TẬP B...
CHUYÊN ĐỀ DẠY THÊM HÓA HỌC LỚP 11 CHUNG 3 BỘ SÁCH NĂM 2024 HỆ THỐNG BÀI TẬP B...CHUYÊN ĐỀ DẠY THÊM HÓA HỌC LỚP 11 CHUNG 3 BỘ SÁCH NĂM 2024 HỆ THỐNG BÀI TẬP B...
CHUYÊN ĐỀ DẠY THÊM HÓA HỌC LỚP 11 CHUNG 3 BỘ SÁCH NĂM 2024 HỆ THỐNG BÀI TẬP B...Nguyen Thanh Tu Collection
 
40 ĐỀ LUYỆN THI ĐÁNH GIÁ NĂNG LỰC ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH NĂM ...
40 ĐỀ LUYỆN THI ĐÁNH GIÁ NĂNG LỰC ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH NĂM ...40 ĐỀ LUYỆN THI ĐÁNH GIÁ NĂNG LỰC ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH NĂM ...
40 ĐỀ LUYỆN THI ĐÁNH GIÁ NĂNG LỰC ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH NĂM ...Nguyen Thanh Tu Collection
 
SÁNG KIẾN PHÁT TRIỂN NĂNG LỰC TỰ LÀM MÔ HÌNH KHI TÌM HIỂU KIẾN THỨC “THẠCH QU...
SÁNG KIẾN PHÁT TRIỂN NĂNG LỰC TỰ LÀM MÔ HÌNH KHI TÌM HIỂU KIẾN THỨC “THẠCH QU...SÁNG KIẾN PHÁT TRIỂN NĂNG LỰC TỰ LÀM MÔ HÌNH KHI TÌM HIỂU KIẾN THỨC “THẠCH QU...
SÁNG KIẾN PHÁT TRIỂN NĂNG LỰC TỰ LÀM MÔ HÌNH KHI TÌM HIỂU KIẾN THỨC “THẠCH QU...Nguyen Thanh Tu Collection
 
40 ĐỀ THI THỬ TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH NĂM HỌC 2024 - 2025 SỞ GIÁO...
40 ĐỀ THI THỬ TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH NĂM HỌC 2024 - 2025 SỞ GIÁO...40 ĐỀ THI THỬ TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH NĂM HỌC 2024 - 2025 SỞ GIÁO...
40 ĐỀ THI THỬ TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH NĂM HỌC 2024 - 2025 SỞ GIÁO...Nguyen Thanh Tu Collection
 
IELTS READING - Earth’s lakes are under threat.pptx
IELTS READING - Earth’s lakes are under threat.pptxIELTS READING - Earth’s lakes are under threat.pptx
IELTS READING - Earth’s lakes are under threat.pptxNguynHn870045
 
BÀI TẬP – BÀI GIẢI HÓA HỮU CƠ – TẬP 1 DÙNG BỒI DƯỠNG HỌC SINH GIỎI TỈNH VÀ QU...
BÀI TẬP – BÀI GIẢI HÓA HỮU CƠ – TẬP 1 DÙNG BỒI DƯỠNG HỌC SINH GIỎI TỈNH VÀ QU...BÀI TẬP – BÀI GIẢI HÓA HỮU CƠ – TẬP 1 DÙNG BỒI DƯỠNG HỌC SINH GIỎI TỈNH VÀ QU...
BÀI TẬP – BÀI GIẢI HÓA HỮU CƠ – TẬP 1 DÙNG BỒI DƯỠNG HỌC SINH GIỎI TỈNH VÀ QU...Nguyen Thanh Tu Collection
 
Day tieng Viet cho nguoi nuoc ngoai.pptx
Day tieng Viet cho nguoi nuoc ngoai.pptxDay tieng Viet cho nguoi nuoc ngoai.pptx
Day tieng Viet cho nguoi nuoc ngoai.pptxngothevinhs6lite
 
HƯỚNG DẪN GIẢI ĐỀ THI THAM KHẢO KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤ...
HƯỚNG DẪN GIẢI ĐỀ THI THAM KHẢO KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤ...HƯỚNG DẪN GIẢI ĐỀ THI THAM KHẢO KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤ...
HƯỚNG DẪN GIẢI ĐỀ THI THAM KHẢO KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤ...Nguyen Thanh Tu Collection
 
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...Nguyen Thanh Tu Collection
 
BÀI TẬP BỔ TRỢ TIẾNG ANH LỚP 8 CẢ NĂM CÓ TEST ÔN TẬP ĐỊNH KÌ + NÂNG CAO - FRI...
BÀI TẬP BỔ TRỢ TIẾNG ANH LỚP 8 CẢ NĂM CÓ TEST ÔN TẬP ĐỊNH KÌ + NÂNG CAO - FRI...BÀI TẬP BỔ TRỢ TIẾNG ANH LỚP 8 CẢ NĂM CÓ TEST ÔN TẬP ĐỊNH KÌ + NÂNG CAO - FRI...
BÀI TẬP BỔ TRỢ TIẾNG ANH LỚP 8 CẢ NĂM CÓ TEST ÔN TẬP ĐỊNH KÌ + NÂNG CAO - FRI...Nguyen Thanh Tu Collection
 
GIÁO ÁN KẾ HOẠCH BÀI DẠY MÔN VẬT LÝ 11 CẢ NĂM (SÁCH KẾT NỐI TRI THỨC) THEO CÔ...
GIÁO ÁN KẾ HOẠCH BÀI DẠY MÔN VẬT LÝ 11 CẢ NĂM (SÁCH KẾT NỐI TRI THỨC) THEO CÔ...GIÁO ÁN KẾ HOẠCH BÀI DẠY MÔN VẬT LÝ 11 CẢ NĂM (SÁCH KẾT NỐI TRI THỨC) THEO CÔ...
GIÁO ÁN KẾ HOẠCH BÀI DẠY MÔN VẬT LÝ 11 CẢ NĂM (SÁCH KẾT NỐI TRI THỨC) THEO CÔ...Nguyen Thanh Tu Collection
 
GIÁO ÁN KẾ HOẠCH BÀI DẠY SINH HỌC 10 CHÂN TRỜI SÁNG TẠO - CẢ NĂM THEO CÔNG VĂ...
GIÁO ÁN KẾ HOẠCH BÀI DẠY SINH HỌC 10 CHÂN TRỜI SÁNG TẠO - CẢ NĂM THEO CÔNG VĂ...GIÁO ÁN KẾ HOẠCH BÀI DẠY SINH HỌC 10 CHÂN TRỜI SÁNG TẠO - CẢ NĂM THEO CÔNG VĂ...
GIÁO ÁN KẾ HOẠCH BÀI DẠY SINH HỌC 10 CHÂN TRỜI SÁNG TẠO - CẢ NĂM THEO CÔNG VĂ...Nguyen Thanh Tu Collection
 
14 CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN VẬT LÝ 8 - NĂM 2024 (4...
14 CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN VẬT LÝ 8 - NĂM 2024 (4...14 CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN VẬT LÝ 8 - NĂM 2024 (4...
14 CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN VẬT LÝ 8 - NĂM 2024 (4...Nguyen Thanh Tu Collection
 
lịch sử đảng cộng sản việt nam chương 1.ppt
lịch sử đảng cộng sản việt nam chương 1.pptlịch sử đảng cộng sản việt nam chương 1.ppt
lịch sử đảng cộng sản việt nam chương 1.pptLinhPham480
 
ĐỀ KIỂM TRA THEO UNIT TIẾNG ANH GLOBAL SUCCESS 11 - HK2 (BẢN HS-GV) (3 TESTS ...
ĐỀ KIỂM TRA THEO UNIT TIẾNG ANH GLOBAL SUCCESS 11 - HK2 (BẢN HS-GV) (3 TESTS ...ĐỀ KIỂM TRA THEO UNIT TIẾNG ANH GLOBAL SUCCESS 11 - HK2 (BẢN HS-GV) (3 TESTS ...
ĐỀ KIỂM TRA THEO UNIT TIẾNG ANH GLOBAL SUCCESS 11 - HK2 (BẢN HS-GV) (3 TESTS ...Nguyen Thanh Tu Collection
 
HƯỚNG DẪN GIẢI ĐỀ MINH HỌA KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤC MÔN...
HƯỚNG DẪN GIẢI ĐỀ MINH HỌA KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤC MÔN...HƯỚNG DẪN GIẢI ĐỀ MINH HỌA KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤC MÔN...
HƯỚNG DẪN GIẢI ĐỀ MINH HỌA KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤC MÔN...Nguyen Thanh Tu Collection
 
CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN 7 + 8 CHƯƠNG TRÌNH GDPT M...
CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN 7 + 8 CHƯƠNG TRÌNH GDPT M...CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN 7 + 8 CHƯƠNG TRÌNH GDPT M...
CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN 7 + 8 CHƯƠNG TRÌNH GDPT M...Nguyen Thanh Tu Collection
 

Dernier (17)

CHUYÊN ĐỀ DẠY THÊM HÓA HỌC LỚP 11 CHUNG 3 BỘ SÁCH NĂM 2024 HỆ THỐNG BÀI TẬP B...
CHUYÊN ĐỀ DẠY THÊM HÓA HỌC LỚP 11 CHUNG 3 BỘ SÁCH NĂM 2024 HỆ THỐNG BÀI TẬP B...CHUYÊN ĐỀ DẠY THÊM HÓA HỌC LỚP 11 CHUNG 3 BỘ SÁCH NĂM 2024 HỆ THỐNG BÀI TẬP B...
CHUYÊN ĐỀ DẠY THÊM HÓA HỌC LỚP 11 CHUNG 3 BỘ SÁCH NĂM 2024 HỆ THỐNG BÀI TẬP B...
 
40 ĐỀ LUYỆN THI ĐÁNH GIÁ NĂNG LỰC ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH NĂM ...
40 ĐỀ LUYỆN THI ĐÁNH GIÁ NĂNG LỰC ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH NĂM ...40 ĐỀ LUYỆN THI ĐÁNH GIÁ NĂNG LỰC ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH NĂM ...
40 ĐỀ LUYỆN THI ĐÁNH GIÁ NĂNG LỰC ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH NĂM ...
 
SÁNG KIẾN PHÁT TRIỂN NĂNG LỰC TỰ LÀM MÔ HÌNH KHI TÌM HIỂU KIẾN THỨC “THẠCH QU...
SÁNG KIẾN PHÁT TRIỂN NĂNG LỰC TỰ LÀM MÔ HÌNH KHI TÌM HIỂU KIẾN THỨC “THẠCH QU...SÁNG KIẾN PHÁT TRIỂN NĂNG LỰC TỰ LÀM MÔ HÌNH KHI TÌM HIỂU KIẾN THỨC “THẠCH QU...
SÁNG KIẾN PHÁT TRIỂN NĂNG LỰC TỰ LÀM MÔ HÌNH KHI TÌM HIỂU KIẾN THỨC “THẠCH QU...
 
40 ĐỀ THI THỬ TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH NĂM HỌC 2024 - 2025 SỞ GIÁO...
40 ĐỀ THI THỬ TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH NĂM HỌC 2024 - 2025 SỞ GIÁO...40 ĐỀ THI THỬ TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH NĂM HỌC 2024 - 2025 SỞ GIÁO...
40 ĐỀ THI THỬ TUYỂN SINH VÀO LỚP 10 MÔN TIẾNG ANH NĂM HỌC 2024 - 2025 SỞ GIÁO...
 
IELTS READING - Earth’s lakes are under threat.pptx
IELTS READING - Earth’s lakes are under threat.pptxIELTS READING - Earth’s lakes are under threat.pptx
IELTS READING - Earth’s lakes are under threat.pptx
 
BÀI TẬP – BÀI GIẢI HÓA HỮU CƠ – TẬP 1 DÙNG BỒI DƯỠNG HỌC SINH GIỎI TỈNH VÀ QU...
BÀI TẬP – BÀI GIẢI HÓA HỮU CƠ – TẬP 1 DÙNG BỒI DƯỠNG HỌC SINH GIỎI TỈNH VÀ QU...BÀI TẬP – BÀI GIẢI HÓA HỮU CƠ – TẬP 1 DÙNG BỒI DƯỠNG HỌC SINH GIỎI TỈNH VÀ QU...
BÀI TẬP – BÀI GIẢI HÓA HỮU CƠ – TẬP 1 DÙNG BỒI DƯỠNG HỌC SINH GIỎI TỈNH VÀ QU...
 
Day tieng Viet cho nguoi nuoc ngoai.pptx
Day tieng Viet cho nguoi nuoc ngoai.pptxDay tieng Viet cho nguoi nuoc ngoai.pptx
Day tieng Viet cho nguoi nuoc ngoai.pptx
 
HƯỚNG DẪN GIẢI ĐỀ THI THAM KHẢO KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤ...
HƯỚNG DẪN GIẢI ĐỀ THI THAM KHẢO KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤ...HƯỚNG DẪN GIẢI ĐỀ THI THAM KHẢO KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤ...
HƯỚNG DẪN GIẢI ĐỀ THI THAM KHẢO KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤ...
 
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...
TỔNG HỢP HƠN 100 ĐỀ THI THỬ TỐT NGHIỆP THPT TOÁN 2024 - TỪ CÁC TRƯỜNG, TRƯỜNG...
 
BÀI TẬP BỔ TRỢ TIẾNG ANH LỚP 8 CẢ NĂM CÓ TEST ÔN TẬP ĐỊNH KÌ + NÂNG CAO - FRI...
BÀI TẬP BỔ TRỢ TIẾNG ANH LỚP 8 CẢ NĂM CÓ TEST ÔN TẬP ĐỊNH KÌ + NÂNG CAO - FRI...BÀI TẬP BỔ TRỢ TIẾNG ANH LỚP 8 CẢ NĂM CÓ TEST ÔN TẬP ĐỊNH KÌ + NÂNG CAO - FRI...
BÀI TẬP BỔ TRỢ TIẾNG ANH LỚP 8 CẢ NĂM CÓ TEST ÔN TẬP ĐỊNH KÌ + NÂNG CAO - FRI...
 
GIÁO ÁN KẾ HOẠCH BÀI DẠY MÔN VẬT LÝ 11 CẢ NĂM (SÁCH KẾT NỐI TRI THỨC) THEO CÔ...
GIÁO ÁN KẾ HOẠCH BÀI DẠY MÔN VẬT LÝ 11 CẢ NĂM (SÁCH KẾT NỐI TRI THỨC) THEO CÔ...GIÁO ÁN KẾ HOẠCH BÀI DẠY MÔN VẬT LÝ 11 CẢ NĂM (SÁCH KẾT NỐI TRI THỨC) THEO CÔ...
GIÁO ÁN KẾ HOẠCH BÀI DẠY MÔN VẬT LÝ 11 CẢ NĂM (SÁCH KẾT NỐI TRI THỨC) THEO CÔ...
 
GIÁO ÁN KẾ HOẠCH BÀI DẠY SINH HỌC 10 CHÂN TRỜI SÁNG TẠO - CẢ NĂM THEO CÔNG VĂ...
GIÁO ÁN KẾ HOẠCH BÀI DẠY SINH HỌC 10 CHÂN TRỜI SÁNG TẠO - CẢ NĂM THEO CÔNG VĂ...GIÁO ÁN KẾ HOẠCH BÀI DẠY SINH HỌC 10 CHÂN TRỜI SÁNG TẠO - CẢ NĂM THEO CÔNG VĂ...
GIÁO ÁN KẾ HOẠCH BÀI DẠY SINH HỌC 10 CHÂN TRỜI SÁNG TẠO - CẢ NĂM THEO CÔNG VĂ...
 
14 CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN VẬT LÝ 8 - NĂM 2024 (4...
14 CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN VẬT LÝ 8 - NĂM 2024 (4...14 CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN VẬT LÝ 8 - NĂM 2024 (4...
14 CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN VẬT LÝ 8 - NĂM 2024 (4...
 
lịch sử đảng cộng sản việt nam chương 1.ppt
lịch sử đảng cộng sản việt nam chương 1.pptlịch sử đảng cộng sản việt nam chương 1.ppt
lịch sử đảng cộng sản việt nam chương 1.ppt
 
ĐỀ KIỂM TRA THEO UNIT TIẾNG ANH GLOBAL SUCCESS 11 - HK2 (BẢN HS-GV) (3 TESTS ...
ĐỀ KIỂM TRA THEO UNIT TIẾNG ANH GLOBAL SUCCESS 11 - HK2 (BẢN HS-GV) (3 TESTS ...ĐỀ KIỂM TRA THEO UNIT TIẾNG ANH GLOBAL SUCCESS 11 - HK2 (BẢN HS-GV) (3 TESTS ...
ĐỀ KIỂM TRA THEO UNIT TIẾNG ANH GLOBAL SUCCESS 11 - HK2 (BẢN HS-GV) (3 TESTS ...
 
HƯỚNG DẪN GIẢI ĐỀ MINH HỌA KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤC MÔN...
HƯỚNG DẪN GIẢI ĐỀ MINH HỌA KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤC MÔN...HƯỚNG DẪN GIẢI ĐỀ MINH HỌA KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤC MÔN...
HƯỚNG DẪN GIẢI ĐỀ MINH HỌA KÌ THI TỐT NGHIỆP THPT NĂM 2024 TỪ BỘ GIÁO DỤC MÔN...
 
CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN 7 + 8 CHƯƠNG TRÌNH GDPT M...
CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN 7 + 8 CHƯƠNG TRÌNH GDPT M...CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN 7 + 8 CHƯƠNG TRÌNH GDPT M...
CHUYÊN ĐỀ BỒI DƯỠNG HỌC SINH GIỎI KHOA HỌC TỰ NHIÊN 7 + 8 CHƯƠNG TRÌNH GDPT M...
 

1 gioi thieu httt

  • 1. TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 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
  • 12. Best Practices of Software Engineering
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 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 Model Visually (UML) Continuously Verify Quality
  • 19. 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
  • 20. Practice 1: Develop Iteratively Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
  • 21.
  • 22.
  • 23.
  • 24. Risk Profiles Time Risk Waterfall Risk Iterative Risk Risk Reduction
  • 25. Practice 2: Manage Requirements Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
  • 26.
  • 27. Practice 3: Use Component Architectures Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
  • 28.
  • 29.
  • 30. Practice 4: Model Visually (UML) Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
  • 31.
  • 32. Visual Modeling with the Unified Modeling Language Dynamic Diagrams 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
  • 33.
  • 34. Use Case Diagram Use Case Actor Use Case Diagram B <<extend>> A <<include>> a1 Generalization
  • 35. Class Diagram Personal Customer creditCard# Customer name address creditRating() {if Order.customer.creditRating is &quot;poor&quot; 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 0..n 1 0..n Product Order Line quantity : Integer price : Money isSatisfied : Boolean 1..n 1 1..n 1 1 0..n 1 0..n
  • 36. Sequence Diagram – Lược đồ tuần tự
  • 37. Collaboration Diagram – Lược đồ cộng tác
  • 38. Statechart Diagram – Lược đồ trạng thái
  • 39.
  • 40. Practice 5: Continuously Verify Quality Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
  • 41.
  • 42. Test Dimensions of Quality Reliability Test the application for consistent and predictable behavior. Performance Test online response under average and peak loading. Functionality Test the accurate workings of each usage scenario. Usability Test the application from the perspective of convenience to end-user. Supportability Test the ability to maintain and support the application under production use.
  • 43. Test Each Iteration UML Model and Implementation Tests Iteration 1 Test Suite 1 Iteration 2 Test Suite 2 Iteration 3 Test Suite 3 Test Suite 4 Iteration 4
  • 44. Practice 6: Manage Change Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
  • 45. Change Request Management Concepts Change requests come from many sources throughout the product lifecycle. Help Desk User input Coders input Testers input Customer and User input Marketing New Feature New Requirement Bug Approved Decision Process Change Control Board (CCB) Single Channel for Approval Change Request (CR) Reqt Design Code Test Maint Weinberg, ‘95
  • 46.
  • 47.
  • 48. Rational Unified Process Implements Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Best Practices Process Made Practical
  • 49.
  • 50.
  • 51.
  • 52. Bringing It All Together: The Iterative Approach Disciplines group activities logically. In an iteration, you walk through all disciplines.
  • 53.

Notes de l'éditeur

  1. System Boundary – Phạm vi hệ thống Bao gồm các thành phần chịu ảnh hưởng mạnh mẽ bởi hệ thống sở hữu chúng. System Environment – Môi trường hệ thống &amp;quot;Các thành phần bên ngoài mà sự thay đổi hành vi, ứng xử hay thuộc tính của chúng ảnh huởng tới trạng thái của hệ thống và các thành phần này cũng bị ảnh hưởng bởi ứng xử của hệ thống.&amp;quot; (Lucey) Subsystem - Hệ thống con Là một hệ thống bên trong hệ thống khác. Interface – Giao diện Nơi mà sự tương tác xảy ra giữa 2 hệ thống/ hệ thống con.
  2. Môi trường tổ chức: Môi trường bên ngoài chứa các tổ chức khác liên quan đến hoạt động của tổ chức. Môi trường kinh tế: khách hàng, nhà cung cấp, ngân hàng, … Môi trường xã hội: nhà nước, công đoàn, …
  3. Các đặc điểm của thông tin “tốt” relevance : thích hợp accuracy : chính xác completeness : đầy đủ confidence in the source : nguồn thông tin tin cậy communication to the right person : truyền đạt tới đúng người timing : cập nhật detail : chi tiết channels of communication : là kênh truyền thông understandability : dễ hiểu
  4. Broad definition An IS is a means of processing which generates information may be informal, manual, computer-based
  5. Các mức ra quyết định Mức chiến lược (Strategic level): Dài hạn, liên quan đến các vấn đề phức tạp, tính không chắc chắn và rủi ro cao. Ví dụ: Xác định các mục tiêu cho công ty, lập kế hoạch để đạt được các mục tiêu, chọn dòng sản phẩm mới, lĩnh vực kinh doanh mới, … Mức chiến thuật (Tactical level): giám sát tổ chức ở bất cứ thời điểm nào. Đảm bảo đạt được và sử dụng hiệu quả các tài nguyên Ví dụ: Quyết định ngân quỹ bộ phận, quy hoạch các vị trí nhân viên, chọn sản phẩm cải tiến, lập kế hoạch công việc trung hạn, … Mức thực hiện (Operational level) Đảm bảo các nhiệm vụ cụ thể được thực hiện hiệu quả Ví dụ: Tuyển nhân viên, lập lịch sản xuất, quản lý tồn kho, …
  6. Give examples of each along the line of banking systems dealing with transfer of funds etc. Leisure industry systems in box office ticket sales etc. Worth pointing out that TPS have a wide variety of differing requirements but also there is a great deal of commonality e.g. all TPS have large volumes of similar transactions, detailed data needed. These themes will be covered in detail in week 2.
  7. As above but emphasise the importance of control in RT systems. Give examples of generic commonality and specific differences in RT systems.
  8. Again as above for MIS. Explain that different types of MIS exist with different purposes and also aimed at different levels within management.
  9. In this module, you will learn about recommended software development Best Practices and the reasons for these recommendations. Then you will see how the Rational Unified Process (RUP) is designed to help you implement the Best Practices. The Best Practices are the key terms and concepts introduced in this module.
  10. The stakeholder role is defined as anyone who is materially affected by the outcome of the project.  Effectively solving any complex problem involves satisfying the needs of a diverse group of stakeholders. Typically, stakeholders will have different perspectives on the problem and different needs that must be addressed by the solution. Many stakeholders are users of the system. Other stakeholders are only indirect users of the system or are affected only by the business outcomes that the system influences. Many are economic buyers or champions of the system. An understanding of who the stakeholders are and their particular needs are key elements in developing an effective solution. Examples of stakeholders: Customer or customer representative User or user representative Investor Shareholder Production manager Buyer Designer Tester Documentation writer and so on
  11. By treating these root causes, you will eliminate the symptoms. By eliminating the symptoms, you ’ ll be in a much better position to develop high-quality software in a repeatable and predictable fashion. Best Practices are a set of commercially proven approaches to software development, which, when used in combination, strike at the root causes of software development problems. They are called “ Best Practices, ” not because we can precisely quantify their value, but because they have been observed to be commonly used in the industry by successful organizations. The Best Practices have been harvested from thousands of customers on thousands of projects and from industry experts. Animation note: The first mouse click highlights: Symptom The second mouse click highlights: Root Causes The third mouse click highlights: - Best Practices
  12. This slide may be confusing unless it is explained properly. Use this opportunity to briefly discuss each of the Best Practices. They will be presented more thoroughly in subsequent slides. Ask the students if they can identify some Best Practices of their own. This slide is intended to illustrate how the Best Practices used together provide much more benefit than each individually. The slide only illustrates how one of the Best Practices (Develop Iteratively) supports the others. How others interact might make a good discussion point for the students. For example, how do Manage Change and Continuously Verify Quality relate? The answer is that there is no point in running a test against an unknown configuration and no point in writing a defect against an unknown baseline. Similarly, there is no point in controlling changes until you have reached a stable level of quality in a product. Remind the students that the Best Practices reinforce each other. In the case of our Best Practices, the whole is much greater than the sum of the parts. Each of the Best Practices reinforces and, in some cases, enables the others. This slide shows just one example: how iterative development supports the other five Best Practices. However, each of the other five practices also enhances iterative development. For example, iterative development done without adequate requirements management can easily fail to converge on a solution. Requirements can change at will, which can cause users not to agree and the iterations to go on forever. When requirements are managed, this is less likely to happen. Changes to requirements are visible, and the impact on the development process is assessed before the changes are accepted. Convergence on a stable set of requirements is ensured. Similarly, every Best Practices supports each of the other Best Practices. Hence, although it is possible to use one Best Practice without the others, this is not recommended, since the resulting benefits will be significantly decreased.
  13. Developing iteratively is a technique that is used to deliver the functionality of a system in a successive series of releases of increasing completeness. Each release is developed in a specific, fixed time period called an “ iteration. ” Each iteration is focused on defining, analyzing, designing, building and testing some set of requirements. Keep the concept of iterative development at a very high level in this module. It is easy to get bogged down in the many ramifications of iterative development. Try just to get the concept across. The Essentials of the Rational Unified Process course covers this in more detail.
  14. Waterfall is conceptually straightforward because it produces a single deliverable for each step (requirements, analysis model, design model, code, etc), resulting in a single release. The fundamental problem is that it pushes risk forward in time, where it ’ s costly to undo mistakes from earlier phases. An initial design will likely be flawed with respect to its key requirements, and furthermore, the late discovery of design defects tends to result in costly overruns or project cancellation. The waterfall approach tends to mask the real risks to a project until it is too late to do anything meaningful about them. To illustrate a problem with the waterfall model: Suppose I estimate that the project will take two years, and it really takes three years. At the end of two years, what do I have? Nothing useful works. No partial delivery is possible. Diagrams and models are great, but they can not execute.
  15. Iterative processes were developed in response to these waterfall characteristics. With an iterative process, the waterfall steps are applied iteratively. Instead of developing the whole system in lock step, an increment (that is, a subset of system functionality) is selected and developed, then another increment, and so on. The selection of the first increment to be developed is based on risk, the highest priority risks first. To address the selected risk(s), choose a subset of use cases. Develop the minimal set of use cases that will allow objective verification , for example, through a set of executable tests, of the risks that you have chosen. Then select the next increment to address the next highest risk, and so on. Thus you apply the waterfall within each iteration, and the system evolves incrementally. P: Planning R: Requirements analysis D: Design C: Code and unit test I: Integration T:Test In the iterative approach, the waterfall is applied to a single system increment at a time. Each iteration produces an executable.
  16. Developing iteratively is a technique that is used to deliver the functionality of a system in a successive series of releases of increasing completeness. Each release is developed in a specific, fixed time period called an iteration . Each iteration is focused on defining, analyzing, designing, building, and testing a set of requirements. The earliest iterations address the greatest risks. Each iteration includes integration and testing and produces an executable release. Iterations help: Resolve major risks before making large investments. Enable early user feedback. Make testing and integration continuous. Define a project ’ s short-term objective milestone. Make deployment of partial implementations possible. Instead of developing the whole system in lock step, an increment (for example, a subset of system functionality) is selected and developed, then another increment, and so on. The selection of the first increment to be developed is based on risk, with the highest priority risks first. To address the selected risk(s), choose a subset of use cases. Develop the minimal set of use cases that will allow objective verification (that is, through a set of executable tests) of the risks that you have chosen. Then, select the next increment to address the next-highest risk, and so on.
  17. Iterative development produces the architecture first, allowing integration to occur “ as the verification activity ” of the design phase and allowing design flaws to be detected and resolved earlier in the lifecycle. Continuous integration throughout the project replaces the “ big bang ” integration at the end of a project. Iterative development also provides much better insight into quality, because of system characteristics that are largely inherent in the architecture. For example, performance, fault tolerance, and maintainability are tangible earlier in the process. Thus, issues are still correctable without jeopardizing target costs and schedules.
  18. A report from the Standish Group confirms that a distinct minority of software development projects is completed on-time and on-budget. In their report, the success rate was only 28 percent, while challenged projects (operational, but late and over-budget) accounted for 49 percent. Cancelled projects accounted for 23 percent. These failures are attributed to lack of executive management support, lack of user involvement, inexperienced project managers, ill-defined business objectives, poor scope management, no standard software infrastructure, no firm basic requirements, no formal methodology, and unreliable estimates. (Source: Chaos 2001 Report, http://www.standishgroup.com).
  19. A report from the Standish Group confirms that a distinct minority of software development projects is completed on time and on budget. In their report, the success rate was only 16.2%, while challenged projects (operational, but late and over budget) accounted for 52.7%. Impaired (canceled) projects accounted for 31.1%. These failures are attributed to incorrect requirements definition from the start of the project and poor requirements management throughout the development lifecycle. (Source: Chaos Report , http://www.standishgroup.com) Aspects of requirements management: Analyze the problem Understand user needs Define the system Manage scope Refine the system definition Manage changing requirements
  20. Software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost, according to the authors of Software Architecture in Practice (Len Bass, Paul Clements &amp; Rick Kazman [1998] Addison-Wesley). The Software Engineering Institute (SEI) has an effort underway called the Architecture Tradeoff Analysis (ATA) Initiative to focus on software architecture, a discipline much misunderstood in the software industry. The SEI has been evaluating software architectures for some time and would like to see architecture evaluation in wider use. By performing architecture evaluations, AT&amp;T reported a 10 percent productivity increase (from news@sei, Vol. 1, No. 2).
  21. Architecture is a part of Design. It is about making decisions on how the system will be built. But it is not all of the design. It stops at the major abstractions, or, in other words, the elements that have some pervasive and long-lasting effect on system performance and ability to evolve. A software system ’ s architecture is perhaps the most important aspect that can be used to control the iterative and incremental development of a system throughout its lifecycle. The most important property of an architecture is resilience – flexibility in the face of change. To achieve it, architects must anticipate evolution in both the problem domain and the implementation technologies to produce a design that can gracefully accommodate such changes. Key techniques are abstraction, encapsulation, and object-oriented Analysis and Design. The result is that applications are fundamentally more maintainable and extensible. Software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost, according to the authors of Software Architecture in Practice (Len Bass, Paul Clements, and Rick Kazman [1998] Addison-Wesley). The Software Engineering Institute (SEI) has an effort underway called the Architecture Tradeoff Analysis (ATA) Initiative that focuses on software architecture, a discipline much misunderstood in the software industry. The SEI has been evaluating software architectures for some time and would like to see architecture evaluation in wider use. As a result of performing architecture evaluations, AT&amp;T reported a 10% productivity increase (from news@sei, Vol. 1, No. 2). You can encourage a brief discussion at this point. A single requirement, such as throughput or fault tolerance, affects almost every design decision made on a system. For example, if a transportation system (such as for trains) is being built, it is likely to have a “no single point of failure” requirement that must be in every developer’s mind every step of the way. Many architectural mechanisms will be developed to accommodate that single requirement. If you can get some students to describe their architectural challenges, this point will be driven home more effectively.
  22. Definition of a (Software) Component: RUP Definition : A nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A component conforms to and provides the physical realization of a set of interfaces. UML Definition : A physical, replaceable part of a system that packages implementation, and conforms to and provides the realization of a set of interfaces. A component represents a physical piece of implementation of a system, including software code (source, binary, or executable) or equivalents, such as scripts or command files. Because students vary in how familiar they are with the concept of architecture applied to software, it is best to get a sense of this from the students before beginning this section. If they are fairly unfamiliar, it helps to use the analogy of buildings or civil engineering. As a building becomes more complex , good architecture becomes more critical. The longer you want the building to be useful, the more effort and expense you should put into the architecture. I n both cases, the choice of architect is critical.
  23. A model is a simplification of reality that provides a complete description of a system from a particular perspective. We build models so that everyone can understand the system to be built. Models are built for complex systems because we cannot comprehend any such system in its entirety. You may wish to lead a discussion about models and why we build models in general. For example, before building a bridge, the architect builds a model and has it reviewed. We build models because some projects are so complex that no one can understand all of the details. A model leaves out all the details that are unimportant. It facilitates our understanding of the larger issues.
  24. A model is a simplification of reality that provides a complete description of a system from a particular perspective. We build models so that we can better understand the system we are building. We build models of complex systems because we cannot comprehend any such system in its entirety. Modeling is important because it helps the development team visualize, specify, construct, and document the structure and behavior of system architecture. Using a standard modeling language such as the UML (the Unified Modeling Language), different members of the development team can communicate their decisions unambiguously to one another. Using visual modeling tools facilitates the management of these models, letting you hide or expose details as necessary. Visual modeling also helps you maintain consistency among system artifacts: its requirements, designs, and implementations. In short, visual modeling helps improve a team ’ s ability to manage software complexity. Visual modeling for software is analogous to blueprints for construction.
  25. In building a visual model of a system, many different diagrams are needed to represent different views of the system. The UML provides a rich notation for visualizing models. This includes the following key diagrams: Use-case diagrams to illustrate user interactions with the system Class diagrams to illustrate logical structure Object diagrams to illustrate objects and links Component diagrams to illustrate physical structure of the software Deployment diagrams to show the mapping of software to hardware configurations Activity diagrams to illustrate flows of events State Machine diagrams to illustrate behavior Interaction diagrams (that is, Communication and Sequence diagrams) to illustrate behavior This is not all of the UML diagrams, just a representative sample. The UML provides a graphical language for representing models but provides little or no guidance on when and how to use these diagrams. This is an area in which the RUP helps. It describes the kinds of project artifacts needed, including diagrams, and puts them in the context of an overall project plan.
  26. Quality , as used within RUP, is defined as &amp;quot;The characteristic of having demonstrated the achievement of producing a product which meets or exceeds agreed-upon requirements, as measured by agreed-upon measures and criteria, and is produced by an agreed-upon process.&amp;quot; Given this definition, achieving quality is not simply &amp;quot;meeting requirements&amp;quot; or producing a product that meets user needs and expectations. Quality also includes identifying the measures and criteria (to demonstrate the achievement of quality) and the implementation of a process to ensure that the resulting product has achieved the desired degree of quality (and can be repeated and managed). In many organizations, software testing accounts for 30 percent to 50 percent of software development costs. Yet most people believe that software is not well-tested before it is delivered. This contradiction is rooted in two clear facts. First, testing software is enormously difficult. The different ways a particular program can behave are almost infinite. Second, testing is typically done without a clear methodology and without the required automation or tool support. While the complexity of software makes complete testing an impossible goal, a well-conceived methodology and use of state-of-the-art tools can greatly improve the productivity and effectiveness of the software testing. Do not assume that verifying quality and testing are synonymous. While testing is used to do the bulk of quality verification, there are other techniques.
  27. Quality , as used within the RUP, is defined as “ The characteristic of having demonstrated the achievement of producing a product which meets or exceeds agreed-upon requirements, as measured by agreed-upon measures and criteria, and is produced by an agreed-upon process.&amp;quot; Given this definition, achieving quality is not simply “ meeting requirements&amp;quot; or producing a product that meets user needs and expectations. Quality also includes identifying the measures and criteria (to demonstrate the achievement of quality) and the implementation of a process to ensure that the resulting product has achieved the desired degree of quality (and can be repeated and managed). This principle is driven by a fundamental and well-known property of software development: It is a lot less expensive to correct defects during development than to correct them after deployment. Tests for key scenarios ensure that all requirements are properly implemented. Poor application performance hurts as much as poor reliability. Verify software reliability by checking for memory leaks and bottlenecks. Test every iteration by automating testing. Inception, Elaboration, Construction, and Transition are all RUP terms that will be discussed shortly. Many people remember Barry Boehm’s groundbreaking work in Software Economics , where he quantified the relative expense to fix a bug at different times in the development lifecycle. Be cautious, however, since his work was based on the waterfall model, not an iterative development model. The iterative model fundamentally changes how and when we test.
  28. Functional testing verifies that a system executes the required use-case scenarios as intended. Functional tests may include the testing of features, usage scenarios, and security. Usability testing evaluates the application from the user ’ s perspective. Usability tests focus on human factors, aesthetics, consistency in the user interface,   online and context-sensitive help, wizards and agents, user documentation, and   training materials. Reliability testing verifies that the application performs reliably and is not prone to failures during execution (crashes, hangs, memory leaks). Effective reliability testing requires specialized tools. Reliability tests include integrity, structure, stress, contention, and volume tests. Performance testing checks that the target system works functionally and reliably under production load. Performance tests include benchmark tests, load tests, and performance profile tests. Supportability testing verifies that the application can be deployed as intended. Supportability tests include installation and configuration tests. This is the FURPS model of dimensions of quality presented in RUP. See the RUP for details about all these types of tests. Be prepared to define and discuss all.
  29. In each iteration, automated tests are created that test the requirements addressed in that iteration. As new requirements are added in subsequent iterations, new tests are generated and run. At times, a requirement may be changed in a later iteration. In that case, the tests associated with the changed requirement may be modified or simply regenerated by an automated tool. It is important to start automating test in the earliest iterations. Some people think that you do not need to automate testing until the later iterations when requirements are pretty stable. Even if you expect that the requirements…and hence the tests, are still unstable, it is still more efficient to automate.
  30. As indicated earlier, you cannot stop change from being introduced into a project. However, you must control how and when changes are introduced into project artifacts and who introduces the changes. As well, you must synchronize change across development teams and locations. Unified Change Management (UCM) is Rational Software&apos;s approach to managing change in software system development, from requirements to release. Control of change is especially important in an iterative project. Artifacts are generally produced incrementally. At the end of each iteration, another increment is put under configuration control. Otherwise, no progress is made, and iterations do not converge on a complete and consistent system. We are not just talking about changes to source code, but also to requirements, models, documents, plans, and all development artifacts.
  31. Change Request Management (CRM) addresses the organizational infrastructure required to assess the cost and schedule impact of a requested change to the existing product. CRM addresses the workings of a Change Review Team or Change Control Board. Configuration Status Accounting (Measurement) is used to describe the “ state ” of the product based on the type, number, rate, and severity of defects found and fixed during the course of product development. Metrics derived under this aspect, either through audits or raw data, are useful in determining the overall completeness of the project. Configuration Management (CM) describes the product structure and identifies its constituent configuration items that are treated as single versionable entities in the configuration management process. CM deals with defining configurations, building and labeling, and collecting versioned artifacts into constituent sets and maintaining traceability between these versions. Change Tracking describes what is done to components for what reason and at what time. It serves as the history and rationale of changes. It is quite separate from assessing the impact of proposed changes as described under Change Request Management. Version Selection is to ensure that the right versions of configuration items are selected for change or implementation. Version selection relies on a solid foundation of “ configuration identification. ” Software Manufacture covers the need to automate the steps to compile, test, and package software for distribution.
  32. Establishing a secure workspace for each developer provides isolation from changes made in other workspaces and control of all software artifacts — models, code, documents and so forth. A key challenge to developing software-intensive systems is the need to cope with multiple developers, organized into different teams, possibly at different sites, all working together on multiple iterations, releases, products, and platforms. In the absence of disciplined control, the development process rapidly degrades into chaos. Progress can come to a stop. Three common problems that result are: Simultaneous update : When two or more roles separately modify the same artifact, the last one to make changes destroys the work of the others. Limited notification : When a problem is fixed in shared artifacts, some of the developers are not notified of the change. Multiple versions : With iterative development, it would not be unusual to have multiple versions of an artifact in different stages of development at the same time. For example, one release is in customer use, one is in test, and one is still in development. If a problem is identified in any one of the versions, the fix must be propagated among all of them. If possible, use examples from your experience to illustrate what can go wrong when doing parallel development without adequate controls. For example, describe two programmers making simultaneous updates to the same component, or a very important test failing in front of a customer because the wrong version of the test case was run.
  33. Unified Change Management (UCM) is “ the Rational software approach ” to managing change in software system development, from requirements to release. UCM spans the development lifecycle, defining how to manage change to requirements, design models, documentation, components, test cases, and source code. One of the key aspects of the UCM model is that it unifies the activities used to plan and track project progress and the artifacts undergoing change. You cannot stop change from being introduced into a project; however, you must control how and when changes are introduced into project artifacts, and who introduces those changes. You must also synchronize changes across development teams and locations. Unified Change Management (UCM) is the Rational Software approach to managing change in software system development, from requirements to release. Regarding support for UCM in the RUP: The CM concepts described in UCM are covered in the RUP by the following workflow details: Create Project CM Environments Change and Deliver Configuration Items Manage Baselines and Releases UCM does not cover the RUP activities described in these workflows: Monitor and Report Configuration Status Manage Change Requests The activities described in the RUP workflow detail — Plan Project Configuration and Change Control — are at a higher level of abstraction than the notion of a project described in UCM. However, UCM does cover the fact that policies need to be set, and that there is a CM process to be followed to ensure that all project artifacts are maintained under configuration control.
  34. Why have a process? It provides guidelines for efficient development of quality software It reduces risk and increases predictability It promotes a common vision and culture It captures and institutionalizes Best Practices The Rational Unified Process (RUP) is a generic business process for object-oriented software engineering. It describes a family of related software-engineering processes sharing a common structure and a common process architecture. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget. The RUP captures the Best Practices in modern software development in a form that can be adapted for a wide range of projects and organizations. The UML provides a standard for the artifacts of development (semantic models, syntactic notation, and diagrams): the things that must be controlled and exchanged. But the UML is not a standard for the development process . Despite all of the value that a common modeling language brings, you cannot achieve successful development of today ’ s complex systems solely by the use of the UML. Successful development also requires employing an equally robust development process, which is where the RUP comes in.
  35. Examples: The dynamic structure (phases and iterations) of the Rational Unified Process creates the basis of iterative development. The Project Management discipline describes how to set up and execute a project using phases and iterations. Within the Requirements discipline, the Use-case model and the risk list determine what functionality you implement in an iteration. The workflow details of the Requirements discipline show the activities and artifacts that make requirements management possible. The iterative approach allows you to progressively identify components and to decide which one to develop, which one to reuse, and which one to buy. The Unified Modeling Language (UML) used in the process represents the basis of visual modeling and has become the de facto modeling language standard. The focus on software architecture allows you to articulate the structure: the components, the ways in which they integrate, and the fundamental mechanisms and patterns by which they interact.
  36. It can be very difficult to explain what a process is, if the students are not already familiar with it. An informal example most people can relate to is the process of balancing a checkbook at the end of the month. Most of us have developed a process we use that includes the same steps every month. It shortens the time required to accomplish the task and ensures that we do not forget any steps. The same applies to a software-engineering process. We want it to be repeatable and to ensure that all required tasks are accomplished when required. Of course, a software-engineering process is much more complex than balancing a checkbook, and there is a tremendous amount of information contained in the RUP.
  37. During Inception, we define the scope of the project: what is included and what is not. We do this by identifying all the actors and use cases, and by drafting the most essential use cases (typically 20% of the complete model). A business plan is developed to determine whether resources should be committed to the project. During Elaboration, we focus on two things: getting a good grasp of the requirements (80% complete) and establishing an architectural baseline. If we have a good grasp of the requirements and the architecture, we can eliminate a lot of the risks, and we will have a good idea of how much work remains to be done. We can make detailed cost and resource estimates at the end of Elaboration. During Construction, we build the product in several iterations up to a beta release. During Transition, we move the product to the end user and focus on end-user training, installation, and support. The amount of time spent in each phase varies. For a complex project with many technical unknowns and unclear requirements, Elaboration may include three to five iterations. For a simple project, where requirements are known and the architecture is simple, Elaboration may include only a single iteration. The Student Notes are quite extensive. There is no need to go into that much detail in class. The important thing is to understand how the RUP uses phases to organize the lifecycle. You can also mention that we deliberately chose names that do not match the waterfall names (analysis, design, implementation, and test) to emphasize that they are not the same as the waterfall phases. Some ways of describing the phases in common terminology: Inception — Bid and proposal Elaboration — Building blueprints Construction — I think I’m done. Transition — How do users react?
  38. This slide illustrates how phases and iterations (the time dimension) relate to the development activities (the discipline dimension). The relative size of each color area in the graph indicates how much of the activity is performed in each phase or iteration. Each iteration involves activities from all disciplines. The relative amount of work related to the disciplines changes between iterations. For instance, during late Construction, the main work is related to Implementation and Test, and very little work on Requirements is done. Note that requirements are not necessarily complete by the end of Elaboration. It is acceptable to delay the analysis and design of well-understood portions of the system until Construction because they are low in risk. This is a brief summary of the RUP disciplines: Business Modeling – Encompasses all modeling techniques you can use to visually model a business. Requirements – Defines what the system should do. Analysis &amp; Design – Shows how the system&apos;s use cases will be realized in implementation. Implementation – Implements software components that meet quality standards. Test – Integrates and tests the system. Deployment - Provides the software product to the end-user. Configuration &amp; Change Management – Controls and tracks changes to artifacts. Project Management – Ensures tasks are scheduled, allocated and completed in accordance with project schedules, budgets and quality requirements. Environment – Defines and manages the environment in which the system is being developed.