nhập môn công nghệ phần mềm,nguyễn tấn trần minh khang ...

i

MỤC LỤC

MỤC LỤC ............................................................................................... i

Chƣơng 1 GIỚI THIỆU VỀ CÔNG NGHỆ PHẨN MỀM ............. 1

1.1 SOFTWARE DEVELOPER ..................................................................... 5

1.2 SDLC - VÕNG ĐỜI PHÁT TRIỂN HỆ THỐNG................................... 11

1.3 HỌC TẬP TÍNH KHẢ THI: BƢỚC ĐẦU TIÊN ................................... 17

1.4 CÁC CÁCH THU THẬP THÔNG TIN.................................................. 19

1.5 SƠ ĐỒ HỆ THỐNG HAY MÔ HÌNH HỆ THỐNG ............................... 25

1.6 PHƢƠNG PHÁP LUẬN PHÁT TRIỂN ................................................. 32

1.7 THIẾT KẾ HỆ THỐNG .......................................................................... 37

1.8 PHƢƠNG PHÁP HƢỚNG ĐỐI TƢỢNG .............................................. 42

1.9 KIỂM TRA PHẦN MỀM ....................................................................... 50

1.10 STANDARD AND METRIC ............................................................... 55

1.11 THỦ TỤC .............................................................................................. 60

1.12 CÀI ĐẶT ............................................................................................... 66

1.13 TÀI LIỆU HÓA .................................................................................... 67

1.14 BẢO TRÌ ............................................................................................... 69

1.15 HUẤN LUYỆN ..................................................................................... 72

1.16 KẾT LUẬN ........................................................................................... 73

CuuDuongThanCong.com https://fb.com/tailieudientucntt

http://cuuduongthancong.com?src=pdf

https://fb.com/tailieudientucntt

ii

Chƣơng 2 NGHIÊN CỨU VỀ TÍNH KHẢ THI VÀ PHÂN TÍCH

CHI PHÍ/LỢI NHUẬN ....................................................................... 77

2.1 NHỮNG THÀNH PHẦN TRONG NGHIÊN CỨU TÍNH KHẢ THI ... 80

2.1.1 Tinh khả thi về tai chinh ............................................................ 80

2.1.2 Tinh khả thi về mặt kỹ thuật ...................................................... 82

2.1.3 Tinh khả thi về tổ chức, điều hanh ............................................ 85

2.2 PHÂN TÍCH CHI PHÍ/LỢI NHUẬN ..................................................... 91

2.3 LẬP KẾ HOẠCH NGHIÊN CỨU TÍNH KHẢ THI .............................. 97

2.4 QUY TRÌNH NGHIÊN CỨU TÍNH KHẢ THI.................................... 100

2.4.1 Xác định tinh khả thi ............................................................... 102

2.4.2 Những đánh giá khác ............................................................... 103

2.4.3 Các công đoạn nghiên cứu tinh khả thi ................................... 106

2.5 KẾT LUẬN ........................................................................................... 108

Chƣơng 3 LÊN DỰ ÁN CHO KẾ HỌACH PHẦN MỀM .......... 111

3.1 TẠI SAO PHẢI LÊN KẾ HOẠCH CHO DỰ ÁN ................................ 113

3.2 AI LÊN KẾ HOẠCH CHO DỰ ÁN ..................................................... 116

3.3 ĐIỀU GÌ XẢY RA KHI LÊN KẾ HOẠCH CHO DỰ ÁN ................... 117

3.4 THE PROJECT PLAN UNWRAPPED ................................................ 121

3.4.1 Mục đich của phần mềm .......................................................... 121

3.4.2 Đánh giá phần mềm ................................................................. 123

3.4.3 Kỹ thuật phân rã ...................................................................... 128

3.4.4 Mô hình kinh nghiệm .............................................................. 129




iii

3.4.5 Quản lý rủi ro........................................................................... 130

3.4.6 Bảng thời gian: ........................................................................ 134

3.4.7 Tai nguyên dự án: .................................................................... 140

3.4.8 Cơ chế theo dõi va kiểm soát: ................................................. 144

3.5 CÓ ĐÁNG ĐỂ LÀM CÔNG VIỆC NÀY HAY KHÔNG? .................. 145

Chƣơng 4 THU THẬP YÊU CẦU ................................................ 148

4.1 STAKEHOLDER ANALYSIS ............................................................. 149

4.2 ELICITATION TECHNIQUES ............................................................ 154

4.2.1 Interviewing ............................................................................. 154

4.2.2 Questionnaires and Surveys..................................................... 169

4.2.3 Observation.............................................................................. 177

4.2.4 Participation ............................................................................. 180

4.2.5 Competitive Intelligence ......................................................... 183

4.2.6 Brainstorming .......................................................................... 186

4.2.7 Focus Groups ........................................................................... 186

4.2.8 Prototyping .............................................................................. 187

4.3 A CHECK LIST FOR REQUIREMENTS MANAGEMENT .............. 187

4.4 KẾT LUẬN ........................................................................................... 187

Chƣơng 5 THIẾT KẾ HỆ THỐNG THEO HƢỚNG NGƢỜI SỬ

DỤNG 189




iv

5.1 BÍ MẬT THƢƠNG MẠI ...................................................................... 191

5.2 VIỆC TAILOR HỆ THỐNG TỚI YÊU CẦU NGƢỜI DÙNG CUỐI . 193

5.3 KÊU GỌI SỰ HĂNG HÁI .................................................................... 196

5.4 PHƢƠNG PHÁP LUẬN ....................................................................... 200

5.5 PHÂN PHỐI DỮ LIỆU CHO CHỦ NHÂN HỢP PHÁP – NGƢỜI

DÙNG CUỐI .................................................................................................. 208

5.6 SỰ LỰA CHỌN CHO CÁC HỆ THỐNG ............................................ 212

5.7 KẾT LUẬN ........................................................................................... 218

Chƣơng 6 XEM XÉT QUYẾT ĐỊNH THUÊ NGOÀI ................ 219

6.1 BƢỚC 1: PHÂN TÍCH VÀ ĐÁNH GIÁ .............................................. 220

6.2 BƢỚC 2: THẨM ĐỊNH YÊU CẦU VÀ LỰA CHỌN ĐỐI TÁC ........ 221

6.3 BƢỚC 3: TRIỂN KHAI ........................................................................ 223

6.4 MỘT VÍ DỤ VỀ OUTSOURCE ........................................................... 225

6.4.1 Những vấn đề khi outsource .................................................... 227

6.4.2 Chi phí bao nhiêu? ................................................................... 236

6.4.3 Sử dụng nha cung cấp dịch vụ Internet ................................... 238

6.4.4 Tự xoay sở ............................................................................... 241

6.4.5 Giá nhân công .......................................................................... 243

6.4.6 Giá dựa trên những cái ma bạn muốn đặt vao site................... 244

6.5 CÓ NÊN THUÊ NGOÀI KHÔNG? ...................................................... 245

6.6 NHỮNG CÂU HỎI CHO CÁC CÔNG Ty OUTSOURCE TIỀM NĂNG

255

6.7 NHỮNG MÔ HÌNH THUÊ NGOÀI .................................................... 258




v

6.8 KẾT LUẬN ........................................................................................... 260

Chƣơng 7 LỰA CHỌN PHƢƠNG PHÁP LUẬN........................ 261

7.1 ĐÁNH GIÁ PHƢƠNG PHÁP LUẬN .................................................. 261

7.1.1 Phƣơng pháp luận có xác định những bƣớc cần thiết để phát

triển hệ thống không? .......................................................................... 261

7.1.2 Phƣơng pháp luận có đơn giản hóa quá trình phát triển hệ thống?

263

7.1.3 Phƣơng pháp luận có tạo ra những bƣớc tiến lớn trong phát triển

hệ thống? ............................................................................................. 264

7.1.4 Phƣơng pháp luận có thể tùy biến để tƣơng thich bới các yêu cầu

cụ thể của tổ chức hay không? ............................................................. 266

7.1.5 Phƣơng pháp luận có phải la ―trạng thái của nghệ thuật?‖ ...... 268

7.1.6 Phƣơng pháp luận có hoan thiện không?................................. 271

7.1.7 Phƣơng pháp luận có thể bị chia ra thanh các thanh phần nhỏ

không? 274

7.1.8 Phƣơng pháp luận có thể thich ứng với nhiều lĩnh vực, nganh

nghề? 274

7.1.9 Phƣơng pháp luận có sản sinh ra tai liệu ? .............................. 275

7.1.10 Phƣơng pháp luận có những phƣơng pháp riêng biệt cho mỗi

bƣớc trong từng giai đoạn của SDLC hay không ? ............................. 276




vi

7.1.11 Liệu các phƣơng pháp luận có cung cấp các phƣơng pháp kĩ

thuật ma mô tả lam cách nao để thực hiện các phƣơng pháp của nó ?

277

7.1.12 Các phƣơng pháp luận sẽ kết hợp chặt chẽ các tiêu chuẩn va

ngoai thực tiễn của tổ chức ? .............................................................. 279

7.1.13 Phƣơng pháp luận có xác định đƣợc từng vai trò của những

thanh viên khác nhau trong team của dự án hay không ? .................. 279

7.1.14 Liệu đồng nhất phƣơng pháp có cung cấp công cụ phù hợp cho

việc thi hanh từng phƣơng pháp? ........................................................ 281

7.1.15 Phƣơng pháp luận có thể thực hiện đƣợc không? .................. 282

7.1.16 Phƣơng pháp luận có thể đƣợc tìm thấy? .............................. 283

7.1.17 Phƣơng pháp luận có duy trì giao diện tiêu chuẩn công nghiệp?

285

7.1.18 Sự đao tạo thich hợp có phù hợp với phƣơng pháp luận ....... 286

7.1.19 Ngƣời quản lý giải thich rằng bộ công cụ, phƣơng pháp đƣợc

sử dụng trong tổ thức giống nhƣ trong tổ chức của bạn? .................... 287

7.2 QUYẾT ĐỊNH MỨC ĐIỂM PHƢƠNG PHÁP LUẬN ........................ 288

7.3 TÀI LIỆU THAM KHẢO ..................................................................... 288

Chƣơng 8 LỰA CHỌN VÀ KẾT HỢP THÔNG TIN ĐỂ QUẢN

LÝ TÀI NGUYÊN HIỆU QUẢ ........................................................ 289

8.1 QUẢN LÝ HIỆU QUẢ TÀI NGUYÊN THÔNG TIN ......................... 290

8.2 CÁCH SỬ DỤNG CHƢƠNG NÀY ..................................................... 295




vii

8.2.1 Đánh giá Repository Workbench ............................................ 297

8.2.2 Chuân bi Repository Workbench ............................................ 321

8.2.2.1 Những hanh đông cần lên kê hoach: .................................... 321

8.2.2.2 Những câu hoi đăt ra cho viêc đinh cơ những nỗ lực thu thâp

tai liệu: 323

8.2.2.3 Những câu hoi đăt ra liên quan đên vân đê ky thuât va thao tac:

327

8.2.2.4 Những câu hoi đăt ra về bảo mật .......................................... 329

8.2.2.5 Những câu hoi đăt ra liên quan đến dữ liệu trùng lắp va không

thống nhất ............................................................................................ 329

8.2.2.6 Những câu hoi yêu câu vê đô phức tap va phu thuôc lân nhau

331

8.2.3 Repository Metrics .................................................................. 332

8.2.3.1 Tinh liên quan ....................................................................... 333

8.2.3.2 Viêc sử dụng phổ biến các IS khác biệt ................................ 334

8.2.3.3 Độ tự đông hoa ..................................................................... 334

8.2.3.4 Độ bảo mật ........................................................................... 335

8.2.3.5 Metrics kho lƣu trữ ............................................................... 336

8.2.3.6 Tinh nhất quán ...................................................................... 336

8.2.3.7 Truy xuât trực quan .............................................................. 337

8.2.3.8 Mức đô cua sự phân tich tac đông ........................................ 337

8.2.3.9 Tinh kết hợp.......................................................................... 338

8.3 CHO ĐIỂM REPOSITORY WORKBENCH ....................................... 338

8.4 TÀI LIỆU THAM KHẢO ..................................................................... 339




viii

Chƣơng 9 STRUCTURED METHODOLOGY REVIEW ......... 341

9.1 RAPID APPLICATIONS DEVELOPMENT (RAD): .......................... 346

9.2 CASE TOOL ......................................................................................... 355

9.3 VARIETY OF STRUCTURED METHODOLOGIES ......................... 358

9.4 FINKELSTEIN INFORMATION ENGINEERING ............................. 360

9.5 EXTREME PROGRAMMING ............................................................. 367

Chƣơng 10 KHÁI NIỆM LẬP TRÌNH EXTREME ................... 371

10.1 NHỮNG LUẬT LỆ CỦA LẬP TRÌNH EXTREME .......................... 373

10.1.1 Vòng lặp ................................................................................ 380

10.1.2 Phát triển ................................................................................ 381

10.1.3 Thẻ CRC ................................................................................ 383

10.1.4 Hệ thống ẩn............................................................................ 384

10.1.5 Mã sơ hữu chung ................................................................... 385

10.1.6 Bộ Test .................................................................................. 386

10.1.7 Test chấp thuận ...................................................................... 386

10.1.8 Tốc độ dự án: ......................................................................... 387

10.1.9 Phiên bản nhỏ ........................................................................ 388

10.1.10 Bản thiết kế đơn giản ........................................................... 389

10.1.11 Tiêu chuẩn viết code ............................................................ 389

10.1.12 Refactoring .......................................................................... 389

10.1.13 Lập trình cặp đôi .................................................................. 390




ix

10.1.14 Continuos Intergration ......................................................... 390

10.1.15 40 giờ mỗi tuần .................................................................... 391

10.1.16 On-site customer .................................................................. 392

10.2 KẾT LUẬN ......................................................................................... 392

Chƣơng 11 KỶ THUẬT PHÁT TRIỂN TRƢỚC KHI TIẾN

HÀNH CÔNG VIỆC ......................................................................... 394

11.1 SAI SÓT TRONG HỆ THỐNG LÀ GÌ .............................................. 395

11.2 DEVELOPMENT BEFORE THE FACT ........................................... 402

11.3 THE TECHNOLOGY ......................................................................... 405

11.4 PRIMITIVE STRUCTURES (CẤU TRÖC MẪU) ............................ 412

11.5 DEFINED STRUCTURES ................................................................. 416

11.6 FMAPS, TMAP VÀ SỰ KẾT HỢP CỦA CHÖNG............................ 420

11.7 NHỮNG PHÉP TOÁN NGUYÊN THỦY THÔNG DỤNG .............. 423

11.8 XEM XÉT THỰC HIỆN ..................................................................... 432

11.9 HÕA HỢP VỚI HỆ THỐNG HƢỚNG ĐỐI TƢỢNG ....................... 434

Chƣơng 12 BẢN ĐẶC TẢ THIẾT KẾ ......................................... 443

12.1 QUY TRÌNH ....................................................................................... 444

12.2 CHI TIẾT BẢN THIẾT KẾ ................................................................ 446

12.3 THIẾT KẾ LOGIC VÀ VẬT LÝ ........................................................ 461

12.3.1 Phân tích logic va vật lý ........................................................ 461

12.3.2 Thiết kế logic ......................................................................... 466




x

12.3.3 Thiết kế vật lý ........................................................................ 469

12.4 SỰ ĐẶC TẢ CỦA CÁC HỆ THỐNG ................................................ 471

12.5 MỘT SỐ HƢỚNG DẪN CHO MỘT BẢN ĐẶC TẢ HỆ THỐNG ... 475

12.6 KẾT LUẬN ......................................................................................... 477

12.7 TÀI LIỆU THAM KHẢO: .................................................................. 480

Chƣơng 13 THIẾT KẾ HƢỚNG ĐỐI TƢỢNG .......................... 482

13.1 WHAT IS OO ? ................................................................................... 483

13.2 OO FROM THE BOTTOM UP .......................................................... 488

13.3 METHODOLOGIES ........................................................................... 494

13.3.1 OOAD Methodologies ........................................................... 494

13.3.2 Booch ..................................................................................... 494

13.3.3 Coad and Yourdon ................................................................ 495

13.3.4 Jacobson: Objectory and OOSE ............................................ 497

13.3.5 LBMS SEOO ......................................................................... 499

13.3.6 Phƣơng Pháp Rumbaugh OMT ............................................. 500

13.3.7 Shlaer và Mellor: ................................................................... 501

13.3.8 OOAD Simplied .................................................................... 502

Chƣơng 14 THIÊT KÊ GIAO DIÊN NGƢỜI DUNG ................. 507

14.1 NHỮNG NGUYÊN TẮC CƠ BẢN CỦA THIẾT KẾ GIAO DIỆN .. 509

14.2 QUÁ TRÌNH THIẾT KẾ GIAO DIỆN ............................................... 519

14.3 THIẾT KẾ NHẬP XUẤT HIỆU QUẢ ............................................... 523




xi

14.3.1 Thiết kế nhập ......................................................................... 524

14.3.1.1 Giấy .................................................................................... 525

14.3.1.2 Mâu điên tử ......................................................................... 530

14.3.1.3 Những thiêt bi nhâp trực tiêp .............................................. 532

14.3.2 Thiêt kê xuất .......................................................................... 533

14.4 KIỂM THỬ TÍNH TIỆN DỤNG ........................................................ 534

14.5 KẾT LUẬN ......................................................................................... 535

14.6 TÀI LIỆU THAM KHẢO ................................................................... 537

Chƣơng 15 SOFTWARE RE-ENGINEERING ........................... 540

15.1 WHAT IS SOFTWARE RE-ENGINEERING? .................................. 542

15.2 WHY WE NEED SOFTWARE RE-ENGINEERING ........................ 542

15.3 SOFTWARE RE-ENGINEERING STRATEGIES ............................ 544

15.4 THE PROCESS OF RE-ENGINEERING .......................................... 548

15.4.1 Source Code Translation ....................................................... 548

15.4.2 Reverse Engineering .............................................................. 550

15.4.3 Program Structure Improvement ........................................... 554

15.4.4 Program Modularization ........................................................ 557

15.4.5 Data Re-Engineering ............................................................. 560

15.5 FORWARD ENGINEERING ............................................................. 565

Chƣơng 16 KIỂM THỬ PHẦN MỀM .......................................... 567

16.1 KIỂM THỬ PHẦN MỀM LÀ GÌ ? ..................................................... 568




xii

16.2 CHIẾN LƢỢC KIỂM THỬ PHẦN MỀM .......................................... 576

16.3 TEST AUTOMATION ....................................................................... 582

16.4 NGUYÊN LÝ TEST AUTOMATION .............................................. 587

16.5 THỰC TẾ TIẾP CẬN TỰ ĐỘNG TESTING SFTWARE ................. 592

16.6 SỬ DỤNG CÔNG CỤ THỬ NGHIỆM TỰ ĐỘNG .......................... 594

16.7 KẾT LUẬN ......................................................................................... 598

Chƣơng 17 QUÁ TRÌNH THỰC HIỆN KIỂM ĐỊNH EDP ....... 602

17.1 QUÁ TRÌNH THỰC HIỆN KIỂM ĐỊNH EDP .................................. 603

17.2 TỔ CHỨC CỦA SỰ KIỂM ĐỊNH ..................................................... 605

17.3 SYSTEMIC AUDIT: ........................................................................... 612

17.3.1 Hệ thống kiểm toán ............................................................... 612

17.3.2 Thời gian đáp ứng .................................................................. 613

17.3.3 Liên kết hỏng ......................................................................... 615

17.3.4 Cơ sở dữ liệu kiểm toán ......................................................... 615

17.3.5 Mạng kiểm toán ..................................................................... 617

17.3.6 An ninh va chất lƣợng ........................................................... 618

17.4 BẢO MẬT VÀ CHẤT LƢỢNG BẢO MẬT ...................................... 619

17.4.1 Xem xét lại những kế hoạch bảo mật .................................... 620

17.4.2 Passwords .............................................................................. 621

17.4.3 Staff Background ................................................................... 622

17.4.4 Connectivity .......................................................................... 623

17.4.5 Cơ sở cần có của phần mềm .................................................. 624

17.4.6 Phát triển trong nha ............................................................... 625




xiii

17.4.7 Testing ................................................................................... 635

17.4.8 Lập báo cáo............................................................................ 637

17.4.9 Sao lƣu ................................................................................... 637

17.5 KHOA HỌC NGHIÊN CỨU TÍNH TIỆN DỤNG ............................. 638

17.5.1 Điều hƣớng ............................................................................ 639

17.5.2 Tiện lợi .................................................................................. 641

17.6 DỊCH VỤ KHÁCH HÀNG ................................................................. 643

17.6.1 Acvessibility .......................................................................... 644

17.6.2 E-Commerce .......................................................................... 644

17.6.3 Sự riêng tƣ ............................................................................. 646

17.6.4 Tinh hợp pháp ........................................................................ 646

17.6.5 Bản quyền .............................................................................. 647

17.6.6 Cách sử dụng Web của nhân viên ......................................... 647

17.7 KẾT LUẬN ......................................................................................... 648

Chƣơng 18 QUẢN LÝ BẢO TRÌ PHẦN MỀM ........................... 650

18.1 QUÁ TRÌNH BẢO TRÌ: ..................................................................... 653

18.2 CÁC LOẠI BẢO TRÌ: ........................................................................ 656

18.2.1 Bảo trì hiệu chỉnh: ................................................................. 657

18.2.2 Bảo trì tƣơng thích: ................................................................ 658

18.2.3 Hoàn thiện bảo dƣơng: .......................................................... 658

18.2.4 Bảo trì dự phòng .................................................................... 659

18.3 CHI PHÍ BẢO TRÌ .............................................................................. 660




xiv

18.4 MẪU BẢO TRÌ ................................................................................... 664

18.5 QUẢN LÝ BỘ PHẬN BẢO TRÌ ........................................................ 667

18.6 ĐÁNH GIÁ HIỆU QUẢ ..................................................................... 669

18.7 QUẢN LÝ YÊU CẦU BẢO TRÌ ........................................................ 671

18.8 KẾT LUẬN ......................................................................................... 674


Chƣơng 19 KHOA HỌC VỀ TÀI LIỆU HÓA ............................ 673

19.1 TÀI LIỆU HÓA LÀ GÌ? ..................................................................... 674

19.1.1 Tạo ra các văn bản phần mềm cơ bản .................................... 678

19.1.2 Sự công nhận tầm quan trọng của tai liệu ở mức ngƣời quản lý

679

19.1.3 Sự tồn tại của chinh sách hay tiêu chuẩn về tai liệu .............. 679

19.1.4 Giám sát thực hiện chinh sách hoặc tiêu chuẩn ..................... 680

19.1.5 Sự tồn tại của một quá trình định sẵn để tạo các tai liệu ....... 680

19.1.6 Phƣơng pháp để đảm bảo chất lƣợng của các tai liệu ............ 681

19.1.7 Đánh giá về tinh tiện dụng của các tai liệu ............................ 681

19.1.8 Định nghĩa về các thƣớc đo chất lƣợng va tinh tiện dụng của tai

liệu phần mềm ..................................................................................... 682

19.1.9 Tập hợp va phân tich các thƣớc đo chất lƣợng của tai liệu ... 682

19.1.10 Tập hợp va phân tich các thƣớc đo tinh tiện dụng của tai liệu

683

19.1.11 Quy trình phản hồi - cải tiến ................................................ 684

19.2 CÁC PHƢƠNG PHÁP VÀ TIÊU CHUẨN ........................................ 686




xv

19.3 TẠO TÀI LIỆU MỘT CÁCH ĐÖNG ĐẮN ....................................... 691

19.3.1 Tất cả các tai liệu hƣớng dẫn đƣợc sản xuất trƣớc khi bắt đầu

phát triển mã nguồn ............................................................................. 692

19.3.2 Lƣu đồ chƣơng trình .............................................................. 693

19.3.3 Mô hình sử dụng hay mô hình nghiệp vụ .............................. 694

19.3.4 Thuật ngữ tham khảo ............................................................. 695

19.3.5 Từ điển dữ liệu ...................................................................... 695

19.3.6 Tai liệu về chƣơng trình / Thanh phần / Đối tƣợng ............... 700

19.3.7 Các tai liệu trình bay .............................................................. 701

19.3.8 Các trƣờng hợp kiểm tra (Phụ lục O) va kế hoạch kiểm tra .. 702

19.3.9 Tiêu chuẩn đo lƣờng .............................................................. 702

19.3.10 Các hƣớng dẫn hoạt động .................................................... 703

19.3.11 Tập tin trợ giúp ngƣời dùng cuối ......................................... 703

19.3.12 Tai liệu hƣớng dẫn ngƣời dùng ........................................... 704

19.4 BẢO TRÌ TÀI LIỆU ........................................................................... 706

19.5 KẾT LUẬN ......................................................................................... 709


Chƣơng 20 KHẢO SÁT VỀ NĂNG SUẤT VÀ CHẤT LƢỢNG713

20.1 KẾ HOẠCH CHO CHẤT LƢỢNG .................................................... 717

20.2 QUÁ TRÌNH ĐÁNH GIÁ .................................................................. 722

20.3 ĐỘ ĐO GỐC ....................................................................................... 730

20.4 CÁCH CỦA HP .................................................................................. 737

20.5 THE FUNCTION POINT ADVANTAGE ......................................... 741




xvi

20.6 CÂN BẰNG CHẤT LƢỢNG ............................................................. 753

20.7 KẾT LUẬN ......................................................................................... 756


Chƣơng 21 PUTNAM’S SOFTWARE EQUATION AND SLIM

758

21.1 TỔNG QUAN ..................................................................................... 758

21.2 THỦ TỤC- VẤN ĐẾ- CHÍNH SÁCH ................................................ 760


Chƣơng 22 MÔ HÌNH COCOMO II ............................................ 766

22.1 MỞ ĐẦU ............................................................................................. 766

22.2 MÔ HÌNH THÀNH PHẦN ỨNG DỤNG .......................................... 767

22.3 MÔ HÌNH THIẾT KẾ BAN ĐẦU ...................................................... 771

22.4 MÔ HÌNH POST_ARCHITECTURE ................................................ 773


Chƣơng 23 MẪU ƢỚC TÍNH CHI PHÍ PUTNAM .................... 777

23.1 TỔNG QUAN ..................................................................................... 777

23.2 THỦ TỤC/VẤN ĐỀ/CHÍNH SÁCH .................................................. 778





xvii

Chƣơng 24 MALCOLM BALDRIGE QUALITY AWARD ...... 781

24.1 TỔNG QUAN ..................................................................................... 781

24.2 THỦ TỤC/ VẤN ĐỀ/ CHÍNH SÁCH ................................................ 782

24.2.1 The award is built upon a number of key concepts: .............. 782

24.2.2 Examination categories/items ................................................ 784

Chƣơng 25 ZACHMAN’S FRAMEWORK ................................. 791

25.1 TỔNG QUAN ..................................................................................... 791

25.2 THỦ TỤC / VẤN ĐỀ / CHÍNH SÁCH .............................................. 792


Chƣơng 26 PHƢƠNG PHÁP LINKMAN CHO VIỆC KIỂM

SOÁT CHƢƠNG TRÌNH THÔNG QUA CÁC PHÉP ĐO ........... 798

26.1 TỔNG QUAN ..................................................................................... 798


Chƣơng 27 KELLNER’S NONTECHNOLOGICAL ISSUES IN

SOFTWARE ENGINEERING ........................................................ 800

27.1 TỔNG QUAN ..................................................................................... 800

27.2 THỦ TỤC/ VẤN ĐỀ/ CHÍNH SÁCH ............................................... 802





xviii

27.4 CHUYÊN ĐỀ CHỌN LỌC ................................................................. 810

Chƣơng 28 MARTIN AND CAREY’S SURVEY OF SUCCESS

IN CONVERTING PROTOTYPES TO OPERATIONAL

SYSTEMS 811

28.1 TỔNG QUAN ..................................................................................... 811


Chƣơng 29 KHUYNH HƢỚNG CỦA PUTNAM TRONG SỰ ĐO

LƢỜNG, DỰ ĐOÁN VÀ KIỂM SOÁT ........................................... 823

29.1 TỒNG QUAN ..................................................................................... 823


Chƣơng 30 KỸ THUẬT CỦA SPRAGUE CHO QUẢN TRỊ CẤU

HÌNH PHẦN MỀM TRONG KỸ NGHỆ PHẦN MỀM DỰA VÀO

ĐO LƢỜNG 831

30.1 TỔNG QUAN ..................................................................................... 831


30.3 THỦ TỤC PHÁT TRIỂN MỘT QUY TRÌNH SCM .......................... 841






xix

Chƣơng 31 HỆ PHƢƠNG PHÁP LUẬN CỦA CORBIN VỀ

THIẾT LẬP MÔI TRƢỜNG PHÁT TRIỂN PHẦN MỀM .......... 847

31.1 TỔNG QUAN ..................................................................................... 847


Chƣơng 32 BÀY NGUYÊN TẮC CỦA CHẤT LƢỢNG ............ 847

32.1 TỔNG QUAN ..................................................................................... 847

32.2 THỦ TỤC/ VẤN ĐÊ/ CHÍNH SÁCH ................................................ 848

Chƣơng 33 THỐNG KÊ CỦA VỀ NĂNG SUẤT LÀM VIỆC

NHÓM 857

33.1 TỔNG QUAN ..................................................................................... 857


Chƣơng 34 QUAN ĐIỂM CỦA GOULD VỀ TÍNH TIỆN DỤNG

867

34.1 TỔNG QUAN ..................................................................................... 867






xx

Chƣơng 35 NGUYÊN TẮC CHỈ ĐẠO CỦA PRESCOTT VỀ

VIỆC SỬ DỤNG PHƢƠNG PHÁP CÓ CẤU TRÖC .................... 881

35.1 TỔNG QUAN ..................................................................................... 881


Chƣơng 36 KEMAYEL’S CONTROLLABLE FACTORS IN

PROGRAMMER PRODUCTIVITY .............................................. 891

36.1 TỔNG QUAN ..................................................................................... 891

36.2 THỦ TỤC/VẤN ĐỀ/ CHÍNH SÁCH ................................................. 892



Chƣơng 37 THE AT&T’S “ESTIMEETING’ PROCESS FOR

DEVELOPING ESTIMATES .......................................................... 908

37.1 TỔNG QUAN ..................................................................................... 908

37.2 ThỦ TỤC/CHÍNH SÁCH/VẤN ĐỀ ................................................... 912

Chƣơng 38 KHUNG BURN ĐỂ XÂY HỆ THỐNG ĐÁNG TIN

CẬY 921

38.1 TỔNG QUAN ..................................................................................... 921





xxi

Chƣơng 39 PHƢƠNG PHÁP TIẾP CẬN ĐA DIỆN CỦA

AVISON 930

39.1 TỔNG QUAN ..................................................................................... 930




Chƣơng 40 BYRNE’S REVERSE ENGINEERING TECHNIQUE

940

40.1 TỔNG QUAN ..................................................................................... 940

40.2 THỦ TỤC/ VẤN ĐẾ/ CHÍNH SÁCH ................................................ 943

Chƣơng 41 MÔ HINH TAI SỬ DỤNG CỦA PERIETO-DIAZ. 949

42.1 TỔNG QUAN ..................................................................................... 949


Chƣơng 42 NHẬN XÉT CỦA FARBEY VỀ CÁC THƢỚC ĐO

CHẤT LƢỢNG PHẦN MỀM TRONG GIAI ĐOẠN QUẢN LÝ

YÊU CẦU 962

42.1 TỔNG QUAN ..................................................................................... 962

42.2 THỦ TỤC/VẤN ĐỀ/ CHÍNH SÁCH ................................................. 964




xxii


Chƣơng 43 NHỮNG XEM XÉT VỀ CHẤT LƢỢNG CỦA

REDMILL TRONG VIỆC QUẢN LÝ QUÁ TRÌNH PHÁT TRIỂN

PHẦN MỀM 970

43.1 TỔNG QUAN ..................................................................................... 970




Chƣơng 44 ĐỘ ĐO CONTEL TRONG KHUNG HOÀN THIỆN

QUY TRÌNH ...................................................................................... 982

44.1 TỔNG QUAN ..................................................................................... 982




Chƣơng 45 KYDD’S TECHNIQUE TO INDUCE

PRODUCTIVITY THROUGHT SHARED INFORMATION

TECHNOLOGY ................................................................................ 994

45.1 TỔNG QUAN ..................................................................................... 994





xxiii

45.3 TÀI LIỆU THAM KHẢO ................................................................. 1000

45.4 CHUYÊN ĐỀ CHỌN LỌC ............................................................... 1000

Chƣơng 46 THƢỚC ĐO CHẤT LƢỢNG PHẦN MỀM

BELLCORE 1001

46.1 TỔNG QUAN ................................................................................... 1001

46.2 THỦ TỤC/ VẤN ĐỀ/ CHÍNH SÁCH .............................................. 1003

46.3 TẢI LIỆU THAM KHẢO ................................................................. 1009

46.4 CHUYÊN ĐỀ CHỌN LỌC ............................................................... 1009

Chƣơng 47 GIÁ TRỊ THÔNG TIN CỦA KEYES .................... 1009

47.1 TỔNG QUAN ................................................................................... 1009

48.2 THỦ TỤC/ VẤN ĐỀ/ CHÍNH SÁCH ............................................. 1010

48.3 TÀI LIỆU THAM KHẢO ................................................................ 1012

Chƣơng 48 PHƢƠNG PHÁP CỦA PFLEEGER ĐỂ LỰA CHỌN

CÔNG CỤ CASE DỰA TRÊN SỰ TRƢỞNG THÀNH CỦA QUÁ

TRÌNH 1013

48.1 TỔNG QUAN ................................................................................... 1013

48.2 THỦ TỤC/ VẤN ĐỀ/ CHÍNH SÁCH .............................................. 1015

48.3 TÀI LIỆU THAM KHẢO ................................................................. 1020




Chương 1: Giới thiệu về công nghệ phần mềm 1

CHƢƠNG 1 GIỚI THIỆU VỀ CÔNG NGHỆ

PHẨN MỀM

Người dịch:

1. Lê Quang Thảo

2. Huỳnh Thảo Hạnh Duy

3. Trịnh Quang Huy

You must start somewhere so I have chosen to start this book at the

beginning with a very brief introduction to software engineering. In this

chapter we are going to touch lightly on topics that we will cover in more

depth in later chapters. Reading this chapter will give you a sense of the

interconnectivity of the myriad of software engineering activities that we

talk about.

Bạn phải bắt đầu tại một nơi nao đó vì vậy bạn có thể chọn quyển

sách nay để bắt đầu với những giới thiệu ngắn gọn về công nghệ phần mềm.

Trong chƣơng nay chúng ta sẽ đi tổng quát hết các chƣơng, sau đó thì





chúng ta sẽ đi sâu hơn ở những chƣơng kế tiếp. Chƣơng nay sẽ cho bạn một

ý thức về sự nối liền của vô số hoạt động công nghệ phần mềm.

Computer systems come in all shapes and sizes. There are systems

that process e-mail and systems that process payroll. There are also systems

that monitor space missions and systems that monitor student grades. No

matter how diverse the functionality of these systems, they have several

things in common:

Những hệ thống máy tinh có rất nhiều hình dạng va kich thƣớc. Có

những hệ thống xử lý e-mail va những hệ thống xử lý tiền lƣơng nhân viên.

Có những hệ thống giám sát (công việc ngoai vũ trụ - space mission) và

những hệ thống giám sát kết quả học tập của sinh viên. Dù cho chức năng

của chúng có khác nhau đi nữa thì chúng vẫn có các điểm chung sau:

All systems have end users. It is for these end users that the system

has been created. They have a vested interest in seeing that the

system is correctly and efficiently doing what it is supposed to be

doing. You might say that these end users have a ―stake‖ in seeing

that the system is successful so sometimes they are referred to as

―stakeholder‖. There are different types of stakeholders. A good

systems analyst is careful to make sure that he does not leave out

stakeholders erroneously. This is indeed what happened when the

post office started developing the automated system that you now

see in use today at all post offices. This system was developed ―in a





vacuum‖. What this means is that only higher level employees

were involved in system development. The clerks who actually

man the windows were left out of the process; when it came time

for this system to be deployed, the lack of involvement of this

critical set of stakeholders almost led to an employee mutiny.

Tất cả các hệ thống đều có ngƣời dùng cuối: một nha phân tich hệ

thống có khá nhiều quyết định phải đƣa ra. Anh ta phải quyết định

nền tảng để xây dựng hệ thống nay: 1) PC only; 2) mainframe

only; 3) Client/server … Anh ta còn phải quyết định có nên dùng

third-party software (các phần mềm danh cho các nhãn hiệu máy

tính có sẵn nhƣ Word, Excel …). Anh ta thậm chi còn phải quyết

định ngôn ngữ lập trình va loại cơ sở dữ liệu cần dùng.

All systems are written using programming languages. If the IT

(information technology) department is filled with COBOL

programmers, it might not be a wise decision to use Java. If Java is

mandatory, then the systems analyst needs to plan for this by

training existing staff or outsourcing the development effort to a

consulting firm. This information is contained within the

―requirements document‖, which, in this handbook we will call the

system requirements specification, or SRS

Tất cả các hệ thống đƣợc viết đều sử dụng những ngôn ngữ chƣơng

trình: nếu doanh nghiệp IT chỉ gồm những ngƣời viết chƣơng trình





(programmer) COBOL, nó có thể không phải la một quyết định

khôn ngoan nếu dùng Java. Nếu Java la bắt buộc, khi đó ngƣời

phân tich hệ thống cần có kế hoạch cho nó bằng cách huấn luyện

các nhân viên hoặc outsource sự cố gắng phát triển cho một hãng

cố vấn:D. Thông tin nay thể hiện bên trong ―tai liệu yêu cầu‖

(requirements document) ma trong cuốn sách nay chúng ta sẽ gọi la

―đặc tả các yêu cầu của hệ thống‖ (System Requirements

specification), hoặc SRS

All systems should be designed using a methodology and proper

documentory techniques. There are many developmental

methodologies. The two main generic categories are structured and

object-oriented. The tools and techniques surrounding these

methodologies are part and parcel of ―software engineering‖. A

properly developed system is carefully analyzed and then designed.

The first step of this process is the plan; the next step is the SRS,

and the third step is the design document. Finally implementation,

testing, and then deployment take place. These are some of the

main steps in the software development life Cycle or SDLC.

Tất cả các hệ thống nên đƣợc thiết kế bằng một phƣơng pháp luận

va những kỹ thuật tai liệu đúng chuẩn (proper documentory

techniques): Có nhiều phƣơng pháp luận phát triển. Hai phạm trù

giống loai (generic) chinh la cấu trúc (structured) va hƣớng đối

tƣợng (object-oriented). Những công cụ va kỹ thuật xung quanh





những phƣơng pháp luận nay la thanh phần va gói ―công nghệ

phần mềm‖. Một hệ thống đƣợc phát triển đúng đắn nghĩa la nó

đƣợc phân tich kỹ lƣơng, sau đó mới thiết kế. Bƣớc đầu tiên của

quá trình nay la lên kế hoạch, bƣớc tiếp theo la SRS, bƣớc thứ 3 la

tai liệu thiết kế. Cuối cùng la sự bổ sung, kiểm tra, va sau đó la

triển khai. Đây la vai bƣớc chinh trong vòng đời phát triển phần

mềm (software development life cycle) hay SDLC.

1.1 SOFTWARE DEVELOPER

I started out in this field as a programmer. In those days (several eons

ago) there were real boundaries between the different types of jobs one

could do. If you were a programmer you did not do analysis work and vice

versa. In fact, most analysts back then knew very little about programming.

Trƣớc đây, có những rao cản phân biệt các nghề nghiệp khác nhau.

Nếu bạn la một programmer, bạn không phải lam công việc phân tich va

ngƣợc lại. Trên thực tế, hầu hết những nha phân tich biết rất it về viết

chƣơng trình.

That has all changed but, typically, you still start out as a

programmer but then the sky‘s the limit. A programmer is a person who

knows one or more programming languages (e.g., Java, C++, etc.). His job

is to read a programming specification, which is usually written by the

systems analyst and then translate that specification into program code.





Mọi chuyện đã thay đổi nhƣng, điển hình, bạn còn có thể bắt đầu

công việc nhƣ một developer tha hồ. Một developer la một ngƣời biết một

hoặc nhiều ngôn ngữ lập trình. Công việc của anh ta la đọc một đặc tả,

thƣờng đƣợc viết bởi những nha phân tich hệ thống va dịch đặc tả đó thanh

những đoạn code.

In most companies the programmer works within project teams that

are managed by a project leader who, in turn, is managed by a project

manager.Each project team has one or more programmers and probably one

or more systems analysts. The programmer works on the code and seldom,

if ever, works with the end users. The systems analysts, on the other hand,

work directly with the end users to develop requirements and specifications

for the system to be designed.

Trong hầu hết công ty, programmer lam việc trong những đội dự án

đƣợc quản lý bởi ngƣời lãnh đạo dự án (project leader), ngƣời nay lại đƣợc

quản lý bởi ngƣời quản lý dự án. Mỗi đội dự án có một hoặc nhiều

programmer va chắc chắn phải có một hoặc nhiều nha phân tich hệ thống.

Programmer lam việc trên code va hiếm khi, nếu có, lam việc trực tiếp với

ngƣời dùng cuối. Mặt khác, nha phân tich hệ thống lam việc trực tiếp với

ngƣời dùng cuối để phát triển các yêu cầu va đặc tả cho hệ thống để đƣợc

thiết kế.

A programmer can lack all the social graces because few ―outsiders‖

deal with him, but the systems analyst is on the front lines. He needs to be





articulate, friendly, and a good listener. The systems analyst must also have

the capability to pay a great deal of attention to detail and be creative in

coming up with techniques for uncovering hidden information. For

example, when developing the FOCUS system, I needed to uncover

hundreds of mathematical formulas that could be used to analyze the

financial forms. I also had to design dozens of screens that could be utilized

efficiently by the end users. Instead of designing the screens (this was pre

Internet days), I turned the end users loose with a word processing

programmer and asked them to list the information they wanted to see and

where they wanted to see it. This is called JAD, or joint application

development.

Một programmer có thể không có tất cả những kỹ năng giao tiếp xã

hội vì rất it những yếu tố bên ngoai tác động đến anh ta; nhƣng nhà phân

tich hệ thống lại gặp vấn đề nay. Anh ta cần có khả năng ăn nói lƣu loát,

thân thiện va la một ngƣời biết lắng nghe. Nah phân tich hệ thống còn phải

tỉ mỉ va sáng tạo trong việc nghĩ ra những kỹ thuật để lấy đƣợc những thông

tin đã đƣợc giấu. Vi dụ khi phát triển hệ thống FOCUS, tác giả cần khám

phá ra hang trăm công thức toán học ma có thể đã từng đƣợc dùng để phân

tich các mẫu đơn tai chinh. Tác giả còn phải thiết kế hang tá man hình ma

có thể đã đƣợc sử dụng hiệu quả bởi ngƣời dùng cuối. Thay vì thiết kế các

man hình (giai đoạn trƣớc Internet), tác giả đã tham khảo ý kiến của những

ngƣời dùng cuối những thông tin nao họ muốn thấy, va họ muốn chúng





nằm ở đâu. Nó gọi la JAD, joint application development (phát triển ứng

dụng chung).

When I first starting working for the New York Stock Exchange, I

was responsible for building a computer system that processed a series of

financial forms (like your tax forms) that were required to be filled out by

the various member firms (e.g., Merrill Lynch) of the Exchange. These

forms contained hundreds of financial items.

Khi tác giả bắt đầu lam việc cho NY Stock Exchange, ông đã đƣợc

giao nhiệm vụ xây dựng hệ thống máy tinh để xử lý một dãy những mẫu

đơn tai chinh đƣợc yêu cầu điền vao bởi những hãng thanh viên khác nhau

của Exhange. Những mẫu đơn nay chứa hang trăm chi tiết tai chinh.

My job as an analyst was to work with the people in the regulatory

department who understood how to process these forms these were the end

users. Our job was a hard one; the financial forms were complex. The end

users were accountant types with vast experience in interpreting these

forms. The reason for looking at these forms at all was to determine

whether the firm (i.e., Merrill Lynch) was financially healthy — a very

important job.

Công việc của một nha phân tich nhƣ ông ta la lam việc với những

ngƣời trong phòng ban điều tiết (regulatory department)- những ngƣời hiểu

cách thức xử lý những mẫu đơn nay – họ chinh la ngƣời dùng cuối. Công





việc của họ rất cực nhọc, những mẫu đơn quá phức tạp. Những ngƣời dùng

cuối la những nhân viên kế toán với kinh nghiệm lâu năm trong việc phiên

dịch những mẫu đơn nay. Lý do cho việc nhìn vao những mẫu đơn nay la

để xác định một hãng có đang khỏe mạnh về tai chinh hay không- một công

việc vô cùng quan trọng.

As the systems analyst on the job I had to meet regularly with these

end users to try to ―pick their brains‖. We met several times a week to work

on the project. There was lots of yelling and screaming and tons of pizza. In

the end, however, we developed a document that was quite detailed in

describing everything that the system — called FOCUS — was supposed to

do. Once this document was complete it was turned over to the

programmers whose job it was to turn the document into a complete

working system.

Công việc của một nha phân tich hệ thống la phải gặp gơ thƣờng

xuyên với những ngƣời dùng cuối để học thông tin. Tác giả đã phải gặp

những ngƣời kế toán nay vai lần mỗi tuần để lam dự án. Đã có nhiều tiếng

la ó, kêu thét, va hang tấn bánh pizza. Tuy nhiên, cuối cùng, họ đã phát

triển đƣợc một tai liệu vô cùng chi tiết trong việc mô tả mọi thứ ma hệ

thống đó- tên là FOCUS- cần thực thi. Một khi tai liệu nay hoan tất, nó

đƣợc chuyển giao cho những programmer- ngƣời có nhiệm vụ chuyển

những tai liệu đó thanh một hệ thống hoạt động hoan chỉnh.





As you can see from my description, I have left a few job titles out of

the picture because each organization is structured a bit differently. For the

most part, when one develops a system at least two departments are

involved. One is the end-user department (e.g., marketing, operations). The

end users have a ―need‖ for a system to be developed or modified. They

turn to the computer department, sometimes called IS (information

systems), MIS (management information systems), or IT (information

technology) to help them turn this need into a working system.

Nhƣ bạn có thể thấy từ mô tả của tác giả, tác giả đã bỏ một it tên

công việc khỏi bức tranh vì mỗi tổ chức đƣợc tổ chức kháu nhau. Phần lớn,

khi một ngƣời phát triển một hệ thống thì có it nhất 2 phòng ban trong đó.

Một la phòng ban của ngƣời dùng cuối (nhƣ tiếp thị). Những ngƣời dùng

cuối có một yêu cầu để hệ thống để phát triển va sửa đổi. Họ trở thanh

phòng ban máy tinh, thƣờng gọi la IS (information systems), MIS

(management information systems), hoặc IT (information technology) để

giúp họ chuyển yêu cầu đó thanh hệ thống hoạt động.

The end-user department is composed of experts who do a particular

task. Maybe they are accountants or maybe they are in marketing they still

are experts in what they do. They are managed, just like IS people, by

managers. We can refer to these managers as business managers just like

we refer to a computer manager as an IS manager. Although most systems

analysts work directly with those that report to the business manager, the

business manager still plays a critical role. We need to turn to him if we





need some information from the entire department or we need to have

something done that only the business manager can direct.

Phòng ban ngƣời dùng cuối bao gồm các chuyên gia lam những công

việc riêng biệt. Có thể họ la những nhân viên kế toán hoặc có thể họ lam

trong lĩnh vực marketing- họ vẫn la chuyên gia trong công việc họ lam. Họ

đƣợc quản lý, giống nhƣ những nhân viên IS, bởi những ngƣời quản lý.

Chúng ta có thể kể đến những nha quản lý nay nhƣ những ngƣời quản lý

kinh doanh nhƣ cách chúng ta mô tả những nha quản lý máy tinh nhƣ một

quản lý IS.

1.2 SDLC - VÕNG ĐỜI PHÁT TRIỂN HỆ THỐNG

The development of computer systems has many moving parts. Each

of these parts has a name — i.e., analysis, design, etc. We call the entirety

of these steps a systems development life cycle.

Sự phát triển của những hệ thống máy tinh có rất nhiều thanh phần

động. Mỗi thanh phần nay có một cái tên- phân tich, thiết kế … vân vân.

Chúng ta gọi toan bộ các bƣớc nay la một vòng đời phát triển hệ thống.

Why do we call this a life cycle? A system has a life of its own. It

starts out as an idea and progresses until this idea germinates and then is

born. Eventually, when the system ages and is obsolete, it is discarded or

―dies‖. So ―life cycle‖ is really an apt term.





Tại sao lại gọi la vòng đời? Một hệ thống có một cuộc sống của riêng

nó. Nó bắt đầu nhƣ la một ý tƣởng va tiến triển cho đến khi ý tƣởng nay nảy

mầm va sau đó ra đời. Về sau, khi hệ thống ―gia đi‖va lỗi thời, nó bị loại bỏ

hoặc ―chết‖. Vì thế ―vòng đời‖ thật sự la một thuật ngữ thich hợp.

The idea phase of the SDLC is the point at which the end user,

systems analyst, and various managers meet for the first time. This is where

the scope and objectives of the system are fleshed out in a very high-level

document.

Mặt ý tƣởng của SDLC la điểm ma ở đó ngƣời dùng cuối, nha phân

tich hệ thống, va những nha quản lý khác nhau gặp nhau lần đầu tiên. Đây

la nơi ma mục đich của những hệ thống đƣợc bổ sung trong một tai liêu cấp

cao.

Next, a team composed of one or more systems analysts and end

users tries to determine whether the system is feasible. Systems can be

NOT feasible for many reasons: too expensive, technology not yet

available, not enough experience to create the system; these are just some

of the reasons why a system will not be undertaken.

Sau đó, một đội tạo sắp xếp hoặc nhiều nha phân tich hệ thống va

ngƣời dùng cuối cố gắng xác định một hệ thống có khả thi hay

không.Những hệ thống không thể khả thi vì một số lý do sau: giá thanh quá

cao, công nghệ chƣa phát triển tới, không đủ kinh nghiệm để xây dựng hệ





thống; đó la một vai lý do giải thich vì sao một hệ thống sẽ không đƣợc xây

dựng.

Once the system is determined to be feasible, systems analysis is

initiated. This is the point when the analysts put on their detective hats and

try to ferret out all the rules and regulations of the system. What are the

inputs? What are the outputs? What kind of online screens will there be?

What kind of reports will be needed? Will paper forms be required? Will

any hook-ups to external files or companies be required? How shall this

information be processed? As you can see, much work needs to be done at

this point and many questions need to be answered. In the end, all of the

answers to these questions will be fully documented in a requirements

document.

Một khi hệ thống đƣợc xác định la khả thi, những bản phân tich hệ

thống sẽ khởi tạo. Đây la thời điểm khi ma nha phân tich đặt mũ thám tử

xuống va có gắng khám phá tất cả những quy luật va quy tắc của hệ thống.

Input va output những gì? Những loại man hình trực tuyến nao sẽ có?

Những loại báo cáo nao cần thiết? Những mẫu đơn có đƣợc yêu cầu không?

Có bất cứ sự móc nối nao tới những file bên ngoai hoặc công ty đƣợc yêu

cầu không? Thông tin sẽ đƣợc xử lý nhƣ thế nao? Nhƣ bạn thấy, nhiều công

việc cần đƣợc lam tại thời điểm nay va nhiều câu hỏi cần đƣợc trả lời. Cuối

cùng, tất cả những câu trả lời cho những câu hỏi đó sẽ đƣợc hoan toàn tài

liệu hóa thanh những tai liệu yêu cầu.





Once all the unknowns are known and are fully documented, the

systems analyst can put flesh on the skeleton by creating high-level and

then detailed designs. This is usually called a specification and can be

hundreds of pages long. This document contains flowcharts, file and

database definitions, and detailed instructions for the writing of each

program

.Một khi tất cả những điều không biết đƣợc sáng tỏ va đƣợc tai liệu

hóa, nha phân tich hệ thống có thể thêm da thịt vao bằng cách tạo ra những

thiết kế cấp cao, sau đó la thiết kế chi tiết. Việc nay thƣờng đƣợc gọi la đặc

tả va có thể dai hang trăm trang giấy. Tai liệu nay chứa biểu đồ tiến trình,

tập tin va những định nghĩa cơ sở dữ liệu, va những lời chỉ dẫn cụ thể trong

việc viết mỗi chƣơng trình.

All along the way, the accuracy of all of these documents is checked

and verified by having the end users and analysts meet with each other. In

fact,most approaches to system development utilize the creation of a project

team consisting of end users and IS staff. This team meets regularly to work

on the project and verify its progress.

Ngay từ đầu, sự chinh xác của những tai liệu nay đã đƣợc kiểm tra

cùng lúc bởi những ngƣời dùng cuối va nha phân tich. Trên thực tế, hầu hết

đich đến sự phát triển hệ thống đều sử dụng sự sáng tạo của một nhóm dự

án gồm có ngƣời dùng cuối va IS staff. Nhóm nay thƣờng xuyên gặp gơ để

lam việc trên dự án va xác định tiến triển của dự án.





Once a complete working specification is delivered to the

programmers,implementation can get underway. For the FOCUS system,

we turned the specification over to a team of about 20 programmers. The

systems analyst, project leader, and project manager were all responsible

for making sure that the implementation effort went smoothly.

Programmers coded code and then tested that code. When this first level

(unit testing) of testing was done, there were several other phases of testing

including systems testing, parallel testing, and integration testing. Many

companies have QA (quality assurance) departments that use automated

tools to test the veracity of systems to be implemented.

Một khi sự đặc tả công việc hoan tất đƣợc chuyển đến cho những

programmer, dự án bắt đầu tiến hanh. Cho hệ thống FOCUS, họ đã ban

giao tất cả các đặc tả cho một đội gồm 20 programmer. Nha phân tich hệ

thống, lãnh đạo dự án, va quản lý dự án có trách nhiệm trong việc đảm bảo

quá trình diễn ra suôn sẻ. Các programmer viết code, sau đó kiểm thử các

code nay. Khi cấp độ đầu tiên của việc kiểm tra (unit testing) hoan tất, sẽ

có vai công đoạn test khác bao gồm systems testing, parallel testing, va

integration testing. Nhiều công ty có những phòng ban kiểm tra chất lƣợng

dùng những công cụ để kiểm thử tinh chinh xác của hệ thống.

Once the system has been fully tested, it is turned over to production

(changeover). Usually, just prior to this, the end-user departments (not just

the team working on the project) are trained and manuals distributed. The

entire team is usually on call during the first few weeks of the system after





changeover because errors often crop up and it can take several weeks for

the system to stabilize.

Một khi hệ thống đã đƣợc kiểm thử hoan chỉnh, nó đƣợc chuyển giao

để trở thanh sản phẩm. Thông thƣờng, trƣớc đó, phòng ban ngƣời dùng

cuối (không chỉ đội lam việc trong project đó) đƣợc huấn luyện va đƣợc

phân bổ. Toan bộ đội thƣờng sẵn sang ứng cứu trong suốt những tuần đầu

tiên của hệ thống sau khi thay đổi hệ thống lam việc vì những lỗi thƣờng

xảy ra va tốn vai tuần cho hệ thống ổn định.

After the system is stabilized, it is evaluated for correctness. At this

point a list of things to correct as well as a ―wish list‖ of things that were

not included in the first phase of the system is created and prioritized. The

team, which consisted of technical and end-user staff, usually stays put and

works on the future versions of the system.

Sau khi hệ thống ổn định, nó đƣợc đánh giá về độ chinh xác. Tại thời

điểm nay, một danh sách những điều đúng cũng nhƣ la một ―danh sách mơ

ƣớc‖ không bao gồm trong công đoạn đầu tiên la … Đội gồm có đội ngũ

ngƣời dùng cuối va chuyên viên kỹ thuật thƣờng lam việc cho những phiên

bản trong tƣơng lai của hệ thống





1.3 HỌC TẬP TÍNH KHẢ THI: BƢỚC ĐẦU TIÊN

It never pays to jump into developing a system. Usually, it is a good

idea to conduct a feasibility study first. The easiest part of the feasibility

study is determining whether the system is technically feasible. Sometimes,

however, it might not be feasible because the company does not have the

technical expertise to do the job. A good systems analyst will go one step

further and see if it is feasible to outsource (i.e., let someone else do it) the

project to people who can do the job. Sometimes, the technology is just not

robust enough. For example, many years ago I wanted to deliver voice

recognition devices to the floor of the New York Stock Exchange. The

technology at that time was just too primitive so the entire project was

deemed not feasible.

Không bao giờ nhảy vao phát triển một hệ thống. Thông thƣờng,

hƣớng dẫn học tập tinh khả thi đầu tiên la một ý hay. Phần dễ nhất của học

tập tinh khả thi la xác định khi nao hệ thống khả thi về mặt kỹ thuật. Tuy

nhiên, thông thƣờng, nó có thể không khả thi vì công ty không có sự thanh

thạo kỹ thuật để lam việc. Một nha phân tich hệ thống giỏi sẽ đi từng bƣớc

va nhìn nó khả thi để giao project cho ngƣời có thể lam. Thỉnh thoảng, công

nghệ không đủ tinh vi. Vi dụ, nhiều năm trƣớc tác giả muốn đặt máy nhận

diện giọng nói tại tầng trệt của New York Stock Exchange. Công nghệ lúc

bấy giờ rất thô sơ, vì thế toan bộ dự án tƣởng rằng không khả thi.





Discovering that the project is feasible from a technical perspective

but would require vast organizational changes (e.g., creation of new end-

user departments) adds a layer of complexity to the problem. This, then,

would make the project organizationally not feasible.

Nhận ra rằng dự án khả thi với công nghệ trong tƣơng lai nhƣng lại

yêu cầu vô số thay đổi trong cơ quan (vd: sự sáng tạo của phòng ban ngƣời

dùng cuối mới) đã lam tăng thêm độ phức tạp cho vấn đề. Nó lam cho dự án

lại một lần nữa không khả thi.

Finally, the project just might cost too much money. To figure this

out will require you to perform a cost/benefit analysis (take out those

spreadsheets). To do this, you must figure out an estimated cost for

everything you wish to do, including cost of hardware, cost of software,

cost of new personnel, cost of training, etc. Then you need to calculate the

financial savings for creating the new system: reduce staff by one third;

save 5 hours a day. Sometimes the benefits are intangible; for example,

allowing us to compete with our major competitor.

Cuối cùng, dự án có thể sẽ lam tiêu tốn khá nhiều tiền. Để tinh toán

nó, yêu cầu chúng ta thực hiện một bản phân tich chi phi/lợi nhuận. Để thực

hiện điều nay, chúng ta phải tinh toán giá trị có thể đánh giá đƣợc cho mọi

thứ bạn muốn lam, bao gồm chi phi phần cứng, chi phi phần mềm, chi phi

cho nhân viên mới, chi phi huấn luyện.. Sau đó chúng ta cần phải tinh toán

số tiền tiết kiệm đƣợc khi xây dựng hệ thống mới: giảm số nhân viên đi một





phần 3, tiết kiệm đƣợc 5 giờ mỗi ngay. Thỉnh thoảng lợi nhuận rất mơ hồ;

vi dụ: để họ cạnh tranh với đối thủ lớn nhất của họ.

Once it has been determined that the project is feasible, a project

plan is created that plots out the course for the entire systems development

effort — i.e., budget, resources, schedule, etc. The next step, then, is to start

the actual analytical part of systems development. For that we need to

collect some information. (See Chapter 2 for more information on

feasibility studies.)

Một khi xác định đƣợc rằng dự án la khả thi, một kế hoạch dự án sẽ

đƣợc tạo ra những sơ đồ cho tất cả cố gắng của sự phát triển hệ thống- VD:

ngân quỹ, tai nguyên, thời khóa biểu … Bƣớc tiếp theo la thực sự bắt đầu

phần phân tich của sự phát triển hệ thống. Để lam đƣợc điều nay chúng ta

cần thu thập vai thông tin.

1.4 CÁC CÁCH THU THẬP THÔNG TIN

One of the first things you will do when starting a new project is to

gather information. Your job is to understand everything about the

department and proposed system you are automating. If you are merely

modifying an existing system, you are halfway there. In this case you will

review all of the system documentation and the system itself, as well as

interview the end users to ferret out the changed requirements.





Việc đầu tiên ma bạn sẽ lam khi bắt đầu 1 dự án mới đó la thu thập

thông tin. Công việc của bạn la phải tìm hiểu tất cả mọi thứ về các bộ phận

va các hệ thống tự động hóa. Nếu bạn định hƣớng đƣợc một hệ thống đã có

trƣớc thì bạn đã đi đƣợc ½ chặng đƣờng. Trong trƣờng hợp nay bạn sẽ xem

lại tất cả những hệ thống va những tai liệu của nó cũng nhƣ các cuộc phỏng

vấn ngƣời dùng đƣa ra các yêu cầu thay đổi.

How can you make sense out of a department and its processes when

you do not know anything about it? One of the things you do is to act like a

detective and gather up every piece of documentation you can find. When I

built the FOCUS system, I scrounged around and managed to find policy

manuals and memos that got me part of the way toward understanding what

these people did for a living. Other sources of information include: reports

used for decision making; performance reports; records; data capture forms;

Websites; competitors‘ Web sites; archive data. Passive review is seldom

enough, however. The next step is to be a bit more active and direct.

Lam thế nao để bạn có thể hiểu đƣợc về chức năng của một bộ phận

va những qui trình của nó khi bạn không biết gì về nó? Một trong những

điều bạn lam la thu thập tất cả tai liệu bạn tìm thấy. Khi bạn xây dựng 1 hệ

thống chinh, bạn phải xoáy xung quanh nó va quản lý tất cả những chinh

sách, bộ nhớ hệ thống,nó giúp ta hiểu đƣợc những gì ma con ngƣời đã lam

cho cuộc sống. Những thông tin bao gồm nhƣ bản báo cáo về các quyết

định, hiệu suất, hồ sơ, các trang web, trang web của đối thủ cạnh tranh





mình, dữ liệu lƣu trữ. Không nên xem xét vấn đề một cách thụ động ma

phải chủ động va trực tiếp.

The first thing you can do is to interview end users. For our FOCUS

project, I had already created a project team consisting of tech people

and end users; however, I decided that it would be worthwhile to interview

a representative sampling of people working in different jobs that ―touched‖

the process to be automated.

Việc đầu tiên ma bạn có thể lam la phỏng vấn những ngƣời dùng

cuối. Để thực hiện dự án của mình, thì tôi đã lập ra 1 đội ngũ gồm có những

nhân viên va ngƣời dùng cuối, tuy nhiên tôi đã quyết định rằng thật quan

trọng khi mở một cuộc phỏng vấn những ngƣời đại diện cho những công

việc khác nhau.

You cannot interview someone without preparation. This consists

first of understanding all that you can about the job and person being inter

viewed and then preparing a set of questions for this person. However,

sometimes an interview is insufficient to meet your needs. Your subject

may not be able to articulate what he or she does. The next step, then, is to

observe the person at his job.

Bạn không thể phỏng vấn 1 ngƣời nao đó ma không có sự chuẩn bị.

Điều đầu tiên la bạn phải hiểu đƣợc tất cả về công việc va những ngƣời

đƣợc phỏng vấn, sau đó chuẩn bị những câu hỏi cho những ngƣời nay. Tuy





nhiên đôi khi cuộc phỏng vấn la không đáp ứng đủ những đòi hỏi của

bạn.Có thể những gì họ lam không an khớp với dự án của bạn. Vì vậy bƣóc

tiếp theo la quan sát những ngƣời đó trong công việc.

I‘ve done much work in the artificial intelligence arena where

observation is a large part of the systems analysis process. One of the case

histories people in the field often talk about is one concerning building a tax

expert system.

Tôi đã lam việc trong những công ty về tri tuệ nhân tạo la những nơi

mà sự quan sát la một phần lớn trong những tiến trình phân tich hệ thống.

Một trong những trƣờng hợp lịch sử ma ngƣời trong lĩnh nay thƣờng nói về

đó la một vấn đề liên quan đến chuyên gia xây dựng hệ thống thuế.

At one end of a large table sat a junior accountant. A large number of

tax books were piled in front of the junior accountant At the other end sat

some of the most senior tax accountants at the firm. Nothing was piled in

front of them. In the center of the table sat the systems analyst armed with a

video recorder. This person was armed with a script that contained a

problem and a set of questions. The task at hand was for the junior

accountant to work through the problem guided by the experts. The experts

had nothing to refer to but what was in their memories. Thus they were able

to assist the junior accountant to solve the problem while the video camera

recorded the entire process.





Có một cái ban lớn. Một đầu ban la ngƣời kế toán cơ sở ngồi, một số

lƣợng lớn thuế sách đã đƣợc chồng chất trƣớc mặt ngƣời kế toán đó. Một

đầu ban kia la một số quan chức cao cấp kế toán thuế của công ty. Trƣớc

mặt họ thì không có gì. Ở trung tâm của ban la các nha phân tich hệ thống

trang bị một máy ghi hình. Ngƣời nay đã có những kế hoạch cho riêng

mình. Các công việc bằng tay thì ngƣời kế toán cơ sở phải lam thông qua sự

hƣớng dẫn của các chuyên gia. Các chuyên gia thì không có gì phải đề cấp

đến nhƣng kiến thức thì đã nằm trong đầu của họ. Vì vậy họ đã có thể hỗ

trợ ngƣời kế toán giải quyết vấn đề trong khi các máy video ghi lại toan bộ

quá trình.

Observation can only be done selectively — a few people at the

most. Another technique, which will let you survey a broad number of

people at one time, is the questionnaire. Building a questionnaire requires

some skill. There are generally two types of questions:

Quan sát chỉ có thể chọn lọc ra 1 số ngƣời trong toan bộ. Một

phƣơng pháp khác la khảo sát một số lƣợng lớn ngƣời trong một thời gian

bằng 1 bảng câu hỏi. Xây dựng bảng câu hỏi yêu cầu 1 vai kĩ năng. Có 2

loại câu hỏi tổng quát:

Open-ended:

1. What are the most frequent problems you have in buying books

from a book store?





2. Of the problems listed above, what is the single most

troublesome?

Closed:

1. The tool is used as part of the program development cycle to

improve quality 1 2 3 4 5

(circle appropriate response, where 5 is the highest score)

Câu hỏi mở:

1. Những vấn đề nao bạn thƣờng gặp khi mua sách ở cửa hang

sách.

2. Trong những vấn đề ở trên bạn thấy cái nao la khó khăn nhất.

Đóng:

Công cụ nao đƣợc sử dụng nhƣ 1 phần của chu kỳ phát triển để nâng

cao chất lƣợng sản phẩm.

A good questionnaire will probably be a combination of both types

of questions (hybrid). It is also important to make sure that you format your

questionnaire for easy readability (lots of white space and even spacing),

put all the important questions first (in case the respondents do not finish

the survey), and vary the type of question so that participants do not simply

circle 5s or 1s all the way down the page.





Một bảng câu hỏi tốt la sự kết hợp của 2 loại câu hỏi trên. Đó cũng la

quan trọng để đảm bảo định dạng bảng câu hỏi của bạn để ngƣời khác đọc

một cách dễ dang (rất nhiều khoảng trắng, thậm chi có cả dấu cách). Đặt tất

cả những câu hỏi quan trọng lên đầu tiên (đề phòng trong trƣờng hơp ngƣời

đƣợc khảo sát không hoan thanh xong) va thƣờng xuyên thay đổi các loại

câu hỏi.

1.5 SƠ ĐỒ HỆ THỐNG HAY MÔ HÌNH HỆ THỐNG

You can use a wide variety of techniques to describe your problem

and its solution diagrammatically as well as a wide variety of tools that can

assist you in drawing these diagrams. One of the diagrammatic techniques

is flowcharting and the tool of choice is Microsoft Visio, as shown in

Exhibit 1-1.

Bạn có thể dùng nhiều những kĩ thuật khác nhau để miêu tả những

vấn đề của bạn va nó có thể giúp bạn trong việc vẽ những biểu đồ.Một

trong những phần mềm dùng để vẽ biểu đồ đó la Microsoft Visio va nó

đƣợc thể hiện ở hình 1-1.





Exhibit 1-1.





One of the most practical of tools is the DFD, or data flow diagram,

as shown in Exhibit 1-2. DFDs are quite logical, clear, and helpful when

building systems — even Web-based systems. All inputs, outputs, and

processes are recorded in a hierarchical fashion. The first DFD (referred to

as DFD 0) is often the system from a high-level perspective. Child DFDs

get much more detailed. Exhibit 1-2 is a snippet of a real online test system

— a rather complicated system that lets people take tests online. This

particular DFD shows the data flow through the log-in process. The

rectangular boxes (i.e., D5) are the data stores. Notice that D5 is an online

cookie; D1, on the other hand, is a real database. It is a relational database

and this is one particular table. The databases and their tables are defined in

a data dictionary. The square box is the entity (i.e., test taker) and can be a

person, place, or thing; the other boxes are process boxes. Process 1.1 is the

process for Get Name. There will be a child DFD labeled 1.1 Get Name. 1.1

Get Name will also appear in a process dictionary that will contain a

detailed specification for how to program this procedure.

Một trong những công cụ thiết thực la DFD, hay la sơ đồ luồng dữ

liệu,biểu diễn trong hình 1-2. DFD hết sức logic, dễ hiểu, va tiện dụng khi

bạn xây dựng một hệ thống – dù la hệ thống đƣợc xây dựng dựa trên web.

Tất cả những đầu vao, đầu ra va các tiến trình đều đƣợc ghi lại theo thứ tự

rập khuôn. DFD cấp đầu tiên la cấp 0 thƣờng la hệ thống nhìn từ góc độ cao

nhất. Những DFD con thì sẽ chứa đƣợc nhiều thông tin chi tiết hơn. Hình 1-

2 la một đoạn nhỏ của hệ thống kiểm tra trực tuyến – nói đúng hơn la một





hệ thống phức tạp ma ngƣời ta cần phải kiểm tra trƣc tuyến. Mô hình DFD

riêng biệt nay biểu diễn những luồng dữ liệu thông qua việc đăng nhập tai

khoản. Hình chữ nhật (vi dụ nhƣ D5) sẽ chứa dữ liệu. Chú ý D5 la một

cookie trực tuyến, D1 la cơ sở dữ liệu thật. Nó la một cơ sở dữ liệu quan hệ

va ở đây la một cái ban riêng biệt. Hình vuông ở đây la những thực thể, có

thể la ngƣời, nơi hay la sự vật, còn những hình khác la những tiến trình.

Tiến trình 1.1 la tiến trình lấy tên ngƣời dùng. Tiến trình nay sẽ bao gồm

những đặc tả chi tiết nhất cho những chƣơng trình, thủ tục nay.

Other modeling tools include:

• Entity relationship diagram. An ERD is a database model that

describes the attributes of entities and the relationships among them. An

entity is a file (table). Today, ER models are often created graphically, and

software converts the graphical representations of the tables into the SQL

code required to create the data structures in the database as shown in

Exhibit 1-3.

• State transition diagram. An STD describes how a system behaves

as a result of external events. In Exhibit 1-4 we see the effects of a person

reporting a pothole.

• Data dictionary. The data dictionary is a very organized listing of

all data elements that pertain to the system. This listing contains some very





specific information as shown in Exhibit 1-5. It should be noted that there

are many variations in the formats of data dictionaries.

• Process specification. The PSPEC describes the ―what, when,

where, and how‖ of the program in technical terms. It describes just how

the process works and serves to connect the DFD to the data dictionary.

It uses pseudocode (sometimes called structured English or Program

Definition Language — PDL) to explain the requirements for programming

the process to the programmer. An example is shown in

Exhibit 1-6. Other ways of representing process logic are:

—A decision table

—A decision tree

—A mathematical formula

—Any combination of the above

• Class diagrams.Analysts working on an OO (object-oriented

system) will utilize OO tools and diagrammatic techniques. One of these is

a class diagram drawn using UML or unified modeling language. A class

diagram is shown in Exhibit 1-7.

Những công cụ mô hình khác gồm có:





Mô hình quan hệ thực thể. ERD la một mô hình dữ liệu ma nó

miêu tả tất cả các thuộc tinh của thực thể va mối quan hệ giữa

chúng. Một thực thể la một bảng. Ngay nay mô hình ERD thƣờng

đƣợc tạo ra một cách sinh động va những phần mềm chuyển từ

những biểu đồ sang những dòng code SQL thì cần thiết phải tạo

một cấu trúc dữ liệu trong cơ sở dữ liệu hình 1-3

Biểu đồ chuyển tiếp trạng thái. Đó la STD.

Dữ liệu từ điển la một danh sách sắp xếp trật tự bao gồm tất cả

những thông tin thanh phần ma nó gắn liền với hệ thống. Danh

sách nay bao gồm một vai thông tin chi tiết, cụ thể nhƣ hình 1-

5.Nó nên đƣợc chú ý nhiều bởi vì luôn có nhiều sự biến đổi trong

dữ liệu từ điển

Tiến trình đặc tả. Đó la PSPEC miêu tả ―la gì, khi nao, ở đâu va

nhƣ thế nao‖ của chƣơng trình trong giới hạn kĩ thuật. Nó miêu tả

tiến trình lam việc va phục vụ cho sự kết nối DFD đến dữ liệu từ

điển.Nó giải mã (thỉnh thoảng ngƣời ta gọi la structured English

hay là Program Definition Language – PDL) để giải thich những

yêu cầu, tiến trình của chƣơng trình cho ngƣời lập trình. Vi dụ nhƣ

trong hình 1-6. Những cách khác để trình bay 1 tiến trình logic la:

— A decision table

— A decision tree





— A mathematical formula

— Any combination of the above

Những nha phân tich mô hình lớp lam việc trên các hệ thống

hƣớng đối tƣợng sẽ sử dụng công cụ hƣớng đối tƣợng va những

biểu đồ kĩ thuật. Một trong những cách đó la sử dụng UML hay la

mô hình ngôn ngữ hợp nhất. Một mô hình lớp đƣợc thể hiện ở hình

1-7





1.6 PHƢƠNG PHÁP LUẬN PHÁT TRIỂN

The Software Engineering Institute, which is part of Carnegie

Mellon, in Pittsburgh, Pennsylvania, is famous for a framework that

describes software process maturity. A summary of the five phases appears

in Exhibit 1-8. Read this while keeping in mind that most organizations,

sadly, are at stage 2 or 3.

Software Engineering Institute, một phần của Carnegie Mellon, rất

nổi tiếng về framework diễn tả quá trình tiến triển của phần mềm. Kết luận

cho 5 giai đoạn xuất hiện trong Exhibit 1-8. Đọc nó va phải nhớ rằng phần

lớn tổ chức nằm ở chặng 2 va 3.

Companies that have achieved a stage 2 process maturity or higher

make use of methodologies to ensure that the company achieves a

repeatable level of quality and productivity. Many methodologies are

available for use. Some of these are vendor driven — i.e., they are used in

conjunction with a software tool set. In general, methodologies can be

categorized as follows. It should be noted that a methodology can be used

in conjunction with another methodology:

Những công ty đạt đƣợc chặng 2 của quá trình tiến triển hoặc cao

hơn sử dụng phƣơng pháp luận để củng cố những thanh tựu, chất lƣợng va

năng suất của công ty. Có rất nhiều phƣơng pháp luận đang đƣợc sd va





đƣợc chia than những nhóm chinh sau. Phải nhớ la phƣơng pháp luận có thể

đƣợc sử dụng kết hợp với nhau

• System development life cycle (SDLC). This is a phased, structured

approach to systems development. The phases include requirements

feasibility, analysis, system design, coding, testing, implementation, and

testing. Please note that there are variations of these stated phases. Usually,

each phase is performed sequentially, although some potential for overlap

exists. This is the methodology used most often in industry.

System development life cycle (SDLC) Đây la cách tiếp cận về cấu

trúc va giai đoạn trong sự phát triển hệ thống. Những giai đoạn bao gồm

yêu cầu về tinh khả thi, sự phân tich, thiết kế hệ thống, cai đặt, kiểm tra. Có

rất nhiều giai đoạn, chúng co thể tuần tự mặc dù một số lại tiềm tang khả

năng chồng chéo lên nhau. Phƣơng pháp luận nay sd chủ yếu trong công

nghiệp

• Iterative (prototyping). Most of this approach is used to replace

several of the phases in the SDLC, in which the ―time to market‖ can be

months (sometimes years). During this time, requirements may change;

therefore the final deliverable might be quite outmoded. To prevent this

from happening, it is a good idea to try to compress the development cycle

to shorten this time to market and provide interim results to the end user.

The iterative model consists of three steps: 1) listen to the customer; 2)





build or revise a mock-up; 3) enable customer to test drive the mock-up and

then return to step 1.

Iterative (prototyping) Phần lớn cách tiếp cận nay đƣợc sd đề thay

thế rất nhiều giai đoạn trong SDLC, khi ma thời gian tung ra sản phẩm có

thể la nhiều tháng (hay nhiều năm). Trong thời gian nay, những yêu cầu có

thể bị thay đổi dẫn đến sự lỗi thời của sản phẩm cuối. Vì vậy ta nên rút

ngắn quá trình phát triển để giảm thời gian tung ra thị trƣờng va đƣa ra

những kết quả tạm thời cho khách hang. Công việc đƣợc lặp đi lặp lại theo

3 bƣớc: 1) lắng nghe khách hang; 2) xây dựng hoặc duyệt lại mô hình 3)

cho khách hang kiểm tra vận hanh mô hình va quay về bƣớc 1

• Rapid application development (RAD). This is a form of the

iterative model. The key word here is ―rapid‖. Development teams try to get

a first pass of the system out to the end user within 60 to 90 days. To

accomplish this, the normal seven-step SDLC is compressed into the

following steps: business modeling; data modeling; process modeling;

application generation and testing and turnover. Note the term ―application

generation‖. RAD makes use of application generators, formerly called

CASE (computer assisted software engineering) tools.

Rapid application development (RAD) Đây la dạng mô hình lặp đi

lặp lại. Key word ở đây la ―rapid‖. Đội phát triển phần mềm sẽ cố gắng

hoan thiện hệ thống cho ngƣời dùng cuối trong vòng 60 – 90 ngay. Để đạt

đƣợc chuyện nay, 7 bƣớc thông thƣờng của SDLC đƣợc rút ngắn thanh: mô





hình hóa kinh doanh, mô hình hóa dữ liệu, mô hình hóa tiến trình,

application generation, kiểm tra va chuyển giao. Thuật ngữ ―application

generation‖ RAD sử dụng để chỉ application ganerators, còn đƣợc gọi la

CASE (computer assisted software engineering)

• Incremental model. The four main phases of software development

are analysis, design, coding, and testing. If we break a business problem

into chunks, or increments, then we can use an overlapping, phased

approach to software development. For example, we can start the analysis

of increment one in January, increment two in June, and increment three in

September. Just when increment three starts up, we are at the testing stage

of increment one, and coding stage of increment two.

Incremental model: 4 giai đoạn của phát triển phần mềm la phân tich,

thiết kế, cai đặt va kiểm tra. Ta có thể chia tiến trình thanh nhiều phân đoạn

hay increments va những phân đoạn nay có thể đƣợc hoạt động chồng lấp

lên nhau. Vi dụ ta bắt đầu phân tich increment 1 vao tháng 1, increment 2

vao tháng 6 va increment 3 vao tháng 9. Khi ma increment 3 bắt đầu hoạt

động thì chúng ta đang ở chặng kiểm tra của increment 1 va cai đặt của

increment 2.

• Joint application development (JAD). JAD is more of a technique

than a complete methodology. It can be utilized as part of any of the other

methodologies discussed here. The technique consists of one or more end

users who are then ―folded‖ into the software development team. Instead of





an adversarial software-developer–end-user dynamic, the effect is to have

the continued, uninterrupted attention of the persons who will ultimately

use the system.

Joint application development (JAD). JAD giống 1 kĩ thuật hơn la

một phƣơng pháp luận hoan chỉnh. Nó có thể đƣợc sử dụng lam 1 phần

trong các phƣơng pháp đƣợc nói ở đây. Kĩ thuật bao gồm một hoặc nhiều

end-users trong đội phát triền phần mềm. Nhƣ vậy sẽ loại bỏ đƣợc mối

xung đột giữa end-user va software developer bằng sự chú ý không ngừng

của những ngƣời dùng cuối.

• Reverse engineering. This technique is used, first, to understand a

system from its code and, second, to generate documentation based on the

code and then make desired changes to the system. Competitive software

companies often try to reverse engineer their competitors‘ software.

Reverse engineering: Kĩ thuật nay đƣợc sử dụng để hiểu hệ thống từ

mã nguồn, sinh ra những chứng minh dựa trên code va tạo đƣợc những thay

đổi mong muốn trong hệ thống

• Re-engineering. Business goals change over time. Software must

change to be consistent with these goals. Re-engineering utilizes many of

the techniques already discussed in this chapter. Instead of building a

system from scratch, the goal of re-engineering is to retrofit an existing

system to new business functionality.





Re-engineering. Mục tiêu kinh doanh thay đổi theo thời gian. Phần

mềm cũng phải thay đổi theo để phù hợp với những mục tiêu nay, Re-

engineering sử dụng rất nhiều kĩ thuật đƣợc đề cập trong chƣơng nay. Thay

vì xây dựng từ đầu, mục tiêu của Re-engineering la xây dựng từ những hệ

thống có sẵn

• Object-oriented. Object-oriented analysis (OOA), object-oriented

design (OOD), and object-oriented programming (OOP) are very different

from what we have already discussed. In fact, you will need to learn a new

vocabulary as well as new diagramming techniques.

Object-oriented. Object-oriented analysis (OOA), object-oriented

design (OOD), và object-oriented programming (OOP) rất khác nhau qua

những gì chúng ta vừa thảo luận. Các bạn cần biết thêm một số từ ngữ va

những diagramming techniques

1.7 THIẾT KẾ HỆ THỐNG

Most of the models we have discussed fall under the structured

rubric (except for the OO model). The requirements document, or SRS

(systems requirement specification), is written for a broad audience (see

Appendix G) and reflects this structured technique. Usually it is provided

not only to IT staff but also to end users. In this way, the end users are able

to review what they have asked for as well as the general architecture of the

system. Once approved, the system now must be designed. The system





specification, here called the SDS (systems design specification), contains a

very finite level of detail — enough so that programmers will be able to

code the entire system (See Appendices J and L for sample SDS and

OOSDS, respectively). This means that the SDS must contain:

Information on all processes

Information on all data

Information about the architecture

Hầu hết các hệ thống ma chúng ta đã thảo luận đều la những đoạn

cấu trúc (trừ mô hình OO). Những tai liệu cần thiết hay la SRS(yêu cầu đặc

tả hệ thống), đƣợc viết cho một số lƣợng lớn thinh giả va phản ánh kết cấu

kĩ thuật nay. Thông thƣờng nó cung cấp không chỉ cho nhân viên IT ma còn

cho ngƣời dùng. Theo cách nay thì ngƣời dùng có thể xem lại những gì ma

họ yêu cầu có tốt nhƣ trong cái kiến trúc của hệ thống hay không.Khi đã

đƣợc phê chuẩn xong thì hệ thống phải đƣợc thiết kế.Những đặc tả hệ thống

ở đây gọi la SDS (đặc tả thiết kế hệ thống), bao gồm một cấp độ rất chi tiết

đủ để ngƣời lập trình có thể lập trình ra toan bộ hệ thống. Điều nay có nghĩa

la SDS phải bao gồm:

Thông tin trên toan bộ quá trình

Thông tin trên toan bộ dữ liệu





Thông tin về kiến trúc

You must start somewhere. That ―somewhere‖ is usually the very

highest level of a design. There are three logical ways to do this:

Abstraction. This permits you to concentrate at some level of

generalization without regard to irrelevant low-level details. This is

your highlevel or logical design.

Stepwise refinement. This is a successive decomposition or

refinement of the specifications. In other words, you move from the

high level to the detailed, from the logical to the physical.

Modularity. This means that you know a good design when you see

compartmentalization of data and function.

Bạn phải bắt đầu ở một vị tri nao đó. Vị tri đó thƣờng la mức độ cao

nhất của thiết kế. Có 3 con đƣờng logic để lam việc nay:

Abstraction. Điều nay cho phép bạn tập trung tại một vai mức độ

tổng quát ma không cần phải quan tâm đến các mức độ chi tiết.Đây

chinh la vị tri ma bạn cần tìm hay la thiết kế logic

Stepwise refinement. Đây la sự sang lọc những đặc tả hệ thống.

Trong những từ nay, bạn di chuyển từ cấp độ cao nhất đến chi tiết,

từ logic đến vật lý.





Modularity. Điều nay có nghĩa la bạn phải biết một thiết kế một hệ

thống tốt khi bạn nhìn thấy những phần nhỏ dữ liệu va chức năng

của nó

Look again at the DFD in Exhibit 1-2; it was not the first in the

series. The very first DFD would have been DFD 0, which is equivalent to

the high level of detail that it is recommended you start from. Here you can

see the logical components of the system. Underneath the 0 level we start to

get more detailed and more physical. At these lower (or child) levels we

start specifying files and processes.

Nhìn lại mô hình DFD trong hình 1-2, nó không phải la cái đầu tiên.

Mô hình DFD đầu tiên la DFD 0, cái ma tƣơng đƣơng với cấp độ chi tiết

ma bạn phải bắt đầu. Ở đầy bạn có thể thầy những thanh phần logic của hệ

thống. Bên dƣới cấp độ 0 chúng ta bắt đầu lấy thêm thông tin chi tiết va

thêm thông tin vật lý. Tại những cấp độ nay bạn phải bắt đầu định rõ những

dữ liệu va tiến trình.

The design document that you create will rarely look the same from

one organization to another. Each has its own template and its own standard

diagramming tool (i.e., Visio versus SmartDraw) and its own diagramming

format (i.e., flowcharts versus UML (uniform modeling language) versus

DFDs).





Những tai liệu thiết kế ma bạn tạo ra it khi giống từ một tổ chức

khác. Mỗi ngƣời đều có một khuôn mẫu va một chuẩn riêng của mình về

công cụ để vẽ biểu đồ (tức la Visio so với SmartDraw) va những định dạng

mô hình của riêng mình (nhƣ la flowchats so với UML so với DFD).

When the requirements document is high level, the specification is

much more detailed; it is, after all, a programming specification. For the

most part, the specification document for the testing system discussed

included: 1) a general description of the system; 2) its users; 3) its

constraints (i.e., must run on a PC); 4) the DFDs or other format; 5) the data

dictionary; 6) the process dictionary; 7) a chart showing the tasks that need

to be done (Gantt). The purpose of this specification (usually called a

―spec‖ by those in the field) is to give the programmers a manual from

which they can code. If it is a good spec the programmers should not need

to come back to you time after time to get additional information. Chapters

12 through 14 have more information on this subject.

Khi những tai liệu yêu cầu ở cấp cao thì những đặc tả của nó sẽ chi

tiết nhiều hơn va sau đó la đặc tả về cách lập trình. Trong hầu hết các thanh

phần thì tai liệu đặc tả cho kiểm tra hệ thống bao gồm: 1)Một cái miêu tả

tổng quát về hệ thống 2)Về ngƣời dùng 3)Sự rang buộc 4)mô hình DFD hay

la những định dạng khác 5)dữ liệu từ điển 6)từ điển quá trình 7)Một cái

biểu đồ biểu diễn những thao tác cần lam. Mục đich của việc đặc tả (thƣờng

gọi la ―spec‖) la đƣa cho những ngƣời lập trình một cái nhƣ la ―hƣớng dẫn

sử dụng‖ để họ có thể lập trình ra từ nó. Nếu la một đặc tả tốt thì những





ngƣời lập trình không cần phải tốn thời gian để tìm kiếm thêm thông

tin.Chƣơng 12 ->14 sẽ nói thêm thông tin về chủ đề nay.

1.8 PHƢƠNG PHÁP HƢỚNG ĐỐI TƢỢNG

Object-oriented systems development follows the same pattern as

structured systems development. First, you must analyze your system

(object-oriented analysis or OOA). Next, you design the system using

object-oriented design or OOD. Finally, you code the system using object-

oriented (OOP) programming techniques and languages (i.e., C++, Java).

OO techniques may have some similarity to traditional techniques but the

concept of OO is radically different from what most development people

are used to. This methodology revolves around the concept of an object,

which is a representation of any information that must be understood by the

software. Objects can be:

External entities: printer, user, sensor

Things: reports, displays

Occurrences or events: alarm, interrupt

Roles: manager, engineer, salesperson

Organizational unit: team, division





Places: manufacturing floor

Structures: employee record

Việc triển những hệ thống hƣớng đối tƣợng cũng tƣơng tự nhƣ triển

khai hệ thống cấu trúc. Trƣớc tiên, bạn phải phân tich hệ thống của bạn

(phân tich hƣớng đối tƣợng - OOA). Tiếp theo, bạn thiết kế hệ thống bằng

cách sử dụng quy trình thiết kế hƣớng đối tƣợng - OOD. Cuối cùng, bạn

code hệ thống bằng cách sử dụng kĩ thuật lập trình hƣớng đối tƣợng (OOP)

va ngôn ngữ lập trình hƣớng đối tƣợng (vi dụ, C + +, Java).

Kỹ thuật hƣớng đối tƣợng có thể có một số điểm giống với các kỹ thuật

truyền thống. Phƣơng pháp nay xoay quanh khái niệm về một đối tƣợng, la

một đại diện của bất kỳ thông tin nao ma phần mềm phải hiểu đƣợc. Đối

tƣợng có thể la:

Thực thể ngoại vi: máy in, ngƣời dùng, sensor

Những thứ nhƣ: bản báo cáo, trình bày

Sự kiện: báo thức (alarm), ngắt (interrupt)

Các vai trò: quản lý, kĩ sƣ, ngƣời bán hang

Đơn vị tổ chức: nhóm, phân chia (phân đoạn = division)

Địa điểm: san sản xuất (manufacturing floor)





Các cấu trúc: thông tin nhân viên (employee record)

The easiest way to think of an object is just to say it is any person,

lace, or thing. One of the important features of OO is the reusability of its

objects. A well-coded object is often thought of as a ―black box‖. What this

means is that the programmer should be able to glue together several

objects to create a working system. He should not need to know too much

about any of these objects. Does anyone remember playing with Lego

blocks as a child? It was easy to create incredible things such as bridges and

building because each of the blocks was easily connected to all other

blocks. It is the same with objects (see encapsulation below).

Cách dễ nhất để nghĩ về một đối tƣợng la ta nói nó la ngƣời nao, nơi

nao hay thứ gì. Một trong những đặc trƣng của hƣớng đối tƣợng là tính tái

sử dụng các đối tƣợng của nó. Một đối tƣợng đƣợc code tốt thƣờng đƣợc

xem la 1 ―hộp đen‖. Nghĩa la lập trình viện sẽ gắn kết vai đối tƣợng với

nhau để tạo nên một hệ thống hoạt động đƣợc. Anh ta không cần biết quá

nhiều về những đối tƣợng nay. Các bạn còn nhớ trò chơi tạo hình từ những

bộ phần bằng nhựa? Ta có thể tạo nên những thứ không ngờ tới nhƣ ngôi

nga, cây cầu bằng cách kết nối một cách dễ dang các bộ phần rời rạc lại với

nhau. Các đối tƣợng cũng giống vậy (xem sự đóng gói dƣới đây –

encapsulation)

First some OO definitions:





Class: in object technology, a user-defined data type that defines a

collection of objects that share the same characteristics. An object,

or class member, is one instance of the class. Concrete classes are

designed to be instantiated. Abstract classes are designed to pass on

characteristics through inheritance.

Object: a self-contained module of data and its associated

processing. Objects are the software building blocks of object

technology.

Polymorphism: meaning many shapes. In object technology, the

ability of a generalized request (message) to produce different

results based on the object that it is sent to.

Inheritance: in object technology, the ability of one class of objects

to inherit properties from a higher class.

Encapsulation: in object technology, making the data and

processing (methods) within the object private, which allows the

internal implementation of the object to be modified without

requiring any change to the application that uses it. This is also

known as information hiding.

Những khái niệm đầu tiên của hƣớng đối tƣợng:





Lớp (Class): theo thuật ngữ chuyên môn của hƣớng đối tƣợng, 1

kiểu dữ liệu ngƣời dùng tự định nghĩa bao gồm một tập hợp các đối

tƣợng có những đặc điểm chung nao đó. Một đối tƣợng la một thể

hiện của lớp. Concrete class: lớp có thể thể hiện thanh đối tƣợng

đƣợc (instantiated – đối tƣợng hóa?). Abstract class: đƣợc thiết kế

cho việc kế thừa.

Đối tƣợng (Object): la một module tự chứa dữ liệu va những xử lý

liên quan của nó. Đối tƣợng la bộ phân để xây dựng phần mềm

trong công nghệ hƣớng đối tƣợng.

Đa hình (Polymorphism): nghĩa la có nhiều thể hiện. Trong kĩ thuật

hƣớng đối tƣợng, chình la khả năng tổng quát hóa để tạo ra những

kết quả khác nhau dựa trên một đối tƣợng.

Kế thừa (Inheritance): khả năng của 1 lớp có thể kế thừa lại các

thuộc tinh của một lớp cao hơn.

Đóng gói (Encapsulation): tạo ra thuộc tinh (data) va các phƣơng

thức (method) trong phạm vi private của lớp, do đó, khi có những

thay đổi bên trong (private) đối tƣợng thì ta không cần phải thay

đổi chƣơng trình ứng dụng dùng nó.

Take a look at Exhibit 1-9. Here we have a class, called automobile,

that has several common attributes. One is that this thing has a motor.





Another attribute is the fact that an automobile (usually) has four wheels. In

an OO system you can create derived classes from the parent class. Notice

the nice, shiny red sportscar. This is the derived class called ―sports car‖. It

also has a motor and four wheels that it inherits from the parent class.

However, in this derived class we have some additional attributes: fast rpm

and sleek design. The sports car is the child of the parent class named

automobile. So we can say, ―Every convertible is an automobile but not

every automobile is a convertible‖.

Giả sử ta có lớp Xe hơi, vai thuộc tinh chung nhƣ: có 1 động cơ, có 4

bánh. Lớp Xe hơi thể thao thừa kế lớp Xe hơi. Lớp Xe hơi thể thao cũng có

1 động cơ va có 4 bánh – la những thuộc tinh kế thừa từ lớp xe hơi. Tuy

nhiên, nó còn có thêm vai thuộc tinh khác: thiết kế bóng đẹp hơn va vòng

quay số nhanh. Khi đó ta có thể nói: Xe hơi thể thao la xe hơi, nhƣng điều

ngƣợc lại thì không đúng.

To develop an OO application one must define classes. If you know

any thing about OO programming languages such as C++, all variables

within a program are defined as some ―type‖ of data. For example, in C and

C++, a number is defined as a type called ―integer‖. When we define a class

in a programming language, it is defined as a type of class as shown below:





Muốn xây dựng khai 1 ứng dụng hƣớng đối tƣợng phải định nghĩa

các lớp. Trong các ngôn ngữ lập trình hƣớng đối tƣợng nhƣ C++, tất cả các

biến đều thuộc một kiểu dữ liệu nao đó, vi dụ nhƣ: số thực, số nguyên,

chuỗi…. Đó la những kiểu dữ liệu cơ bản. Việc ta tạo ra một lớp chinh là

đỉnh nghĩa một kiểu dữ liệu mới.

DayOfYear la lớp public, nghĩa la không có giới hạn nao khi sử

dụng. Va cũng hề không có lớp private. Lớp DayOfYear có 2 thuộc tinh la

month va day, va 1 phƣơng thức la output().

class DayOfYear

{

public:





void output();

int month;

int day;

};

Designing OO systems requires the use of different modeling and

definitional techniques that take into account the idea of classes and objects.

Unified modeling language (UML) is an emerging standard for modeling

OO software. Exhibit 1-7 shows a sample class diagrammed using UML

and Appendix L contains a complete SDS for an OO system. Contained

within this SDS are numerous diagrams (models): 1) class diagrams, 2)

object models, 3) package diagrams that show how the classes are grouped

together, and 4) collaboration diagrams, which show how the classes

―collaborate‖ or work with each other. (See Chapter 13 for more on object-

oriented methodologies.)

Việc thiết kế một hệ thống hƣớng đối tƣợng yêu cầu các kĩ thuật mô

hình va kĩ thuật định nghĩa khác nhau: Unified modeling language (UML):

nổi lên nhƣ một chuẩn cho các phần mềm hƣớng đối tƣợng. Hình 1-7 cho

thấy 1 lớp đƣợc biễu diễn dạng biểu đồ bằng UML va Phụ lục L chứa 1

SDS hoan chỉnh cho 1 hệ thống hƣớng đối tƣợng. SDS bao gồm nhiều biểu

đồ nhƣ: 1)Biểu đồ biễu diễn class, 2) Biểu đồ biễu diễn object, 3) Biều đồ

biễu diễn sự đóng gói (package) – cho biết các lớp đƣợc nhóm lại với nhau





nhƣ thế nao, 4)Biểu đồ biễu diễn sự cộng tác (collaboration): cho biết cách

ma các lớp hợp tác va lam việc với nhau. (Xem thêm về phƣơng pháp

hƣớng đối tƣợng ở chƣơng 13).

1.9 KIỂM TRA PHẦN MỀM

When you tie many programs together you have a system. It is not

uncommon for a system to have thousands of lines of code, all of which

must be tested. The very first level of testing is at the programmer‘s desk.

Here he works with whatever tools he is using to make sure that everything

works.

Khi ta kết hợp nhiều chƣơng trình lại với nhau, ta đƣợc 1 hệ thống.

Không hiếm các hệ thống có hang ngan dòng code, tất cả chúng đều phải

đƣợc kiểm tra. Kiểm tra ở cấp độ đầu tiên la do lập trình viện thực hiện.

Ngƣời lập trình sử dụng bất kỳ công cụ nao để đảm bảo những gì mình viết

ra đều chạy đúng.

Many applications are built using a Microsoft product called Visual

Basic. Exhibit 1-10 shows what the debugger looks like. For those of you

who do not know the derivation of the term, debug means to take the

―bugs‖ out of a program. A bug is an error, but the term actually stems from

an incident with one of the first computers in the early 1950s. A real bug

crawled into the computer, which stopped working. Ever since, we use the

term debugging to describe the process of ridding a program of its problems





Vi dụ nhƣ ta dùng MS Visual Basic, hình 1-10 cho thấy chƣơng trình

chỉnh lỗi (debugger) của nó.

The debugger will run only if your code ―compiles and links‖ first.

When you compile a program it goes through a syntax checker that checks

for obvious errors (i.e., referencing a variable that does not exist).

Debugger chạy khi code đã đƣợc biên dịch va liên kết (compile and

link). Khi compile sẽ kiểm tra lỗi cú pháp va những lỗi dễ thấy (nhƣ dùng

biến ma chƣa khai báo).

When a group of programmers work together, their project manager

might think it a good idea that a ―walkthrough‖ be held. This is when the

team gets together and examines the code as a group to find flaws and

discuss better ways to do things. Usually this is not done. One reason is that

programmers do not like to do this; another reason is that it is very time

consuming.

Khi các lập trình viên lam việc với nhau, họ sẽ phân tich va thảo luận

để tìm ra giải pháp lập trình tốt hơn. Nhƣng thƣờng việc nay it xảy ra, một

la vì họ không thich, hai la tốn nhiều thời gian.

You can consider the testing the programmer does at his own desk

unit testing — meaning testing a unit of work (a program). When several

programs must interact together, another type of test that you might want to

perform is integrating testing. This test determines if the separate parts of





the system work well together. For example, program 1 creates a file that

contains a student file and program 2 processes that student file. If program

1 makes a mistake and creates the student file incorrectly, then program 2

will not work.

Có thể xem việc kiểm tra của lập trình viên la ―kiểm tra đơn vị‖ (unit

testing) – kiểm tra từng đơn vị của công việc (hay của chƣơng trình). Khi

vai chƣơng trình kết hợp với nhau, một loại kiểm tra nữa đƣợc thực hiện la

―kiểm tra tich hợp‖ (integrating testing): để kiểm tra xem các phần riêng

biệt của hệ thống có chạy tốt khi kết hợp lại. Vi dụ: chƣơng trình 1 tạo ra

file có chƣa thông tin sinh viên, chƣơng trình 2 sẽ xử lý file đó. Nếu chƣơng

trình 1 tạo file bị sai format hay lỗi, thì chƣơng trình 2 sẽ không chạy đúng.

A system test tests the complete system — soup to nuts. All of the

inputs are checked, all of the outputs are checked, and everything in

between is checked. If there is an existing system, a parallel test is done.

―Parallel‖ is a good term for this because you must run both systems in

tandem and then check the results for similarities and differences.

―Kiểm tra hệ thống‖ (system test): kiểm tra hệ thống phần mềm cuối

cùng. Tất cả các bộ test đƣợc cho chạy thử, kết quả trung gian và outputs

sau cùng đều đƣợc kiểm tra. Nếu có một hệ thống tƣơng tự nhƣ vậy rồi, thì

sẽ tiến hanh ―kiểm tra song song‖ (parallel testing) để kiểm tra hệ thống

mới – cho chạy 2 hệ thống cùng lúc va kiểm tra sự khác/giống nhau ở kết

quả.





Finally, acceptance testing is done. This means that you run a test

and the end user agrees or disagrees with the test and approves or

disapproves it.

Cuối cùng la ―acceptance testing‖: một bộ test sẽ đƣợc chạy va ngƣời

dung cuối sẽ đƣa ra ý kiến về kết quả, có thể lả chập nhận hoặc không chấp

nhận chẳng hạn.

In any case, testing is a lot of work that involves many people,

including end users and, usually, a quality assurance (QA) department. QA

people spend all of their time writing testing scripts (i.e., a list of things to

test for) and then running those scripts. If they find an error they send a

report to the programmer, who then fixes it. QA usually uses testing tools to

assist with these massive jobs. These tools assist with the creation of scripts

and then automatically run them. This is especially helpful when

conducting stress testing — testing to see how well the system works when

many people are using it at the same time.

Trong bất kỳ trƣờng hợp nao, việc kiểm tra phần mềm cũng bao gồm

rất nhiều công đoạn va cần nhiều ngƣời tham gia, bao gồm cả ngƣời dùng

cuối, thông thƣờng sẽ do bộ phận QA (Quality Assurance) đảm trách.

Ngƣời của bộ phận QA có công việc la: viết va cho chạy thử các đoạn

scripts kiễm tra phần mềm. Sau đó họ gửi phản hồi lại cho lập trình viên

trong trƣờng hợp có lỗi xảy ra. Với khối lƣợng công việc lớn, thông thƣờng

họ cần đến công cụ hỗ trợ cho việc kiểm tra (testing tool) – các công cụ nay





sẽ tạo ra scripts va tự chạy chúng. Testing tool đặc biết có ich khi tiến hanh

―kiểm tra khắc nghiệt‖ (stress testing) – kiểm tra hoạt động của hệ thống

khi hoạt động vƣợt công suất đã đƣợc chỉ định, chẳng hạn nhƣ hệ thống sẽ

ra sao nếu nhƣ có ngƣời ngƣời dùng sử dụng cùng một lúc.

Testing is usually not performed in a vacuum. An analyst or manager

prepares a test plan that details exactly what must be tested and by whom

(see Appendix A). The test plan contains the testing schedule as well as the

intricate details of what must be tested. These detailed plans are called ―test

cases‖ and form the basis for the test scripts used by the programmer or

QA staff member, usually in conjunction with a testing tool.

Ngƣời phân tich hoặc ngƣời quản lý sẽ lập một kế hoạch kiểm tra

(test plan) chi tiết: cụ thể những gì sẽ đƣợc kiểm tra va do ai đảm nhận

(Xem phụ lục A). Những kế hoạch chi tiết (detailed plans) đƣợc gọi la ―test

cases‖, sẽ cho biết các đoạn test scripts cơ bản ma programmer hay đội ngũ

QA sẽ dùng, thƣờng thì có kết hợp với testing tool.

A sample test case that could appear in a test plan appears in Exhibit

1-11. This would be turned into a script for use by the testers. For more

details of testing, see Chapter 16.





1.10 STANDARD AND METRIC

When you build a house you must adhere to certain standards;

otherwise, the homeowner‘s lamp will not fit into the electrical outlet. The

size of the outlet is consistent with a standard used throughout the building

industry. Those who travel know that they must bring an adaptor because a

hair dryer brought from the United States into Italy will not fit into Italian





outlets. This is because many standards in America are different from the

standards in other countries.

Khi bạn xây 1 ngôi nha bạn phải dựa vao những tiêu chuẩn chắc

chắn; nếu không thì, cái đèn sẽ không vừa với ổ điện. Kich thƣớc của ổ điện

thì đƣợc thống nhất với 1 tiêu chuẩn sử dụng xuyên suốt quá trình công

nghiệp xây dựng. Những ngƣời du lịch biết rằng họ phải mang theo adaptor

bởi vì máy sấy tóc mang từ Mỹ sang Ý sẽ không vừa với ổ điện kiểu Ý. Đó

la bởi vì những tiêu chuẩn của Mỹ khác với những tiêu chuẩn ở các nƣớc

khác.

Standards are an important fact of life; without them we would be

living in chaos. This is especially true in the IT industry. The American

National Standards Institute, which is located in New York (www.ansi.org),

was founded in 1918 to coordinate the development of U.S. voluntary

national standards in the private and public sectors. It is the U.S. member

body to ISO and IEC. Information technology standards pertain to

programming languages, EDI, telecommunications and physical properties

of diskettes, cartridges, and magnetic tapes. The IEEE (Institute of

Electrical and Electronics Engineers — www.ieee.org) is another

membership organization that develops standards.

Tiêu chuẩn la một thanh phần quan trọng của cuộc sống, không có

nó, chúng ta sẽ sống trong sự hỗn loạn. Va nó đặc biệt đúng trong công

nghiệp IT. Viện tiêu chuẩn quốc gia Hoa Kì (American National Standards





Institute), đƣợc đặt tại New York (www.ansi.org), đƣợc thanh lập năm 1918

để phối hợp với việc phát triển của các tiêu chuẩn tự phát quốc gia Hoa Kỳ

trong khu vực công cộng va riêng tƣ. Đó la thanh viên quan trọng của ISO

va IEC. Tiêu chuẩn công nghệ thong tin gắn liền với ngôn ngữ lập trình,

EDI, viễn thông va tinh chất vật lý của đĩa mềm, đầu đĩa, va băng ghi âm.

IEEE (Institute of Electrical and Electronics Engineers — www.ieee.org) là

một tổ chức thanh viên khác phát triển tiêu chuẩn.

For example, IEEE 1284 is an IEEE standard for an enhanced

parallel port that is compatible with the Centronics port commonly used on

PCs. Instead of just data, it can send addresses, allowing individual

components in a multifunction device (printer, scanner, fax, etc.) to be

addressed independently. IEEE 1284 also defines the required cable type

that increases distance to 32 feet.

Vi dụ, IEEE 1284 la 1 tiêu chuẩn IEEE cho công kết nối song song

thich hợp với cổng Centronics thƣờng đƣợc sử dụng trên PC. Ngoai dữ liệu,

nó còn có thể gửi địa chỉ, cho phép những thanh phần riêng biệt trong một

thiết bị đa chức năng (máy in, scanner, fax,..) đƣợc gửi địa chỉ độc lập.

IEEE 1284 còn xác định đƣợc kiểu cáp cần thiết để tăng khoảng cách lên 32

feet

Your company might well adhere to ISO 9000 and 9001. As I

mentioned, ANSI is the U.S. member body to ISO. The International

Organization for Standardization is a Geneva-based organization that sets


http://www.ansi.org/

http://www.ieee.org/




international standards. ISO 9000 is a family of standards and guidelines for

quality in the manufacturing and service industries from the International

Standards Association; it defines the criteria for what should be measured.

ISO 9001 covers design and development, ISO 9002 covers production,

installation and service, and ISO 9003 covers final testing and inspection.

Công ty của bạn có thể dựa vao tiêu chuẩn ISO 9000 va 9001. Nhƣ

tôi đã đề cập, ANSI la thanh viên quan trọng của ISO. Tổ chức quốc tế về

tiêu chuẩn hóa la tổ chức Geneva ma đã thiết lập tiêu chuẩn quốc tế. ISO

9000 la một nhóm các tiêu chuẩn va hƣớng dẫn cho chất lƣợng trong việc

sản xuất va dịch vụ công nghiệp từ tổ chức tiêu chuẩn thế giới; nó xác đinh

tiêu chuẩn cho bất cái cái gì có thể tinh toán đƣợc. ISO 9001 gồm thiết kế

va phát triển, ISO 9002 gồm sản phẩm, lắp đặt va dịch vụ, va ISO 9003

gồm kiểm tra va xem xét.

If you live by the rule of standards you need to have a way to

measure whether or not those standards are adhered to. In our field, we use

metrics (measurements). The most prevalent metric used is lines of code,

which is the number of lines of code a programmer can program in an hour.

There are many more metrics. The second half of this handbook provides

details on a variety of metrics that are in use (or should be in use) today.

Appendix P is a software metrics capability evaluation guide that will be

useful prior to starting on a measurement program.





Nếu bạn sống trong quy tắc của tiêu chuẩn, bạn cần phải có cách để

tính toán có hay không những tiêu chuẩn đƣợc dựa vao. Trong lĩnh vực của

chúng tôi, chúng tôi sử dụng metrics. Metric thƣờng đƣợc sử dụng nhất la

số dòng code, la số dòng ma ngƣời lập trình có thể lập trình trong 1 giờ. Có

rất nhiều metric khác nữa. Nửa sau của cuốn sách nay cung cấp chi tiết của

các loại metric khác đang đƣợc sử dụng(hoặc nên sử dụng) ngay nay.

Appendix P la 1 phần mềm hƣớng dẫn ƣớc lƣợng metric sẽ có ich trƣớc khi

bắt đầu trên 1 chƣơng trình đo lƣờng.

A controlled development and maintenance program is essential for

bringing down the cost associated with software development life cycle.

The control mechanism can be implemented by setting up specific goals nd

then selecting the right set of metrics for measurements against those goals.

Goals must be tangible and balanced or they will be too remote to be

considered achievable. Intermediate targets are needed for monitoring the

progress of the project and making sure that it is on the right track. Project

data collection and analysis should also be part of the control mechanism.

Sự kiểm soát phát triển va bảo trì chƣơng trình thì quan trọng trong

việc giảm chi phi có lien quan đến việc phát triển quá trình sản xuất phần

mềm. Bộ máy kiểm soát có thể đƣợc thi hanh bằng việc thiết lập những

mục tiêu cụ thể va sau đó lựa chọn tập hợp chinh xác các metric cần thiết

cho việc tinh toán cho những mục tiêu đó. Mục tiêu phải hữu hình va cân

bằng hoặc nó có thể hơi xa vời để có thể đạt đƣợc. Mục tiêu trƣớc mắt thì

cần thiết để kiểm soát sự phát triển của dụ án va khẳng định chắc chắn rằng





nó đang đi đúng đƣờng. Thu thập va phân tich dữ liệu của dự án nên la một

phần của bộ máy kiểm soát

A four-step procedure (Linkman and Walker, 1991) is outlined for

establishing targets and means for assessment. The procedure is not focused

on any particular set of metrics; rather, it believes that metrics should be

selected on the basis of goals. This procedure is suitable for setting up goals

for the entire project‘s deliverables or for any partial product created in the

software life cycle. (More information on standards and metrics can be

found in Section II.)

Thủ tục 4 bƣớc (Linkman & Walker, 1991) đƣợc phác thảo để xác

định mục tiêu va phƣơng tiện đánh giá. Thủ tục nay không tập trung vao bất

cứ tập metric nao cụ thể; hơn thê, nó tin rằng metric sẽ đƣợc lựa chọn dựa

trên nền tảng mục tiêu. Thủ tục nay thich hợp cho việc thiết lập mục tiêu

cho dự án có thể phân phối hoặc cho bất cứ phần nao của sản phẩm đƣợc

tạo ra trong quá trình sản xuất phần mềm (nhiều thong tin của Standard va

Metric sẽ đƣợc tìm thấy ở Phần II)

1.11 THỦ TỤC

1. Define measurable goals. The project goals establishment process

is similar to the development process for project deliverables. Software

projects usually start with abstract problem concepts and the final project

deliverables are obtained by continuously partitioning and refining the





problem into tangible and manageable pieces. Final quantified goals can be

transformed from initial intangible goals by following the same divide-and-

conquer method for software deliverables. Three sources of information are

helpful to establishing the targets:

- Historical data under the assumptions that data is available,

development environment is stable, and projects are similar in

terms of type, size, and complexity

- Synthetic data such as modeling results if models used are

calibrated to the specific development environment

- Expert opinions

Xác định mục tiêu khả thi. Quá trình xác định mục tiêu của dự án thì

giống với quá trình phát triển dự án đối với dự án có thể triển khai đƣợc.

Dự án phần mềm thƣờng bắt đầu với vấn đề trừu tƣợng va dự án có thể

triển khai cuối cùng đạt đƣợc từ việc phân nhóm va xác định vấn đề vao

những phần có thể quản lý va có thể xem xét. Mục tiêu chất lƣợng cuối

cùng có thể chuyển từ mục tiêu mơ hồ bằng cách thực hiện cùng phƣơng

pháp chia để trị nhƣ phần mềm triển khai 3 nguồn thông tin có ich cho việc

xác định mục tiêu

- Thông tin đã có từ trƣớc, dƣới giả thuyết rằng dữ liệu có sẵn, môi

trƣờng phát triển ổn định, va dự án thì giống nhau về dạng, kich

thƣớc, va độ phức tạp





- Dữ liệu tổng hợp nhƣ la kết quả theo dạng nếu dạng đó đƣợc lấy

chuẩn từ môi trƣờng phát triển đặc biệt.

- Ý kiến chuyên gia

2. Maintain balanced goals. The measurable goals are usually estab

lished on the basis of cost, schedule, effort, and quality. It is feasible to

achieve a single goal, but it is always a challenge to deliver a project with

the minimum staff and resource, on time, and within budget. It needs to be

kept in mind that trade-off is always involved and all issues should be

addressed to reach a set of balanced goals.

Giữ vững mục tiêu cân bằng. Mục tiêu khả thi thƣờng đƣợc xác định

dựa trên nền tảng chi phi, kế hoạch, sự cố gắng, va chất lƣợng. La khả thi

để đạt đƣợc 1 mục tiêu, nhƣng thƣờng la thách thức khi cung cấp cho 1 dự

an với nhân lực va tai nguyên nhỏ nhất, đúng giờ, va ngân sách có hạn. Cần

thiết luôn có trong đầu ý tƣởng rằng rủi ro luôn luôn tồn tại va mọi khó

khăn đều có thể giải quyết để đạt đƣợc những mục tiêu cân bằng

3. Set up intermediate goals. A project should never be measured

only at its end point. Checkpoints should be set up to provide confidence

that the project is running on course. The common practice involves setting

up quantifiable targets for each phase, measuring the actual values against





the targets, and establishing a plan to make corrections for any deviations.

Cost, schedule, effort, and quality should be broken down into phase or

activity for setting up intermediate targets. Measurements for cost and

effort can be divided into machine and human resources according to

software life-cycle phase so that expenditures can be monitored to ensure

the project is running within budget. Schedule should always be defined in

terms of milestones or check points to ensure intermediate products can be

evaluated and final product will be delivered on time. Quality of

intermediate products should always be measured to guarantee the final

deliverable will meet its target goal.

Thiết lập mục tiêu tức thời, 1 dự án không nên chỉ tinh toán đến điểm

kết thúc. Checkpoint nên đƣợc thiết lập để cung cấp sự tự tin rằng dự án

đang hoạt động đúng tiến độ. Thƣợng đƣợc ứng dụng trong việc xác định

mục tiêu có thể xác định cho từng phần, tinh toán những giá trị chống lại

mục tiêu, thiết lập kế hoạch để sửa chữa bất cứ sai sót nao. Chi phi, kế

hoạch, đầu tƣ, va chất lƣợng có thể bị chia nhỏ thanh từng phần hoặc hoạt

động cho việc thiết lập mục tiêu tức thời.

Tinh toán chi phi va đầu tƣ có thể chia nhỏ thanh máy móc va nguồn

nhân lục dựa vao quy trình phát triển phần mềm nên phi tổn có thể đƣợc

kiểm soát để chắc chắn rằng dự án đƣợc chạy trong nguồn kinh phi cho

phép, Kế hoạch nên luôn luôn đƣợc xác định theo milestones hoặc

checkpoint để chắc chắn sản phẩm tức thì có thể đƣợc định giá va sản phẩn

cuối cùng đƣợc cung cấp đúng hạn. Chất lƣợng sản phẩm tức thì nên luon





luôn đƣợc tinh toán để bảo đảm kết quả phân phối cuối cùng sẽ la mục tiêu

hƣớng tới.

4. Establish means of assessment. Two aspects are involved in this

activity:

- Data collection. Based on the project characteristics such as size,

complexity, level of control, etc., a decision should be made in

terms of whether a manual data collection process or an automated

data collection process should be used. If a nonautomated way is

applied, then the availability of the collection medium at the right

time should be emphasized.

- Data analysis. The following two types of analyses should be con

sidered:

Project analysis, a type of analysis consisting of checkpoint

analysis and continuous analysis (trend analysis), is

concerned with verifying that intermediate targets are met to

ensure that the project is on the right track.

Component analysis is a type of analysis that concentrates

on the finer level of details of the end product and is

concerned with identifying those components in the product

that may require special attention and action. The complete

process includes deciding on the set of measures to be





analyzed, identifying the components detected as anomalous

using measured data, finding out the root cause of the

anomalies, and taking actions to make correction.

Thiết lập phƣơng tiện đánh giá. 2 quan điểm bao ham trong việc nay:

- Thu thập dữ liệu. dựa vao tinh chất dự án nhƣ kich thƣớc, độ phức

tạp, mức độ kiểm soát,… quyết định nên đƣợc tạo ra dựa vao quá

trình thu thập thong tin tự đông hoặc bằng tay. Nếu quá trình ko tự

động đƣợc áp dụng, thì tinh hiệu lực của việc thu thập vao thời

gian chinh xác phải đƣợc quan trọng.

- Phân tich dữ liệu, 2 dạng phân tich nên quan tâm

Phân tich dựa theo dự án. Bao gồm phân tich checkpoint va

phân tich xu hƣớng, đƣợc quan tâm với việc thẩm tra rằng

mục tiêu trƣớc mắt đƣợc tạo ra để chắc chắn rằng dự án

đang đi đúng đƣờng.

Phân tich đối tƣợng la 1 dạng của phân rằng ma tập trung

vao cấp độ thấp hơn về chi tiết của sán phẩm cuối va quan

tâm đến việc xác định các đối tƣợng, thah phần trong sản

phẩm có thể cần những hanh động đặc biệt. Quá trình hoan

chỉnh bao gồm quyết định trên tập hợp nhũng tinh toán để

phân tich, xác định đối tƣợng đƣợc xác định bất thƣờng sử





dụng dữ liệu tinh toán, tìm ra nguyên nhân sâu xa của sự bất

thƣờng, va thực hiện việc sửa chữa.

1.12 CÀI ĐẶT

When you have a very small system you can just put it online

(direct). If your system is larger then there are several ways to approach

installing (implementing) the system. If you are going to replace an existing

system, then you can install the new system in a parallel mode. This means

that you run both systems at the same time for a period of time. Each day

the end users check the outputs and, when they feel comfortable, turn the

old system off.

Khi bạn có một hệ thống nhỏ bạn có thể cai đặt trực tiếp. Nếu hệ

thống của bạn lớn hơn thì có nhiều cách để có thể cai đặt hệ thống. Nếu bạn

muốn cố gắng để thay thế hệ thống cũ, thì bạn có thể cai đặt hệ thống theo

kiểu song song. Có nghĩa la bạn chạy một lúc hai hệ thống trong cùng một

thời gian. Đến lúc ma ngƣời dung có thể kiểm tra truy xuất, họ cảm thấy

thoải mái, thì có thể gơ bỏ hệ thống cũ.

Many companies run multiple servers with the same system running

on each server. One good way to install a system is to install it on a single

server first, see how it runs, and then install it on another server. This is

called a phased approach.





Nhiều công ty chạy hệ thống nhiều máy chủ chung hệ thống chạy

trên từng máy chủ. Một cách tốt để cai đặt la cai đặt nó trên một máy chủ

trƣớc, kiểm tra xem nó chạy nhƣ thế nao, sau đó sẽ cai đặt trên những máy

chủ khác. Đó gọi la tiếp cận giai đoạn.

1.13 TÀI LIỆU HÓA

One day all of the programmers who wrote the original system will

leave. If documentation is not adequate then the new programmers will not

understand how to work on the system. I recently worked on a project

(Internet gambling for a foreign country) where the programmer did not

have any documentation at all. The system was written in C++ and ASP

and there were hundreds of programs. It was almost impossible to figure out

which program ran first. So, you really do need system documentation.

Một ngay tất cả các lập trình viên viết chƣơng trình ban đầu sẽ nghỉ

việc. Nếu tai liệu không đầy đủ thì những ngƣời lập trình mới sẽ không hiểu

đƣợc sẽ phải lam việc nhƣ thế nao trên hệ thống. Tôi thƣờng lam việc trên 1

dự án (Cá cƣợc qua mạng ở nƣớc ngoai) nơi ma các nha lập trình không

bao giờ tai liệu hóa. Hệ thống đƣợc viết trên C++ va ASP va hang trăm

chƣơng trình. Sẽ la không thể để nhận biết đƣợc chƣơng trình nao chạy

trƣớc. Nên, bạn thật sự cần hệ thống đƣợc tai liệu hóa.

It is also critical to have some documentation for the end users. You

have seen the manuals that come with software that runs on your PC. Look





at the manual that comes with Visio; you are the end user for this software.

So, if you write a system, you will need to write a manual for your end

users.

Cũng rất la quan trọng để có 1 số tai liệu cho ngƣời dung cuối. Bạn

đã đƣợc nhìn thấy cách phần mềm hoạt động trên PC. Thử nhìn trong

trƣờng hợp Visio; bạn la ngƣời dung cuối. Vậy, nếu bạn việt chƣơng trình,

ban sẽ cần phải viết hƣớng dẫn sử dụng cho ngƣời dung cuối.

Finally, you will need to train your end users to use the system.

When I worked for the New York Stock Exchange, we brought in a tool

that permitted our end users to use a fourth generation language (4GL) to

do their own queries against the system‘s database. We needed to train

these end users to use the 4GL productively. Instead of writing and teaching

a course ourselves, we hired an expert who did it for us (outsource). (See

Chapter 19 for more on documentation.)

Cuối cùng, bạn sẽ cần để huấn luyện cho ngƣời dùng cuối cách sử

dụng hệ thống. Khi tôi lam việc cho trung tâm giao dịch New York Stock,

chúng tôi mang đến 1 công cụ ma cho phép ngƣời dung cuối sử dụng 4 thế

hệ ngôn ngữ để lam truy vấn của họ với cơ sở dữ liệu hệ thống. Chúng tôi

đã huấn luyện họ cách sử dụng sản phẩm đó. Thay cho việc viết va dạy cho

họ, chúng tôi thuê 1 chuyên gia ngƣời đã viết chƣơng trình đó cho chúng

tôi.





1.14 BẢO TRÌ

Many, many years ago I worked with a project leader who wanted to

play with a new toy. At the time databases were just coming into vogue, so

the project leader decided to create a database for a new system. The

problem was that this particular system did not need this particular

database. The system was written but, as a result of the horrid choice of

databases, it never ran well. In fact, it ―bombed‖ out all the time.

Nhiều năm trƣớc tôi lam dự án với ngƣời leader muốn thử những trò

chơi mới. Vao thời gian cơ sở dữ lieu đang thịnh hanh, nên leader quyết

định tạo cơ sở dữ liệu cho hệ thống mới. Vấn đề la, hệ thống nay không cần

cơ sở dữ liệu. Hệ thống đƣợc viết, nhƣng, nhƣ la kết quả của việc chọn cơ

sở dữ liệu, nó không chạy. Thực tế, nó lam nổ tung mọi thứ.

After a year of problems, management decided that the system

needed to be fixed, and fix it we did. This is called corrective

maintenance— modifying an existing system so that it works correctly.

Maintenance is done for lots of reasons.

Sau 1 năm, ngƣời quản lý quyết định rằng hệ thống phải đƣợc sửa

chữa, va chúng tôi lam. Đó đƣợc gọi chinh xác la bảo trì – hiệu chỉnh 1 hệ

thống có sẵn để nó lam việc đúng. Việc bảo trì hoan thánh cho nhiều li do.

One reason we are all familiar with is because of security and

viruses. Systems people frequently make modifications to software because





of problems such as this. The casino gaming programmers mentioned

previously had to suspend programming new features into the system to

take care of the ―Code Red‖ worm. This is an example of preventative

maintenance. Most often the reason for maintenance is simply to improve

the system. If the casino end users decide to add a new game to the system

or a new data field is added to a database or a new report is required —

these are examples of maintenance for improvement purposes.

Một li do ma chúng tôi quen thuộc la bảo mật va virus. Ngƣời lam hệ

thống thƣờng xuyên cập nhật phần mêm vì những li do nhƣ vậy. Ngƣời lập

trình cho casino đề cập đến trƣớc đó phải hoãn lập trình ứng dụng mới vao

hệ thống để quan tâm đến con sâu Code Red. Đó la vi dụ về bảo trì an ninh.

Li do thƣờng xuyên của bảo trì đơn giản la phát triển hệ thống. Nếu nhƣ

ngƣời dung cuối trong casino quyết định them trò chơi mới vao hệ thống

hoặc dữ liệu mới đƣợc them vao trong cơ sở dữ liệu hoặc báo cáo mới la

cần thiết – đó la vi dụ bảo trì cho mục đich phát triển.

Some organizations have two types of programmers; one type

usually works on new software and the other is stuck with maintenance.

This is not often done anymore because maintenance programmers are

usually an unhappy lot and, therefore, their turnover rate is quite high.

Một số tổ chức có 2 loại lập trình viên, 1 thƣờng xuyên lam ra phần

mềm mới, va 1 chỉ lam bảo trì. Nó ko còn thong dụng nữa bởi vì nhân viên





bảo trì thƣờng la lá thăm ko may mắn va, do đó, tỉ lệ doanh thu của họ

thƣờng khá cao.

All systems need to be managed. You cannot make changes to a

system willy-nilly. The way you control what happens to a system is to

continue holding meetings with your end users and developing a prioritized

list of changes and additions that need to be made. Occasionally, a change

might come in from a person who is not on the end-user committee. To

handle these requests, system personnel usually make use of a standard

change request form. This form contains information such as desired

change, reason for change, screen shots of the existing screen that needs to

be changed, if applicable, and more, depending on the organization. Usually

these changes must be authorized by the end user‘s management before it is

sent to the computer department.

Mọi hệ thống cần đƣợc quản lý. Bạn không thể tạo sự thay đổi với hệ

thống dù la nhỏ nhất. Cách bạn kiểm soát những gì xảy ra cho hệ thống la

tiếp tục gặp gơ với ngƣời dung cuối va phát triển danh sách ƣu tiên cần thay

đổi, va những phần them vao cần thiết. Thỉnh thoảng, sự thay đổi có thể đến

từ những ngƣời không phải ngƣời dung cuối. Để giải quyết những yêu cầu

đó, ngƣời lam hệ thống thƣờng sử dụng mẫu yêu cầu thay đổi. Mẫu nay chứ

những thong tin nhƣ thay đổi nhu cầu, li do, hình minh họa, nếu có, va hơn

thế nữa, tùy theo tổ chức. thƣờng những thay đổi đó sẽ đƣợc xem xét bởi

ngƣời quản li ngƣời dung cuối trƣớc khi gửi cho computer department.





Once the change request comes to the computer department, if it is

simple and there is some spare time, the modification is scheduled

immediately. Usually, however, it is added to a prioritized list of things to

do. When it reaches the top of the list, the same SDLC steps used during

development are used during maintenance. In other words, you need to

determine whether the modification is feasible, determine its cost, develop a

specification, etc. (Chapter 18 provides additonal discussion on

maintenance.)

Khi mẫu thay đổi đến với computer department, nếu đơn giản va có

nhiều thời gian, sự hiệu chỉnh sẽ diễn ra ngay lập tức. Thƣờng, tuy nhiên,

nó sẽ đƣợc them vao trong danh sách ƣu tiên những việc sẽ lam. Khi nó ở

đầu danh sách, các bƣớc SDLC sẽ đƣợc sử dụng để phát triển va bảo trì.

Mặt khác, bạn cần xác định khi nao hiệu chỉnh khả thi, xác định chi phi,

phần phát triển…

1.15 HUẤN LUYỆN

After the system is installed the end users will require some training.

The various ways to achieve this include in-house training to CAI

(computer assisted instruction). Once the end-users are trained they will

need some support on a day-to-day basis. First, as already discussed, they

will need a manual so they can look up answers to questions. Some systems

do not use paper manuals; instead, everything is embedded in a Help file. If

the manuals are insufficient then the company might want to do what most





companies are doing and fund and staff a Help Desk. Sometimes people in

end-user departments rely on a person within their department who has

become quite expert at using the system. This person is usually referred to

as the resident expert.

Sau khi hệ thống đƣợc cai đặt, ngƣời dùng cuối sẽ cần huấn luyện. 1

trong những cách la traning o nha với CAI. Khi ma ngƣời dung cƣới đƣợc

huấn luyện họ sẽ cần những hợ trợ. Thứ nhất, nhƣ đã thảo luận, họ sẽ cần

hƣớng dận nên họ có thể tìm kiểm câu trả lời cho câu hỏi. Một số hệ thống

sẽ không sử dụng giấy hƣớng dẫn, thay vao đó sẽ la tập tin hƣơng dẫn. Nếu

không thich hợp, công ty sẽ cần phải có 1 ban hƣớng dẫn. Thỉnh thoảng,

ngƣời dung cuối sẽ tin cậy vao 1 ngƣời trong bộ phận của họ ngƣời đã la

chuyên gia sử dụng hệ thống đó.

1.16 KẾT LUẬN

In this introductory chapter we have covered a broad array of

systems development issues and methodologies. We started our grand tour

by discussing the SDLC (systems development life cycle) that identifies the

different steps IT team members take when developing a computer system

using the traditional structured approach. These steps include, but are not

limited to, feasibility study, analysis, design, testing, and implementation. It

is very important that an IT team use a methodology to build a system.

Although systems can certainly be built without such a methodology, the

resulting systems are usually quite flawed and inefficient, and cost too much





money to build and maintain. One would not build a house without

blueprints; therefore, it makes sense that one should not build a computer

system without a blueprint for building it (the requirement document and

design specification).

Trong chƣơng giới thiệu, chúng ta đã sơ lƣợc qua chiều rộng của

phƣơng pháp va cách thức phát triển hệ thống. Ch1ung ta bắt đầu bằng

SDLC, xác định các bƣớc khác nhau của nhóm IT khi phát triển hệ thống

máy tínhsử dụng cấu trúc truyền thống. Các bƣớc bao gồm, nhƣng không

giới hạn, nghiên cứu khả thi, phân tich, thiết kế, kiểm tra, va thi hanh. Rất

quan trọng cho đội ngũ IT sử dụng phƣơng pháp để xây dựng hệ thống.

Mặc dù hệ thống có thể đƣợc xâu dựng ma không cần phƣơng pháp, hệ

thống cuối cùng thƣờng có lỗ hổng va không hiệu quả, va tiêu tốn rất nhiều

tiền để xây dựng va bảo trì. 1 ngƣời sẽ không xây 1 căn nha ma không có

kế hoạch; do đó, nó có ý nghĩa rằng một ngƣời không thể xây dựng 1 hệ

thống máy tinh ma không có kế hoạch cho việc xây dựng (tai liệu cần thiết

va thiết kế đặc biệt)

We have seen some of these ―building tools‖ in action in the form of

DFDs (data flow diagrams) and PSPECs (process specifications). There are

many other diagrammatic techniques such as State transition diagrams, E–R

diagrams (entity–relationship), and control flow diagrams. These tools are

used by the analyst to lay out exactly what the system is going to do, how

the system will interact with its data, how the databases will be laid out, and

how the system will interface with other systems.





Chúng tôi nhìn thấy 1 vai công cụ xây dựng trong việc theo mẫu

DFDs va PSPECs. Có nhiều dạng biểu đồ kỹ thuật nhƣ biểu đồ State

transition, biểu đồ E-R, va nhiều biểu đồ kiểm soát. Các công cụ đó đƣợc sử

dụng để phân tich hệ thống thật sự đang lam những gì, hệ thống tƣơng tác

nhƣ thế nao với dữ liệu, cơ sở dữ liệu đƣợc đƣa ra nhƣ thế nao, va cách hệ

thống giao tiếp với bên ngoai với những hệ thống khác.

Of course, none of this is possible without first figuring out what the

end user wants and needs for his or her system. The process of determining

these requirements is usually called requirements elicitation and it is the

information uncovered in this process that the analyst uses to model the

system.

Dĩ nhiên, không cái gì la có thể ma không có việc hoạch định ra cái

ma ngƣời dung cuối muốn cho hệ thống của họ. Quá trình xác định các yêu

cầu thƣờng gọi la gợi ra yêu cầu va đó la thong tin không đƣợc nhắc đến

trong quá trình ma nha phân tich định hình hệ thống.

Once the system is deemed feasible and its requirements determined,

it is now time to physically design the system. This is when the analyst or

designer gets into the ―bits and bytes‖ of the system: exactly what functions

will be programmed, the logic of these functions, what data will be used,

what network architecture should be used, etc. In this step, an extremely

detailed design specification is created — so detailed that the programmers

have all the information they need to write their programs.





Khi hệ thống đƣợc xác định la khả thi la những yêu cầu đƣợc xác

định, bấy giờ la thời gian để thiết kế vật lý cho hệ thống. Đó la khi nha phân

tich hoặc nha thiết kế bắt đầu với bits va bytes của hệ thống; chinh xác chức

năng sẽ đƣợc lập trình, tinh logic của các chức năng, dữ liệu nao sẽ đƣợc sử

dụng, kiến trúc mạng nao sẽ đƣợc sử dụng, … Trong bƣớc nay, các chi tiết

cuối cùng thiết kế đặc biệt sẽ đƣợc tạo ra –chi tiết ma ngƣời lập trình muốn

có tất cả thong tin họ cần để viết chƣơng trình.

The system is then tested (unit testing by the programmer,

acceptance testing by the end users, system testing by the team, etc.). After

the system has been thoroughly tested, it is time to implement the system;

this is often called ―putting it into production‖ by those in the field. Just

prior to this, the IT team documents the system and trains the end users.

Hệ thống sẽ đƣợc kiểm tra sau đó (kiểm tra đon vị bởi ngƣời lập

trình, kiểm tra chấp nhận bởi ngƣời dung cuối, kiểm tra hệ thống bởi

team…) Sauk hi hệ thống vƣợt qua kiểm tra, la thời gian để thi hanh hệ

thống,; thƣờng gọi la đặt hệ thống vao sản phẩm.. Đặt độ ƣu tiên, IT tai liệu

hóa hệ thống va huấn luyện ngƣời dùng cuối.

Finally, the system is in production and it is time to support it (help

desk, training, etc.) and make changes (maintenance) as required.

Cuối cùng, hệ thống sẽ ở trong sản phẩn va đó la thời gian để cung

cấp cho hệ thống (help desk, training…) va thay đổi (bảo trì) nếu cần thiết.




Chương 3: Lên kế hoạch cho dự án phần mềm 77

CHƢƠNG 2 NGHIÊN CỨU VỀ TÍNH KHẢ THI

VÀ PHÂN TÍCH CHI PHÍ/LỢI NHUẬN

Người dịch:

1. Trần Thanh Hải

2. Đặng Hoang Hải

3. Lê Văn Chân

4. Lê Anh Khoa

5. Dƣơng Tùng Sơn





A feasibility study is a detailed assessment of the need, value, and

practicality of a proposed enterprise, such as systems development (Burch,

2000). Simply stated, it is used to prove that a project is either practical or

impractical. The ultimate deliverable is a report that discusses the feasibility

of a technical solution and provides evidence or the steering committee to

decide whether it is worth going on with any of the suggestions.

Nghiên cứu tinh khả thi la đánh giá chi tiết về nhu cầu , giá trị cua

môt hoat đông kinh doanh đƣơc đê xuât chăng han nhƣ phát triển một hê

thông. Nói đơn giản, nó sử dụng để chứng tỏ một dự án thực tế hay phi thực

tê. Mục tiêu cao nhất la môt bao cao ban vê tinh kha thi cua giai phap ky

thuât va cung câp băng chƣng cho ban chi đao để quyêt đinh dự án có nên

đƣợc phát triển hay không.

At the beginning of every project, it is often difficult to determine if

the project will be successful, if its cost will be reasonable with respect to

the requirements of building certain software, or if it will be profitable in

the long run.

Vơi môi dƣ an , tại thời điểm bắt đầu , ta thƣơng kho xac đinh dƣ an

có thanh công hay không?! Chi phi cua no có hơp ly đôi vơi nhƣng đoi hoi

khi xây dƣng môt phâm mêm hay no co thu vê lơi nhuân hay không?

In general, a feasibility study should include the following

information:





Brief description of proposed system and characteristics

Brief description of the business need for the proposed system

A cost/benefit analysis

Estimates, schedules, and reports

Considerable research into the business and technical viability of the

proposed system is necessary in order to develop the feasibility study.

Thông thƣơng, nghiên cƣu tinh kha thi phải bao gôm nhƣng thông tin

sau:

Bản mô tả tóm tắt về hệ thống đƣợc đề xuất va đặc điểm

Bản mô tả tóm tắt của nhu cầu kinh doanh cho hệ thống đề xuất.

Phân tich chi phi/ lợi nhuân.

Đanh gia, lên kê hoạch va báo cáo.

Nghiên cứu nghiêm túc khả năng tai chinh va kỹ thuật của hệ thống

la cần thiết để phát triển việc nghiên cứu tinh khả thi.





2.1 NHỮNG THÀNH PHẦN TRONG NGHIÊN CỨU TÍNH KHẢ THI

There are actually three categories of feasibility

Thƣc tê, có 3 phần:

2.1.1 Tinh khả thi về tai chinh

A systems development project should be economically feasible and

provide good value to the organization. The benefits should outweigh the

costs of completing the project. The financial feasibility also includes the

time, budget, and staff resources used during all the stages of the project

through completion.

Môt dƣ an phat triên hê thông phải kha thi vê kinh tê va tạo ra lợi

nhuận cho tô chƣc. Lơi nhuân phải lớn hơn so vơi chi phi hoan thanh dƣ an.

Tinh khả thi về tai chinh cũng bao gồm thời gian , ngân quy va tai nguyên

con ngƣơi đƣơc sƣ dung trong tất cả các giai đoạn của dự án cho đên khi

hoàn thành.

A feasibility study will determine if the proposed budget is enough to

fund the project to completion. When finances are discussed, time must also

be a consideration. Saving time and user convenience has always been a

major concern when companies develop products. Companies want to make

sure that services rendered will be timely. No end user wants to wait for a





long time to receive service or use a product, however good it is, if another

product is immediately available.

Việc nghiên cứu ở đây se xac đinh xem ngân quy đê xuât co đu đê hô

trơ hoan thanh dƣ an hay không . Ngoài ra, yếu tố thơi gian cung phai đƣơc

tinh đến. Tiêt kiêm thơi gian va sự tiên lơi cho ngƣơi dung luôn la môi quan

tâm chinh khi nhƣng công ty phat triên san phâm . Các công ty muốn đảm

bảo rằng các dịch vụ phải kịp thời. Không ai muôn đơi môt thơi gian dai rôi

mơi nhân một dich vu hay san phâm dù cho nó co tôt thê nao đi chăng nƣa.

Key risk issues include: 1) the length of the project‘s payback (the

shorter the payback, the lower the risk), 2) the length of the project‘s

development time (the shorter the development time, the less likely

objectives, users, and development personnel will change and,

consequently, the lower the risk), and 3) the smaller the differences people

make in cost, benefit, and life cycle estimates, the greater the confidence

that the expected return will be achieved.

Nhƣng vân đê rui ro chinh:

Thơi gian hoan vôn (thơi gian hoan vôn cang ngăn thi đô rui ro

cang thấp)

Lƣơng thơi gian phat triên cua dƣ an (thơi gian phat triên cua dƣ an

cang it, đô rui ro cang thâp)





Sự khác biệt giữa dự tinh va thực tế cang it thì cơ hội thanh công

càng cao.

2.1.2 Tinh khả thi về mặt kỹ thuật

A computer system should be practical to develop and easy to

maintain. It is important that the necessary expertise is available to analyze,

design, code, install, operate, and maintain the system. Technical feasibility

addresses the possibility and desirability of a computer solution in the

problem area. Assessments can be made based on many factors — for

example, knowledge of current and emerging technical solutions,

availability of technical personnel on staff, working knowledge of technical

staff, capacity of the proposed system to meet requirements, and capacity of

the proposed system to meet performance requirements.

Một hệ thống máy tinh cần phải dễ phát triển va bảo trì. Điều quan

trọng la phải có các chuyên môn cần thiết để phân tich, thiết kế, lập trình,

cai đặt, vận hanh, va duy trì hệ thống. Tinh khả thi trong kỹ thuật nói đến

khả năng va yêu cầu của một giải pháp máy tinh trong lĩnh vực liên quan

đến vấn đề. Đánh giá có thể đƣợc thực hiện dựa trên nhiều yếu tố - vi dụ,

kiến thức sẵn có va giải pháp kỹ thuật đang phát triển, đội ngũ kỹ thuật,

kiến thức chuyên nghanh của đội ngũ kỹ thuật, khả năng đáp ứng nghiệp vụ

của hệ thống đƣợc đề xuất, va năng suất của hệ thống đƣợc đề xuất.





Developing new technology will need to take into account the

current technology. Will today‘s technology be able to sustain what we plan

to develop? How realistic is the project? Do we have the now ledge and

tools needed to accomplish the job? Emerging technology is getting more

and more advanced with each passing day; somehow we need to know if

our objectives can be realized. It is not enough to note if the product in

development is technologically feasible, we also must make sure that it is at

par with or more advanced than technology in use today.

Phát triển các công nghệ mới cần phải xem xét công nghệ hiện hanh.

Công nghệ hiện nay có chấp nhận những gì chúng ta sắp phát triển hay

không? Tinh thực tế của dự án? Chúng ta có kiến thức va công cụ cần thiết

để thực hiện công việc hay không? Công nghệ ngay cang phát triển; chúng

ta cần phải biết mục tiêu của chúng ta có thể đƣợc thực hiện không. Cần lƣu

ý rằng nếu các sản phẩm đang phát triển la khả thi về công nghệ, chúng ta

cũng phải đảm bảo rằng nó ngang bằng hoặc cao hơn so với công nghệ hiện

tại.

Key risk issues:

Project staff skills and clarity of project design requirements —

technical risk is reduced where similar problems have been solved

or where the design requirements are understandable to all project

participants.





Proven and accepted equipment and software — tried and tested

hardware and software components carry lower risk. Projects that

are novel or break new ground carry higher risk.

Project complexity — a project that requires a high degree of

technical skills and experience will be a higher-risk undertaking

than one that is not as sophisticated and can be handled by less

specialized people.


Kỹ năng của nhân viên dự án va sự rõ rang của các yêu cầu thiết kế

dự án – các khó khăn về mặt kỹ thuật khi ma những vấn đề tƣơng

tự đã đƣợc giải quyết hoặc các nhân viên dự án đều hiểu những yêu

cầu về thiết kế.

Trang thiết bị va phần mềm đã đƣợc chấp nhận- thử nghiệm thì

mang rủi ro thấp hơn. Dự án không thực tế hoặc không có nền tảng

có nguy cơ cao hơn.

Mức độ phức tạp của dự án - một dự án đòi hỏi một mức độ cao về

kỹ năng va kinh nghiệm về mặt kỹ thuật sẽ có rủi ro cao hơn dự án

không quá phức tạp va có thể đƣợc xử lý bởi it ngƣời chuyên

ngành.





2.1.3 Tinh khả thi về tổ chức, điều hanh

A systems development project should meet the needs and

expectations of the organization. It is important that the system be accepted

by the user and be operational. The following requirements should be taken

into consideration in determining if the system is operationally feasible:

staff resistance or receptiveness to change, management support for a new

system, nature or level of user involvement, direct and indirect impact of

new system on current work practices, anticipated performance and

outcome of the new system compared to the old system, and viability of

development and implementation schedule. The following issues should

also be addressed:

Does the organization for which the information system is to be

supplied have a history of acceptance of information technology or

haspast introduction led to conflict?

Will personnel within the organization be able to cope with

operating the new technology?

Is the organizational structure compatible with the proposed

informationsystem?

Một dự án phát triển hệ thống cần đáp ứng nhu cầu va sự mong đợi

của tổ chức. Điều quan trọng la hệ thống đƣợc chấp nhận bởi ngƣời sử dụng





va đƣợc hoạt động. Các yêu cầu sau đây sẽ đƣợc đƣa vao xem xét trong

việc xác định hệ thống có khả thi để sử dụng hay không: tinh bảo thủ của

nhân viên, hỗ trợ quản lý cho một hệ thống mới, tinh chất hoặc mức độ

tham gia của ngƣời dùng, tác động trực tiếp va gián tiếp của hệ thống mới

vao thực tiễn công việc hiện tại, hiệu suất dự đoán va kết quả của các mới

hệ thống mới so với hệ thống cũ, va khả năng phát triển va tiến độ thực

hiện. Các vấn đề sau cũng cần đƣợc giải quyết:

Liệu các tổ chức ma hệ thống sẽ đƣợc cung cấp có một lịch sử

xung đột nao hay không?

Liệu nhân lực trong tổ chức có thể lam việc với công nghệ mới?

Cơ cấu tổ chức của tổ chức tƣơng thich với các hệ thống đƣợc đề

xuất?

Key risk issues:

User acceptance — the more strongly the users support the project,

the less risk of failure.

Changes to organizational policies and structure — the more a

project influences changes to relationships within an organization

or modifies existing policies, the greater the risk.





Changes to method of operation, practices, and procedures — the

more a project necessitates major changes or modifications to

standard operating procedures in an organization, the greater the

likelihood of risk.


Sự chấp nhận của ngƣời dùng –sự hỗ trợ của ngƣời sử dụng cho dự

án cang mạnh mẽ, rủi ro thất bại cang it.

Thay đổi chinh sách va cơ cấu tổ chức – dự án thay đổi mối quan

hệ trong tổ chức hoặc thay đổi chinh sách hiện tại cang nhiều, thì

nguy cơ cang nhiều.

Thay đổi phƣơng thức hoạt động, thực hanh, va các thủ tục - một

dự án thay đổi các hoạt động chinh hoặc sửa đổi thủ tục tiêu chuẩn

trong một tổ chức cang nhiều, khả năng rủi ro cang lớn.

Depending upon the scope of the software to be developed,

organization feasibility might require the following analyses, particularly if

the software being developed is a product that will be introduced to the

marketplace:

Competitive analysis refers to the study of the current trends and

different brand names available in today‘s market to enforce

competitive advantage in product development.





New product development analysis is a key factor in feasibility

studies;it studies the need for and uniqueness of a product,

justifying further study, development, and subsequent launching.

Performance tracking analysis evaluates how well a product will

perform technically and financially in relation to its features and

requirements.

Tuỳ thuộc vao phạm vi của phần mềm đƣợc phát triển,tinh khả thi

cho một tổ chức có thể đòi hỏi những phân tich sau đây, đặc biệt la nếu

phần mềm đang đƣợc phát triển la một sản phẩm sẽ đƣợc giới thiệu với thị

trƣờng

Phân tich cạnh tranh đề cập đến việc nghiên cứu các xu hƣớng hiện

tại va các thƣơng hiệu khác nhau có sẵn trên thị trƣờng hiện nay để

thực thi lợi thế cạnh tranh trong phát triển sản phẩm.

Phân tich phát triển sản phẩm mới la yếu tố then chốt trong nghiên

cứu khả thi; nó nghiên cứu sự cần thiết va tinh độc đáo của một sản

phẩm, chứng minh thêm về các hoạt động nghiên cứu, phát triển,

va tung ra thị trƣờng.

Phân tich hiệu suất đánh giá một sản phẩm sẽ thực thi về mặt kỹ

thuật va tai chinh trong mối liên quan đến các tinh năng va các yêu

cầu của nó nhƣ thế nao.





Competitive Analysis. How does your product or service measure

up to the competition? What is your market share? Is there room for

growth? Web sites can be visited, marketing literature reviewed, and

financial reports analyzed. Surveys can be developed to figure out the

competition and how the product will be needed. Surveys are an important

source of information on market needs and user expectations. In

competitive analysis, the market is evaluated as well

as the market standing value of existing products. Quantitative

research is also useful in anticipating market changes and foreseeing how

the competition will react.

Phân tich cạnh tranh. Lam thế nao để sản phẩm hoặc dịch vụ của

bạn cạnh tranh? Thị phần của bạn la gì? Có khoảng trống nao cho sự phát

triển? Các trang web có thể truy cập, đọc các văn bản tiếp thị va phân tich

báo cáo tai chinh. Các cuộc khảo sát có thể đƣợc phát triển để tìm ra tinh

cạnh tranh va lam thế nao sản phẩm sẽ đƣợc sử dụng. Những cuộc điều tra

la một nguồn thông tin quan trọng về nhu cầu thị trƣờng va kỳ vọng của

ngƣời dùng. Trong phân tich thị trƣờng cạnh tranh, thị trƣờng đƣợc đánh

giá nhƣ la giá trị thị trƣờng của sản phẩm hiện có. Định lƣợng nghiên cứu la

cũng hữu ich trong việc thay đổi thị trƣờng đã đƣợc dự đoán va dự báo

trƣớc những sự cạnh tranh.

New Product Development. The first goal in launching a new

product is to identify a need. What will the software offer that is not offered





right now in existing products? Are businesses, schools, or personal

consumers interested in such a product? A feasibility study will allow an

organization to find the right niche for products. The feasibility study also

helps evaluate the market for growth, cost, and longevity of the product.

This gives the company a chance to tweak a product before it is

manufactured and subsequently launched.

Phát triển sản phẩm mới. Mục tiêu đầu tiên khi tung ra thị trƣờng

một sản phẩm mới la xác định nhu cầu. Phần mềm cung cấp những gì ma

chƣa đƣợc trong các sản phẩm hiện hanh?Các doanh nghiệp, trƣờng học,

hoặc cá nhân ngƣời tiêu dùng sẽ quan tâm đến sản phẩm? Một nghiên cứu

khả thi sẽ cho phép một tổ chức tìm chỗ đứng cho sản phẩm. Các nghiên

cứu khả thi cũng giúp đánh giá sự tăng trƣởng, chi phi, va tuổi thọ của sản

phẩm. Điều nay tạo cho công ty một cơ hội để tinh chỉnh một sản phẩm

trƣớc khi nó đƣợc sản xuất va tung ra thị trƣờng.

Performance Tracking. There are many factors to consider when

evaluating the market share of a product. Profits and sales certainly reflect

customer acceptance, but true results can be known only when you evaluate

brand awareness as well as consumer attitudes and satisfaction. Equally

important to a healthy business are the people who make it happen. What is

the morale within your company? Are your employees performing at their

best? It is important to evaluate a company‘s internal and external behavior

vis-à-vis the prospective end users of the product. If it is internal, will

employees see the need to implement totally new software and thus relearn





operations or will it hinder them from cooperating for fear that technology

might replace them?

Theo dõi hiệu suất. Có rất nhiều yếu tố cần xem xét khi đánh giá thị

phần của sản phẩm. Lợi nhuận va doanh thu chắc chắn phản ánh sự chấp

nhận của khách hang, nhƣng kết quả thật chỉ đƣợc biết đến khi bạn đánh giá

mức độ của thƣơng hiệu cũng nhƣ thái độ va sự hai lòng của ngƣời tiêu

dùng. Một điều cũng quan trọng đối với một doanh nghiệp lam ăn tốt la

những ngƣời lam việc. Tinh thần lam việc trong công ty của bạn la gì?

Nhân viên của bạn có thể hiện hết đƣợc khả năng của họ hay không? Điều

quan trọng để đánh giá nội bộ va ngoại giao của một công ty la ngƣời sử

dụng tƣơng lai của sản phẩm. Nếu đó la nội bộ, nhân viên có thấy đƣợc sự

cần thiết để học va sử dụng phần mềm hoan toan mới, hoặc nó sẽ cản trở họ

từ hợp tác vì quan ngại rằng công nghệ có thể thay thế họ?

2.2 PHÂN TÍCH CHI PHÍ/LỢI NHUẬN

One of the major deliverables of the feasibility study is the

cost/benefit analysis. In this document the organizational, financial, and

technical aspects of creating the software are put into a dollars and cents

format. Appendix D (sample cost/benefit analysis worksheets) provides a

good framework for this analysis.

Một trong những phần chinh của nghiên cứu tinh khả thi la phân tich

chi phi / lợi nhuận. Trong tai liệu nay những mặt tổ chức, tai chinh, va kỹ





thuật của việc tạo ra các phần mềm đƣợc đƣa vao mô hình giữa đô la xu.

Phụ lục D (mẫu bảng phân tich chi phi/lợi nhuận) cung cấp một khuôn mẫu

tốt cho việc phân tich nay.

The purpose of this analysis is to determine whether the costs

exceed the benefits of the new or modified system. Costs associated with a

computer project can be categorized as follows:

Systems analysis and design

Purchase of hardware

Software costs

Training costs

Installation costs

Conversion and changeover costs

Redundancy costs

Operating costs, including people costs

Mục đich của phân tich nay la để xác định xem các chi phi có vƣợt

quá những lợi ich của hệ thống mới hoặc đƣợc sửa đổi hay không. Chi phi

liên quan với một dự án máy tinh có thể đƣợc phân loại nhƣ sau:





Hệ thống phân tich va thiết kế

Mua phần cứng

Chi phí phần mềm

Chi phi đao tạo

Chi phi cai đặt

Chi phi chuyển đổi

Chi phi điều hanh, bao gồm cả chi phi nhân lực

Many specific costs are subcategorized within these categories; for

example: analyst calculations of total cost of project, alternatives to

purchasing hardware, staff needed to train users, maintenance costs for

hardware and software, costs of power and paper, and costs associated with

personnel to operate the new system. A more detailed list includes:

Equipment — disk drives, computers, telecommunications, tape

drives, printers, facsimiles, voice and data networks, terminals,

modems, data encryption devices, physical firewalls (leased or

purchased)

Software — application programs, operating systems, diagnostic

programs, utility programs, commercial off-the-shelf (COTS)





software such as word processors and graphics programs, database

management software, communications software, server software

(leased or purchased)

Commercial services — teleprocessing, cell phones, voice mail,

online processing, Internet access, packet switching, data entry,

legal services

Support services — systems analysis and design, programming,

training, planning, project management, facilities management,

network support

Supplies — CDs, tapes, paper, pens, pencils, CD-ROMs, etc.

Personnel — salary and benefits for all staff involved, usually

calculated at a rate of 30 percent of the base salary

Nhiều chi phi cụ thể đƣợc phân nhóm trong các loại nay, vi dụ nhƣ:

các tinh toán của các nha phân tich về tổng chi phi của dự án, lựa chọn phần

cứng, nhân viên cần thiết để hƣớng dẫn ngƣời sử dụng, chi phi bảo trì phần

cứng va phần mềm, chi phi điện va giấy, va các chi phi liên quan đến nhân

sự để vận hanh hệ thống mới. Một danh sách chi tiết hơn bao gồm:

Trang thiết bị: ổ đĩa, máy tinh, viễn thông, băng ổ đĩa, máy in, fax,

mạng thoại va dữ liệu, thiết bị đầu cuối, modem, các thiết bị mã

hóa dữ liệu, tƣờng lửa vật lý (thuê hoặc mua).





Phần mềm: chƣơng trình ứng dụng, hệ điều hanh, chƣơng trình

chẩn đoán, các chƣơng trình tiện ich, thƣơng mại off-the-shelf

(Cots) các phần mềm nhƣ bộ xử lý đồ họa từ va các chƣơng trình,

phần mềm quản lý cơ sở dữ liệu, truyền phần mềm, phần mềm máy

chủ (cho thuê hoặc mua).

Thương mại dịch vụ: điện thoại di động teleprocessing, thƣ thoại,

trực tuyến xử lý, truy cập Internet, chuyển mạch gói dữ liệu, nhập

dữ liệu, dịch vụ pháp lý.

Hỗ trợ các dịch vụ: phân tich hệ thống va thiết kế, lập trình, đao

tạo, quy hoạch, quản lý dự án, các cơ sở quản lý, hỗ trợ mạng.

Dụng cụ: đĩa CD, băng, giấy, bút mực, bút chì, đĩa CD-ROM, vv.

Nhân sự: tiền lƣơng va lợi ich cho tất cả các nhân viên tham gia,

thƣờng đƣợc tinh theo tỷ lệ 30% của lƣơng cơ bản.

It is important that the benefits outweigh the costs. Some of the

benefits cannot necessarily be measured, but nevertheless should be taken

into consideration. Some of those benefits are intangible such as savings in

labor costs, benefits due to faster processing, better decision making, better

customer service, and error reduction. It may be difficult to determine

benefits and costs in advance.





Điều quan trọng la những lợi nhuận phải lớn hơn chi phi. Một số lợi

nhuận có thể không nhất thiết phải đƣợc tinh toán, nhƣng vẫn cần đƣợc cân

nhắc. Một số lợi nhuận khó đong đếm nhƣ la tiết kiệm chi phi lao động, lợi

ich do xử lý nhanh hơn, tốt hơn cho việc ra quyết định, dịch vụ khách hang

tốt hơn, va giảm lỗi. Có thể rất khó để xác định lợi nhuận va chi phi trƣớc.

Cost information can be obtained from:

Experiences from the past. Old documents and information will be

useful in getting some ideas about the cost of software, hardware,

and each service. Invoices for expenses for resources purchased for

prior projects are particularly useful.

Costs from the market. It is also important to get the price from the

current market for your software system.

Publishing. Business and trade publications and the Internet are

another source of price information as well as product

functionality.

Personal experience. End users and system staff might have

relevant information on costs and product feature sets.

Thông tin về chi phi có thể đƣợc biết từ:





Kinh nghiệm: Tai liệu cũ va thông tin sẽ hữu ich trong việc một số

ý tƣởng về chi phi của phần mềm, phần cứng, va mỗi dịch vụ. Hoá

đơn chi phi tai nguyên cho các dự án trƣớc đặc biệt hữu dụng.

Giá cả thị trường cũng quan trọng để hệ thống phần mềm của bạn

có đƣợc mức giá từ thị trƣờng hiện tại.

Xuất bản: Các ấn bản về thƣơng mại về kinh doanh, Internet cũng

la một nguồn thông tin về giá cũng nhƣ các chức năng của sản

phẩm.

Kinh nghiệm cá nhân. Ngƣời sử dụng cuối cùng va nhân viên hệ

thống có thể có thông tin liên quan về chi phi va tinh năng sản

phẩm.

2.3 LẬP KẾ HOẠCH NGHIÊN CỨU TÍNH KHẢ THI

Creating a schedule for the feasibility study is very important in that

it puts into perspective the amount of time required, people involved,

potential consumers, and competition that will provide the relevant

information. Tasks include selecting a team, assigning appropriate tasks to

each team member, and estimating the amount of time required to finish

each task. Some of the scheduling tools that can be utilized are diagrams

showing relevant work scheduling in relation to the tasks required to finish





the feasibility study. Some of these use a table as shown below, a Gantt

chart (Exhibit 2-1), or a PERT diagram (Exhibit 2-2), which is represented

by a network of nodes and arrows that are evaluated to determine the

project‘s critical activities. Precedence of activities is important in

determining the length of the project when using a PERT diagram.

Tạo một lịch trình cho việc nghiên cứu khả thi la rất quan trọng, nó

liên quan đến lƣợng thời gian cần thiết, những ngƣời liên quan, khách hang

tiềm năng, va sự cạnh tranh. Công việc bao gồm lựa chọn một nhóm, giao

nhiệm vụ thich hợp cho mỗi thanh viên, va ƣớc tinh số lƣợng thời gian cần

thiết để hoan thanh mỗi nhiệm vụ. Những công cụ lập kế hoạch có thể đƣợc

sử dụng la biểu đồ, thể hiện các việc liên quan đến các nhiệm vụ cần thiết

để hoan thanh việc nghiên cứu tinh khả thi. Có thể sử dụng bảng nhƣ dƣới

đây, một biểu đồ Gantt (hình 2-1), hoặc một sơ đồ Pert (hình 2-2), đƣợc thể

hiện bởi một mạng của các nút va mũi tên ma đƣợc dùng để xác định các

hoạt động quan trọng của dự án. Độ ƣu tiên của các hoạt động la rất quan

trọng trong việc xác định số lƣợng công việc của dự án khi sử dụng một sơ

đồ Pert.





2.4 QUY TRÌNH NGHIÊN CỨU TÍNH KHẢ THI

A feasibility study should follow a certain process. It should analyze

the proposed project and produce a written description, define and

document possible types of systems, and develop a statement of the

probable types of systems. The feasibility study should analyze the costs of

similar systems, produce a rough estimate of the system size, costs, and

schedules, and define the benefits of the system. It should produce an

estimate of the next stage of the life cycle. Analysis of the current system is

necessary in order to establish feasibility of a future technical system. This

will provide evidence for the functions that the new system will perform.

Finally, a report should be written containing suggestions, findings, and

necessary resources (Sauter, 2000)





Một nghiên cứu khả thi nên thực hiện theo một quy trình nhất định.

Ta nên phân tich đề xuất dự án va lập ra một mô tả bằng văn bản, xác định

va tai liệu hóa các loại hệ thống có thể có, va chỉ ra các loại hình có thể xảy

ra của hệ thống. Các nghiên cứu khả thi nên phân tich chi phi hệ thống, ƣớc

tinh sơ bộ kich thƣớc của hệ thống, chi phi, va thời gian, va xác định các lợi

ich của hệ thống. Điều đó cho ra một ƣớc tinh của các giai đoạn tiếp theo

của chu kỳ. Phân tich hệ thống hiện có la cần thiết để thiết lập tinh khả thi

của một hệ thống kỹ thuật trong tƣơng lai. Điều nay sẽ cung cấp cơ sở cho

những chức năng ma hệ thống mới sẽ thực hiện. Cuối cùng, cần viết một

báo cáo bằng văn bản về các đề nghị, kết quả, va các nguồn lực cần thiết

(Sauter, 2000).

A feasibility report will be written and submitted to management

containing all relevant information, including financial expenses and

expected benefits as shown in Exhibit 2-3. Based on this report,

management will make its determination about the future of the project.

Much of the information will come from the analyst and the systems

investigation. The report should include information on the feasibility of the

project, the principal work areas for the project, any needs for specialist

staff that may be required at later dates, possible improvements or potential

savings, costs and benefits, as well as recommendation. Charts and

diagrams relative to the project, such as Gantt and Pert charts, should be

included in the feasibility report. Obviously, the project cannot proceed

until the feasibility report has been accepted.





Một báo cáo khả thi sẽ đƣợc viết va nộp cho quản lý với tất cả các

thông tin liên quan, bao gồm chi phi tai chinh va lợi ich dự kiến nhƣ trong

hình 2-3. Căn cứ vao báo cáo nay, quản lý sẽ đƣa ra quyết định về tƣơng lai

của dự án. Phần lớn các thông tin sẽ đến từ các nha phân tich va điều tra các

hệ thống.Báo cáo phải bao gồm các thông tin về tinh khả thi của dự án, lĩnh

vực lam việc chinh cho dự án, các chi tiết cho các chuyên gia có thể sẽ cần

đến sau nay, cải tiến có thể có hoặc những khoảng tiết kiệm tiềm năng, chi

phi va các quyền lợi, cũng nhƣ khuyến nghị. Bảng xếp hạng va biểu đồ liên

quan đến các dự án, nhƣ bảng xếp hạng Gantt va Pert, nên đƣợc bao gồm

trong các báo cáo tinh khả thi. Rõ rang la, các dự án không thể tiến hanh

cho đến khi các báo cáo đã đƣợc chấp nhận.

2.4.1 Xác định tinh khả thi

A proposal may be regarded as feasible if it satisfies the three criteria

discussed at length earlier: financial, technical, and operational. Scheduling

and legal issues must also be considered (Burch, 2000). It is possible to

proceed with the project even if one or more of these criteria fail to be met.

For example, management may find that it is not possible to proceed with

the project at one point in time but that the project can commence at a later

date. Another option would be for management to make amendments to the

proposed agenda and agree to proceed upon those conditions. Conversely, a

project that may have been determined feasible may later be determined

infeasible due to changes in circumstances.





Các đề xuất có thể đƣợc coi la khả thi nếu đáp ứng ba tiêu chi đã

đƣợc thảo luận ở trên: tai chinh, kỹ thuật, va hoạt động. Thời gian biểu va

các vấn đề pháp lý cũng phải đƣợc xem xét (Burch, 2000). Có thể tiến hanh

các dự án ngay cả khi một hoặc một số các tiêu chi nay không đƣợc đáp

ứng. Vi dụ, quản lý có thể thấy rằng không thể để tiến hanh các dự án tại

một thời điểm ma dự án có thể bắt đầu vao sau đó. Một lựa chọn khác để

quản lý việc sửa đổi vao chƣơng trình nghị sự đề xuất va đồng ý để tiến

hanh dựa trên các điều kiện. Một dự án đã đƣợc xác định có tinh khả thi sau

nay có thể không còn khả thi nữa do các điều kiện thay đổi.

2.4.2 Những đánh giá khác

When dealing with many kinds of projects, costs and benefits are

usually the main concerns. Other concerns, however, should be considered.

Project timeframes should also be addressed in the feasibility study;

realistic estimates should be made detailing staff resources and time

required to complete the different phases of the project. In dealing with the

project, it is also important to consider all legal or regulatory issues that

may occur throughout the feasibility or any stage of the project. It may be

wise to conduct a preliminary investigation of any obligations and

regulatory or legal issues prior to commencement of the initial project

stages.

Khi lam việc với nhiều loại dự án khác nhau, chi phi va lợi ich

thƣờng la những vấn đề chinh. Những vấn đề khác, tuy nhiên, cũng cần





đƣợc xem xét. Khung thời gian dự án cũng nên đƣợc để tâm trong các

nghiên cứu khả thi; những ƣớc lƣợng thực tế cần đƣợc thực hiện chi tiết dựa

vao các nguồn lực nhân viên va thời gian cần thiết để hoan thanh giai đoạn

khác nhau của dự án. Trong khi lam việc với dự án, cũng rất quan trọng để

xem xét tất cả các quy phạm pháp luật hoặc các vấn đề pháp lý có thể xảy

ra trong tất cả các giai đoạn của việc nghiên cứu tinh khả thi. Nó có thể

khôn ngoan để tiến hanh một cuộc điều tra sơ bộ của bất kỳ nghĩa vụ va các

vấn đề pháp lý hay pháp lý trƣớc khi bắt đầu ban đầu dự án giai đoạn.





2.4.3 Các công đoạn nghiên cứu tinh khả thi

Robinson (2002) has neatly summarized the stages of a feasibility

study(Exhibit 2-4):

1. Define project scope

2. Perform activity analysis

3. Perform needs analysis

4. Conduct conceptual modeling

5. Use case modeling

6. Identify nonfunctional requirements

7. Identify options





8. Select options

9. Plan acquisition strategy

10. Develop business case

11. Conduct package feasibility study

Robinson (2002) đã tóm tắt các giai đoạn của một nghiên cứu khả thi

(Exhibit 2-4):

1. Xác định phạm vi dự án

2. Thực hiện phân tich

3. Thực hiện phân tich nhu cầu

4. Mô hình hóa các khái niệm

5. Mô hình hóa các trƣờng hợp

6. Xác định các yêu cầu không có tinh ham

7. Xác định các tuỳ chọn

8. Chọn lựa chọn

9. Xác định chiến lƣợc để đạt đƣợc mục tiêu.





10. Phát triển các trƣờng hợp kinh doanh

11. Tiến hành các gói nghiên cứu tính khả thi

2.5 KẾT LUẬN

The primary goal of the feasibility study is to evaluate the risks,

benefits, and potential of a proposed project. We also know that the study

should aid in producing a solid plan for the research stage and stages to

follow so that the project will be given careful consideration and be

properly funded. According to Burch (2000), a feasibility study will help

you make informed and transparent decisions at crucial points during the

developmental process to determine whether it is operationally,

economically, and technically realistic to proceed with a particular course

of action. It should provide a means of minimizing risks, clarifying issues

and expectations, and improving the decision making process and the stages

to follow.

Mục đich chinh của việc nghiên cứu tinh khả thi la đánh giá những

khó khăn, thuận lợi va tiềm năng của một dự án. Chúng ta cũng đã biết rằng

việc nghiên cứu nên hỗ trợ trong việc lập một kế hoạch vững chắc cho các

công đoạn nghiên cứu va các bƣớc để dự án đƣợc xem xét cẩn thận va đƣợc

tai trợ xứng đáng. Theo Burch (2000), một nghiên cứu tinh khả thi sẽ giúp

bạn có những dự báo va đƣa ra những quyết định minh bạch tại các thời

điểm quan trọng trong quá trình phát triển của dự án để xác định xem nó có





tinh thực tiễn trong thực tế hoạt động, kinh tế, va kỹ thuật với một tập các

thao tác hay không. Nó nên cung cấp một phƣơng tiện để giảm thiểu rủi ro,

làm rõ các vấn đề va sự mong đợi, va cải thiện việc ra quyết định xử lý va

các giai đoạn cần lam.

Tham khảo va đọc thêm:

1. Allen, G.W. (1998). The position of the feasibility study in project

management,(Online)Available:

http://www.dis.port.ac.uk/~allangw/papers/feas-stu.htm.

2. Anonymous. (1996). Feasibility study and initial assessment, (Online)

Available: http://cygnus.uwa.edu.au/~belle/ScafEng/feasibil.htm.

3. Burch, J. G. (2000). Designing and implementing record keeping

systems,(Online).Available:

http://www.records.nsw.gov.au/publicsector/DIRKS/exposure_draft/fea

sibility_analysis.htm.

4. Curtis, G., Hoffer, J., George, J., and Valacich, J. (2000). Introduction

to Business Systems Analysis, Pearson Custom Publishing, Boston, 17,

19, 23, 25–229.

5. Kendall, K.E. and Kendall, J.E. (1999). Systems Analysis and Design,

4th ed., Prentice Hall, New York, 54–68.





6. Putnam, L. and Myers, W. (1997). How solved is the cost estimation

problem? IEEE Software,14(6), 105–107.

7. Pressman, R.S. (2001). Software Engineering: a PractitionerÕs

Approach, 5th ed., McGraw Hill,New York, 117–118.

8. Robinson, P. (2002). Lyonsdale systems. Feasibility study, (Online)

Available: http://members.iinet.net.au/~lonsdale/bm/bm21.htm.

9. Sauter, V. (2000). The feasibility study, (Online) Available:

http://www.umsl.edu/~sauter/analysis/deliverables.htm.


http://www.umsl.edu/~sauter/analysis/deliverables.htm




CHƢƠNG 3 LÊN DỰ ÁN CHO KẾ HỌACH

PHẦN MỀM

Người dịch:

1. Nguyễn Tƣờng Minh

2. Nguyễn Quang Anh

3. Nguyễn Minh Hùng

4. Nguyễn Tiến Vũ

5. Nguyễn Bá Huy





In the beginning there was just code and nothing but code. The art of

software engineering was just a blip on the horizon and project planning did

not even have a name. In the early days of software development, one

person could carry out the whole process of requirement collection,

analysis, designing, development, testing, and maintenance by himself. Of

course, he did not recognize these processes as independent steps with the

names I have used.

Trong những ngay đầu, nganh công nghệ phầm mềm chỉ tập trung

vao việc viết code, không tập trung vao các việc khác. Các vấn đề nhƣ lên

kế hoạch cho dự án đƣợc cho la vấn đề nhỏ va cũng chƣa đƣợc quan tâm

đúng mức. Lúc nay, một ngƣời có thể lo toan bộ các phần trong qui trình

phát triển phầm mềm nhƣ thu thập yêu cầu, phân tich, thiết kế, kiểm chứng,

va bảo trì. Dĩ nhiên la ngƣời nay chƣa nhận ra đƣợc sự độc lập giữa các

bƣớc với các tên gọi của từng bƣớc nhƣ chúng ta gọi ngay nay.

As computers became ubiquitous software engineering, the ―policies

and procedures‖ of developing computer systems became an important -

and organized — discipline. Project planning became an indispensable part

of software engineering.

Sự phát triển của máy tinh cá nhân giúp nganh công nghệ phầm mềm

ngay cang trở nên phổ biến. Các bƣớc trong việc phát triển một phầm mềm

dần đƣợc chuyên biệt hóa va đƣợc tổ chức chặt chẽ. Việc lên kế hoạch cho





dự án cũng trở thanh một bƣớc không thể thiếu trong qui trình phát triển

phần mềm.

The project plan is the roadmap that details all of the components of

a software engineering effort. It is a work product generated by the

planning tasks in a software engineering process that contains detailed

information about budgets, schedules, and processes. It necessarily

addresses a broad audience, including management, staff, and customers.

For this purpose it should be comprehensive but concise.

Kế hoạch của dự án la một ―bản đồ‖ hoạch định chi tiết mọi thanh

phần trong khi phát triển phần mềm. Nó bao gồm các thông tin chi tiết về

ngân quĩ, lịch trình va các bƣớc xử lý. Đồng thời việc lên kế hoạch cho dự

án cũng liên quan đến nhiều đối tƣợng nhƣ ngƣời quản lý, hội đồng va cả

khách hang. Do vậy việc lên kế hoạch phải đƣợc quan tâm đúng mức.

3.1 TẠI SAO PHẢI LÊN KẾ HOẠCH CHO DỰ ÁN

Projects often go awry. A China Airlines Airbus took off from Taipei

International Airport on April 26, 1994, and continued flying according to

its flight plan. While approaching Nagoya Airport for landing, the aircraft

crashed. On board were 271 persons: 256 passengers (including 2 infants)

and 15 crew members, of whom 264 persons (249 passengers including 2

infants and 15 crew members) were killed and 7 seriously injured. The

aircraft ignited and was destroyed.





Các kế hoạch thƣờng đƣợc triển khai không nhƣ mong đợi. Một máy

bay Aibus của hãng hang không Trung Quốc hạ cánh xuống sân bay cuối tế

Đai Loan vao 26/4/1994. Sau đó nó lại tiếp tục bay theo lịch trình. Khi sắp

hạ cánh xuống sân bay Nagoia, máy bay bị rơi. Trên máy bay có 271 ngƣời

gồm 256 hanh khách (trong đó có 2 trẻ nhỏ) va 15 phi hanh đoan thì 264 đã

chết (gồm 249 hanh khách va 15 phi hanh đoan), 7 ngƣời bị thƣơng nặng.

Máy bay cũng bị phá hủy hoan toan.

While the aircraft was making an approach under manual control by

the flight officer, he inadvertently activated the GO lever, which caused the

FD (flight director) to GO AROUND mode and caused a thrust increase.

This made the aircraft deviate above its normal glide path, which, in turn

led to 48 SOFTWARE ENGINEERING HANDBOOK the chain of events

that ultimately caused the airplane to stall and then crash.

Nguyên nhân la khi máy bay sắp hạ cánh va đƣợc điều khiển bằng

tay bởi cơ trƣởng, anh ta vô tình tăng tốc cho máy bay, điều nay lam máy

bay bay chệch hƣớng khỏi đƣờng băng đƣợc định sẵn dấn đến việc máy bay

gặp tai nạn.

Computers are increasingly being introduced into safety-critical

systems and, as a consequence, have been involved in more than a few

accidents. Some of the most widely cited software-related accidents in

safetycritical systems have involved a computerized radiation therapy

machine called the Therac-25. Between June, 1985, and January, 1987, six





known accidents involved massive overdoses by the Therac-25 — with

resultant deaths and serious injuries. They have been described as the worst

series of radiation accidents in the 35-year history of medical accelerators.

Máy tinh đang đƣợc sử dụng trong nhiều hệ thống tự động đƣợc cho

la an toan. Tuy nhiên nó cũng ngay cang góp mặt nhiều trong các vụ tai nạn

ma nguyên nhân chinh la do sự hoạt động của hệ thống máy tinh bị sai sót.

Các sai sót này có thể tránh đƣợc bằng cách phát triển va kiểm chứng phần

mềm một cách kỹ lƣơng. Việc định hƣớng sản xuất một phần mềm có chất

lƣợng sẽ không thể thanh công nếu bỏ qua việc lên kế hoạch cho dự án.

Software disasters like these could have been avoided had the

software been designed and tested properly. Productivity and quality

oriented software design cannot be accomplished without adequate project

planning. A realistic project plan must be developed at the beginning of a

project. It must be monitored during the project and modified, if necessary.

Ultimately, a project plan is a vehicle and focal point that enables the

project manager to carry out all sorts of project management activities. It

provides a roadmap for a successful software project.

Việc lên kế hoạch cho dự án phải đƣợc lam đầu tiên khi triển khai dự

án. Nó cần đƣợc tuân thủ chặt chẽ va có thể sửa chữa nếu thấy cần thiết.

Các kế hoạch giúp cho ngƣời quản lý nắm đƣợc mọi mặt trong việc phát

triển dự án. Nó vẽ ra con đƣờng chinh xác để dự án đƣợc thanh công.





3.2 AI LÊN KẾ HOẠCH CHO DỰ ÁN

The project manager or team leader normally writes the project plan,

although experienced consultants are often called in for this aspect of the

project. In truth, there are as many ways to write a project plan as there are

companies that write them. If the project is large, the proposed system

might be divided into subsystems — each with its own team. Each team

leader may need to write his own part of the project plan. The project

manager then compiles each subplan into a plan for the whole project.

Ngƣời quản lý hay lãnh đạo thƣờng la ngƣời lập kế hoạch cho dự án.

Các kinh nghiệm chuyên môn cũng giúp cho việc lên kế hoạch đƣợc hiệu

quả. Có nhiều cách để lên kế hoạch cho dự án. Thực tế thì có khá nhiều

cách để lên kế hoạch cho dự án, nếu dựa án đó lớn thì có thể chia nhỏ ra va

đƣợc giao cho từng nhóm riêng biệt, mỗi nhóm tự lên kế hoạch cho công

việc của mình. Ngƣời quản lý sau đó sẽ ghép từng dự án nhỏ riêng biệt lại

để thanh một dự án lớn.

Another alternative is to divide the project plan into discrete tasks

and parcel out the effort to team members. Appendix F contains a sample

project plan. As you can see from its table of contents, it is easily divisible.

Một cách khác la cũng có thể chi dựa án ra thanh các công việc rời

rạc va giao cho mỗi nhóm thực hiện một công việc nhất định.





3.3 ĐIỀU GÌ XẢY RA KHI LÊN KẾ HOẠCH CHO DỰ ÁN

Pressman (2001) has defined the prototypical project plan. A student

implementation of this guideline can be found in Appendix F; the reader is

directed there for a concrete example of how a project plan is orchestrated.

Fressman (2001) định nghĩa một mẫu cho việc lên kế hoạch cho dự

án. Ngƣời đọc có thể tham khảo thêm trong phụ lục F.

The first section introduces the system and describes its purpose. The

project scope and objectives need to be defined here. This subsection

containsa formal statement of scope, description of major functions,

concerns on performance issues, and a list of management and technical

constraints.

Phần đầu tiên la giới thiệu về hệ thống va mô tả mục đich của nó.

Phạm vi của dự án cũng nên đƣợc định nghĩa ở đây. Phần nay mô tả một

cách hình thức phạm vi, các chức năng chinh, các khó khăn có thể gặp phải

va các việc quản lý va kỹ thuật liên quan.

The second section discusses project estimates and resources.

Historical data used for estimates needs to be specified, as do estimation 49

techniques. As a result of the estimation process, the estimates of effort,

cost, and duration need to be reported here. Resources are required to be





discussed in terms of people and minimal hardware and software

requirements.

Phần hai nói về việc ƣớc lƣơng dự án va các tai nguyên. Các dữ liệu

giúp cho việc ƣớc lƣợng cần phải đƣợc chỉ rõ. Các ƣớc lƣợng về giá thanh

cũng phải đƣợc liệt kê ở bƣớc nay. Các tai nguyên dùng cần dùng nhƣ con

ngƣời, các hệ thống phần cứng, phần mềm cũng cần đƣợc chỉ rõ.

The third section discusses risk management strategy. A risk table

needs to be created at first, followed by more detailed discussions on

risks to be managed. Based on that, a risk mitigation, monitoring, and

management (contingency) plan needs to be created for each risk that has

been addressed.

Phần ba nói về việc quản lý rủi ro. Một bảng quản lý rủi ro phải đƣợc

lập trƣớc tiên. Dựa vao bảng nay, chi tiết về các lỗi sẽ đƣợc quản lý nhƣ

việc phát hiện lỗi, cách thức sửa chữa … sẽ đƣợc quản lý.

The fourth section is an actual project schedule in terms of

deliverables and milestones. A project work breakdown structure, or WBS,

needs to be created, followed by a task network and a timeline chart (Gantt

chart). In addition, a resource table describes the demand for and

availability of resources by time windows. In a WBS the total task is broken

down into series of smaller tasks. The smaller tasks are chosen based on





size and scope to fit in the management structure of the project. Therefore,

efficient planning and execution are possible.

Phần thứ tƣ nói về việc lên lịch trình cho dự án. Các phần nhỏ của dự

án phải đƣợc mô tả kỹ cang, đồng thời thời gian để thực hiện từng phần

cũng phải đƣợc chỉ rõ. Trong từng phần của dự án, các công việc lớn sẽ

đƣợc chia ra thanh các việc nhỏ hơn. Các việc nhỏ nay đƣợc chọn dựa vao

kich cơ va phạm vi của cấu trúc dự án.

The fifth section discusses staff organization. Usually a project is

carried out by a group of people and therefore a team structure needs to be

defined and a management reporting relationship specified.

Phần thứ năm nói về việc tổ chức quản lý. Thông thƣờng thì dự án

đƣợc điều khiển bởi một nhóm ngƣời, do vậy số lƣợng, nhiệm vụ của từng

ngƣời đối với các phần trong dự án cũng cần đƣợc nêu rõ trong phần nay.

The sixth section lays out a picture on tracking and control

mechanisms.It can be divided into two subsections: quality assurance and

control and change management and control.

Phần sáu nói về cơ chế quản lý va điểu khiển. Nó thƣờng gồm 2

phần la quản lý việc đảm bảo chất lƣợng va quản lý các thay đổi.

At the end of the project plan, all supporting materials that do not fit

into the body of the document can be attached in the appendices section.





Phần cuối cùng la các tai liệu đinh kèm cần thiết cho dự án.

Most project managers have a difficult time writing a project plan

because it is often required at project inception, which, unfortunately, is

when information is most scarce. The project manager must choose a

process model most appropriate for the project, and then define a

preliminary plan based on the set of common process framework activities.

The possible models include linear sequential model, prototyping model,

RAD model (Mantei, 1991), incremental model (McDermid and Rook,

1993), spiral model, etc. — many of which are described in other chapters

of this handbook. Afterward, process decomposition (partitioning) is carried

out, generating a complete plan reflecting the work tasks required to

populate the framework activities.

Hầu hết những ngƣời quản lý đều gặp khó khăn khi lên kế hoạch cho

dự án vì đây la công việc đầu tiên phải lam. Ma những thông tin cần thiết ở

bƣớc nay lại rất hạn chế. Ngƣời quản lý phải chọn một mẫu qui trình thich

hợp với dự án nhất sau đó đƣa ra các kế hoạch dựa vao các mẫu qui trình

nay. Các mô hình có thể tham khảo la mô hình chuỗi đƣờng thẳng, mô hình

mẫu, mô hình RAD (Mantei, 1991), mô hình tăng trƣởng ((McDermid and

Rook, 1993) …Tiếp sau đó la việc phân tich dự án, tich hợp các kế hoạch

với công việc chi tiết để hoan thanh dự án.





3.4 THE PROJECT PLAN UNWRAPPED

3.4.1 Mục đich của phần mềm

Determination of software scope needs to be ascertained first. One

establishes software scope by answering questions about context,

information objectives, function, performance, and reliability. The context

usually includes hardware, existing software, users, and work procedures.

Normally a system specification developed by a system analyst supplies the

information necessary to bind the scope.

Xác định rõ mục đich của phần mềm la việc cần phải lam đầu tiên.

Một ngƣời sẽ thiết lập mục đich của phần mềm bằng cách trả lời những câu

hỏi về phạm vi (context), thông tin khách quan (information objectives),

chức năng (function), thi hanh (performance), va mức độ tin cậy

(reliability). Phạm vi thƣờng bao gồm phần cứng (hardware), các software

đã có, ngƣời dùng (user) va các thủ tục lam việc (work procedure).Thông

thƣờng đặc điểm kỹ thuật một hệ thống (system specification) đƣợc phát

triển bởi hệ thống phân tich sẽ cung cấp những thông tin cần thiết để kết nối

với mục đich.

Techniques like question and answer sessions and FAST (facilitated

application specification techniques) can be used to gather requirements

and establish project scope (Zahniser, 1990).

The following is a minimum that needs to be ascertained:





Major functions are the customers‘ requirements as to what the

software should be able to do.

Performance issues are about speed, response time, and other

performance- related requirements. They can have serious impacts

on the requirement of effort and therefore should be clarified here.

Management and technical constraints should be listed as

foundation for the next section‘s estimation.

Các kỹ thuật nhƣ hỏi, trả lời va FAST (facilitated application

specification techniques) có thể dùng để thu thập yêu cầu va đƣa ra mục

đich phần mềm (Zahniser, 1990).

Ta phải xác định it nhất các yêu cầu sau:

Các chức năng chinh (major function) la những yêu cầu của ngƣời

dùng ma phần mềm cần phải thực hiện đƣợc.

Những vấn đề về thực thi (performance issue) nhƣ tốc độ, thời gian

đáp ứng (response time), va những yêu cầu liên quan đến thực thi

khác.Có thể có những tƣơng tác nghiêm trọng về mặt yêu cầu về

kết quả đạt đƣợc va vì vậy vấn đề nay cần đƣợc lam rõ ở đây.





Quản lý va các kỹ thuật thúc ép (management & technique

constrains) cần đƣợc liệt kê để lam nền tảng cho sự đánh giá ở các

bƣớc sau.

3.4.2 Đánh giá phần mềm

Estimation is the one activity that lays a foundation for all other

project planning activities. However, a project manager should not be

overly manic in estimation. If an iterative process model is adopted, it is

possible to revisit and revise the estimates when customer requirements

change.

Đánh giá la công việc đặt nền tảng cho tất cả các họat động lên kế

họach phần mềm khác. Tuy nhiên, ngƣời quản lý phần mềm không nên quá

chú trọng vao việc đánh giá.Nếu gặp một hình quá trình đã có trƣớc đây, ta

có thể lấy lại khi yêu cầu của ngƣời dùng thay đổi.

Historical Data Used for Estimates. Historical data is key to a good

estimation.The availability of reliable historical software metrics from

previous projects assists the project planner in translating the product size

estimation into effort, time and cost estimations. Baseline productivity

metrics (e.g., LOC (lines of code) or FP (function points)) should be stored

by project domain for use in future estimation efforts.





Những dữ liệu đã có dùng cho đánh giá: Những dữ liệu nay la chìa

khóa cho một đánh giá tốt. Sự có ich của những dữ liệu từ các project trƣớc

đây giúp cho ngƣời lập kế họach phần mềm trong việc chuyển đổi những

đánh giá về kich thƣớc phần mềm vao kết quả, thời gian va đánh giá chi

phi. Cách đánh giá chất lƣợng sản phẩm (LOC – Line of code hay FP-

function point,…) cần đƣợc lƣu trữ theo phạm vi project để sử dụng trong

việc đánh giá phần mềm sau nay.

Estimation Techniques. If similar projects have already been

completed, estimates can easily be based on that available data. Otherwise,

a decomposition technique or an empirical model can be used. There are

also software tools that automate the process using the two preceding

approaches. At least two estimation methods should be used, with the final

estimation a triangulation of the two. Even so, common sense and

experience should be the ultimate judge.

Các kỹ thuật đánh giá: Nếu một project tƣơng tự đã đƣợc hoan

thanh, việc đánh giá có thể dựa vao dữ liệu có sẵn một cách dễ dang.Ngƣợc

lại, ta có thể sử dụng kỹ thuật phân rã hay mô hình kinh nghiệm. Ta cũng

có sẵn những công cụ phần mềm dùng để đánh giá tự động sử dụng 2 cách

tiếp cận trƣớc (preceding approaches).Ít nhất hai phƣơng pháp đánh giá nên

đƣợc sử dụng với lần đánh giá cuối cùng bằng cả 2 phƣơng pháp nay.Va

những đánh giá cuối cùng luôn dựa trên cảm nhận va kinh nhgiệm của

ngƣời đánh giá.





In the example provided in Appendix F two estimation

methodologies are used:

Process based where the system is decomposed into discrete tasks

such as analysis of the user interface and design of the user

interface with an estimated amount of time allocated to each. For

the online resource scheduling system the process-based estimate

was 7.5 person months.

LOC, or line of code, estimation is much harder to estimate

manually. A tool such as COCOMO (an abbreviation of cost

construction model) makes the effort much easier. A wealth of

information as well as a free version of the COCOMO automated

tool can be found on the CSE center for software engineering web

site (http://sunset.usc.edu/research/COCOMOII/index.html).

Trong vi dụ ở phụ lục F, 2 phƣơng pháp đánh giá đã đƣợc sử dụng:

Phân rã dự án thanh những phần riêng lẻ để đánh giá vi dụ nhƣ phân

tich giao diện ngƣời dùng va thiết kế giao diện ngƣời dùng với từng khỏang

đánh giá thời gian cho chúng.Với hệ thống kế họach nguồn trực tuyến thì

thòi gian đánh giá dựa trên quá trình la 7.5 person months.

Đánh giá theo LOC thì khó hơn cách đánh giá bằng tay.Sử dụng

công cụ COCOMO sẽ dễ dang hơn rất nhiều. Nhiều thông tin cũng nhƣ các

phiên bản miễn phi của công cụ tự động COCOMO có thể đƣợc tìm thấy ở


http://sunset.usc.edu/research/COCOMOII/index.html




trung tâm CSE cho công nghệ phần mềm:


COCOMO II is a model that allows one to estimate the cost, effort,

and schedule when planning a software developmental activity. It is based

on the original COCOMO model devised by Dr. Barry Boehm in 1981. The

COCOMO II model is actually derived from the following original

mathematical formula that is described in the second half of this book:

m = c1 * KLOCa*PROD[fi]

COCOMOII là công cụ cho phép ngƣời dùng đánh giá chi phi, công

sức, thời gian biểu khi lập kế họach phần mềm. Nó dựa trên phiên bản

COCOMO đƣợc phát triển bởi Dr. Barry Boehm năm 1981.Mô hình

COCOMOII thật ra đƣợc dẫn xúât từ công thức tóan học đƣợc diễn tả ở

phần sau sách:

m = c1 * KLOCa*PROD[fi]

COCOMO II permits the estimator to estimate a project cost in terms

of LOC or function points (FP). FP calculation is quite complex; a chapter

explaining function points can be found in this section.

COCOMOII cho phép ngƣời đánh giá đánh giá chi phi project bằng

LOC hay FP. Tinh tóan FP thì phức tạp. Một chƣơng vể FP sẽ đƣợc trình

bay trong cuốn sách nay.






Exhibit 3-1 shows the COCOMO II tool set in action. Although a bit

cumbersome — the nonfree COCOMO tools are much more user friendly

— the free version is quite functional. In this real-world example, I used

COCOMO to estimate the cost of building an Internet gaming system using

the LOC option (see module size). If you look down at the bottom of the

screen shot, you will notice three estimates: optimistic, most likely and

pessimistic. The COCOMO tool set has many features. I would recommend

that you download this tool and try it out.

Hình 3.1 hiển thị cách COCOMOII lam việc.Mặc dù công cụ nay hơi

cồng kềnh, công cụ COCOMO lại thân thiện với ngƣời dùng hơn- phiên

bản miễn phi lại có nhiều chức năng hơn.Trong vi dụ về thế giới thực, tôi

sử dụng COCOMO để đánh giá chi phi một tòa nha, trung tâm hệ thống

Internet game sử dụng LOC.Nếu nhìn xuống cuối man hình, bạn sẽ thấy 3

đánh giá: optimistics, most likely va pessimistic.Công cụ COCOMO có rất

nhiều đặc trƣng. Tôi khuyên bạn nên tải công cụ nay về thử nghiệm.

Thus, the planner first needs to estimate the size of the product to be

built, and then translate the size estimate into human effort, calendar time,

and dollars.

Do đó, ngƣời lập kế họach trƣớc hết cần đánh giá kich thƣớc của dự

án sẽ thực hiện, sau đó chuyển kich thƣớc nay vao chi phi, công sức ngƣời

lam, thời gian biểu va tiền.





3.4.3 Kỹ thuật phân rã

According to Putnam and Myers (1992), several approaches can be

used to handle the project sizing problem: ―fuzzy-logic‖ sizing, which uses

approximate reasoning technique as in the art of ―guestimating‖, function

point sizing, standard component sizing (i.e., modules, screens, reports,

etc.), and change sizing, which is used in estimating the size of an effort to

modify an existing system.

Theo Putnam va Myers (1992), có nhiều cách tiếp cận có thể đƣợc sử

dụng để tiếp cận phầm mềm: Logic mờ (fuzzy logic), phƣơng pháp sử dụng

các kỹ thuật xấp xỉ để dự đóan, function point sizing. Standard component

(modules, screens, reports…), va change sizing, phƣơng pháp đánh giá

công sức bỏ ra khi điều chỉnh một dự án có sẵn.

Problem-based estimation techniques include FP- and LOC-based

estimation, which we just discussed. Both require the project planner to

decompose the software into problem functions that can be estimated

individually. Then the project planner estimates LOC or FP (or other

estimation variable) for each function and applies the baseline productivity

metrics to derive the cost of or effort for the function. Finally, these

function estimates are combined to produce the overall estimate for the

whole project. Alternatively, a process-based estimation is commonly used.

Here the process is partitioned into a relatively small set of activities (i.e.,





the large project is decomposed or segmented into more manageable tasks)

or tasks and the effort required to accomplish each is estimated.

Cách đánh giá dựa trên vần đề bao gồm FP va LOC. Hai phƣơng

pháp đều yêu cầu ngƣời đánh giá phải phân rã phần mềm thanh những chức

năng có thể đánh giá độc lập. Sau đó ngƣời đánh giá sẽ đánh giá LOC hay

FP (hoặc các biến đánh giá khác) cho từng chức năng va áp dụng mức đánh

giá chi phi va công sức cho từng chức năng.Cuối cùng những chức năng đã

đƣợc đánh giá nay sẽ kết hợp với nhau để cho ra đánh giá sản phẩm cuối

cùng. Cách đánh giá nay đƣợc sử dụng nhiều. Ở đây quá trình đƣợc chia

lam nhiều phần nhỏ (vi dụ nhƣ một dự án lớn đƣợc phân rã lam nhiều công

việc có thể quản lý đƣợc) hoặc la những công việc, công sức có thể đánh

giá đƣợc.

3.4.4 Mô hình kinh nghiệm

A variety of empirical models are available to calculate the effort

required based on the size estimation in FP or LOC. Other than COCOMO

(Boehm, 1981), the most widely used model is the software equation

(Putnam and Myers, 1992).

Có rất nhiều kiểu mô hình kinh nghiệm đƣợc dùng để đánh giá yêu

cầu công sức dựa trên LOC hay FP.Ngòai COCOMO (Boehm, 1981), mô

hình đƣợc sử dụng rộng rãi nhất la phần mềm Cân bằng dự án (Putnam va

Myers, 1992).





Putnam‘s cost estimation model is a macro-estimation model. The

model recognizes the relationship between cost and the amount of time

available for the development effort. The Putnam model supports the

mythical man-month idea first put forth by Frederick Brooks that states that

people and time are not always interchangeable. The software equation is

explained in the second half of this book. The results of these estimation

techniques are estimates of effort, cost, and duration. They, in turn, are used

in other sections of the project plan.

Mô hình đánh giá chi phi của Putnam la mô hình đánh giá mức độ

tổng quát (macro-estimation model).Mô hình sẽ nhận diện mối quan hệ

giữa chi phi va thời lƣợng cần thiết cho việc phát triển công sức bỏ ra. Kết

quả của những đánh giá nay la sự đánh giá về chi phi, công sức, va thời

lƣợng. Nó đƣợc sử dụng trong những phần khác của kế họach dự án.

3.4.5 Quản lý rủi ro

A proactive risk strategy should always be adopted. It is better to

plan for possible risk than to need to react to it in a crisis. Software risks

include project risks, technical risks, and business risks; they can also be

categorized as known, predictable, or unpredictable risks. First, risks need

to be identified. One method is to create a risk item checklist. The sample

project plan in Appendix F lists the following risks:

• Customer will change or modify requirements





• Lack of sophistication of end users

• Users will not attend training

• Delivery deadline will be tightened

• End users resist system

• Server may not be able to handle larger number of users

simultaneously

• Technology will not meet expectations

• Larger number of users than planned

• Lack of training of end users

• Inexperienced project team

• System (security and firewall) will be hacked

Chiến lƣợc rủi ro ban đầu nên đƣợc chấp nhận. Việc lên kế hoạch

các rủi ro có khả năng xảy ra tốt hơn so với việc đối phó với khủng hoảng.

Rủi ro phần mềm bao gồm rủi ro dự án, rủi ro kĩ thuật, rủi ro kinh doanh.

Chúng có thể đƣợc phân loại dựa vao sự xác minh, dự đoán trƣớc va không

dự đoán. Đầu tiên rủi ro đƣợc nhận dạng. Mẫu rủi ro khi lên kế hoạch dự án

nằm trong bảng sau:





Khách hang sẽ thay đổi yêu cầu.

Thiếu ngƣời dùng cuối tinh tế

Ngƣời dung sẽ ko tham gia huấn luyện

Hạn cuối phân phối siết chặt.

Ngƣời dung cuối chống lại hệ thống

Máy chủ không thể thao tác với số lƣợng lớn ngƣời dùng cuối

đồng thời.

Kĩ thuật sẽ không nhƣ mong đợi.

Số ngƣời dùng thực tế nhiều hơn trong kế hoạch

Đội lam dự án thiếu kinh nghiệm

Hệ thống (bảo mật va tƣờng lửa) sẽ bị tấn công.

Then risks need to be projected in two dimensions: likelihood and

consequences. This section can be a separate RMMM (risk, mitigation,

monitoring, and management) plan and used as part of the overall project

plan.





Sau đó rủi ro đƣợc lên dự án thanh 2 phần: phần có thể thật va phần

hậu quả. Phần nay có thể chia thanh (rủi ro, sự lam nhẹ, giám sát, quản lý)

kế hoạch va sử dụng phần của tất cả dự án.

Risk Table: A risk table is a simple tool for risk projection. First,

based on the risk item checklist, list all risks in the first column of the table.

Then in the following columns fill in each risk‘s category, probability of

occurrence, and assessed impact. Afterward, sort the table by probability

and then by impact, study it, and define a cut-off line.

Bảng rủi ro: la 1 công cụ đơn giản cho việc quản lý rủi ro. Đầu tiên

dựa vao danh sách các rủi ro, liệt kê tất cả các rủi ro trƣớc cột đầu tiên của

bảng. Sau đó, các cột tiếp theo liệt kê từng loại rủi ro, khả năng xuất hiện,

tác động. Ngay sau đó, sắp xếp bảng nay bởi khả năng xuất hiện va sau đó

la tác động.

Discussion of Risks to Be Managed: All risks above the cut-off line

must be managed and discussed. Factors influencing their probability and

impact should be specified.

Thảo luận về các rủi ro đƣợc quản lý: Tất cả các rủi ro trên đƣờng

cắt ngang phải đƣợc quản lý va thảo luận. Các yếu tố tác động nên đƣợc chỉ

rỏ.

RMMM Plan for Each Risk: A risk mitigation plan is a tool that

can help in avoiding risks. Causes of the risks must be identified and





mitigated. Risk monitoring activities take place as the project proceeds and

should be planned early. Risk management — i.e., the contingency plan —

is a list of activities that are put into action in the event a risk is realized. A

plan should be created well before that.

Lên kế hoạch cho các rủi ro: Kế hoạch giảm nhẹ rủi ro la 1 công cụ

giúp tránh đƣợc rủi ro. Nguyên nhân rủi ro phải đƣợc nhận ra va giảm nhẹ.

Giám sát các hoạt động rủi ro chiếm 1 vùng nhƣ la tiến trình của dự án va

nên đƣợc lên kế hoạch sớm. Quản lý rủi ro la 1 danh sách các hoạt động đặt

trong các sự kiến có thể phát sinh rủi ro. Kế hoạch nên đƣợc tổ chức tốt

trƣớc đó.

3.4.6 Bảng thời gian:

Before drafting a schedule several things need to be done. The

project manager needs to first decide the type of the project from four

choices: concept development, new application development, application

enhancement, and re-engineering projects. Then the project manager needs

to compute a task set selector value (Pressman, 2001) by: 1) grading the

project for a set of adaptation criteria including its size, requirements, and

constraints, 2) assigning weighting factors to each criterion, 3) multiplying

the grade by weighting factors and by the entry point multiplier for the type

of the project, and 4) computing the average of all results in the previous

step. Based on this average value, the project manager can choose the

degree of rigor required for the project from four options: casual,





structured, strict, and quick reaction. Afterward, the task set can be decided

and distributed on the project time line based on the process model choice:

linear sequential, iterative, or evolutionary.

Trƣớc khi lam nháp thì vai việc cần đƣợc thực hiện trƣớc. Ngƣời

quản lý dự án cần quyết định trƣớc loại dự án từ 4 loại sau: phát triển khái

niệm, phát triển ứng dụng mới, nâng cấp ứng dụng va tái cơ cấu lại dự án.

Sau đó ngƣời quản lý dự án cần tinh toán các công việc 1) Phân loại dự án

cho các tiêu chuẩn thich nghi bao gồm, kich thƣớc, yêu cầu va rang buộc.

2) Phân công từng yếu tối đến các tiêu chuẩn 3) tăng thêm cấp bậc bởi các

yếu tố đặc biệt va bởi các mục cho từng loại dự án 4) tinh toan kết quả

trung bình trong bƣớc trƣớc đó. Dựa vao giá trị trung bình nay, ngƣời quản

lý dự án có thể chọn độ chinh xác đòi hỏi cho dự án từ 4 tùy chọn sau: ngẫu

nhiên, cấu trúc, nghiêm khắc, phản ứng nhanh. Sau đó các công việc thiết

lập có thể quyết định va đóng góp vao thời gian dự án dựa vao kiễu mẫu:

liên tiếp tuyến tinh, lặp lại, tiến hóa.

A sample from the schedule created for use in Appendix F appears in

Exhibit 3-2.

Hình 3.2 la vi dụ về tạo bảng thời gian sử dụng cho phụ lục F





Hình 3-2: mẫu bảng thời gian.

Project tasks, also known as project work breakdown structure

(WBS) are now defined as shown in Exhibit 3-3.

Công việc của dự án, đƣợc biết đến nhƣng cấu trúc công việc đƣợc

phân nhỏ đƣợc định nghĩa theo hình 3-3

Hình 3-3 Một vi dụ sử dụng Microsoft project để tạo mộ WBS

Lƣới công việc: Interdependencies among tasks are defined using a

task network as shown in Exhibit 3-5. A task network is also known as an

activity network because it shows all of the activities for the project — and





each activity‘s dependencies. In Exhibit 3-5, task 1.1 must be completed

prior to initiation of task 1.2, and so on. A variety of automated tools

implementing program evaluation and review technique (PERT) and critical

path method (CPM) (Moder et al., 1983) can be used for project scheduling.

Sự phụ thuộc lẫn nhau giữa các công việc đƣợc định rõ theo hình 3-

5. Lƣới công việc đƣợc biết đến nhƣ mạng lƣới các hoạt động bởi vì nó chỉ

ra tất cả các hoạt động của dự án va mỗi hoạt động độc lập. Hình 3-5, công

việc 1.1 phải đƣợc hoan thanh trƣớc công việc 1.2 … Sự đa dạng các công

cụ tự động thi hanh đánh giá chƣơng trình va xem xét kĩ thuật (PERT), phê

bình phƣơng pháp (CPM) đƣợc dùng cho việc định thời gian dự án.

DuPont developed the CPM for use in chemical plants. The objective

is to determine the trade-off between project duration and the total project

cost, which is accomplished by identifying the critical path through activity

network. The critical path can help management to change the duration of

the project. In CPM, an activity time is assumed to be known or predictable.

Dupont phát triển CPM cho sử dụng nha máy hóa học. Mục tiêu xác

định rõ sự thỏa hiệp giữa thời gian kéo dai dự án va tổng chi phi dự án.

Đƣờng dẫn phê bình có thể giúp ngƣời quản lý dự án thay đổi thời gian kéo

dai dự án. Trong CPM, thời gian hoạt động có vẻ đƣợc biết hay có thể dự

đoán trƣớc.





Project evaluation and review technique was developed by the Navy

when the Polaris missile was designed. When accurate time estimates are

not available, PERT is an ideal tool for Project Planning since it uses

probability theory.

Đánh giá dự án va xem xét kĩ thuật đƣợc phát triển trong Hải Quân

khi tên lửa Polaris đƣợc thiết kế. Khi thời gian đánh giá chinh xác không có

thật, PERT la 1 công cụ lý tƣởng cho việc lên kế hoạch dự án kể từ khi

dùng lý thuyết.

Eventually CPM and PERT merged into a single technique. Events

are shown as nodes and activities are shown as arrows that connect events.

Arrows represent the effort required for achieving the next event; direction

specifies the order in which events must occur. There are two types of times

for each event. One is the ―earliest time‖, the earliest possible time at which

the event can be chieved. The other is the ―latest time‖, which is the latest

time the event can occur without delaying subsequent events and

completion of the project. For an event, the slack time can be obtained or

calculated by the difference between the latest and the earliest times.

Cuối cùng CPM va PERT đƣợc trộn vao 1 kĩ thuật. Các sự kiện đƣợc

chỉ ra các nút, hoạt động nhƣ những mũi tên kết nối sự kiện.Những mũi tên

nay đòi hỏi nổ lực cho đạt đƣợc sự kiện tiếp theo; trực tiếp chỉ rõ thứ tự các

sự việc xảy ra.Có 2 loại thời gian cho từng sự kiện. Một la thời gian sớm

nhất sự kiện đó có thể đạt đƣợc. Hai la thời gian trễ nhất sự kiện đó có thể





đạt đƣợc. Cho từng sự kiện, sự thiếu thời gian có thể đạt đƣợc va tinh toán

bởi sự khác nhau giữa thời gian sớm nhất va thời gian trễ nhất.

Biểu đồ thời gian: Usually the timeline chart is generated using

automated tools after inputting the task network or task outline and each

task‘s effort, duration, start date, and resource assignment. This chart is

visual and usually the most used part of a project plan. However, it is also

possible to create a viable Gantt chart using Microsoft Excel as shown in

Exhibit 3-6.

Thƣờng thì biểu đồ thời gian đƣợc tạo ra sử dụng công cụ tự động

sau khi nhập vao mạng lƣới công việc hay phát thảo công việc va sự nổ lực

của công việc, thời gian kéo dai, ngay bắt đầu, tai nguyên đƣợc phân công.

Biểu đồ nay thƣờng có thể xem va dùng vao 1 phần của kế hoạch dự án.

Tuy nhiên, nó có thể tạo ra biểu đồ Gantt bằng Excel nhƣ hình 3-6.

Bảng tài nguyên: This is another output generated by the automated

tool, with a focus on the workload for and utilization of the project

resources, particularly human resources. Once a proper project schedule is

developed, its tasks and milestones should be tracked and controlled as the

project proceeds.

Đây la sản phẩm tạo ra bởi công cụ tự động, tập trung vao lƣợng

công việc máy lam va tiện ich của tai nguyên dự án, đặc biệt la tai nguyên





con ngƣời. 1 dự án có thời gian biểu đƣợc phát triển, công việc của nó va

cột mốc nên đƣợc đánh dấu va quản lý theo tiến độ của dự án.

3.4.7 Tai nguyên dự án:

Estimation of resources required is an important component of

software planning. For each resource the planner needs to specify with

these characteristics: description, statement of availability, and time

window.

Ƣớc lƣợng tai nguyên yêu cầu la một thanh phần quan trọng của thiết

kế phần mềm,với mỗi tai nguyên thì ngƣời phát thảo cần phải chỉ rõ những

đặc điểm:

Mô tả

Trình bay các khả năng

Thời gian

Các loại tai nguyên:

People: the planner needs to specify the organizational position and

specialty of human resources required by the project. Only after estimating

the development effort can we define the number of people required.





Con ngƣời: ngƣời thiết kế cần chỉ rõ vị tri tổ chức va nét đặc biệt của

nguồn nhân lực yêu cầu bởi dự án. Chỉ duy nhất sau khi ƣớc lƣợng ngƣời

phát triển phải nổ lực để chỉ rõ số lƣợng ngƣời đƣợc yêu cầu bởi dự án.

Hardware and software: hardware and software form the foundation

of the software engineering environment (Naur and Randall, 1969). The

project planner must determine its time window and verify its availability.

Reusable software components should also be specified, alternatives

evaluated, and acquisition made early.

Phần cứng va phần mềm: Phần cứng va phần mền la nền tảng của

của môi trƣờng kỹ nghệ phần mềm, Ngƣời thiết kế dự án phải xác định thời

gian thực va kiểm tra các khả năng có thể có. Những thanh phần có thể sử

dụng lại cũng đƣợc chỉ rõ, lựa chọn thay thế đƣợc đánh giá, va cần đƣợc

lam sớm.

Special resources: any other resources not covered in the previous

two sections should be listed here.

Những tai nguyên đặc biệt: la những tai nguyên khác với 2 phần đã

nêu trên va đƣợc nêu ra ở dƣới.

Staff organization: people are the critical factor in a software

development effort. In a typical software project, the players fall into five





categories: senior managers, project (technical) managers, practitioners,

customers, and end users. A good team leader should be able to motivate

other players, organize the process, and innovate or encourage people to be

creative.

Tổ chức nhân viên: con ngƣời la yếu tố chủ chốt trong nỗ lực phát

triển phần mềm. Trong một dự án phần mềm điển hình, Có 5 loại vai trò:

ngƣời quản lý cấp cao, ngƣời quản lý (kỹ thuật) dự án,các nhân viên thực

hiện, khách hang va ngƣời dùng cuối.Một ngƣời lãnh đạo nhóm tốt phải có

khả năng đốc thúc những ngƣời khác, tổ chức quy trình, va cải tiến hoặc

khuyến khich sáng tạo của con ngƣời.

Team structure (if applicable): a project manager should decide on

the organizational structure for the team. According to Mantei (1981), these

three generic team organizations exist: democratic decentralized (DD),

controlled decentralized (CD), and controlled centralized (CC). The factors

that influence the team structure decision include: difficulty of the problem,

size of the resultant programs, team lifetime, problem modularity, criticality

of the solution, rigidity of timeline, and communications required.

Generally speaking, a DD structure is best for difficult problems and a CC

or CD structure is best for very large projects.

Cấu trúc của nhóm: một ngƣời quản lý dự án nên quyết định cấu trúc

tổ chức của nhóm. Theo Mantei (1981), ba cách tổ chức nhóm còn tồn tại

là: dân chủ phân cấp (DD), kiểm soát phân cấp (CD), va kiểm soát tập trung





(CC). Những nhân tố ảnh hƣởng tới quyết định cấu trúc của một nhóm bao

gồm:

Độ khó của vấn đề

Kich thƣớc của kết quả chƣơng trình

Thời gian sống của nhóm

Vấn đề modun

Những giải pháp hóc búa

Thời gian cứng nhắc

Yêu cầu liên lạc

Nói chung, một cấu trúc DD (dân chủ phân cấp la khó nhất) va cấu

trúc CD hoặc CC la tốt nhất cho những dự án lớn

Management reporting: coordination and communication issues,

including management reporting relationships, should be addressed here.

Báo cáo quản lý: tổng hợp va truyền đạt các vấn đề bao gồm báo cáo

các mối quan hệ quản lý.





3.4.8 Cơ chế theo dõi va kiểm soát:

This may be the last section, but not the least important. Errors and

changes are inevitable, and we need to plan ahead to stay prepared for when

they actually happen.

Phần nay có lẽ la phần cuối nhƣng không phải la phần it quan trọng

nhất, lỗi va những thay đổi la không thể tránh khỏi, chúng ta cần phải hoạch

định trƣớc để chuẩn bị đói phó khi nó thực sự xảy ra.

Quality assurance and control: software quality assurance activities

(SQA) happen at each step of the software process and are carried out by

software engineers and an SQA group. Software engineers assure quality by

applying rigorous technical methods and measures, and conducting formal

technical reviews and well-planned testing. SQA group assists software

engineers through a set of activities that address quality assurance planning,

oversight, record keeping, analysis, and reporting. We need to plan these

activities in this subsection.

Đảm bảo chất lƣợng va kiểm soát: Chất lƣợng phần mềm đảm bảo

(SQA) cho các hoạt động xảy ra trong mỗi bƣớc của tiến trình phần mềm,

va đƣợc tiến hanh bởi kỹ sƣ phần mềm va 1 nhóm SQA. Kỹ sƣ phần mềm

đảm bảo chất lƣợng bởi ứng dụng những công nghệ nghiêm khắc va bằng

việc đo lƣờng, tiến hanh những đánh giá về kỹ thuật va những kế họach

kiểm tra tốt. Nhóm SQA sẽ giúp cho kỹ sƣ phần mền xuyên suốt một bộ

các hoạt động đó la địa điểm phác thảo kế hoạch chất lƣợng tin cậy, giám





sát, giữ lại những bản ghi, phân tich va báo cáo. Chúng ta cần phải có kế

hoạch cho những hoạt động trong những phần nhỏ.

Change management and control: the later the changes happen in a

project, the higher the cost. Change control combines human procedures

and automated tools to provide a mechanism for the control of changes that,

if uncontrolled, can rapidly lead a large project to chaos. The change

control process begins with a change request, leads to a decision to make or

reject the request, and culminates with a controlled update of the software

configuration item to be changed. This part of the activities should be

planned here.

Thay đổi sự quản lý va kiểm soát: Sau những thay đổi trong một dự

án, các chi phi sẽ tăng cao hơn. Kiểm soát sự thay đổi kết hợp các thủ tục

của con ngƣời va các công cụ tự động để cung cấp 1 cơ chế kiểm soát cho

sự thay đổi.Nếu không kiểm soát, dự án rất nhanh chóng sẽ trở nên hỗn

độn. Sự thay đổi của quá trình kiểm soát bắt đầu từ sự thay đổi của 1 yêu

cầu, dẫn tới quyết định thực hiện hay từ chối một yêu cầu va lên tới cực

điểm với sự cập nhật kiểm soát của các mục cấu hình phần mềm sẽ đƣợc

thay đổi, phần hoạt động nay cần đƣợc quy hoạch ở đây.

3.5 CÓ ĐÁNG ĐỂ LÀM CÔNG VIỆC NÀY HAY KHÔNG?

Like any other software engineering task, project planning and

writing a detailed project plan take time and costs money. Therefore a





natural question arises: is it worth it? The answer is yes. If you want a

system that is cost effective, does not go over budget, and actually works, a

project plan is mandatory.

Cũng giống nhƣ các kĩ thuật phần mềm khác, lập kế hoạch va mô tả

chi tiết kế hoạch đó la tốn thời gian va chi phi. Do đó nảy sinh một câu hỏi

thông thƣờng: có đáng hay không? Câu trả lời la có. Nếu bạn muốn một hệ

thống có hiệu quả về chi phi, không vƣợt quá chi phi giới hạn va thật sự

lam việc, lập kế hoạch cho dự án la bắt buộc.

More than a few people in this field use the ―roadmap‖ metaphor to

describe the role of a project plan; however, it is also a ―compass‖. Its

estimation and scheduling part may be like a rough roadmap (never precise

enough at the beginning of a project), but its risk management, organization

plan, tracking, and control part are definitely a compass. It guides the

project team in handling unpredictable risks or undesired events.

Một vai ngƣời trong lĩnh vực nay dùng phép ẩn dụ ―bản đồ chỉ

đƣờng‖ để mô tả vai trò của lập kế hoạch dự án; tuy nhiên, nó đồng thời

cũng la một ―la ban‖. Phần đánh giá va lập bảng thời gian có thể đƣợc vi

nhƣ một bản đồ chỉ đƣờng dạng thô (không chinh xác khi bắt đầu dự án),

nhƣng phần quản lý rủi ro, hay la kế hoạch tổ chức, theo dõi va kiểm soát

thì chinh xác la một la ban. Nó hƣớng dẫn đội lam dự án xử lý các rủi ro

không dự báo đƣợc hay la những sự kiện không mong muốn.





A good project plan benefits not only the project, but also the domain

as whole by its measures and metrics, which can be historical data for later

projects.

Một kế hoạch dự án tốt mang lại không chỉ cho bản thân dự án, ma

còn cho cả toan bộ công việc lam phần mềm bằng những thƣớc đo va độ đo

của nó, những thứ có thể dùng lam tƣ liệu lịch sử cho những quá trình sau.




Chương 4: Thu thập yêu cầu 148

CHƢƠNG 4 THU THẬP YÊU CẦU

Người dịch:

1. Phạm Ngọc Vân Anh

2. Trần Ngọc Hiệu

3. Trần Duy Khang

4. Huỳnh Lâm Linh

5. Nguyễn Thị An Nhơn





Without proper information it is difficult, if not impossible, to define

or start a systems development project. Information gathered in this process

is called requirements elicitation; it will enable the project manager or

analyst to create a blueprint of current systems and allow definition of

objectives, description of processes, and deployment of objectives for the

new system. In addition, if the systems analyst is careful, he can lay the

foundation of efficient and effective communications with stakeholders

that will lead to a higher likelihood of a successful project.

Chúng ta không thể thực hiện 1 dự án phần mềm nếu không có thông

tin chinh xác về nó . Do đó , trƣơc hêt ta cân phai biêt nhƣng yêu cân ma

phân mêm cân phai co . Những thông tin thu thập nay đƣợc gọi la

Requirements Elicitation. Nó sẽ cho phép ngƣời quản lý dự án hoặc nha

phân tich để tạo ra một kế hoạch chi tiết của các hệ thống hiện tại va cho

phép định nghĩa của mục tiêu, mô tả về quy trình, va triển khai các mục tiêu

cho các mới hệ thống.

4.1 STAKEHOLDER ANALYSIS

PHÂN TÍCH CÁC BÊN LIÊN QUAN

Stakeholders are the people needed to ensure the success of the

project, for example, daily users and their managers, as well as technical

support people. It is important to find all the stakeholder groups and

determine their interests and needs. The first step, then, in requirements





elicitation is stakeholder analysis in which you try to find answers to the

following questions:

Stakeholder la những ngƣời cần thiết để quyết định sự thanh công

của một dự án , họ la ngƣời sử dụng phần mềm , quản lý , nhân viên kỹ

thuật…Việc xac đinh cac bên liên quan va xac đinh ho mong muôn điêu gi

la rất cần thiết. Trong quá trình xác định các bên liên quan nay, bƣớc đầu

tiên cần trả lời các câu hỏi:

Who are the stakeholders?

What goals do they see for the system?

Why would they like to contribute?

What risks and costs do they see?

What kind of solutions and suppliers do they see?

Các bên liên quan la ai?

Họ mong đơi gì ở phần mềm?

Nhƣng vân đê, trơ ngai ma ho măc phai?

Họ có nhƣng giải pháp gì?





Stakeholders could be:

The sponsor who pays for the development of the product

People who will be using the product on a daily basis

Managers of departments looking to increase work force efficiency

The company‘s customers (clients of the system), without whose

support there will be no business advantages

Business partners: suppliers, carriers, and banks that also need to

interact with the system

IT people and hotline staff in case the product is to be developed

within the company

IT people at the client‘s site

Các bên liên quan có thể la:

Ngƣơi tai trơ cho phân mêm

Ngƣơi sƣ dung phân mêm hăng ngay

Ngƣơi lanh đao (nhƣng ngƣơi nay mong muôn công viêc hiêu qua

hơn khi sử dụng phần mềm)





Các khách hang của công ty sẽ sử dụng phần mềm.

Các bên công tac cua công ty se sƣ dung phân mêm : nha cung cấp,

ngân hang, vân chuyên.

Bô phân IT cua công ty se sƣ dung phân mêm.

Bô phân IT cua bên khach hang cua công ty se sƣ dung phân mêm.

Stakeholders should be carefully interviewed (Curtis et al., 2000) to:

Define financial constraints

Define the current and proposed information systems

Define current and proposed development process

Define current and proposed hardware assets and availability

Define current and proposed software assets and availability

Define current and future goals and objectives of the stakeholders

Các bên liên quan cần đƣợc phỏng vấn để xác định các vấn đề sau:

Măt tai chinh ma công ty có thể bỏ ra

Hệ thống thông tin hiện tại va sắp tới của công ty.





Quá trình lam viêc hiên tai va nhƣng phat triên săp tơi cua công ty.

Hê thông phân mêm hiên tai va hê thông mong muôn săp tơi

Hê thông phân cƣng hiên tai va hê thông phân cƣng săp tơi.

Mục đich tƣơng lai của các bên liên quan la gì.

Information gathered from the financial constraints will allow

examination of realistic designs and eliminate unnecessary expenditures of

resources on unrealistic approaches. One must also know the current

information systems in place and hardware assets as well as the current

software assets available within the company. It is also critical that the

development team fully understand the current development methodologies

and tool sets that the company utilizes. The goals and objectives of the

information gathering process are to be able to accumulate enough

information to define all of these items as well as the goals of the

stakeholders.

Thông tin thu thập từ về khả năng tai chinh dùng để đƣa ra các thiết

kế phù hợp với khả năng thực tế va giảm bớt các tai nguyên va các mục tiêu

không cần thiết. Tất cả các thông tin trên đều rất cần thiết để cung cấp

thông tin đầy đủ cho việc thực hiện phần mềm.





4.2 ELICITATION TECHNIQUES

KĨ THUẬT THU THẬP THÔNG TIN

Various methods can be used to obtain the information necessary to

prepare a project plan. These methods include interviewing, questionnaires,

observation, participation, documentation, research, business intelligence

(BI), competitive intelligence (CI), reverse engineering, and benchmarking.

Có rất nhiều phƣơng pháp khác nhau để thu thập yêu cầu phần mềm:

phỏng vấn, bảng câu hỏi khảo sát, quan sát, tham gia, các tai liệu của công

ty, business intelligence(BI), competitive intelligence(CI), reverse

engineering, benchmarking.

4.2.1 Interviewing

The most common method of gathering information is by

interviewingpeople. Interviewing can serve two purposes at the same time.

The first is a fact-finding mission to discover what each person‘s goals and

objectives are with respect to the project; the second is to begin a

communications process that enables one to set realistic expectations for the

project.

Phƣơng pháp phổ biến nhất để thu thập yêu cầu là phỏng vấn. Phỏng

vấn có thể phục vụ đồng thời 2 mục đich: tìm ra mục đich trong phạm vi dự





án của con ngƣời nhanh chóng, bắt đầu quá trình giao tiếp để khơi gợi

những mong muốn thực tế cho dự án.

A wide variety of stakeholders can and should be interviewed.

Stakeholders are those with an interest in seeing this project successfully

completed — i.e., they have a ―stake‖ in the project. As discussed earlier,

stakeholders include employees, management, clients, and partners.

Cần phỏng vấn nhiều thanh phần khác nhau của các bên liên quan.

Các bên lien quan la những ngƣời mong muốn dự án hoan thanh thanh

công, vi dụ: nhân viên, quản lý, khách hang…

Employees: It is amazing to me that some analysts develop systems

without ever interviewing those whose jobs will be affected the most. This

occurred most notably at the U.S. Post Office when the clerical staff was

automated in the 1980s. So little information was shared about what the

new system was going to do that the clerks got the misimpression that they

were soon to be replaced.

Rất ngạc nhiên là một số nhà phân tích phát triển hệ thống mà không

phỏng vấn những ngƣời có công việc bị ảnh hƣờng nhiều nhất. Điển hình là

ở U.S Post Office khi bộ phận kế toán đƣợc tự động hóa vào những năm

1980. Rất ít thông tin về sự hoạt động trong tƣơng lai của hệ thống đƣợc

chia sẻ, do đó các kế toán viên cứ tƣởng rằng họ sắp bị thay thế.





The number and type of employees that will need to be interviewed

will depend on the type of system being developed. Systems generally fall

into two categories: tactical and strategic. Tactical systems are usually

transactional- based systems such as check processing, student registration,

and medical billing where data volumes are high and staff members

accessing those systems are clerical. Strategic systems support the decision

making process and are utilized by middle and senior managers. It is

possible for a system to be a hybrid of both these system types. An example

of this would be a transactional back end that collects data for analysis by

managers at the front end.

Số lƣợng va các thanh phần nhân viên đƣợc phỏng vấn phụ thuộc

vao loại hệ thống phần mềm nay. Hệ thống nay đƣợc chia thanh 2 loại:

chiến thuật (tactical) va chiến lƣợc(strategic). Hệ thống chiến thuật la

những hệ thống thực hiện các công việc ―kinh doanh‖ (transactional-based

system) thông thƣờng nhƣ kiểm tra, đăng ký, báo giá. Hệ thống nay chứa

lƣợng dữ liệu lớn va ngƣời truy cập hệ thống nay chủ yếu la nhân viên văn

phòng. Hệ thống chiến lƣợc la hệ thống hỗ trợ va la công cụ của những

ngƣời quản lý cấp cao. Một hệ thống có thể có cả 2 tinh chất chiến thuật va

chiến lƣợc.

Interviews can have some major obstacles to overcome. The

interviewee may resist giving information out of fear, may relate his

perception of how things should be done rather than how they are really

done, or may have difficulty in expressing himself. On the other hand, the





analyst‘s own mindset may also act as a filter. The interviewer sometimes

needs to set aside his own technical orientation and make a strong effort to

put himself in the position that the interviewee is in. This requires that the

analyst develop a certain amount of empathy.

Phỏng vấn nhân viên có thể có những trở ngại sau đây . Nhân viên

đƣợc phỏng vấn thƣờng e ngại khi cung cấp thông tin . Họ thƣờng nói ra

những gì nên xảy ra chứ không phải những gì xảy ra trong thực tế . (Phản

ánh quá trình lam việc không giống với thự c tê ho lam thƣơng ngay ). Khả

năng diễn đạt của nhân viên đƣợc phỏng vấn kém. Bên cạnh đó, ngƣời phân

tich có khi lại chọn lọc thông tin theo suy nghĩ chủ quan của họn. Do đó

ngƣời phỏng vấn cần đặt mình vao vị tri của ngƣời đƣợc phỏng vấn để hiểu

vấn đề những ngƣời nay đang gặp phải.

An interview outline should contain the following information:

Name of interviewee

Name of interviewer

Date and time

Objectives of interview — i.e., what areas you are going to explore

and what data you are going to collect

General observations





Unresolved issues and topics not covered

Agenda — i.e., introduction, questions, summary of major points,

closing

Các ghi chép lại khi phỏng vấn chứa nội dung sau:

Ngƣơi phong vân

Thơi gian phong vân

Nôi dung mục tiêu của cuộc phong vân

Các tai liệu cần thu thập.

Nhƣng quan sat

Các vấn đề nảy sinh trong khi lam việc của nhân viên

Các câu hỏi, tóm tắt, các nhận định của bản thân…

Recommended guidelines for handling the employee interview

process include:

Hƣớng dẫn thực hiện quá trình phỏng vấn nhân viên:

Determine the system type (tactical, strategic, hybrid).





Xác định loại hệ thống

Make a list of departments affected by the new system.

Tạo danh sách các bộ phận lien quan

For each department, request or develop an organization chart that

shows the departmental breakdown along with the name,

extension, and list of responsibilities of each employee.

Với mỗi bộ phận, yêu cầu các bảng biểu, giấy tờ, hồ sơ với tên, list,

bảng trách nhiệm của từng nhân viên.

Meet with the department head to request recommendations and

then formulate a plan that details which employees are the best

interview prospects. The ―best‖ employees to interview are those:

1) who are very experienced (i.e., senior) in performing their job

functions; 2) who may have come from a competing company and,

thus, have a unique perspective; 3) who have had a variety of

positions within the department or company.

Gặp ban lãnh đạo đề lấy có đƣợc đề cử về danh sách nhân viên

tham gia phỏng vấn và lập kế hoạch tìm ra chi tiết nhân viên nào

đem lại hiệu quả phỏng vấn tốt nhất. Các tiêu chi đánh giá: ngƣời

có kinh nghiệm trong công việc của họ, ngƣời đến từ một công ty





cạnh tranh nên có những nhận thức khác biệt, ngƣời đã từng có

nhiều vị trí khác nhau trong bộ phận của công ty.

Plan to meet with employees from all units of the department. In

other words, if you are automating the marketing function and

interviewing the marketing department, you will want to meet with

employees from the marketing communications unit, marketing

research unit, public relations group, etc. In some cases, you may

find that interviewing several employees at a time is more effective

than dealing with a single employee because interviewing a group

of employees permits them to bounce ideas off each other.

Lập kế hoạch gặp gơ nhân viên từ tất cả các bộ phận. Nói cách

khác, nếu bạn thực hiện tự động hóa chức năng marketing va

phỏng vấn bộ phận marketing, bạn sẽ muốn gặp gơ nhân viên từ

các bộ phận nhỏ của bộ phận marketing nhƣ: marketing

communications, marketing research, public relations group,

….Trong một số trƣờng hợp, bạn sẽ thấy phỏng vấn một vài nhân

viên cùng một lúc hiệu quả hơn la phỏng vấn 1 ngƣời 1 lần vì

phỏng vấn nhóm sẽ giúp họ hiệu chỉnh thông tin cho nhau làm cho

thông tin chinh xác hơn.

If a departmental unit contains many employees, it is not optimum

to interview every one. It would be wrong to assume that the more

people in a department, the higher the number of interviewees





should be. Instead, sampling should be used. Sampling is used to:

1) contain costs; 2) improve effectiveness; 3) speed up the data-

gathering process; 4) reduce bias. Systems analysts often use a

random sample; however, calculating a sample size based on

population size and your desired confidence interval is more

accurate. Rather than provide a formula and instructions on how to

calculate sample size here, I direct the reader to the sample size

calculator located at http://www.surveysystem.com/sscalc.htm.

Nếu một bộ phận có nhiều nhân viên thì không thể phỏng vấn tất

cả các nhân viên. Sai lầm khi cho rằng nếu 1 bộ phận có nhiều

nhân viên thì nên phỏng vấn nhiều nhân viên. Thay vao đó nên sử

dụng các mẫu.Chọn ra các mẫu để: 1)chứa các chi phí, 2)cải thiện

hiệu quả, 3)tăng tốc quá trình tổng hợp dữ liệu, 4)giảm số lƣợng dữ

liệu không có giá trị. Ngƣời phân tích hệ thống thƣờng chọn các

mẫu ngẫu nhiên nhƣng chọn mẫu dựa vào tổng số lƣợng thực và

khoảng cách mà bạn mong muốn. Thay vì chỉ cho ngƣời đọc công

thức và cách tính thì tác giả chỉ rat rang web hỗ trợ thực hiện tính

toán độ lớn của mẫu http://www.surveysystem.com/sscalc.htm.

Carefully plan your interview sessions. Prepare your interview

questions in advance. Be familiar with any technical vocabulary

your interview subjects might use.


http://www.surveysystem.com/sscalc.htm

http://www.surveysystem.com/sscalc.htm




Lập kế hoạch cẩn thận cho buổi phỏng vấn. Chuẩn bị câu hỏi kỹ

càng. Hiểu rõ về các từ ngữ kỹ thuật trong chủ đề phỏng vấn của

bạn.

No meeting should last longer than an hour. A half hour is

optimum.There is a point of diminishing returns with the interview

process. Your interviewees are busy and usually easily distracted.

Keep in mind that some of your interviewees may be doing this

against their will.

Thời gian phỏng vấn không nên quá 1 tiếng. Nửa tiếng là tốt nhất.

Có nhiều điểm có thể làm giảm chất lƣợng phỏng vấn. Ngƣời đƣợc

phỏng vấn rất bận va thƣờng dễ bị phân tâm. Nhớ rằng một số

ngƣời đƣợc phỏng vấn có thể lam nhƣ vậy để chống lại sự sẵn sàng

cho cuộc phỏng vấn.

Customers: If the new or modified system will be affecting

customers in any way, one should interview several customers to obtain

their impressions of the current process and what features would be

desirable. This information can be very enlightening. Often customers just

live with the frustrations and never mention them to anyone at the

company. Customers often have experiences with other vendors or

suppliers and can offer insight into the processes that other companies use

or that they have experienced.





Nếu hệ thống phần mềm sẽ ảnh hƣởng tới quá trình lam việc giữa

công ty va khách hang của công ty thì cần phỏng vấn khách hang của công

ty. Các thông tin lấy từ khách hang la các thông tin về hệ thống hiện tại va

họ mong muốn gì ở hệ thống. Khách hang cũng có thể cung cấp thông tin

về hệ thống phần mềm ở các công ty khác hay cung cấp thông tin về các

nha cung cấp hay các nha phân phối của công ty.

Guidelines for interviewing customers include:

Work with the sales and marketing departments to select

knowledgeable and cooperative customers.

Prepare an adequate sample size as discussed in the prior section.

Carefully plan your interview sessions. Prepare your interview

questions in advance.

Hƣớng dẫn phỏng vấn khách hang:

Hỏi bộ phận bán hang hay marketing để tìm danh sách khách hang

phỏng vấn

Hỏi khách hang về các nhu cầu liên quan tới phần mềm, các vấn đề

găp phai khi lam viêc vơi công ty

Hỏi khách hang về các công ty khác ma họ đã giao dịch





Companies and Consultants: Another source of potentially

valuableinformation is other companies in the industry and consultants who

specialize in the areas that will change with the new processes. Consultants

can be easily located and paid for their expert advice, but it is wise to tread

slowly when working with other companies who are current or potential

competitors.

Guidelines for interviewing other companies include:

Work with senior management and marketing to create a list of

potential companies to interview. This list should contain the

names of trading partners, vendors (companies that your company

buys from), and competitors.

Attend industry trade shows to meet and mingle with competitor

employees and listen to speeches made by competitive companies.

Attend trade association meetings; sit on policy and standards

committees.

Các cố vấn la những nha chuyên môn trong lĩnh vực sẽ ứng dụng hệ

thống phần mềm. Các công ty khác la các công ty cạnh tranh của công ty.

Các nha cố vấn thì có thể dễ dang tiếp cận để lấy thông tin, mặc dù có thể

phải trả phi. Nhƣng các công ty khác thì không dễ dang nhƣ vậy.

Hƣớng dẫn phỏng vấn các công ty khác:





Nhờ bộ phận quản lý va marketing của công ty cung cấp danh sách

các nha cung các, các công ty cạnh tranh…

Tham dƣ cac hôi nghi doanh nghiệp đê găp gơ các nhân viên của

các công ty va nghe các bai diễn thuyết của các công ty nay.

Supliers: Suppliers of the products you are considering are also an

important source of ideas for the problem you are facing. These suppliers

know a great deal about how their product has been used and how problems

have been overcome in different systems. They can also give you a long list

of features they provide.

Các nha phân phối sẽ cho biết sản phẩm của họ đƣợc tiêu thụ thế nao

va các vấn đề đƣợc giải quyết thế nao.

Types of question: When interviewing anyone it is important to be

aware of how to ask questions properly. Open-ended questions are best for

gaining the most information because they do not limit individuals to

predefined answers. Other benefits of using open-ended questions are that

it: puts the interviewee at ease, provides more detail, induces spontaneity,

and is far more interesting for the interviewee. Open-ended questions

require more than a yes or no answer (Yate, 1993). An example of an

openended question is ―What types of problems do you see on a daily basis

with the current process?‖ These questions allow individuals to elaborate on





the topics and potentially uncover the hidden problems at hand that might

not be discoverable with a question that requires a yes or no answer.

Khi phỏng vấn cần biết làm sao hỏi câu hỏi một cách đúng đắn. Câu

hỏi mở là câu hỏi tốt nhất để lấy hầu hết thông tin vì nó không giới hạn

trong các câu trả lời đƣợc định trƣớc. Một điểm có lợi khác là nó làm cho

ngƣời đƣợc phỏng vấn dễ dàng trả lời và cho nhiều chi tiết hơn, đƣợc thích

hơn. Câu hỏi mở yêu cầu ở ngƣời trả lời nhiều hơn la ―yes‖, ―no‖. Một câu

hỏi mở điển hình: ―Bạn thấy vấn đề gì trong công việc thƣờng ngày với quá

trình làm việc hiện tại‖. Những câu hỏi nhƣ vậy cho thấy nhiều thông tin

hơn la các câu hỏi ―yes‖, ―no‖ thông thƣờng.

Often one starts a systems development effort with the intention of

solving a problem that turns out to be a symptom of a larger problem. If the

examination of problems leads to the underlying issues, the resolution of

those issues will be more valuable to the company in the end. Many

symptoms are a result of the same problem, and a simple change can fix

many issues at once. One disadvantage of open-ended questions is that they

create lengthier interviews. Another is that it is easy for the interview to get

off track and it takes an interviewer with skill to maintain the interview in

an efficient manner (Yates, 1993).

Thông thƣờng việc phát triển hệ thống la để giải quyết các vấn đề mà

có thể là biểu hiện của các vấn đề lớn hơn vẫn còn tiềm ẩn. Nếu việc kiểm

tra vấn đề dẫn đến việc tìm ra đƣợc nguyên nhân cốt lõi, thì việc giải quyết





những vấn đề có giá trị hơn đối với công ty. Một bất lợi của câu hỏi mở là

kéo dài cuộc phỏng vấn hoặc ngƣời trả lời có thể dễ dàng bị lạc đề. Điều đó

đòi hỏi ngƣời phỏng vấn có kỹ năng hỏi.

Closed-ended questions are, by far, the most common questions in

interviewing. They are questions that have yes and no answers and are

utilized to elicit definitive responses.

Câu hoi đóng la loại câu hỏi phổ biến nhất trong phỏng vấn . Đó la

các câu hỏi có lựa chọn trả lời la: ―Có‖, ―Không‖ va đƣợc dùng để thu thập

các câu trả lời đã xác định.

Past-performance questions can be useful to determine past

experiences with similar problems (Yates, 1993). Often interviewees are

reluctant to discuss problems so questions about past-performance can

allow the person to discuss an issue with similar problems. An example of

how a past-performance question is used is, ―In your past job how did you

deal with these processes?‖

Câu hỏi về quá trình làm việc trong quá khứ để xác định kinh

nghiệm trong quá khứ về cùng một vấn đề có thể có ích. Hầu hết các ngƣời

trả lời không thích nói về các vấn đề nên việc hỏi về công việc trong quá

khứ làm cho họ dễ dàng nói về các vấn đề tƣơng tự. Câu hỏi ví dụ: Trong

quá khứ, bạn làm sao xử lý vấn đề này.





Reflexive questions are appropriate for closing a conversation or

moving forward to a new topic (Yates, 1993). Reflexive questions are

created with a statement of confirmation and adding a phrase such as: Don‘t

you? Couldn‘t you? Wouldn‘t you?

Câu hỏi linh hoạt rất thích hợp để kết thúc buổi phỏng vấn hoặc

chuyển sang chủ đề khác. Loại nay thƣờng tạo bởi câu xác nhận lại và thêm

cụm từ nhƣ: ―Phải vậy không?‖, ―Bạn sẽ nhƣ vậy chứ?‖…

Mirror questions are a subtle form of probing and are useful in

obtaining additional detail on a subject. After the interviewee makes a

statement, pause and repeat the statement with an additional or leading

question: ―So, when this problem occurs, you simply move on to more

pressing issues?‖.

―Mirror question‖ là loại câu hỏi khéo để lấy thêm thông tin. Sauk hi

ngƣời trả lời trả lời xong, dừng lại và lặp lại câu đó với câu hỏi dẫn dắt

thêm ‖Khi vấn đề này xảy ra bạn giải quyết vấn đề quan trọng trƣớc?‖.

Often answers do not give the interviewer enough detail so one

follows the question with additional questions to prod the interviewee to

divulge more details on the subject. For example:

Can you give some more details on that?

What did you learn from that experience?





Another, more subtle, prodding technique can be used by merely

sitting back and saying nothing. The silence will feel

uncomfortable causing the interviewee to expand on his or her last

statement.

Câu trả lời thƣờng không cung cấp cho ngƣời trả lời nhiều thông

tin nên có thể thêm các câu hỏi phia sau để lấy thêm thông tin. Ví

dụ:

Bạn có thể cho thêm thông tin về điều này không?

Bạn học đƣợc điều gì từ kinh nghiệm đó?

Một cách khác, khéo léo hơn, la tựa ngƣời ra phía sau và không nói

gì cả. Sự im lặng sẽ lam cho ngƣời trả lời khó chịu và sẽ mở rộng câu trả lời

của họ.

4.2.2 Questionnaires and Surveys

Bảng câu hỏi và khảo sát:

If large numbers of people need to be interviewed, one might start

with a questionnaire and then follow up with certain individuals that present

unusual ideas or issues in the questionnaires. Survey development and

implementation is composed of the following tasks, according to Creative





Research Systems, makers of a software solution for survey creation

(surveysolutions.com):

Nếu số lƣợng lớn những ngƣời cần đƣợc phỏng vấn, ngƣời ta có thể

bắt đầu với một bảng câu hỏi va sau đó theo dõi với các cá nhân nhất định

ma trình bay những ý kiến không bình thƣờng hoặc những vấn đề trong

bảng câu hỏi Sự phát triển va hoan thanh cuộc khảo sát bao gồm những

nhiệm vụ sau đây, theo những hệ thống Ngiên Cứu Sáng Tạo, các nha

hoạch định của một giải pháp phần mềm cho sự tạo ra cuộc khảo sát

(surveysolutions.com):

Establish the goals of the project — what you want to learn.

Determine your sample — whom you will interview.

Choose interviewing methodology — how you will interview.

Create your questionnaire — what you will ask.

Pretest the questionnaire, if practical — test the questions.

Conduct interviews and enter data — ask the questions.

Analyze the data — produce the reports.

Thiết lập các mục tiêu của dự án – những gì bạn muốn tìm hiểu.





Xác định mẫu của bạn – những ngƣời ma bạn sẽ phỏng vấn.

Chọn phƣơng pháp phỏng vấn – bạn sẽ phỏng vấn nhƣ thế nao.

Tạo bảng câu hỏi của bạn – những gì bạn sẽ hỏi.

Kiểm tra lại bảng câu hỏi, nếu thực hiện – kiểm tra các câu hỏi

Tiến hanh các cuộc phỏng vấn va nhập dữ liệu – hỏi những câu

hỏi.

Phân tich dữ liệu – tạo báo cáo.

Similar to interviews, questionnaires may contain closed-end or

openended questions or a combination of the two.

Tƣơng tự nhƣ các cuộc phỏng vấn, bảng câu hỏi có thể có câu hỏi

đóng hay câu hỏi mở hoặc sự kết hợp của cả hai.

Appendix H contains a survey that was created for a Y2K software

product. This survey demonstrates the use of a hybrid questionnaire.

Although most of the questions are quite specific, and thus closed-ended,

there are at least two open-ended questions. Questions 6 and 8 under the

heading of ―management aspects‖ permit the respondent to reply to an

essay type of question.





Phụ lục H bao gồm một cuộc khảo sát đã đƣợc tạo ra cho một sản

phẩm phần mềm Y2K. Khảo sát nay chứng tỏ ich lợi của bảng câu hỏi kết

hợp 2 loại câu hỏi nói trên. Mặc dù hầu hết các câu hỏi rất cụ thể va la câu

hỏi đóng, nhƣng có it nhất hai câu hỏi mở. Câu hỏi 6 va 8 ở dƣới tiêu đề

của ―Khia cạnh quản lý‖ cho phép ngƣời trả lời viết ra một đoạn dai chứa

rất nhiều thông tin va ý kiến nhƣ một bai tiểu luận về 1 chủ đề.

Survey creation is quite an art form. Guidelines for creation of a

survey include:

Provide an introduction to the survey. Explain why it is important

to

respond to it. Thank participants for their time and effort.

Put all important questions first because it is rare that all questions

will be responded to. Those filling out the survey often become

tired

of or bored with the process.

Use plenty of ―white space‖. Use an appropriate font (i.e., Arial)

and font size (i.e., at least 12), and do skip lines.





Use nominal scales if you wish to classify things (i.e., What make

is your computer? 1 = Dell, 2 = Gateway, 3 = IBM).

Use ordinal scales to imply rank (i.e., How helpful was this class?

3 = not helpful at all, 2 = moderately helpful, 1 = very helpful).

Use interval scales when you want to perform some mathematical

calculations on the results; i.e.:

How helpful was this class?

Not useful at all Very useful

1 2 3 4 5

Hƣớng dẫn tạo ra một cuộc khảo sát bao gồm:

Cung cấp giới thiệu về cuộc khảo sát. Giải thich sự quan trọng của

việc trả lời bảng câu hỏi. Cảm ơn những ngƣời tham gia vì đã bỏ

thời gian va những cố gắng của họ để trả lời bảng câu hỏi

Đặt tất cả các câu hỏi quan trọng ở đầu vì rất hiếm khi ngƣời trả lời

sẽ trả lời hết tất cả các câu hỏi. Việc điền vao các ô trống có vẻ la

quá trình nhàm chán





Sử dụng nhiều ―không gian trắng‖. Sử dụng Font chữ thich hợp (vi

dụ, Arial) va font size (vi dụ, it nhất la 12), va bỏ dòng.

Sử dụng hệ thống danh nghĩa,nếu bạn mong muốn phân loại những

điều nay (Vi dụ: Máy tinh của bạn thuộc hãng gì? 1= Dell, 2 =

Gatway, 3 = IBM)

Sử dụng các phân loại về mức độ (Vi dụ: Lớp nay thì hữu ich nhƣ

thế nao? 3 = không hữu ich chút nao, 2 = hữu ich vừa phải, 1 = rất

hữu ich)

Trong từng mức độ có thể chia ra thanh các mức nhỏ hơn. Sử dụng

cách nay khi bạn muốn có số liệu tinh toán

Vi dụ: Lớp nay hữu ich nhƣ thế nao?

Không có ích chút nào Rất có ich

1 2 3 4 5

Tallying the responses will provide a ―score‖ that assists in making a

decision that requires the use of quantifiable information. When using

interval scales, keep in mind that not all questions will carry the same

weight. Hence, it is a good idea to use a weighted average formula during

calculation. To do this, assign a ―weight‖ or level of importance to each

question. For example, the preceding question might be assigned a weight





of 5 on a scale of 1 to 5, meaning that this is a very important question. On

the other hand, a question such as ―Was the training center comfortable‖

might carry a weight of only 3. The weighted average is calculate by

multiplying the weight by the score (w * s) to get the final score. Thus the

formula is

snew = w * s.

Việc tổng hợp lại các câu trả lời sẽ cung cấp một lợi ich la trợ giúp

trong việc đƣa ra quyết định, do đó thông tin thu thập để đƣa ra quyết định

cần phải la những thông tin có chất lƣợng.Khi sử dụng các phân loại về

mức độ trong các câu hỏi (nhƣ ở trên), hãy nhớ không phải tất cả mức độ ở

các câu hỏi có giá trị tƣơng đƣơng nhau. Vi dụ mức độ 3 ở một câu hỏi

quan trọng phải đƣợc tinh lớn hơn mức độ 3 ở một câu it quan trọng hơn.

Do đó,nó la ý tƣởng tốt để sử dụng trọng lƣợng trung bình trong công thức

tính toán. Để lam điều nay, chỉ định một ―trọng lƣợng‖ hoặc mức độ tầm

quan trọng của mỗi câu hỏi. Vi dụ, câu hỏi trƣớc có thể đƣợc chỉ định một

trọng lƣợng =5, có nghĩa la đây la một câu hỏi rất quan trọng. Mặt khác,

một câu hỏi chẳng hạn nhƣ "La trung tâm đao tạo thoải mái‖ có thể mang

một trọng lƣợng chỉ có 3. Các trung bình đƣợc tinh toán bằng cách nhân

trọng lƣợng của các điểm số (w * s) để có đƣợc những điểm số cuối cùng.

Vì vậy, công thức la:

snew = w * s. (w: trọng lƣợng, s: cấp độ)





Several problems might result from a poorly constructed

questionnaire. Leniency is caused by respondents who grade

nonsubjectively — in other words, too easily. Central tendency occurs

when respondents rate everything as average. The halo effect occurs when

the respondent carries his good or bad impression from one question to the

next.

Một số vấn đề xảy ra la do hậu quả từ bảng câu hỏi đƣợc xây 0dựng

nghèo nan. Sự dễ dãi của ngƣời đƣợc hỏi cũng la một vấn đề. Họ không

phân loại các câu hỏi về mức độ quan trọng của nó ma xem các câu hỏi la

nhƣ nhau. Nhiều khi họ có ấn tƣợng tốt hay xấu về câu hỏi trƣớc va đem ấn

tƣợng nay gán vao câu hỏi sau.

Several methods can be used to deploy a survey successfully. The

easiest and most accurate is to gather all respondents in a conference room

and hand out the survey. For the most part, this is not realistic, so other

approaches would be more appropriate. E-mail and traditional mail are two

methodologies that work well, although you often must supply an incentive

(i.e., prize) to get respondents to fill out those surveys on a timely basis.

Web-based surveys (Internet and Intranet) are becoming increasingly

popular because they enable the inclusion of demos, audio, and video. For

example, a Web-based survey on what type of user interface is preferable

could have hyperlinks to demos or screen shots of the choices.





Một số phƣơng pháp có thể đƣợc sử dụng để triển khai một cuộc

khảo sát thanh công. Đơn giản nhất va chinh xác nhất la phải tập trung tất

cả ngƣời trả lời trong một phòng họp va trao tay bảng khảo sát. Đối với

hầu hết các phần, điều nay la không thực tế, vì thế phƣơng pháp khác sẽ

thich hợp hơn. E-mail va thƣ truyền thống la hai phƣơng pháp luận lam việc

tốt, mặc dù bạn thƣờng phải cung cấp một sự khuyến khich (nghĩa la, giải

thƣởng) để lam cho ngƣời trả lời điền đầy vao những bảng khảo sát trong

một khoảng thời gian nhất định. Khảo sát dựa vao web (Internet va

Intranet) đang ngay cang trở nên phổ biến, vì họ cho phép sự bao gồm của

trình diễn, âm thanh, va video. Vi dụ, khảo sát dựa vao web về loại hình

giao diện ngƣời sử dụng nao đƣợc yêu thich có thể có các siêu liên kết đến

trình diễn hoặc ảnh chụp man hình của những lựa chọn.

Creative Research Systems summarizes the different approaches to

surveys in the table shown in Exhibit 4-1.

Hệ thống Nghiên Cứu Sáng Tạo (Creative Research System) tóm tắt

các phƣơng pháp tiếp cận khác nhau để khảo sát trong bảng hiển thị trong

bảng 4-1.

4.2.3 Observation

Sự quan sát

Observation is an important tool that can provide a wealth of

information. There are two forms of observation: silent and directed. In





silent observation, the analyst merely sits on the sidelines with pen and pad

and observes what is happening. If it is suitable, a tape recorder or video

recorder can record what is observed. However, this is not recommended if

the net result will be several hours of random footage.

Quan sát la 1 phƣơng pháp quan trọng để thu đƣợc số lƣợng lớn

thông tin. Có 2 hình thức của sự quan sát: Quan sát gián tiếp (Silence) và

quan sát trực tiếp (derected). Quan sát gián tiếp hay còn gọi la quan sát

trong im lặng: Có nghĩa la ngƣời quan sát chỉ đơn thuần ngồi ngoai những

gì đang diễn ra để quan sát va ghi chép lại với bút, tập giấy hay sữ dụng

băng, đĩa để lƣu lại những gì đã quan sát đƣợc. Tuy nhiên, điều nay la

không nên nếu những kết quả thu đƣợc lấy từ những kết quả quan sát không

có mục đich (ngẫu nhiên).

Silent observation is best used to capture the spontaneous nature of a

particular process or procedure. For example:

When customers will be interacting with staff

During group meetings

On the manufacturing floor

In the field





Quan sát gián tiếp la phƣơng pháp tốt nhất để ghi lại những hình ảnh

đƣợc thực hiện tự nhiên liên quan đến các quá trình hay thủ tục. Vi dụ:

Khi nhân viên đang lam việc với khách hang.

Trong quá trình họp.

Trên khu vực sản xuất.

Trong một số lĩnh vực khác.

Directed observation provides the analyst with a chance to

microcontrol a process or procedure so that it is broken down into its

observable parts. At one accounting firm a tax system was being developed.

The analysts requested that several senior tax accountants be coupled with a

junior staff member. The group was given a problem as well as all of the

manuals and materials needed. The junior accountant sat at one end of the

table with the pile of manuals and forms while the senior tax accountants

sat at the other end. A tough tax problem was posed. The senior tax

accountants were directed to think through the process and then direct the

junior member to follow through on their directions to solve this problem.

The catch was that the senior members could not walk over to the junior

person or touch any of the reference guides. This whole exercise had to be

verbal and use just their memories and expertise. The entire process was

videotaped. The net result was that the analyst had a complete record of

how to perform one of the critical functions of the new system.





Quan sát trực tiếp:Cung cấp cho ngƣời quan sát cơ hội kiểm soát

từng chi tiết của các quá trình hay thủ tục, từ đó các quá trình đƣợc chia nhỏ

thanh từng phần để quan sát. Tại một công ty tinh toán hệ thống thuế đã

đƣợc phát triền, các nha phân tich một số yêu cầu kế toán cao cấp đi đôi với

một nhân viên cấp cơ sở. Nhóm nay đƣợc giao cho vấn đề cũng nhƣ tất cả

các thiết bị va vật chất họ cần. Nhân viên kế toán ngồi ở một bên của ban

với một chồng hƣớng dẫn va biểu mẫu trong khi những nhân viên kế toán

thuế cấp cao ngồi ở đầu bên kia ban. Một vấn đề khó khăn đƣợc đặt ra,

những nhân viên thuế cao hơn đƣợc hƣớng dẫn la suy nghĩ về các quá trình

thực hiện sau đó hƣớng dẫn lại cho các nhân viên thuế thấp hơn theo những

gì họ đã hƣớng dẫn để giải quyết vấn đề. Việc nắm bắt của các nhân viên

cấp thấp không phải la việc chỉ sơ qua của các nhân viên cấp cao hơn hay

chỉ dẫn qua tai liệu hƣớng dẫn ma toan bộ phải thực hiện bằng lời nói va

những kinh nghiệm va chuyên môn. Toan bộ quá trình đƣợc ghi lại. Kết quả

cuối cùng la các nha phân tich đã có một bản ghi đầy đủ để thực hiện những

đánh giá cho hệ thống mới.

4.2.4 Participation

Sự tham gia

The flip side of observation is participation. Actually becoming a

member of the staff and thereby learning exactly what it is that the staff

does, so that it might be automated, is an invaluable experience.





Bên cạnh việc quan sát la việc tham gia. Thực sự trở thanh thanh

viên của đội ngũ nhân viên va qua đó học tập một cách chinh xác những gì

mà các nhân viên đó lam. Đó la những kinh nghiệm vô giá.

Documentation: It is logical to assume that a wide variety of

documentation will be available to the analyst. This includes, but is not

limited to, the following:

Tai liệu hóa: Một cách hợp lý để cho rằng các tai liệu hóa khác nhau

sẽ luôn luôn sẵn sang để phân tich. Bao gồm các loại sau đây:

Documentation from existing systems, including requirements and

design specifications, program documentation, user manuals, and

help files. (This also includes whatever ―wish‖ lists have been

developed for the existing system.)

Archival information

Policies and procedures manuals

Reports

Memos

Standards

E-mail





Minutes from meetings

Government and other regulatory guidelines and regulations

Industry or association manuals, guidelines, and standards (e.g.,

accountants are guided not only by in-house ―rules and

regulations‖ but also by industry and other rules and regulations)

Tài liệu hóa những hệ thống đã tồn tại từ trƣớc bao gồm: các yêu

cầu, chi tiết thiết kế, tai liệu chƣơng trình, hƣớng dẫn sử dụng va

các hỗ trợ.

Thông tin thu thập đƣợc.

Các chính sách va các thủ tục hƣớng dẫn.

Báo cáo

Bản lƣu trữ, ghi nhớ.

Các chuẩn quy định

Thƣ điện tử

Chính quyền va các nguyên tắc va các quy định pháp lý khác





Các quy định chung của nganh công nghiệp hay các hƣớng dẫn về

tiêu chuẩn doanh nghiệp

4.2.5 Competitive Intelligence

Competitive intelligence (CI) is business intelligence that is limited

to competitors and how that information affects strategy, tactics, and

operations (Brock, 2000b). 4Sight partners (2000) define competitive

intelligence as ―a systematic and ethical program for gathering, analyzing,

and managing external information that can affect your company‘s plans,

decisions, and operations‖. 4Sight goes on to state that utilization of the

Internet as the method of gathering information on individuals and

companies has become widespread and automatic. CI enables management

to make informed decisions about everything from marketing, R & D, and

investing tactics to long-term business strategies (SCIP, 2002).

4Sight partners(2000) xác định CI la ‖Chƣơng trình có tinh hệ thống

va chuẩn mực để thu thập, phân tich, quản lý các thông tin bên ngoài mà

ảnh hƣởng tới các kế hoạch, quyết định hay sự hoạt động của công ty bạn‖.

4Sight cũng nhận định rằng Internet đang trở thanh công cụ tự động va

đƣợc sử dụng rộng rãi để thu thập thông tin từ các cá nhân va công ty. CI

hỗ trợ cho các vấn đề quản lý nhƣ: đƣa ra các quyết định về marketing,

R&D, va chiến thuật đầu tƣ tới các chiến lƣợc dai hạn của công ty.

CI data can be gathered from the following sources:





Internet discussion groups (listservs) and news groups (Usenet).

Simple searches on the Internet can obtain expert discussions on

issues in listservs and Usenet (Graef, 2002). Often a quick form of

CI is to search these Internet postings for discussions of similar

issues. The level of detail contained in these discussions is

beneficial for things to do and also things that will not work

(Graef, 2002). This is one of the quickest and most cost-effective

methods of obtaining information about a project (Graef, 2002).

Former employees of your competitors often are invaluable in

providing information about your competitors‘ operations,

products, and plans.

Your competitors‘ Web sites usually contain marketing

information about products and services offered as well as press

releases, white papers, and even product demos. Product demos

enable the analyst and business manager to effectively ―reverse

engineer‖ the competitive product (i.e., see how it ticks).

If your competitor is a public company then its investor relations

Web page will contain a wealth of financial information such as

annual reports. An alternative source of financial filings can be

found at www.sec.gov. A company‘s 10Q (quarterly) and 10K

(annual) reports contain information on products, services,

products, budgets, etc.





Dữ liệu CI có thể thu thập từ các nguồn sau:

Các nhóm thảo luận(listservs) va các nhóm tin tức(Usenet) trên

Internet. Có thể tìm các thảo luận rất sâu sắc về các vấn đề của

listservs va Usenet một cách dễ dang. Các thảo luận nay có thể rất

có lợi cho việc xác định điều gì nên lam va điều không nên lam cho

doanh nghiệp. Đây la nơi rất có ich cho bạn để thu thập yêu cầu

phần mềm.

Các cựu nhân viên của các công ty cạnh tranh có thể không cung

cấp thông tin của công ty các công ty cạnh tranh nay nhƣng có thể

đƣa các thông tin lên CI.

Các trang web của các công ty cạnh tranh chứa các thông tin về

marketing về sản phẩm,…Demo của các sản phẩm cũng có thể

xuất hiện trên các trang web. Từ đó có thể các doanh nghiệp hay

các nha phân tich có thể ―copy‖ sản phầm cạnh tranh.

Nếu công ty cạnh tranh la công ty public thì các trang web về các

đầu tƣ có thể chứa thông tin về tai chinh của công ty đó. Một nơi

chứa thông tin tai chinh của các công ty la www.sec.gov.

Normally, it is the role of the business or marketing manger to

perform competitive intelligence. However, when this is obviously not

being done, a proactive systems analyst will take the lead.


http://www.sec.gov/




Việc tiến hanh CI la việc của các doanh nghiệp hay các quản lý

marketing. Nếu công việc nay không đƣợc thực hiện thì có thể tiến hanh

các phƣơng pháp khác thay thế.

4.2.6 Brainstorming

In a brainstorming session you gather together a group of people,

create a stimulating and focused atmosphere, and let people come up with

ideas without risk of being ridiculed. Even seemingly stupid ideas may turn

out to be ―golden‖.

Điều kiện trong một buổi họp Brainstorming, một nhóm ngƣời tập

họp lại, tạo ra không khi tập trung va khuyến khich mọi ngƣời suy nghĩ và

để mọi ngƣời theo đuổi nọi ý nghĩ ma không hề có sự chế nhạo. Đôi khi các

ý kiến ngu ngốc có thể biến thanh vang.

4.2.7 Focus Groups

Nhóm tập trung

Focus groups are derived from marketing. These are structured

sessions where a group of stakeholders are presented with a solution to a

problem and then are closely questioned on their views about that solution.

Phƣơng pháp nay bắt nguồn từ marketing. Đây la buổi họp để đƣa ra

các giải pháp để các bên liên quan cho ý kiến về các giải pháp đó.





4.2.8 Prototyping

Mẫu thử

A prototype is a simplified version of part of the final system.

Developers experiment with the prototype to get an idea of how it would

work in real life and what its problems and plus points are.

Một Prototype la một phiên bản đơn giản của một phần của hệ thống

phần mềm cuối cùng. Đƣa Prototype vao chạy thử nghiệm để lấy ý kiến về

cách thức nó hoạt động trong thực tế va các vấn đề phát sinh.

4.3 A CHECK LIST FOR REQUIREMENTS MANAGEMENT

Bảng checklist cho quản lý yêu cầu

The requirements management checklist shown in Exhibit 4-2 is

used by the U.S. Department of the Navy.

Bảng nay đƣợc thể hiện ở Exhibit 4-2. bảng nay đƣợc US

Department of the Navy sử dụng

4.4 KẾT LUẬN

Information gathering is a very intensive process with many aspects.

The more information one has about a project from the start, the better

prepared one will be to complete the project. Successful project





management demands that enough information be known at the beginning

of a project to anticipate potential problems in the systems development life

cycle (Keogh, 2000). The role of a systems analyst in information gathering

is to gain knowledge and interpret it to the benefit of the project plan.

Anthony Smith said that turning information into knowledge is the creative

skill of our age (ASH, 2002).

Thu thập yêu cầu phần mềm la quá trình nhạy cảm với rất nhiều khia

cạnh. Thông tin yêu cầu cang chi tiết thì việc thực hiện dự án phần mềm sau

nay dễ dang hơn. Thông tin yêu cầu đƣợc thu thập đầy đủ ban đầu thì có thể

kiểm soát đƣợc các vấn đề phát sinh khi thực thi dự án phần mềm. Công

việc thu thập yêu cầu cần đƣợc đƣa vao kế hoạch thực hiện dự án.




Chương 5: Thiết kế hệ thống theo hướng người sử dụng 189

CHƢƠNG 5 THIẾT KẾ HỆ THỐNG THEO

HƢỚNG NGƢỜI SỬ DỤNG

Người dịch:

1. Dƣơng Hữu Thanh

2. Trần Xuân Tiến

3. Nguyễn Tấn

4. Trịnh Đắc Thắng

5. Lê Hoang Vũ





Developers of system software need to involve users in the design

process from the start. Until now, developers have kept the secrets of their

trade to themselves. At the same time, they have failed to take an interest in

the work of the business for which they are producing a tool. Users

frequently share in the development process only through beta tests of

products long after they have been designed. Users can frequently be a

constant source of data on work habits, loads, and performance

requirements. Developers can keep up with user needs the same way they

are required to keep up with changes in technology. Maintaining a good

relationship between the development and user communities ensures a

healthy development process.

Nha phát triển phần mềm hệ thống cần chú ý đến ngƣời dùng trong

quá trình thiết kế từ lúc bắt đầu. Cho đến bây giờ, các nha phát triển cứ giữ

bi mật thƣơng mại cho riêng mình. Trong lúc đó, họ lại thất bại trong việc

tạo thú vị cho công việc của doanh nghiệp, ma họ đã cung cấp công cụ.

Những ngƣời sử dụng thƣờng chia sẻ quan điểm dùng của mình đối với

phần mềm duy nhất thông qua bản beta ma sau đó chúng sẽ đƣợc thiết kế

lại. Ngƣời sử dụng thƣờng có thể cung cấp nguồn dữ liệu dồi dao về thói

quen lam việc, nạp dữ liệu va yêu cầu thực hiện của phần mềm nhƣ thế nao.

Liệu nha phát triển có thể theo kịp nhu cầu của ngƣời sử dụng cũng nhƣ đòi

hỏi theo kịp với những thay đổi trong kĩ thuật va việc duy trì mối quan hệ





tốt giữa việc phát triển va cộng đồng ngƣời sử dụng đảm bảo một quá trình

phát triển tốt.

5.1 BÍ MẬT THƢƠNG MẠI

During the last few decades while automation of the business world

has proceeded at an ever-accelerating pace, the practitioners of the black art

of systems development have jealously guarded the secrets of their trade.

Members of today‘s computer cult, who talk among themselves in tongues

of Java, C++, and all things Internet, have forgotten the sounds of the

human language — so much so that it is often necessary to hire a translator

to explain the systems developer‘s work to the confused customer, the

actual user of the cult‘s handiwork.

Trong suốt một vai thập kỷ gần đây trong khi sự tự động hóa của thế

giới thƣơng mại tiến lên không ngừng, Các học viên black art của sự phát

triển hệ thống thì tranh nhau bảo vệ bi mật thƣơng mại riêng của họ. Những

thành viên của trƣờng phái máy tinh ngay nay, họ thƣờng nói với nhau bằng

ngôn ngữ Java, C++ va tất cả những ngôn ngữ mạng, ma quên đi ngôn ngữ

tự nhiên của con ngƣời, họ dùng quá nhiều ngôn ngữ máy tinh vì thế sẽ cần

phải thuê 1 ngƣời thông dịch để giải thich công việc của ngƣời phát triển hệ

thống cho những khách hang thắc mắc (ngƣời dùng thực tế của trƣờng phái

việc lam, những ngƣời lam việc).





This translator would not be needed if companies would design their

systems with the user in mind. That means involving end users at the start

of the systems development process. To accomplish this, the technical staff

must take some time away from studying the nuts and bolts of new tools to

learn the tricks of the users‘ trades.

Thật ra thì ngƣời thông dịch nay sẽ trở nên không cần thiết nếu

những công ty lƣu ý đến ngƣời sử dụng khi thiết kế (thiết kế theo hƣớng

ngƣời sử dụng). Điều đó thì liên quan tới ngƣời sử dụng cuối cùng khi bắt

đầu của tiến trình phát triển hệ thống. Để thực hiện điều nay, các nhân viên

kĩ thuật phải mất một thời gian để nghiên cứu các nút thắt va mấu chốt của

công cụ mới, (công cụ ma họ lam cho ngƣời dùng cuối) va phải tìm hiểu,

học hỏi những thủ thuật, bi quyết trong kinh doanh của ngƣời dùng.

It also means that the end users need to be encouraged to get

involved in the entire systems development effort, from the specification

stage to actual application testing. Their involvement will help ensure that

the finished system meets their needs and, in turn, the information needs of

the corporation.

Điều đó cũng có nghĩa la ngƣời dùng cuối đƣợc khuyến khich trong

việc tham gia vao sự phát triển của toan bộ hệ thống, từ những giai đoạn

đặc điểm kĩ thuật đến việc thử nghiệm thực tế. Sự tham gia của họ sẽ giúp

đảm bảo rằng hệ thống sau khi hoan thanh đáp ứng nhu cầu của họ va hơn

nữa cũng đáp ứng nhu cầu thông tin của công ty.





Today, under traditional systems analysis methods, the user is

frequently left out of the loop. During the standard requirements definition

phase, representatives from the user department are interviewed. Then a

work flow analysis may be performed to determine the relationships

between functions within that department. Finally, several months after the

requirements definition, some customer testing is conducted — testing that

unfortunately constitutes the sum total of user involvement. So it is not

surprising that a plethora of changes must be made after the user finally

reviews the test results.

Ngay nay, dựa vao phƣơng pháp phân tich hệ thống truyền thống,

ngƣời sử dùng thƣờng bi rơi ra khỏi vòng lặp nay. Trong giai đoạn xác định

yêu cầu chuẩn, đại diện từ những ngƣời sử dụng của một phòng đƣợc

phỏng vấn. Sau đó, việc phân tich đƣợc thực hiện để xác định mối quan hệ

giữa chức năng cần thiết trong phòng đó. Cuối cùng, vai tháng sau, sau khi

những yêu cầu đƣợc xác định xong, một số bai test khách hang hƣớng dẫn

cho khách hàng – việc test nay đại diện cho tổng số những ngƣời sử dụng.

Vì thế không ngạc nhiên khi xảy ra việc thừa của việc thay đổi phải đƣợc

lam sau khi ngƣời sử dụng đánh giá kết quả bài test.

5.2 VIỆC TAILOR HỆ THỐNG TỚI YÊU CẦU NGƢỜI DÙNG CUỐI

The systems staff can avoid this last-minute retrofit by building a

system tailored to specific end-user needs. To do that tailoring, the IT team





should apply the same quick-study principle used in keeping up with new

technology to learning end-user job functions. In fact, systems designers

should know these functions at least as well as a six-month employee who

is doing that work.

Các nhân viên hệ thống có thể tránh (sai lầm phút cuối cùng) (this

last-minute retrofit, retrofit trang bị thêm) bằng cách xây hệ thống tailored

để cụ thể yêu cầu của ngƣời sử dụng cuối. Để lam đƣợc điều đó, đội ngũ IT

cần áp dụng cùng việc nghiên cứu nhanh (học tập nhanh chóng) để theo kịp

với kĩ thuật mới trong việc tìm hiểu (học) những chức năng trong công việc

của ngƣời sử dụng cuối. Thực tế, những ngƣời thiết kế hệ thống phải cần

nên biết những chức năng nay it nhất la nhƣ một nhân viên đã lam việc đó

đƣợc 6 tháng.

The necessary knowledge, however, is not always easy to come by

because, all too often, systems gurus balk at attending user meetings. A big

price tag may be attached to such behavior, as the New York Stock

Exchange (NYSE) found out during my tenure there. During the mid-

1980s, a series of user meetings was held to determine the rules and

regulations of an important regulatory system that the Exchange wanted to

develop. The NYSE‘s IT group found these critical meetings boring and, as

a consequence, the finished system ended up incomplete; much money

had to be spent adding enhancement features.





Tuy nhiên, những kiến thức cần thiết không phải luôn dễ dang đến va

cũng không thƣờng xuyên đến, bởi vì có chƣớng ngại trong việc tham gia

các cuộc họp của ngƣời dùng. Một cái giá lớn có thể gắn liền với hanh vi

nhƣ vậy, nhƣ NYSE đã tìm ra trong giai đoạn (nhiệm kỳ) ma tôi ở đó. Giữa

thập niên 1980, một loại các cuộc họp ngƣời sử dụng đƣợc tổ chức để xác

định luật va quy định của hệ thống điều chỉnh ma Exchange muốn phát

triển. Kết quả la Nhóm IT của NYSE đã phát hiện đƣợc những cuộc họp

nay, hệ thống đã hoan thanh kết thúc không đầy đủ, nhiều tiền phải bỏ ra để

thêm vao những tinh năng nâng cao.

A thorough immersion in the customer‘s culture also negates the

―we‖ versus ―them‖ attitude that exists between many end users and the

supporting IT staff. Top managers in the IT division at a major New York-

based Swiss Bank learned this lesson the hard way. The bank‘s foreign

exchange trading group was adamant about needing a foreign exchange

trading system. The head of the Swiss Bank‘s IT department disagreed, so

the trading group brought in an outside consultant who spoke their language

and care fully listened to what they had to say.

Việc nhúng hoan toan trong nền văn hóa của khách hang cũng phủ

nhận thái độ ―chúng tôi‖ so với ―họ‖, điều đó tồn tại giữa nhiều ngƣời sử

dụng cuối va các nhân viên IT hỗ trợ. Ngƣời quản lý cao nhất trong bộ phận

IT của cơ sở Swiss Bank chinh ở New York đã học đƣợc bai học nay một

cách khó khăn. Nhóm thƣơng mại đối ngoại của ngân hang thì cứng rắn

(quyết) về việc cần một hệ thống thƣơng mại đối ngoại. Ngƣời đứng đầu bộ





phận IT của Swiss Bank không đồng ý, vì thế nhóm thƣơng mại đƣa một

nhà chuyên môn – ngƣời ma nói đƣợc những ngôn ngữ của họ va nghe một

cách cẩn thận những gì họ nói.

As a result, the consultant was able to develop a usable, mostly error

free system that the users proudly showed off to other departments at the

bank. At the next IT status meeting, users demanded to know why the IT

staff could not or would not deliver systems as fast and as good as the one

built by the foreign exchange group. Needless to say, the management of

Swiss Bank‘s IT group was soon replaced.

Kết quả la nha chuyên môn có thể phát triển va sử dụng, hầu hết lỗi

rảnh trong hệ thống la thứ ma ngƣời sử dụng tự hao với các phòng ban khác

trong ngân hang. Tại cuộc hợp tình trạng của IT kế tiếp, ngƣời dùng muốn

biết tại sao các nhân viên IT không thể va sẽ không cung cấp hệ thống càng

nhanh cang tốt nhƣ la đã xây bởi nhóm đối ngoại (ngoại hối ?). không cần

phải nói thêm, thế nao quản lý của nhóm IT Swiss Bank cũng bị thay thế.

5.3 KÊU GỌI SỰ HĂNG HÁI

Once you have a user-friendly IT staff, then you need to drum up

enthusiasm and interest among the user community so that it will want to be

involved every painful step of the way. ―Community‖ is the operative word

here because as many users as is feasible should be involved in the systems

development process. In today‘s systems world, however, the norm is to





have only one user who serves as the liaison for the entire group and assists

the IT team as it develops specifications and tests the application.

Một khi bạn có một nhân viên IT thân thiệt với ngƣời dùng, thì bạn

cần phải kêu gọi sự nhiệt tình va thú vị trong cộng đồng ngƣời sử dụng để

ma họ sẽ chịu để tâm vao những bƣớc rắc rối của quá trình. ―cộng đồng‖ là

một từ thực tế ở đây, bởi vì cang nhiều ngƣời dùng tham gia thì cang khả

thi trong quá trình phát triển hệ thống. Tuy nhiên, trong những hệ thống thế

giới ngay nay, mức nay thì chỉ để cho 1 ngƣời dùng liên lạc phục vụ cho

toan nhóm va giúp đội IT khi phát triển kĩ thuật va kiểm tra các ứng dụng.

Can one person adequately represent an entire user group? The

answer is almost always no if you want a system worth its development

dollars. Although involving many users can cause giant headaches, if the

process is properly handled, the resulting system will be superior.

Một ngƣời có thể đại diện mọi mặt cho toan nhóm ngƣời sử dụng

không? Câu trả lời hầu nhƣ luôn la không, (nếu bạn muốn thì việc phát triển

hệ thống nay sẽ tốn nhiều đô la). Mặc dù liên quan đến nhiều ngƣời dùng có

thể gây ra khó khăn lớn, nếu quá trình đƣợc xử lý thủ công một cách thich

hợp, hệ thống kết quả sẽ khá hơn.

That was the experience I had at the NYSE when faced with the

challenging chore of devising a system for over 150 professional users

spread through five separate departments.Despite the fact that each of the





five departments did the exact same job, the diversity of opinion among the

people in these units was nearly overwhelming. It took the great

organizational skills of a talented analyst to pull all the heterogeneous

information together into one cohesive specification. What resulted was far

more complex, but a much more accurate and usable system that covered

all the bases. To cover all those bases, the NYSE IT team formed a working

committee of users made up of one very verbal representative from each of

the five departments. For roughly three months prior to the start of the

specification stage, this working group would sometimes meet as often as

two or three times a week.The meetings were spent discussing actual use

cases upon which the system would be based. In this way, the users were

able to come up with all of the criteria that would ultimately be used in

developing the system. It was during this conceptual phase of system

definition that NYSE‘s IS staff and the departmental end users were able to

reach a meeting of the minds in terms of desired inputs and outputs.

Đó la kinh nghiệm tôi đã có tại NYSE khi phải đối mặt với thách

thức vặt vãnh hang ngay để nghĩ ra (sáng chế ra) một hệ thống cho hơn, 150

ngƣời dùng chuyên nghiệp thông qua 5 phòng ban riêng biệt. Mặc dù thực

tế mỗi cái trong 5 phòng ban lam những việc giống nhau, nhƣng sự đa dạng

về ý kiến giữa những ngƣời trong những phòng nay gần nhƣ áp đảo. Phải

mất kĩ năng tuyệt vời của nha phân tich tai năng để có thể kết những thông

tin không đồng nhất với nhau thanh một kỹ thuật liên kết. Điều nay thì cang

phức tạp hơn, nhƣng một hệ thống cang chinh xác va hữu dụng phải bao





ham toan bộ cơ sở nay. Để bao ham đƣợc tất cả các cơ sở nay, các nhóm IT

của NYSE phải hình thanh một ủy ban lam việc của ngƣời sử dụng, tạo

thanh đại diện (phát ngôn) từ mỗi phòng trong 5 phòng ban. Đối với khoảng

3 tháng, trƣớc khi bắt đầu giao đoạn kĩ thuật, nhóm lam việc ay đôi khi sẽ

gặp gơ thƣờng xuyên từ hai đến ba tuần một lần. Các cuộc họp danh thời

gian thảo luận về trƣờng hợp sử dụng thực tế ma hệ thống đặt cơ sở. Bằng

cách nay, ngƣời dùng đã có thể đến với tất cả các tiêu chi ma cuối cùng sẽ

đƣợc sử dụng trong việc phát triển hệ thống. Trong giai đoạn quan niệm về

định nghĩa hệ thống ma nhân viên IT của NYSE va những ngƣời sử dụng

cuối của các phòng ban có thể đi tới cuộc họp nhất tri trong việc giới hạn

mong muốn về đầu vao va đầu ra (giới hạn đầu vao va đầu ra nhƣ mong

muốn).

Determining the users‘ real information needs is indeed the stickiest

wicket of the entire specification process. If all you do is translate the paper

avalanche to the tube, then the ultimate system will not be much better than

the former manual one. In fact, many of these paperwork clone systems

actually decrease productivity.

Xác định các thông tin thực tế của nhu cầu ngƣời dùng thật la không

có lợi (stickiest wicket) cho toan bộ tiến trình kĩ thuật. Nếu tất cả những gì

bạn lam la dịch (chuyển) paper avalanche to the tube, sau đó hệ thống cuối

cùng sẽ không tốt hơn cái lam bằng tay (thủ công) trƣớc đây. Trong thực tế,

nhiều hệ thống paperwork nhân bản thật sự sẽ lam giảm năng suất.





The key to pinpointing the users‘ actual information needs is not to

present more data, but to present less, but more meaningful or relevant,

data. To date, IT has applied the pitch-hit-and-run theory to most systems

development. Little, if any, consideration has been given to the differing

information requirements of the various decision-making levels within an

organization. As a result, you end up with fancy applications that spit out a

kludge of irrelevant information.

Chìa khóa để xác định nhu cầu thông tin thật sự của ngƣời sử dụng

thì không đƣa ra nhiều dữ liệu, nhƣng để đƣa ra it, nhƣng có ý nghĩa hơn

hoặc có liên quan, dữ liệu. Đến nay, IT đã áp dụng lý thuyết pitch-hit-and-

run cho hầu hết sự phát triển hệ thống. Việc xem xét đã cung cấp những yêu

cầu thông tin khác nhau của những mức quyết định khác nhau trong 1 tổ

chức. Kết quả la, bạn kết thúc với các ứng dụng ƣu thich ma lại nói ra

những thông tin không liên quan về 1 lời giải nhanh.

5.4 PHƢƠNG PHÁP LUẬN

To avoid that systems scenario and to present the optimum mix of

detailand composite data to users, the developer can follow several time-

tested methods. All of the methods recognize a relationship between the

type ofuser and the level of detail needed to do the job or make a decision.

Để tránh kịch bản hệ thống va hiện diện điều kiện tốt nhất la hổn hợp

của dữ liệu ghép va chi tiết cho những ngƣời dùng. Lập trình viên có thể





theo sau nhiều phƣơng thức đã đƣợc kiểm tra đúng đắn.Tất cá các phƣơng

thức công nhận mối quan hệ giữa loại ngƣời dùng va cấp độ chi tiết cần

thiết để lam công việc hay đƣa ra quyết định.

The three types of users — technical, tactical, and strategic — corre-

spond to the three levels of workers in today‘s typical corporation.

Thetechnical users are generally the paper pushers in the corporate

hierarchy. These employees —check processors and complaint takers, for

example— are the people who need to see all the data. They input and

review a wealth of data, normally in rote fashion.

3 loại ngƣời dùng – chuyên môn, chiến thuật va chiến lƣợc – tƣơng

xứng với ba cấp độ ngƣời lam việc trong các công ty tiêu biểu ngay

nay.Những ngƣời dùng chuyên môn thì nói chung la ngƣời đẩy giấy tờ vao

hệ thống cấp bậc thuộc tập đoan. Những nhân viên – kiểm tra bộ xử li máy

tinh va la ngƣời nhận những than phiền, chẳng hạn – la những ngƣời cần

thấy tất cả các dữ liệu. Họ nhập dữ liệu vao va kiểm tra tinh đa dang của dữ

liệu, thông thƣờng la cách nhớ vẹt.

At the opposite end of the spectrum are the senior managers, who use

information gathered at the lower rungs for strategic purposes. A whole

range of executive information and decision support systems is now avail-

able to help this corporate vanguard. These wares feature flashy colors on

touch screens notable for the scarcity of data displayed. The data is likely to





show sales projections, profitability numbers, and comparisons with the

competition.

Ngƣợc lại với những ngƣời quản li có kinh nghiệm sử dụng tinh tức

tập hợp những cập bật thập hơn cho mục đich chiến lƣợc. Toan bộ những

tin tức va quyết định thực thi chống đở cho hệ thống thi có sẳn để giúp đở

nhũng tập đoan đi tiên phong. Nét đặc biệt những vật chế tạo nay la mau

sắc hao nhoáng, tiếp cận với man hình khan hiếm dữ liệu đƣợc trình bay.Dữ

liệu có thể để trình diễn để bán,lấy lợi nhuận, va so sánh với các đối thủ

cạnh tranh.

In the middle, between the strategic users and the technical users, are

the tactical users. These are the middle managers, the poor unfortunates

buried under the paper avalanche. It is these professionals who therefore

need the most careful balance of data.

Giữa ngƣời dùng chuyên môn va ngƣời dùng chiến lƣợc la ngƣời

dùng chiến thuật. Nhừng ngƣời nay giữa những ngƣời quản li..... Bởi vậy

những ngƣời chuyên nghiệp cần cân đối thật cẩn thận dữ liệu.

As always, users‘ needs dictate the data representation discipline

used.

Human resources or utility users, for example, are good candidates

for descriptive models in the form of rganization charts or floor plans. Mod-

eling is also a good mode for operations maagement students who want to





apply game theory to problems that lack supporting information. On the

other hand, a normative representation of data is an apt choice for budget

personnel, who need the best answer to a given problem.

Mệnh lệnh cần thiết của ngƣời dùng những...... Tai nguyên tự nhiên

va những ngƣời dùng có ich, chẳng hạn, la những ứng viện tốt cho mô hình

mô tả hình thức bản đồ một tổ chức hay những kế hoạch nền tảng. Mô hình

nay cũng la một mô hih tốt cho những chức năng quản li nhƣng viên những

ngƣời muốn dụng ứng dụng lý thuyết game vao vấn đề thiếu tin tức phụ trợ.

Mặc khác, những đặc trƣng đƣợc tiêu chuẩn hoá của dữ liệu la lựa chọn dễ

cho những nhân viên ngân quỹ, những ngƣời cần câu trả lời tốt nhất cho

vấn đền đƣa ra.

Deciding on the type of information and how to present it to a

particular group of users is the job of IT personnel. Sometimes they get

carried away with their mission. At the NYSE, for example, the systems

staff realized they had gone too far when adisplay for a large customer

exceeded 91 screens of information. Going back to the drawing board, they

came up with a plan to make the 91-screen monster more manageable.

What they did was use graphics to tame the tangle of numbers displayed,

coupled with embedded expert systems that enabled users to navigate

quickly and more effectively through the data. In this filtering process, the





systems developer sifts through the data, displaying only what is relevant at

any point in time.

Quyết định loại thông tin va trình bay nó thế nao cho một nhóm đặc

thù của ngƣời dùng la nghề nhân viên công nghệ thông tin. Thỉnh thoảng họ

bị cuốn theo vai trò của họ. Tại NYSE, chẳng hạn, ban hệ thống nhận ra

rằng họ đi quá xa khi trình bay cho một lƣợng khách hang lớn hơn 91 man

hình tin tức. Theo sau ban đồ hoạ, họ tới gần với kế hoạch lam 91 hình ảnh

quái vật có thể quản li tốt hơn. Những gì họ lam sử dụng đồ hoạ...Trong

tiến trình lọc, lập trình viên hệ thống chọn lọc dữ liệu, trình bay những gì

thich đáng ở một thời điểm nao đó.

One way to do the filtering is by using the monitoring method, which

serves up data to the user on an exception basis. This can take the form of

variance reporting, in which the system produces only exceptions based on

a programmatic review of the data. After reviewing credit card pay- ments,

a system can, for instance, display only those accounts where the payment

is overdue or below the minimum. The monitoring method can also be used

in programmed decision-making applications, in which case the system

makes all of the technical decisions and many of the tactical ones as well.

Một cách thức để lọc la sử dụng cách thức giám sát, phục vụ dữ liệu

cho ngƣời dùng trên vai ngoại lệ cơ bản. điều nay có thể la cách thức thuật

lại sự khác nhau, ma sản phẩm hệ thống chỉ ngoại lệ cơ bản xét duyệt

chƣơng trình dữ liệu. Sau khi xét duyệt tiền phải trả, hệ thống có thể, chẳng





hạn, trình bay chỉ những tai khoản nay những nơi trả tiền quá chậm hoặc

dƣới mức tối thiểu. Cách thức giám sát cũng cố thể đƣợc dùng trong ứng

dụng lam chƣơng trình, trong trƣờng hơp nao hệ thống lam tất cả quyết

định chuyên môn va nhiều quyết định chiến thuật tốt.

American Express made the decision to go with a monitoring method

that simplified its complex credit authorization chores. An expert system,

aptly named Authorizer Assistant, helped Amex reduce the percentage of

bad credit authorizations. It also reduced the number of screens needed to

review customer data from a high of 12 to a manageable 2.

Sự tốc hanh ngƣời Mĩ đƣa ra những quyết định đi cùng những cách

thức giám sát đơn giản hoá sự phức tạp công việc nhỏ. Một hệ thống

chuyên nghiệp, tên ngƣời phụ tá uỷ quyền thich hợp, giúp Amex rút ngắn

phần trăm những thẻ uỷ quyền xấu. Nó cũng rút ngắn số các hình ảnh cẩn

thiết để xét duyệt những dữ liệu khách hang.

The advent of fourth generation languages (4GLs), which enabled

end users to access corporate databases with an easy-to-use query syntax,

has made interrogative methods of systems design more popular today.

Implicit in this approach is the understanding that on many occasions

users in complex decision-making environments cannot identify the infor-

mation they need to perform ad hoc analyses. In these cases, all of the data

elements must be resident in an accessible database. There must also be a





tool that allows users to easily develop queries and variations on these

queries against the data.

Đế thế hệ ngôn ngữ thứ tƣ (4GLs), ngƣời dùng cuối có thể truy cập

dữ liệu công ty với cú pháp truy vấn dễ sử dụng, lam cho cách thức hỏi hệ

thống thiết kế phổ biến ngay nay. Ngầm định, gần đây hiểu đƣợc rằng có

nhiều cơ hội, những ngƣời dùng môi trƣờng đƣa ra quyết định phức tạp thì

không thể nhận ra tin tức họ cần thực hiện phân tich. Trong những trƣờng

hợp nay, tất cả các yếu tố dữ liệu cần một dữ liệu sử dụng đƣợc. Cần có

công cụ cho phép ngƣời dùng dễ dang phát triển truy vấn khác nhau trên

câu truy vấn nay dựa vao dữ liệu.

The ease-of-use factor provided by a 4GL came in very handy when

Bankers Trust in New York (now Deutsche Bank) opted to leave the retail

business. The data processing effort required to achieve this feat was

enormous. With the help of Focus, the 4GL product from Information

Builders in New York (www.ibi.com), the bank was able to ensure a

smooth transfer of accounts from Bankers to many other far-flung financial

institu- tions. Some accounts were spun off to a bank in Chicago and some

to Albany, New York, while a few high rollers were retained as privileged

Bankers Trust customers.

Yếu tố dễ sử dụng cung cấp bởi 4GL đƣợc xem la rất thuận tiện khi

Bankers Trust trong New York (giờ la Deutsche Bank) lựa chọn rời khởi

kinh doanh bán lẻ. Sự số gắng để gia công dữ liệu yêu cầu công sức không





lồ. Với sự giúp đở điều chỉnh, sản phẩm 4GL từ những nha xây dựng thông

tin trong New York (www.ibi.com), ngân hang đã có thể đảm bảo sự di

chuyển trôi trải của nhƣng tai khoản từ Bankers đến viện tai chinh rộng

khác.

Once users are certain about the correct way to handle the data, the

IT squad can then translate this information into the specification that spells

out how the system should run. In many IT shops, how a system should run

is a function of what is available in-house. This means that user require-

ments are forcibly fit into an existing tool set and — just like a bad shoe fit

— a bad system fit causes users great pain. Some of that pain was felt at the

Securities Industry Automation Corp. (SIAC), which originally cramped its

users by limiting tself to just one database product. SIAC began using

Total from Cincom Systems Inc., Cincinnati, back in 1977, when few

database tools were on the market. There was absolutely nothing wrong

with Total; what was wrong was the implicit order to use it for all systems.

Use it SIAC did — for everything!

Một vai tai khoản đƣợc quay quanh ngân hang Chicago va một vai

đến Albany, New York, trong khi một vai trục lăn cao đƣợc giữ lại nhƣ

những khách hang Bankers Trust có đặc quyền.Khi những ngƣời dùng chắc

chắn về cách chinh xác về xử li dữ liệu, tổ IT có thể phiên dịch thông tin

nay những chi tiết giải thich rõ rang hệ thống nên hoạt động nhƣ thế nao.

Trong nhiều cửa hang IT, một hệ thông nên chạy nhƣ một chức năng gốm

những gì có sẳn trong nha.. Điều nay có nghĩa la đòi hỏi ngƣời dùng phải


http://www.ibi.com/




cân đối vao một thiết lập công cụ có sẳn va một hệ thống xấu la hình phạt

lớn với ngƣời dùng.

5.5 PHÂN PHỐI DỮ LIỆU CHO CHỦ NHÂN HỢP PHÁP – NGƢỜI

DÙNG CUỐI

Most IT shops today design superbly efficient systems — for batch

and transaction-based systems. Unfortunately, these systems are then jury-

rigged for the part of the system visible to the user. Such technology tink-

ering often leaves the user out on a limb.

Phần lớn các nha cung cấp phần mềm ngay nay thiết kế các

(superbly efficient systems) hệ thống hiệu quả cho các thao tác (batch) và

hệ thống kinh doanh cơ sở (transaction-based systems). Thật không may

các hệ thống nhƣ thế thƣờng không hoan thiện, tạm bợ (jury-rigged) một

phần của hệ thống đối với ngƣời dùng. Nhƣ công nghệ tink-ering thƣờng để

ngƣời dùng văng ra ngoai.

That is exactly where some end users at the NYSE found themselves

when a billing system using a hierarchical production database was defined

to a 4GL. The database, which was composed of numerous seg- ments of

data keyed by a brokerage firm number, ran very fast during over- night

update processing due to its efficient design, specifically labored over for

this purpose.





Một điều chinh xác la ngƣời dùng cuối ở NYSE nhận thấy khi ma hệ

thống thanh toán sử dụng một sản phẩm database phân cấp (hierarchical

production database) đƣợc định nghĩa nhƣ la một 4GL. Các Database đó,

cái ma tich hợp trong nó nhiều phân đoạn (segment) của các dữ liệu khoá

của một số công ty mua giới xử lý rất nhanh trong các tiến trình nâng cấp

bất ngờ nhờ sự thiết kế hiệu quả của nó,va rõ rang thì phải tốn công sừ hơn

cho mục đich nay.

Meanwhile, some NYSE users were anticipating a new system with

the extra added attraction of ad hoc inquiry. By a happy coincidence — or

so it was originally thought —a 4GL had just been brought into the

Exchange for end-user computing. The hierarchically defined database was

dutifully defined to RAMIS; the users were trained and then let loose.

RAMIS came up empty.

Trong lúc ấy, một vai ngƣời dùng ở NYSE đang đề cập đến một hệ

thống mới với sự tich hợp của các yêu cầu đặc biệt. Bởi một sự trùng hợp

ngẫu nhiên hoặc la nó la một cách nghĩ mới mẻ - 4GL đã đƣợc mang đến sở

giao dịch (Exchange) cho ngƣời dùng sử dụng tinh toán. Cái database-đƣợc

định nghĩa phân cấp(hierarchically defined database) đƣợc định nghĩa một

cách nghiêm túc la RAMIS, các ngƣời dùng đƣợc huấn luyện va sau đó

đƣợc cho lam một cách tự do. RAMIS trở nên thiếu. (RAMIS came up

empty).





The problem was that bane of logic, the JOIN. Although the internal

database was segmented into a logical structure for efficiencies, the data on

every brokerage house was dispersed throughout, making it difficult for he

users to get to it without understanding a bit more than they wanted to know

about information processing.

Cái nguyên nhân đến từ sự suy sụp về mặt logic – JOIN(phép kết

trong Đai số quan hệ). Mặc dù bên trong database đƣợc phân chia thanh các

cấu trúc logic để hiệu quả hơn, nhƣng các data từ các nha mua giới lại đƣợc

phân tán ra khắp nơi, điều đó lam cho nó khó sử dụng đối với những ngƣời

dùng không hiểu hơn la việc ma họ muốn biết thông tin.

There are as many ways of designing systems as there are people to

use them. Most systems are designed out of prejudice: John Doe, the

database administrator at the Widget Corp., is expert at Microsoft Access;

therefore, all systems at the company are designed using Microsoft Access.

Most corporate systems are designed around some sort of heavy-duty

database. There are several types of database architectures: hierarchical, as

in IBM IMS; networked, as in Computer Associates‘ IDMS, which has

lately morphed into a combination networked and relational database;

relational, as in Microsoft‘s SQL Server; and object oriented, as in

Objectivity‘s Objectiv- ity/DB. The proper choice depends upon many

factors, not the least of which should be ease of access by the user.





Có nhiều cách để thiết kế hệ thống tuỳ thuộc vao những ngƣời sử

dụng chúng. Hầu hết các hệ thống đƣợc thiết kế theo sở thich: John Doe

nha quản trị database của Widget Corp ngƣời chuyên về Microsoft Access,

vì thế các hê thống tại công ty đƣợc thiết kết dựa trên Microsoft Access.

phần lớn các hệ thống chung đƣợc thiết kế cho phù hợp dựa vao một hệ cơ

sở dữ liệu quan trọng nao đó. Có nhiều kiến trúc database:

Cơ sở dữ liệu phân cấp (hierarchical) nhƣ IBM IMS

Cơ sở dữ liệu mạng lƣới (network) nhƣ IDMS của Computer

Associates, cái ma mới đây morphed into kết hợp giữa cơ sở dữ

liệu mạng va cơ sở dữ liệu quan hê.

Cơ sở dữ liệu quan hệ (relational) nhƣ SQL Server của Microsoft

Cơ sở dữ liệu hƣớng đối tƣợng Objectivity‘s Objectivity/DB.

Sự lựa chọn đúng đắn phải dựa vao nhiều yếu tố chứ không chỉ dựa

vao loại cơ sở dữ liệu nao dễ dang sử dụng cho ngƣời dùng.

Serious decisions must also be made regarding the system platform.

In a world of mainframes, PCs, minicomputers, advanced workstations,

Inter- net, and Intranets, the endless possibilities boggle the systems

developer‘s mind. Solutions run the gamut from pure mainframe to a cluster

of connected micros and minis to web-based distributed. In vogue today is





an any-to-any environment where a user with a smart workstation has easy

access to various mainframes, minis, or PCs across an Intranet.

Quyết định thực sự còn dựa trên nền tảng của hệ thống. Có rất nhiều

thanh phần mainframes, PCs, minicomputers, workstations, Internet, and

Intranets va rất nhiều khả năng xãy ra sẽ lam cho những ngƣời phát triển hệ

thống do dự. Những giải pháp có thể thay đổi để phù hợp cho những máy

mainframe hoặc đến hệ thống có kết nối của những máy micro va mini hoặc

hệ thống web-based. Cái xu thế của ngay nay la một môi trƣờng mọi với

mọi (any-to-any environment) nơi ma user với một workstation có thể dễ

dang liên kết với những máy mainframes, minis, hay PCs thông qua

internet.

5.6 SỰ LỰA CHỌN CHO CÁC HỆ THỐNG

Choosing hardware and software is truly the fun part of systems

design. Visits to vendors and trips to trade shows where you can play with

test equipment transport you into an IT Disneyland. But while you are out

there high-teching it up, at some point you had better come down to earth

and get the user involved. If not, your dream machine will turn into an

expensive nightmare. So, no matter what platform or program you pick,

the user variables in making your selection must be examined at every

technological turn. Among those user considerations are cost, ease of use,

access to corporate data, graphics requirements compatibility with current

environment, and particular preferences.





Việc lựa chọn phần cứng hay phần mềm cho hệ thống la một công

việc khá thú vị. Viếng thăm các đại lý, tham dự các cuộc triển lãm nơi ma

bạn có thể thử va test những thiết bị sẽ đƣa bạn diến vùng đất thú vị của tin

hoc. Tuy nhiên, sau khi nếm trải đủ những sự kì diệu đó thì bạn phải chú ý

đên quan điểm va khả năng chi tra của ngƣời sử dụng, nếu không thì hệ

thống của bạn sẽ chỉ la một giấc mơ xa sỉ. vì vậy thì dù bạn chọn nền tảng

hệ thống (platform) va ứng dụng thế nao thì những sự thay đổi của ngƣời

dùng luôn phải đƣợc nghiên cứu. những điều ngƣời dùng suy xét tới la giá

thanh, dễ dang trong sử dụng, khả năng kết hợp với dữ liệu, các yêu cầu về

mặt đồ hoạ sự tƣơng thich với môi trƣờng hay thậm chi la sở thich riêng.

Ease of use was the major criterion that caused some equipment the

NYSE was considering to be scuttled. Bar code readers for use in the field

were the equipment under investigation. The technial group at the

Exchange, who thought they had found the perfect solution, promptly

ordered sample equipment and found that it worked like a charm. How-

ever, in order for it to work properly, the credit-card size readers had to be

held at a certain angle. It was a good thing the users were consulted because

it turned out that they were not able to hold the devices at that precise angle.

Dễ sử dụng la một tiêu chuẩn chinh, la lý do ma một vai thiết bị

NYSE đƣợc đánh giá la không thanh công. Vi dụ về dụng cụ đọc mã vạch

chẳng hạn. Các kỹ thuật viên ở Exchange (sở giao dịch) đã nghĩ rằng ho tìm

ra môt phƣơng án tuyệt vời,va lập tức lam các thiết bị mẫu, họ nhận thấy

rang nó lam việc một cách hoan hảo. Tuy nhiên, mạc dù cho nó lam việc





một cách hiệu quả thì miếng dán mã vạch cần phải dán ở một góc cố định.

Một điều bật ra la họ không thể vừa giữ cái máy vừa xoay sản phẩm để tìm

kiếm, điều đó có thể tránh đƣợc nếu tham khảo ý kiến của ngƣời sử dụng.

The lesson here is that just because you find it easy to use does not

mean the user will necessarily agree with you. Also, keep in mind that just

because it is state of the art and your technical staff adores it does not mean

the user will concur. It all adds up to input: the user needs to have a say in

the selection process.

Cái bai học rút ra o day la cho dù bạn thấy rang nó dễ dang để sử

dụng thì điều đó không có nghĩa la ngƣời dùng sẽ đồng ý với bạn. Vì vậy,

ngƣời sử dụng cần phải có tiếng nói trong quá trinh lựa chọn. (selection

process).

This lesson is particularly pertinent when it comes to developing the

specification for online screens and reports — the most visible part of any

system. What frequently happens is that the IS people gater information and

create a specification. After six to twelve months, they are ready to demo

the system they developed to the users. With so much time interven- ing,

the users have invariably changed their minds about or forgotten what they

want.

Bai học nay đặc biệt thich hợp khi nó dùng để phái triển những bảng

thông báo va gởi báo cao về qua mạng – cái ma bạn thƣờng thấy ở bất kì hệ





thống nao. Chuyện đó thƣờng sãy ra va một nhóm ngƣời có trách nhiệm sẽ

thu thập thông tin va tạo ra những đặc điểm về kỹ thuật. sau 6 – 12 tháng họ

sãn sang để thử nghiệm hệ thống đó trên ngƣời dùng. với chừng đó thời

gian chen vào, ngƣời dùng sẽ thay đổi quan điểm hoặc quên đi họ muốn gì.

At Bankers Trust, when it was developing an equipment leasing

system, that time was not allowed to elapse without user feedback. Instead,

the bank decided to rapid-prototype (RAD) the system for users. During the

specification stage, a series of screens were put up on the system within a

matter of days. Users were given an ID into the system so they could play

with the prototype. They got the feel for the system and were able to voice

their opinions and objections immediately.

EX: ở Bankers Trust (ngân hàng trust), đang thiết kế một hệ thống,

khoảng thời gian thu thập ý kiến trôi qua ma bất chấp những ý kiến của

ngƣời dùng (feetback). Thay vao đó họ cho chạy thử phiên bản đầu tien cho

khách hang. Chỉ trong khoảng môt ngay, một lỗi nghiêm trong đã xuất hiên

với hệ thống. một số ngƣời dùng đã cho ID vao hệ thống nhƣng không thể

giao dịch đƣợc, va họ cho ý kiến bằng những lời la ó va sự giận dữ.

An even more daring user approach was taken by the NYSE. Certain

Exchange users were given an online editor and told to develop the screens

utilizing a JAD (joint application development) methodology. IT staffers

held their breath for many days, fearing the outcome of this experiment.

They need not have feared; users know what they want to see and how they





want to see it. Therefore, forget about textbook cases of good screen design

and give your users a paintbrush.

Một cách tiếp cận ngƣời dùng táo bạo đƣợc đƣa ra bởi NYSE. Cụ thể

những ngƣời dùng ở sở giao dịch Exchange sẽ đƣợc cung cấp một phần

mềm soạn thảo van bản online va nói cho các nha phát triển cái giao diện

ma họ muốn thấy để phái triển giao diện cho JAD (có thể hiểu la một

chƣơng trình quản lý dữ liệu cao hơn hệ phƣơng pháp luận). Cuộc thử

nghiệm nay khiến cho những nhân viên IT khá lo lắng. Nhƣng họ không

cần phải lo lắng, ngƣời dùng biết họ muốn thấy gì va thấy nó nhƣ thế nao.

Bởi vậy hãy bỏ qua những trƣờng hợp lý thuyết về một khung hình đƣợc

thiết kế tốt va trao cho ngƣời sử dụng một cây cọ.

Far more control is necessary in the system testing phase, however.

Users are notorious for their lax standards when they are involved in test-

ing. Therefore, the IT group must carefully oversee a test plan that covers

all facets of the system, using as many test cases and as many users as

possible.

Một giai đoạn cần thiết hơn đó la chạy thử nghiệm, tuy nhiên ngƣời

sử dụng thì nổi tiếng la dễ dãi khi họ vƣớng phải những thử nghiệm rắc rối.

vì vậy một nhóm IT phải có trách nhiệm giám sát kế hoạch thử nghiệm để

đảm bảo test đủ tất cả các khia cạnh của hệ thống va nhiều nhất những

trƣờng hợp có thể.





In one company the systems squad exercised both caution and

control in testing a very large financial system that was distributed across a

group of seven users. The users were asked to compare test results with raw

data and to annotate screen printouts or reports as appropriate. Because the

users were given very specific tasks and very specific instructions (not the

usual ―take a look at the system and let me know if you see anything

wrong‖), the system was 99 percent debugged before it went into

production.

Trong một công ty, một hệ thống sử dụng môt nhóm ngƣời trong

việc thông báo va quản lý việc chạy thử nghiệm, ở các hệ thống tai chinh

lớn công việc đó thƣờng đƣơc giao cho một nhóm khoang 7 ngƣời. Những

ngƣời đó đƣợc yêu cầu so sánh kết qua thử nghiệm với dữ liệu thô va chú

giải những dữ liệu xuất ra từ mạn hình hay báo cáo thich hợp. Bởi vì ngƣời

dùng đã đƣợc trao những nhiệm vụ va hƣớng dẫn cụ thể (không phải la bình

thƣờng "hãy xem hệ thống va cho tôi biết nếu bạn thấy bất kỳ điều sai "), hệ

thống đã đƣợc 99 % debugged trƣớc khi nó đã đi vao sản xuất.

Once the system has been tested, it is time to go live. Ideally, the

users have been involved every step of the way in the design process, and

pains have been taken to keep all those who will ultimately use the system

informed of its progress.

Một khi hệ thống đã thử nghiệm xong sẽ đƣợc đƣa vao sử dụng. Thật

tốt khi những ngƣời sử dụng đã tham gia vao từng bƣớc của quá trình thiết





kế, (pains have been taken to keep all those who will ultimately use the

system informed of its progress) va trả công cho những ngƣời dùng cuối

cùng khi thông báo về những tiến trình của hệ thống.

5.7 KẾT LUẬN

The points I have mentioned are all quite obvious, but they are

oftenoverlooked by harried IT staffs. This results in installed systems that

aredeemed successful by technicians but are dubbed flops by users. Thus,

todesign a system for all-around success, ―May the USER be with you‖.

Thực ra, những vấn đề đƣợc đề cập đến kể trên khá hiển nhiên,

nhƣng nó thƣờng bị bỏ sót bởi những tổ chức IT quá vội vang. Kết quả la

khi đã lắp đặt một hệ thống tƣởng rằng thanh công về mặt kỹ thuật thì thật

sự lại bị từ chối bởi ngƣời dùng. Do đó để thiết kế một hệ thống thanh công

về mọi mặt thì ―Hãy cùng lam viêc với Ngƣời Sử dụng nó‖.




Chương 6: Xem xét quyết định thuê ngoài 219

CHƢƠNG 6 XEM XÉT

QUYẾT ĐỊNH THUÊ NGOÀI

Người dịch:

1. Đam Quỳnh Giang

2. Lê Anh Dũng

3. Nguyễn Thanh Tòng

4. Lê Văn Huy

5. Nguyễn Hoang Việt





Outsourcing is a three-phased process:

Phase 1. Analysis and evaluation

Phase 2. Needs assessment and vendor selection

Phase 3. Implementation and management

Outsource la một quy trình 3 bƣớc:

Bƣớc 1: Phân tinh va đánh giá

Bƣớc 2: Thẩm định yêu cầu va lựa chọn đối tác

Bƣớc 3: Triển khai va quản li

6.1 BƢỚC 1: PHÂN TÍCH VÀ ĐÁNH GIÁ

In order to understand the services that need to be outsourced,

organizational goals need to be identified — particularly the core

competencies. Once the goals and core competencies are identified,

information related to these activities is gathered to compare the cost of

performing the functions in-house with the cost of outsourcing them. This

enables the company to answer nonfinancial questions such as ―How

critical are these functions and activities?‖ or ―What depends on these

activities?‖ or ―Will this activity become a ‗mission critical‘ activity?‖ This

will help organizations reach decisions about whether or not to outsource.

Long-term cost and investment implications, work morale, and support

should also be considered (see Appendix D for sample cost-benefit analysis

worksheets).





Để hiểu những dịch vụ cần đƣợc outsource, những mục tiêu của công

ty phải đƣợc xác định – đặc biệt la những năng lực cốt lõi. Một khi những

năng lực cốt lõi đã đƣợc xác định, thông tin liên quan đến những hoạt động

nay đƣợc thu thập để so sánh chi phi khi tiến hanh tự lam (in-house) với chi

phi khi outsource. Việc nay giúp công ty trả lời những câu hỏi phi tai chinh,

nhƣ la ―Những chức năng va hoạt động nay mang tinh quyết định nhƣ thế

nào?‖ hay ―Cái gì phụ thuộc va những hoạt động nay‖ hay ―Những hoạt

động nay sẽ trở thanh những hoạt động mang tinh ‗cốt yếu‘ hay không?‖.

Việc nay giúp cho công ty có đƣợc những quyết định về việc có nên

outsource hay không. Những mối quan hệ mật thiết giữa chi phi dai hạn va

sự đầu tƣ, tinh thần lam việc, va sự ủng hộ cũng cần đƣợc xem xét (xem

Phụ lục D về bảng phân tich chi phi – năng suất)

6.2 BƢỚC 2: THẨM ĐỊNH YÊU CẦU VÀ LỰA CHỌN ĐỐI TÁC

The objective of this phase is to develop a detailed understanding of

the needs of the organization and the capabilities of possible solution

providers.

Mục tiêu của bƣớc nay la để triển khai một phân tich chi tiết về

những nhu cầu của công ty cũng nhƣ năng lực của những nha cung cấp giải

pháp.

In this phase a ―request for a proposal‖ (RFP) is developed and

delivered to applicable vendors. RFPs need to be structured in a manner to





facilitate assessment and comparison of the various vendors. They should

contain the complete requirements, problem that needs to be resolved,

desires, etc. A clearly structured and documented RFP also helps vendors

understand and evaluate what a company is looking for and assists them

inassessing whether they can provide the required service.

Trong bƣớc nay, một lời ―mời thầu‖ (request for proposal – RFP)

đƣợc tạo ra va gửi đến những đối tác thich hợp. Bản RFP cần đƣợc cấu trúc

theo cách sao cho thuận tiện với việc thẩm định va so sánh những đối tác

khác nhau. Chúng cần phải trình bay đầy đủ các yêu cầu, vấn đề cần giải

quyết, mong muốn, v.v… Một bản RFP đƣợc cấu trúc va tai liệu hoá rõ

rang cũng giúp cho các đối tác hiểu va đánh giá đƣợc một công ty đang tìm

kiếm điều gì va giúp họ xem xét liệu họ có thể cung cấp đƣợc những dịch

vụ đề xuất hay không.

When evaluating the vendor proposals, the organization should look

not only at the technological capability of the vendor but also at factors

such as the vendor‘s financial stability, track record, and customer support

reputation. Contacting vendor‘s existing and previous clients would give

the organization a good idea about the vendor‘s abilities.

Khi đánh giá những đề xuất của đối tác, công ty nên không chỉ nhìn

vao năng lực kĩ thuật của đối tác đó ma còn phải nhìn vao những yếu tố

khác nhƣ sự ổn định về tai chinh của đối tác, thanh tich, cũng nhƣ khả năng





hỗ trợ khách hang. Liên hệ với những khách hang hiện tại va trƣớc đây của

đối tác sẽ giúp công ty có một cái nhìn tốt hơn về khả năng của đối tác.

Once a vendor is selected, the organization needs to make sure that a

fair and reasonable contract, beneficial to the organization, is negotiated. It

is imperative to define service levels and the consequences of not meeting

them clearly. Both parties should make sure that they understand the

performance measurement criteria (see Appendix Q for a software metrics

capabilities guide).

Một khi đối tác đã đƣợc chọn, công ty cần bảo đảm rằng một bản

hợp đồng công bằng va hợp li, có lợi cho công ty đƣợc đem ra thƣơng

lƣợng. Vấn đề mấu chốt la phải định đƣợc cấp độ của dịch vụ va những hệ

quả từ việc không đáp ứng rõ rang những dịch vụ đó. Cả hai bên nên bảo

đảm rằng họ hiểu đƣợc những tiêu chi đánh giá hiệu suất công việc (xem

Phụ lục Q về hƣớng dẫn thƣớc đo năng lực phần mềm).

6.3 BƢỚC 3: TRIỂN KHAI

The final phase in the outsourcing decision process is the

implementation. During this phase a clear definition of the task needs to be

identified, so establishing a time frame would be very helpful. Mechanisms

need to be established to monitor and evaluate performance during the

vendor‘s developmental process. This is important even after

implementation to make sure that the outsourced tasks are being delivered





by the vendor as agreed upon. Ability to identify, communicate, and resolve

issues promptly and fairly will help the company achieve mutual benefits

and make a relationship successful.

Bƣớc cuối cùng trong quy trình xem xét quyết định outsource la việc

triển khai. Trong bƣớc nay, một bản định nghĩa rõ rang về những nhiệm vụ

cần đƣợc xác định, cho nên việc thiết lập một khung thời gian sẽ trở nên

hữu ich. Một cơ chế cũng cần đƣợc thiết lập để điều phối va đánh giá hiệu

suất trong quá trình lam việc của đối tác. Việc nay rất quan trọng, ngay cả

sau khi đã qua bƣớc triển khai để bảo đảm những nhiệm vụ outsource đang

đƣợc đối tác giao nộp lại nhƣ đã thoả thuận. Khả năng xác định, trao đổi, va

giải quyết vấn đề nhanh chóng va minh bạch sẽ giúp công ty đạt đƣợc

những lợi ich qua lại va lam cho quan hệ trở nên tốt đẹp.

Depending on the size of the outsourcing contract, the manager

responsible for the program‘s delivery and integration may be responsible

for all of the process, or only some. These are the horizontal and vertical

factors of outsourcing management. A manager of the horizontal process is

often involved in the decision to outsource, and is then responsible for

defining the work, selecting and engaging the vendor, and managing the

delivery and completion of the program. This manager normally handles all

day-today negotiations. With larger programs, particularly those on a global

scale, a decision is often made at senior levels to outsource. A negotiation

team is appointed to work through the complex agreements, usually under

strict confidentiality, until the agreement is finalized and announced. It is





then the role of the manager of the vertical component to implement and

manage the ongoing program. Part of this role is the interpretation of the

agreement and identification of areas not covered by the agreement.

Tuỳ vao quy mô hợp đồng outsource, ngƣời quản li chịu trách nhiệm

trong việc chuyển giao va tich hợp chƣơng trình có thể cũng chịu trách

nhiệm về toan bộ quy trình, chứ không chỉ một vai bƣớc. Đây la những yếu

tố dọc va ngang trong việc quản li outsource. Một ngƣời quản li quy trình

ngang thƣờng liên quan đến quyết định outsource, va sau đó chịu trách

nhiệm trong việc xác định công việc, lựa chọn va gặp gơ dối tác, cũng nhƣ

quản li việc chuyển giao va hoan thiện của chƣơng trình. Ngƣời quản li nay

thƣờng sẽ điều khiển tất cả những thoả thuận theo từng ngay. Với những

chƣơng trình lớn hơn, cá biệt la những chƣơng trình quy mô toan cầu, một

quyết định thƣờng đƣợc trình lên cấp cao để outsource. Một nhóm thƣơng

lƣợng sẽ đƣợc hẹn để lam việc xuyên suốt những bản thoả thuận phức tạp,

thông thƣờng la dƣới sự bi mật nghiêm ngặt, cho đến khi những thoả thuận

hoan thanh va đƣợc loan báo. Sau đó la vai trò của ngƣời quản li thanh phần

ngang, để triển khai va quản li chƣơng trình hiện tại. Một phần của nhiệm

vụ nay la việc diễn giải bản thoả thuận va xác định những phần không đƣợc

đề cập trong thoả thuận.

6.4 MỘT VÍ DỤ VỀ OUTSOURCE

In this chapter we will break down the outsourcing decision-making

process using an e-business system as an example. Since the Internet





opened for business just a short ten years ago and despite the boom–bust

cyclical nature of the market, few companies have not jumped into the

foray by building a corporate Internet presence. The Internet is the one

thing most companies have in common.

Trong chƣơng nay, chúng ta sẽ phân tich về quy trình đƣa quyết định

outsource sử dụng thƣơng mại điện tử (e-bussiness) nhƣ la một vi dụ. Từ

khi Internet đƣợc mở ra cho việc kinh doanh chỉ mới 10 năm trƣớc, va mặc

cho sự bùng nổ của thị trƣờng, một vai công ty vẫn không vội nhảy vao.

Internet la một trong những thứ ma hầu nhƣ mọi công ty đều có.

Visit Gateway.com and wander over to their accessory store

(http://www.gtwaccessories.com). Here you can buy everything from

digital cameras to software to printers. Sounds like quite an operation does

it not? The store might have the Gateway logo on it, but you will not find it

on any Gateway corporate computer. Where you will find it is at

Vcommerce.com — a company that is in the business of putting other

companies in the e-commerce business. According to Gateway, by

outsourcing the entire function, it is able to sell products and grow revenues

while focusing its attention on its core competencies.

Ghé thăm gateway.com va dạo quanh cửa hang bán linh kiện của họ

(http://www.gtaccessories.com). Ở đây bạn có thể mua mọi thứ, từ máy ảnh

kĩ thuật số đến phần mềm, cho đến máy in. Nghe giống nhƣ một chiến dịch

phải không? Cửa hang có thể có logo Gateway tren đó, nhƣng bạn sẽ không


(http:/www.gtwaccessories.com

http://www.gtaccessories.com/




thể tìm thấy bất kì một chiếc máy tinh nao của Gateway cả. Chỗ ma bạn có

thể tìm thấy nó la ở Vcommerce.com – một công ty chuyên lam nhiệm vụ

la đặt các công ty khác vao môi trƣờng thƣơng mại điện tử. Theo Gateway,

bằng cách outsource toan bộ chức năng nay, họ có thể bán đƣợc sản phẩm

va tăng doanh thu trong khi vẫn đặt sự quan tâm vao những năng lực chinh

yếu.

In other words, Gateway, no slouch in the computer expertise

department, has decided that even they do not have the expertise or desire

to run a sophisticated e-commerce site. Instead, they decided to give the

problem to someone else — someone with the expertise. What, then, does

this say about the rest of us?

Nói cách khác, Gateway, không hề vụng về chút nao trong lĩnh vực

chuyên môn máy tinh cả, đã quyết định rằng thậm chi họ còn không có khả

năng chuyên môn cũng nhƣ không muốn sẽ vận hanh một site thƣơng mại

điện tử rắc rối cả. Thay vao đó, họ quyết định đƣa vấn đề nay cho ngƣời

khác – một ngƣời có chuyên môn. Còn bạn, bạn nghĩ sao về vấn đề nay ?

6.4.1 Những vấn đề khi outsource

It is important to understand the ramifications of systems

development in the world of high-risk interconnected computers. In order to

make an ROI-enhancing decision, the CIO must gather much information

from a diversity of areas:





Rất quan trọng khi hiểu đƣợc sự phân nhánh về sự phát triển hệ

thống trong thế giới đầy nguy cơ của các máy tinh đƣợc kết nối với nhau.

Để đƣa ra đƣợc quyết định lam tăng hiệu quả đầu tƣ (ROI-enhancing

decision), CIO buộc phải tập hợp thông tin từ nhiều lĩnh vực khách nhau:

Legal issues. It is amazing how many Web sites are without benefit

of legal counsel. This stems from the days when the Web had the

reputationof the ―Wild, Wild West‖. Today, the CIO must be

concerned about issues such as copyright infringement of images

and text, the use ofonline warranties, licensing, contracts, and

spamming.

Vấn đề luật pháp. Thật ngạc nhiên có bao nhiêu Web-sites không

cần đến lợi ich từ việc tƣ vấn luật. Chuyện nay bắt nguồn từ khi

Web còn có tiếng la ―Miền Tây, Miền Tây hoang dã‖. Ngay nay,

CIO phải xem xét về các vấn đề nhƣ la sự xâm phạm bản quyền về

hình ảnh va văn bản, việc sử dụng những sự bảo hanh, giấy phép,

hợp đồng, hay thƣ rác trực tuyến.

Regulatory issues. Right now purchases on the Web are not taxed

but expect that this reprieve will not last forever. Other taxation

issues to consider include the effect of telecommuting Web

developers on the jurisdictional exposure of the corporation. Of

course, we all know by now that online gambling is prohibited, but

what about lotteries and contests — even if you offer them as a





promotional gimmick? Then consider First Amendment issues,

pornography issues — et cetera, et cetera, et cetera.

Vấn đề về quy định. Hiện giờ, mua bán trên Web không bị đánh

thuế, nhƣng việc trì hoãn nay không phải la mãi mãi. Những vẫn đề

thuế má khác để xem xét bao gồm cả những hiệu ứng từ việc liên

lạc viễn thông với những nha phát triển Web trong sự công khai

pháp lý của công ty. Tất nhiên, chúng ta đều biết la hiện giờ đánh

bạc trực tuyến bị cấm, nhƣng còn xổ số va các cuộc thi thì sao –

thậm chi nếu bạn chao mời họ nhƣ la mánh khoé khuyến mãi. Rồi

xem xét cả các vấn đề về tự do ngôn luận va vấn đề về thông tin

đồi trụy – vân vân và vân vân.

Security. Once you open your doors you will probably be letting

inmore than customers. Hackers, crackers, and other malevolent

creaturesof the night seem to spend all of their waking hours

figuring outnew ways to wreak havoc on unsuspecting

organizations. Top this offwith a veritable plague of new viruses,

concerns about fire, sloppydata entry, and attacks by internal

employees and security becomes afull-time job. Things you need to

understand are uses of firewalls, encryption,and authentication —

ultracomplex technologies not for thetechnologically faint of heart.

Even the most sophisticated of preventivemeasures will not ward

off all attacks. Think back to the massive denial of service attacks





on sites such as Yahoo and eTrade in February, 2000, and the

various klez viruses that plagued us in 2002.

Bảo mật. Khi bạn mở cửa ra, bạn có lẽ cho nhiều ngƣời vao chứ

không chỉ có khách hang. Hacker, cracker va những kẻ xấu bụng

khác dƣờng nhƣ danh toan bộ thời gian thức để tìm ra cách phá

hoại những công ty thiếu cảnh giác. Kết thúc bằng một đại dịch với

những thứ virus mới, dinh liu đến những dữ liệu lộn xộn, va sự tấn

công từ chinh nhân viên trong công ty. Va bảo mật trở thanh một

công việc toan thời gian. Những thứ bạn cần phải hiểu la việc sử

dụng tƣờng lửa, mã hoá va chứng thực – những công nghệ cực kì

phức tạp không danh cho những kẻ nhát gan. Ngay cả những giới

hạn ngăn chặn phức tạp nhất cũng không loại bỏ hết đƣợc mọi sự

tấn công. Hãy nhớ lại về loạt tấn công từ chối dịch vụ quy mô lớn

vao những site nhƣ Yahoo va eTrade vao tháng 2/2000, va vô số

loại virus klez tạo thanh dịch vao năm 2002.

Staffing issues. Do you have the staff to implement an e-business

initiative successfully? E-business is hard work; it is 24 × 7 × 52.

Also keepin mind that new bells and whistles are invented almost

daily. You will need to invest a substantial sum to keep your staff

trained so that they can take advantage of these new technologies.

Vấn đề nhân sự. Bạn có đƣợc đội ngũ nhân viên triển khai thƣơng

mại điện tử thanh công không? Thƣơng mại điện tử la một việc





khó, đó la việc 24x7x52. Cũng nhớ thêm rằng những phát minh

đƣợc tạo ra gần nhƣ hằng ngay. Bạn sẽ cần phải đầu tƣ một số vốn

lớn để giữ cho nhân viên của bạn đƣợc huấn luyện nhằm tận dụng

đƣợc những lợi thế từ những công nghệ mới trên.

System usability. Long gone are the days when you could throw up

a Web site and expect kudos. With a plethora of tool sets such as

Macromedia Flash, Web conferencing, instant chat, etc., the stakes

for a usable Web site have gotten a lot higher — and much more

expensive. Given the size of many Web sites, ergonomics and

navigability issues must be explored. Would GM ever release a

new kind of car without some sort of driver-acceptance testing?

Tính khả dụng của hệ thống. Đã qua rồi cái ngay ma bạn chỉ cần

tung ra một Web-site va ngồi chờ vinh qua. Với đầy những bộ

công cụ dạng nhƣ Macromedia Flash, Hội thảo trực tuyến, tán gẫu,

v.v.., những nguyên tắc về tinh khả dụng của Web đã đƣợc nâng

cao hơn nhiều – va tốn kém hơn nhiều. Lấy một Web-site nao đó,

những vấn đề về tinh dễ sử dụng va định hƣớng tốt cần phải đƣợc

tìm hiểu. Có bao giờ GM (General Motors) lại sản xuất một loại xe

mới ma không qua thử nghiệm về sự chấp nhận của ngƣời mua?

System functionality. It was so much easier just five years ago to

throw up a Web site and have it considered novel. Today all things

novel probably have already been done so you will not be able to





lure new web visitors to your site with the promise of the ―newest

and the greatest‖. Instead you must focus on your site‘s

functionality. For example, a small golf Web site named

swapgolf.com offers a wide variety of functions: a golf shopping

mall, ability to swap golf tee times, a bulletin board, and even golf

puzzles. Notice all the functionality is related to the golf theme.

CNBC.com, on the other hand, is a large site with many more

financial resources than swapgolf so it is no wonder that this site is

loaded with functionality. Note too that CNBC.com offers

themerelated functionality. Because CNBC is a financial news

service, Web site functionality includes financial-related services

such as MoneyTalk, Quote Box, and Markets. Also keep in mind

that a Web siteis a high maintenance project that needs to be fed

constantly.

Chức năng hệ thống. Cách đây chỉ mới 5 năm thôi, việc tung ra

một Web site đơn giản hơn nhiều, còn giờ đây nó chỉ có trong tiểu

thuyết. Ngay nay, mọi thứ trong tiểu thuyết đều đã đƣợc lam rồi,

cho nên bạn sẽ không thể dụ những ngƣời duyệt web mới ghé thăm

Web site của bạn với lời hứa hẹn về những thứ ―mới nhất va tuyệt

nhất‖. Thay vao đó bạn phải chú trọng vao chức năng của site. Vi

dụ, một Web site nhỏ về Golf tên la swapgolf.com cung cấp nhiều

chức năng: gian hang mua sắm golf, khả năng thay đổi điểm phát

bóng, bảng điểm, va ngay cả những câu đố về golf. Chú ý la tất cả





những chức năng nay đều liên quan đến chủ đề về golf.

CNBC.com, mặt khác, la một site lớn, với nhiều tai nguyên về tai

chinh hơn la swapgolf.com, nên chẳng có gì thắc mắc khi ma nó có

nhiều chức năng hơn. Cũng ghi chú thêm la CNBC.com cung cấp

những chức năng theo chủ đề. Vì CNBC la một dịch vụ tin tức tai

chinh, chức năng của Web site bao gồm cả các dịch vụ liên quan

đến tai chinh nhƣ la MoneyTalk, QuoteBox, va Markets. Nhớ luôn

la một Web site la một dự án cần bảo trì thƣờng xuyên với việc

cung cấp thông tin đều đặn.

System reliability. Perhaps the most irritating problem Web surfers

encounter is sites that have bad links, databases that decline to

work, and general overall system development sloppiness. It is

almost as if many sites were thrown online without any testing

whatsoever. Netslaves is a most intriguing Web site that takes

delight in shooting down what they consider to be myths and

outright lies about all things Internet. Self-professed Netslave

media assassin Steve Gilliard has this to say about the Net myth

that ―things move fast online and we have to stay ahead‖. He

explains, ―It takes time to develop a reliable business.The faster

you move, the more likely you are to screw up. It takes time, years,

to get things right, develop trust in key employees and stabilize.

Moving fast in many cases is an excuse for incompetence‖.





Sự tin cậy của hệ thống. Có lẽ những thứ bực bội nhất ma Web gặp

phải la việc chứa những liên kết xấu, CSDL không chịu hoạt động,

va nói chung la sự lộn xộn trong việc phát triển hệ thống. Gần nhƣ

thể la nhiều sites đƣợc tung lên mạng ma không qua kiểm tra gì cả.

Netslaves la Web site hấp dẫn nhất đem đến sự thich thú bằng việc

loại bỏ những gì họ xem la hoang đƣờng hoặc những lời nói dối

trắng trợn về Internet. Ngƣời tự nhận la kẻ săn tin trên Netslave –

Steve Gilliard – phải nhận xét rằng ―mọi thứ thay đổi rất nhanh

trên môi trƣờng trực tuyến, va chúng tôi phải hƣớng ra phia trƣớc‖.

Anh ta giải thich, ―Phát triển một hệ thống kinh doanh tin cậy cần

thời gian. Bạn đi cang nhanh, bạn cang dễ bị rối. Cần có thời gian,

hang năm trời, để lam cho mọi thứ đi đúng cách, tạo dựng niềm tin

ở những nhân viên chủ chốt va lam ổn định. Phát triển quá nhanh

trong nhiều trƣờng hợp la một lời bao chữa cho sự thiếu trình độ.

System integration. Web-based systems should never operate in a

vacuum. Instead, they should be fully integrated into your current

corporate systems. For example, your marketing and sales systems

need information about who is visiting your site, what they are

looking at, and what they are buying. Only a solid integrative

infrastructure will accomplish this. Real synergy occurs when

internal and external systems are effectively linked together,

creating more efficient ways to market, sell, and process and

deliver orders. This translates to integrating a whole spate of





disparate systems, including inventory, ordering, and invoicing,

along with supply-chain data from business partners — in other

words, the organization‘s ERP (enterprise resource planning)

resource.

Sự tích hợp hệ thống. Một hệ thống dựa trên nền web sẽ không

hoạt động riêng lẻ. Ma chúng sẽ đƣợc tich hợp đầy đủ vao hệ thống

hiện tại của công ty bạn. Vi dụ, bộ phận tiếp thị va bán hang của

công ty cần thông tin về những ai ghé thăm site, họ tìm những gì,

va mua những gì. Chỉ một số it những cơ sở hạ tầng có cấu trúc

thống nhất mới thực hiện đƣợc điều đó. Những vấn đề về phối hợp

công việc aka team-work (synergy) xảy ra khi các hệ thống trong

va ngoai đƣợc liên kết với nhau 1 cách hiệu quả, tạo ra nhiều hơn

các cách thức tiếp thị, bán va vận chuyển hang đến tay ngƣời dùng.

Điều nay diễn giải cho việc tich hợp một khối lƣợng lớn những hệ

thống khác biệt với nhau, bao gồm quản lý kho hang, đặt hang,

xuất hang, đi cùng với một dây chuyền cung cấp dữ liệu từ đối tác

kinh doanh, nói một cách khác, đây la 1 cách tổ chức tai nguyên

theo kiểu ERP.

Meaningful metrics. It really does not pay to spend $5 million to

build an e-commerce system if you will never know how it affects

the bottom line. Will it increase sales by 10 percent or boost

customer retention by 15 percent? Before you ever do the

technology planning for an e-business, you should decide just what





it is you are hoping to accomplish (i.e., your business strategy plan)

and then develop meaningful metrics to measure your progress.

Những độ đo có nghĩa. Nó thực sự không đáng để chi ra 5 triệu đô

la nhằm xây dựng một hệ thống thƣơng mại điện tử ma bạn không

biết chắc chắn nó sẽ có ảnh hƣởng đến sự phát triển của công ty.

Liệu nó có tăng doanh số bán hang lên 10% hay thu hút 15% lƣợng

khách đã sử dụng dịch vụ của công ty hay không ? Trƣớc khi lên

kế hoạch chi tiết kỹ thuật cho thƣơng mại điện tử, bạn cần phải xác

định mục tiêu bạn muốn đạt đƣợc la gì (nói cách khác, đó la dự

định chiến thuật cho kinh doanh của bạn) va tiếp đó la phát triển

những con số biết nói để đánh giá mức độ hoan thanh của bạn.

Costs. Even if you plan carefully, there will always be those hidden

and unexpected costs for hardware, software, communications, and

even new staff.

Giá cả. dù đã tinh toán chi li, sẽ luôn có những khoản giá mới va

không ngờ tới cho phần cứng, phần mềm, giao dịch, va có khi la cả

đội ngũ nhân viên mới.

6.4.2 Chi phí bao nhiêu?

Back in 1995, Tom Vassos, an instructor at the University of

Toronto, was part of an IBM team that created IBM‘s Web site. It had





10,000 documents spread across 30 Web servers around the world. Their

requirements included everything from translation into multiple languages,

downloadable documents, demonstration tools, contents of entire IBM

magazines and publications, graphics images, audio clips, and fulfillment

mechanisms for other deliverables such as CD Roms.

Vao năm 1995, Tom Vassos, giảng viên của trƣờng ĐH Toronto,

một thanh viên của đội sáng lập ra website của IBM. Nó gồm 10000 tai liệu

trải dai ở 30 server web khắp thế giới. Yêu cầu lúc bấy giờ của họ gồm mọi

thứ từ dịch đến đa ngôn ngữ, những tai liệu có thể tải đƣợc, những công cụ

thể hiện (demonstration tools), nội dung của tất cả các bai báo, tạp chi va

công bố của IBM, những hình ảnh, đoạn âm thanh, va đầy đủ các phƣơng

tiện cho việc vận chuyển nhƣ CD Roms.

The site cost several million dollars initially, with an IBM

commitment to spending several more to maintain and expand the site.

Trang web tiêu tốn của IBM khoảng vai triệu đô la, va một khoản

không nhỏ cho chi phi bảo trì va mở rộng website.

Some experts estimate that a large site should cost $6 million over

two years, a medium site $2 million, and $500,000 for a small site over two

years. These numbers include many costs for site and product promotion

and content upkeep.





Các chuyên gia ƣớc tinh rằng một trang website lớn có thể tiêu tốn

khoảng 6 triệu đô la cho 2 năm, 2 triệu đô la, va 500 000 đô la tƣơng ứng

với website trung bình, va nhỏ trong vòng 2 năm. Các chi phi nay bao gồm

nhiều khoản cho trang web, các sản phẩm giới thiệu va nội dung cập nhật.

The Gartner Group surveyed 100 leading companies operating e-

commerce sites and found that the average firm had spent three-quarters of

a million dollars on the technology (i.e., hardware/software/peopleware)

alone. Add to that the cost of marketing that site and you may need a budget

as high as amazon.com, which now spends upward of $40 million per

quarter to market itself.

Tập đoan Gartner đã khảo sát 100 công ty tiến hanh thƣơng mại điện

tử hang đầu va nhận thấy gần nhƣ rằng một số lƣợng lớn các công ty đã bỏ

ra ¾ của một triệu đô la (750 ngan) chỉ cho kỹ thuật (nhƣ phần cứng/ phần

mềm/ nhân lực). Ngoai ra còn phải chi tiêu thêm cho tiếp thị, va bạn nên có

ngân quỹ cang cao cang tốt cho việc nay (cơ Amazon.com, chi cho việc tiếp

thị đã lên tới 40 triệu 250 ngan đô la).

6.4.3 Sử dụng nha cung cấp dịch vụ Internet

With the rise of Web-hosting companies, today the organization has

a wide variety of less expensive alternatives. For example, a small business

using a typical ISP such as VeriSign would pay about $376 per month for

monthly service, file storage and data transfer fees, and a shopping cart. An





even smaller business can get away with a bare-bones site for about $10 per

month at Schogini.com. In neither of these cases does Web design figure

into the equation. That is a separate cost.

Với sự phát triển của internet, ngay nay các tổ chức đã có nhiều hơn

những biện pháp thay thế it tốn kém hơn. Vi dụ, một công ty nhỏ dùng dịch

vụ cung cấp mạng điển hình nhƣ VeriSign chỉ tổn khoảng 376 đô la một

tháng cho tiền dịch vụ hang tháng, phi lƣu trữ dữ liệu, truyền tải dữ liệu va

mua sắm. Thậm chi một công ty nhỏ hơn vẫn có khả năng có một trang web

cơ bản với giá chỉ cơ 10 đô la một tháng tại Schogini.com. Ngoai ra còn

phải tốn khoản chi phi cho việc thiết kế trang web. Đó đƣợc tinh nhƣ một

khoản chi phi riêng biệt.

Web site design costs vary considerably among web design firms.

One company I have worked with charged $2,000 for a 10-page site and

$10,000 for a 25-page site. A high-end site for a mid-sized business I

worked with set the company back around $50,000. This got them about 50

pages and assorted add-ons such as user tracking, image maps, frames,

Shockwave or Quicktime animation, audio, database, shopping cart, SSL

(secure transaction server), creative illustrations, CGI, and database

programming. Hosting charges were separate. For a mid-sized business low

end costs about $100 to $160 a month, mid level $160 to $350 a month and

high end about $350 a month. Add $1,500 a month for a T-1

communications line.





Giá của việc thiết kế trang web dao động khá xa tùy vao sự ổn định

của thiết kế của trang. Một công ty tác giả từng lam việc đƣa ra mức giá la

2000 đô la cho một site gồm 10 trang va 10 000 đô la cho một site gồm 24

trang. Một site cao cấp cho một doanh nghiệp cơ trung ma tác giả từng lam

việc có mức giá 50 000 đô la. Site gồm 50 trang va những phần phụ thêm

(add-ons) nhƣ đánh dấu ngƣời dùng (user tracking), bản đồ hình ảnh (image

maps), khung, Shockwave va QuickTime cho các file ảnh động, âm thanh,

dữ liệu, mua sắm, SSL, sự minh họa sáng tạo, CGI, va lập trình cho cơ sở

dữ liệu. Phi cho host đƣợc tinh riêng. Một công ty cơ trung dùng site yêu

cầu thấp tốn khoảng 100 tới 160 đô la một tháng, yêu cầu trung bình

khoảng 160 tới 350 đô la một tháng va yêu cầu cao cấp khoảng 350 đô la

một tháng. Hoặc 1500 đô la một tháng cho đƣờng dây giao tiếp T-1.

A good place to start doing comparative research is

www.thelist.com, which provides a list of virtually all of the ISPs in the

world and the services and price structures they offer. As mentioned, you

will find wide variation in prices.

Nơi tốt để có thể tra cứu về các nha cung cấp dịch vụ internet la

trang www.thelist.com, nơi cung cấp danh sách nhiều nha cung cáp dịch vụ

internet trên thế giới va dịch vụ cùng giá cả họ đề nghị. Nhƣ đã đề cập, bạn

có thể tìm thấy rất nhiều giá.


http://www.thelist.com/

http://www.thelist.com/




6.4.4 Tự xoay sở

The other choice, one that only very large companies seem to take

today, is to roll your own. Rough estimates for a start-up configuration for a

small to mid-sized company are as follows:

Một cách khác ma các công ty rất lớn thƣờng lam, đó la tự xoay sở.

Một dự báo sơ cho việc tự thiết lập cai đặt cho một công ty cơ nhỏ đến

trung cần một số bƣớc sau:

Computer. Keep in mind that the IBM site described previously

had 30 Web servers. Just one of them can cost you between $5,000

and $25,000, which includes only the hardware. This is a one-time

cost though maintenance upgrades will need to be figured into the

equation.

Máy tính:Nên nhớ rằng trang của IBM cần đến 30 máy chủ. Mỗi

máy đã tốn của bạn từ 5000 tới 25000 đô la, đã có chi phi cho phần

cứng. Đây la chi phi cho một lần duy nhất mặc dù việc nâng cấp,

bảo trì vẫn sẽ tốn thêm vao tổng chi phi của bạn.

OS/server software. This can cost anywhere from $0 if you run a

free version of Linux to over $10,000. Usually either UNIX or

Windows/ NT/2000 is used, with Linux quickly gaining ground.

You may also need to buy multiple Web servers. First there is the

Web server that runs the actual Web site. Add an additional Web





server if you are running an e-commerce server. Add a third server

if you need to run something like RealAudio. Again, this is a one-

time cost requiring maintenance upgrades.

Hệ điều hành/ phần mềm máy chủ: Nó có thể miễn phi nếu bạn xai

phần mềm của Linux hoặc tốn khoảng 10 000 đô la. Dùng UNIX

hay Windows, bạn vẫn phải cần mua nhiều máy chủ web. Đầu tiên

la máy chủ để chạy web site thực sự. Một máy chủ để thực hiện tác

vụ của một máy chủ thƣơng mại điện tử. Va một máy chủ nữa nếu

bạn cần chạy một ứng dụng nhƣ RealAudio. Va tƣơng tự, chi phi

cho một lần, chƣa kể nâng cấp va bảo trì.

Modems. Modem pricing varies, depending upon how many you

need and their capabilities. Modems, in case you did not know, are

used for those people who might need to dial into your system.

This is a onetime cost.

Modem: có nhiều giá, tùy vao bạn cần gì, va tùy vao độ ổn định của

nó. Modem, nếu nhƣ bạn chƣa rõ, dùng để ngƣời khác truy cập vao

hệ thống của bạn. Chi phi cho modem tốn 1 lần.

Connectivity hardware. Hardware or software devices such as

routers and couplers will run you anywhere from $1000 to $5000+.

This is a one-time cost.





Kết nối đường truyền: phần cứng hay phần mềm cho đƣờng truyền

nhƣ router va coupler sẽ tốn của bạn từ 1000 đến 5000 đô la. Chi

phi nay la một lần.

Communications. You cannot simply hook up your PC to a slow

modem and expect to be able to use that as your Web site.

Connecting your PC to the Net will require you to lease a high-

speed telephone line. A T-1 will cost you about $1500 a month. A

T-3, which has a higher speed, will cost you even more.

Phương thức giao tiếp: để kết nối máy tinh với Net tốt hơn, bạn sẽ

phải cần một đƣờng mạng thuê riêng T-1, khoảng 1500 đô la một

tháng, với T-3, chi phi sẽ còn cao hơn.

6.4.5 Giá nhân công

As is true for most labor costs, the price of labor is all across the

board. Staff salaries for technology experts are rather high, with an average

cost of about $60,000 a year for someone with several years of experience.

Tƣơng tự các nganh khác, giá nhân công trong lĩnh vực nay cũng có

nhiều loại. Với những nhân viên la chuyên gia kỹ thuật, giá sẽ tƣơng đối

cao, trung bình khoảng 60 000 đô la một năm với một ngƣời.

Hiring consultants will bring a variety of proposals to your doorstep.

Web page authors charge anywhere from $30 to $150 an hour with the





higher-end price going to those that can build you a database or write you a

custom script using Perl or Java.

Thuê tƣ vấn viên có thể mang lại cho bạn nhiều cơ hội để vƣơn lên.

Các kỹ thuật viên thiết kế web có giá từ 30 đến 150 đô la một giờ hoặc mức

giá cao hơn cho những ngƣời có khả năng xây dựng cơ sở dữ liệu cho bạn

hoặc chuyển yêu cầu của bạn thanh đoạn mã Perl hay Java.

The Gartner Group has estimated that, through 2004, IT contractors

and other outside resources will be used to complete 50 percent of the e-

business work in large enterprises.

Theo số liệu của Gartner, vao năm 2004, các nha thầu IT va các

nguồn lực khác đƣợc sử dụng để hoan thanh 50% lƣợng công việc của

thƣơng mại điện tử trong nganh công nghiệp lớn.

6.4.6 Giá dựa trên những cái ma bạn muốn đặt vao site

Whether you outsource or not, figuring out what your Web site will

cost is a lengthy, complicated process. The first thing to do is to make a list

(see Exhibit 6-1) of exactly what you expect to put on this site, how often

you will update it, and the site‘s expected functionality.

Dù rằng bạn có muốn thuê ngoai hay không, tinh toán chi phi trang

web của bạn sẽ tốn bao nhiều tiền la công đoạn khá dai, va phức tạp. Đầu





tiên la lập danh sách những gì bạn muốn ở trong trang web, bạn sẽ cập nhật

trang web định kỳ bao lâu, va các yêu cầu chức năng bạn muốn ở nó la gì.

Once this list is made, you can send out RFPs (requests for proposal)

to various Web-hosting companies to determine their cost structure to

develop your site. Your IT department should be given a chance to bid as

well.

Khi lập danh sách các yêu cầu xong, bạn có thể gửi nó (còn gọi la

RFPs, các yêu cầu cần thiết) cho các nha cung cấp web-hosting để xác định

mức giá khung khi thiết kế trang web của bạn. Hoặc phòng ban chuyên về

IT sẽ đƣợc cho 1 cơ hội để đƣa giá.

6.5 CÓ NÊN THUÊ NGOÀI KHÔNG?

Moving to an e-business model requires an enormous commitment.

Ask yourself whether you are up to it. Also ask yourself whether your

company is up to it.

Khi quyết định xây dựng hình thức thƣơng mại điện tử sẽ phải đối

mặt với nhiều loại hình phạm tội mới. Hãy tự hỏi mình bạn đã sẵn sang cho

điều đó chƣa. Va hãy tự hỏi công ty của bạn đã sẵn sang cho điều đó chƣa.

There are many good reasons to outsource as Gateway discovered

when it decided to outsource many of its own e-business functions.





Deciding whether or not to outsource is a very individual decision based on

many corporate factors:

Có nhiều lý do để thuê ngoai nhƣ Gateway đã lam khi họ quyết định

thue ngoai khá nhiều các yêu cầu công việc thƣơng mại điện tử của công ty.

Quyết định có thuê ngoai hay không la một quyết định rất chủ quan dựa

trên nhiều yếu tố sau:

Danh mục chủ chốt

Feature

Giá của

công ty

bạn

IT Dept

Price

Giá đối thủ

cạnh tranh

thứ 1

Competitor

1 Price

Giá đối thủ

cạnh tranh

thứ 2.

Competitor

2 Price

Number of pages of text?

Số trang văn bản

a. Provide names and location of

this text.

Cung cấp tên va nơi lƣu trữ văn

bản

Number of images?

Số lƣợng ảnh?

a. Provide name and location of

each image file.

Tên va nơi lƣu trữ các file ảnh

b. Do any of these images need to

be altered?

Có ảnh nào cần chỉnh sửa hay

không?






Feature

Giá của

công ty

bạn

IT Dept

Price

Giá đối thủ

cạnh tranh

thứ 1

Competitor

1 Price

Giá đối thủ

cạnh tranh

thứ 2.

Competitor

2 Price

Number of animations required?

Số lƣợng phim?

a. Provide name and location of

each.

Cung cấp tên va nơi lƣu trữ

b. If new ones must be designed,

provide design information

Có các đoạn phim nào cần thiết

kề mới, cung cấp thông tin thiết

kế

Number of documents you wish to

store on the Web?

Số lƣợng tai liệu cần lƣu trữ trên

Web?

a. PDFfiles (name and location of

each)

PDF file(Tên và vị trí)

b. Doc files (name and location of

each)

Doc file (Tên và vị trí)

c. Powerpoint files (name and

location of each)

Powerpoint (Tên và vị trí)

d. Wave or audio files (name and

location of each)

Wav hoặc audio files (Tên và vị

trí)






Feature

Giá của

công ty

bạn

IT Dept

Price

Giá đối thủ

cạnh tranh

thứ 1

Competitor

1 Price

Giá đối thủ

cạnh tranh

thứ 2.

Competitor

2 Price

e. Avi or other video files (name

and location of each)

Avi file hoặc file video loại

khác (Tên và vị trí)

f. Other files - list

Các loại khác (danh sách)

Will you be using RealAudio or

video?

Bạn sẽ sử dụng RealAudio hay

video

a. Are media file already available

or do they need to be created or

digitalized?

Tập dữ liệu đa truyền thông của

bạn đã sẵng sàn hay cần đƣợc

tạo ra hoặc cần số hoá?

Will you require SSL connectivity?

This is secure server capability so

that people can do things like enter

private information online.

Bạn có yêu cầu kết nói SSL không?

Đây la máy chủ an ninh để ngƣời ta

có thể lam những việc nhƣ truy cập

trực tuyến vao thông tin cá nhân.

a. Do you require encryption?

Bạn có mã hoá thông tin

không?






Feature

Giá của

công ty

bạn

IT Dept

Price

Giá đối thủ

cạnh tranh

thứ 1

Competitor

1 Price

Giá đối thủ

cạnh tranh

thứ 2.

Competitor

2 Price

b. Do you require digital

certificates?

Bạn có cần chứng thực số

không?

c. What level of security do you

need?

Cấp độ an toàn mà bạn cần có

là gì

How many e-mail account do you

need?

Bạn cần bao nhiêu tai khoản email?

a. Will you need e-mail routing?

Bạn cần biết đƣờng đi của

email hay không?

b. Will you need autoresponder?

Email sẽ tự động trả lời hay

không?

Will you need a shopping cart

service for online purchases?

Bạn sẽ cần một dịch vụ giỏ hang để

mua hàng trực tuyến?

a. Do you already have product

information for those products

you wish to sell, including

images and text information?

Provide file name and location

of each

Bạn đã có thông tin về sản

phẩm bán nhƣ hình ảnh, tài






Feature

Giá của

công ty

bạn

IT Dept

Price

Giá đối thủ

cạnh tranh

thứ 1

Competitor

1 Price

Giá đối thủ

cạnh tranh

thứ 2.

Competitor

2 Price

liệu?cung cấp tên files va địa

điểm.

Will you need a chat room?

Bạn sẽ cần phòng chat?

Will you need a bulletin board?

Bạn sẽ cẩn bản tin vắn tắt ?

Will you need a guestbook?

Bạn sẽ cần sổ góp ý?

Will you need feedback forms?

Bạn sẽ cần các mẫu phản hồi?

Will you need activity reports?

What periodicity?

Bạn sẽ cần bản báo cáo hoạt động?

chu kỳ ?

Will you need banner creation?

Bạn sẽ cần tạo ra biểu ngữ

To which other sites do you wish to

link?

Bạn muốn trang Web nao sẽ liên kết

với bạn

Do you need database lookup?

Bạn có cần tra cứu cơ sở dữ liệu ?






Feature

Giá của

công ty

bạn

IT Dept

Price

Giá đối thủ

cạnh tranh

thứ 1

Competitor

1 Price

Giá đối thủ

cạnh tranh

thứ 2.

Competitor

2 Price

Do you need visistor registration

program?

Ngƣời truy cập đến Web có cấn

đăng ký?

Will yo outsource or do it

internally? If done internally, add

costs for:

Bạn thuê ngoai hay lam trong nội

bộ công ty? Nếu la trong nội bộ

công ty thì chi phí thêm là:

a. Hardware

Phần cứng

b. Servers

Máy chủ

c. Modems

d. Connectivity

Dịch vụ kết nối

e. T1

Will your company require Internet

fax?

Công ty bạn cần Internet fax?

Will the company require virtual

private networks (VPNs)?

Công ty bạn yêu cầu về VPNs?

(giữa các chi nhánh,với đối tác...)





Here are some reasons why outsourcing might be a good idea for

your company.

Một số lý do cho thấy thuê ngoai la ý tƣởng tốt cho công ty của bạn:

Price. Rolling your own is often much more expensive than

outsourcing to a reputable service provider.

Giá cả: Nghiệp vụ hoặc dịch vụ do chinh công ty bạn lam thì sẽ có

chi phi cao hơn nếu sử dụng Outsourcing.

Expertise. Few companies have the level of expertise in-house that

building a sophisticated Web site requires.

Sự chuyên nghiệp:Nha cung cấp thì có đội ngũ nhân viên giỏi, rất

thanh thạo va chuyên nghiệp trong dịch vụ hoặc nghiệp vụ ma họ

cung cấp.

Obsolescence. Hardware and software turn obsolete within six

months and upgrades are often expensive. Outsourcing makes this

someone else‘s problem. For the outsourcer to stay in business, it

must stay at the most current release and use the most sophisticated

equipment. It does this so you do not need to.

Sự lỗi thời: Các nha cung cấp có chuyên gia giỏi trong lĩnh vực của

họ, do đó nắm bắt rất tốt sự phát triển trong dịch vụ. Phần cứng va





phần mền sẽ trễ nên lạc hậu quá 6 tháng.Việc cập nhật va nâng cấp

sẽ rất đắt. Ma Outsourcing sẽ lam những vấn đề nay.

Security. As mentioned earlier, encryption, virus protection, and all

of the other security paraphernalia such as site backup and disaster

recovery are quite expensive to perform on your own.

An toàn: các vấn đề nhƣ mã hoá, bảo vệ chống virus…Va tất cả

các dịch vụ khác nhƣ make up dữ liệu, phục hồi dữ liệu….sẽ do

các nha cung cấp dịch vụ đảm trách.

Complete solution. If you select a reputable hosting company with

lots of experience you benefit from this experience and its

expertise. It can provide you with everything from hosting to

design to maintenance, all in one place.

Giải pháp trọn gói: Nếu bạn chọn một công ty có uy tin va kinh

nghiệm thì bạn sẽ nhận đƣợc lợi ich từ các sự uy tin va kinh

nghiêm của công ty nay, bảo đảm chất lƣợng dịch vụ va các dịch

vụ kèm theo (nếu có). Đối với nha cung cấp dịch vụ wed thì nha

cung cấp có thể cung cấp cho bạn từ dịch vụ lƣu trữ cho đến thiết

kế web….





Scalability. It is likely that your site will grow in complexity and

functionality. A Web-hosting company will be able to scale up

without service interruptions.

Khả năng mở rộng: khi công ty của bạn phát triển thì các nghiệp vụ

va dịch đòi hỏi quy mô lớn hơn,các nha cung cấp outsourcing có

thể đáp ứng tốt điều nay. Do đó dịch vụ đó không bị gián đoạn. Vi

dụ: Web site của công ty bạn trở nên phức tạp va nhiều chức năng,

số lƣợng truy cập tăng lên thì nha lƣu trữ Web (Web-hosting) có

thể tăng qui mô web của bạn lên ma không lam các dịch wed của

bạn bị gián đoạn.

Of course, there are disadvantages to outsourcing as well:

Dĩ nhiên thuê ngoai cũng có những bất lợi:

Hidden charges. If you exceed your quotas (i.e., data transfer, disk

space) you will be charged an additional premium.

Chi phí ẩn: Nếu bạn sử dụng vƣợt quá tiêu chuẩn đã qui định trong

hợp đồng (dung lƣơng lƣu trữ…) thì bạn phải trả thêm tiền.

Their rules and not yours. The Web hosting company makes the

rules and not you. You will need to modify your own corporate

policy to accommodate the outsourcer.





Hoạt đông theo nguyên tắc của họ: Các công ty Web-hosting sẽ

đƣa luật hoạt động chứ không phải la bạn. Do đó bạn cần phải chú

ý đến các chinh sách cung cấp dịch vụ của công ty tiến hanh hoạt

động thuê ngoai.

Timeliness. Say the Web hosting company runs an advertising blitz

to get new customers — and it works. Your request for

modifications might need to wait a while.

Phải lên lịch. Ngƣời ta nói các công ty Web-hosting chạy đua

quảng cáo để tìm khách hang mới. Tuy nhiên, những yêu cầu của

bạn sửa đổi Web của công ty của bạn có thể phải đợi.

Mergers and acquisitions. The Net world moves fast and is on an

acquisition binge. What happens if the company you are using is

acquired?

Liên kết kinh doanh và Sáp nhập: Mạng trên thế giới phát triển

nhanh va có những cuộc sáp nhập. Chuyện gì xảy ra nếu công ty

bạn sử dụng dịch vụ thuê ngoai của công ty bị mua lại.

6.6 NHỮNG CÂU HỎI CHO CÁC CÔNG TY OUTSOURCE TIỀM

NĂNG

A company cannot choose a hosting company out of a hat. Ask the

following questions:





Một công ty không thể lựa chọn một công ty đặt máy chủ theo kiểu

bốc thăm may mắt đƣợc. Phải đặt các câu hỏi sau:

What capabilities do you offer and at what prices? Can you provide

us with everything on our list of requirements?

Với những yêu cầu đƣợc đặt ra thì chi la bao nhiêu? Có thể đáp

ứng đƣợc những yêu cầu trong danh sách chúng tôi đƣa ra hay

không?

What is your level of expertise? Demonstrate by showing a

portfolio of Web sites developed at different levels of

sophistication.

Sự chuyên nghiệp của công ty bạn ở mức nao? Hãy chứng minh

bằng cách cho chúng tôi xem danh sách các Web đã đƣợc phát

triển ở các mức độ phức tạp khác nhau.

How long have you been in business?

Bao lâu để sử dụng nó (Web) đƣợc trong kinh doanh.

What are your sales?

Doanh số bán hang của bạn ra sao?

Provide three references.





Cung cấp cho chúng tôi 3 nha thầu khác để tham khảo.

How quickly do you respond to telephone and e-mail customer

service questions?

Trả lời các câu hỏi bằng điện thoại va email của khách hang nhanh

nhƣ thế nao.

What measures do you have in place to secure our data on your

servers?

Thƣớc đo độ an toan của dữ liệu trên máy chủ.

Are you 24x7?

Bạn lam việc 24x7 không ?

What type of disaster recovery services do you provide?

Loại thảm hoạ nao nao cần khôi phục hồi lại dịch vụ ma bạn cần

cung cấp.

How often do you upgrade your hardware and software?

Bao lâu một lần thì bạn nâng cấp phần mền va phần cứng.





If some of your staff are using dial-up lines to access your

outsourced servers, can they get online without busy signals? Can

staff members use local phone numbers to dial into the network?

Nếu một vai nhân viên bạn đang sử dụng đƣờng dial-up để truy cập

vao các máy chủ ngoai,thì họ có bị nghẽn mạng khi sử dụng trực

tuyến không? Các nhân viên thanh viên sử dụng số điên thoại địa

phƣơng có thể kết nối đến mạng hay không?

What are the speed and capacity of the hosting company‘s link to

the Internet? (This is called throughput.)

Tốc độ va dung lƣợng của công ty lƣu trữ Web hosting ra Internet.

6.7 NHỮNG MÔ HÌNH THUÊ NGOÀI

Outsourcing does not need to be an all or nothing proposition;

several models are available:

Thuê ngoai không nhất thiết phải la một lời khẳng định tất cả hoặc

không gì cả. Có một vai mô hình nhƣ sau:

In-house. If you are a large company with a significant existing

technology infrastructure with commensurate expertise, this

approach might be the most cost-beneficial to you. Of course, you





will not know whether this is the right approach unless you cost out

the other alternatives.

In-house: Nếu công ty của bạn la một công ty lớn có cơ sở hạ tầng

công nghệ với chuyên môn cao,thì mô hình nay có lợi về chi phi

nhất cho bạn. Tất nhiên, tất nhiên bạn sẽ không biết đây la mô hình

gần đúng trừ khi bạn phải đánh giá những sự lƣa chọn khác.

Full outsource. Turn over the entire spectrum of development to an

outsourcing company or combination of outsourcing companies

and consulting firms.

Full outsource: nó rất phổ biến,trên toan bộ sự phát của các công

ty Outsourcing, sự kết hơp giữa các công ty Outsourcing va công

ty tƣ vấn.

Partial outsource. Possible alternatives are hosting your own

servers but hiring a consultancy to program them; outsourcing your

server hosting but programming it in-house, and hosting your

servers but purchasing third-party software packages to run on

those servers.

Partial Outsource: Một sƣ lựa chọn khác la máy chủ lƣu trữ của

chinh công ty bạn nhƣng thuê tƣ vấn phần mền bên trong. Thuê

máy máy chủ nhƣng chƣơng trình chạy bên trong do công ty bạn





lam. Thuê máy chủ nhƣng gói phần mền chạy bên trong thuê bên

thứ ba lam.

6.8 KẾT LUẬN

Whether to outsource or not is a difficult decision and involves the

analysis of many variables. Ultimately the success — and bottom line — of

the organization rests on making the right decision.

Dù có quyết định thuê ngoai hay không thì đây cũng không phải la

một quyết định đơn giản va nó liên quan đến sự cân đo đong đếm kỹ lƣơng

nhiều thanh phần. Hãy dựa vao lợi ich của công ty, va khả năng thuê ngoai

đem lại cho công ty bạn để có quyết định đúng đắn.




Chương 7: Lựa chọn phương pháp luận 261

CHƢƠNG 7 LỰA CHỌN PHƢƠNG PHÁP LUẬN

Người dịch:

1. Lê Quang Thảo

2. Huỳnh Thảo Hạnh

Duy


7.1 ĐÁNH GIÁ PHƢƠNG PHÁP LUẬN

7.1.1 Phƣơng pháp luận có xác định những bƣớc cần thiết để phát

triển hệ thống không?

Methodologies are necessarily very ―step‖ oriented. One cannot and

should not proceed to step two without adequately completing step one. A

person using a particular methodology should be provided with a clear

delineation of all steps as well as what initiates and terminates each of these

steps. A good methodology will define answers to the following questions:

Các phƣơng pháp luận cần đƣợc định hƣớng từng bƣớc một. Chúng

ta không thể va không nên đi đến bƣớc hai khi chƣa hoan thanh bƣớc một.





Khi sử dụng một phƣơng pháp luận nhất định, cần đƣợc phát họa rõ rang tất

cả các bƣớc từ đầu đến cuối. Một phƣơng pháp luận tốt sẽ đƣa đƣợc câu trả

lời cho các câu hỏi sau:

What must be done?

How long will it take?

Why is the step done?

How should it be done?

What is produced?

Who will do it?

When should it be done?

Which tools are to be used?

Phải lam những gì

Làm trong bao lâu

Tại sao lại thực hiện bƣớc nay

Sản phẩm la gì





Ai la ngƣời thực hiện

Khi nào làm

Những công cụ nao sẽ đƣợc dùng

Đánh giá thuộc tinh nay:

7.1.2 Phƣơng pháp luận có đơn giản hóa quá trình phát triển hệ

thống?

Some methodologies are so complicated that they are impossible to

use. If it is not clear to the user of the methodology how to use that

particular methodology, the systems development effort will fail.

Vai phƣơng pháp luận phức tạp đến nỗi không sử dụng đƣợc. Nếu

ngƣời dùng không hiểu rõ đƣợc phƣơng pháp thì những cố gắng sẽ vô ich






7.1.3 Phƣơng pháp luận có tạo ra những bƣớc tiến lớn trong phát

triển hệ thống?

The Software Engineering Institute

(http://www.sei.cmu.edu/seihome.html) in Pittsburgh is the creator of the

well-known capability maturity model (CMM). The framework consists of

several levels of maturity that an IT department goes through on its way to

becoming completely optimized and productive:

Viện công nghệ phần mềm tại Pittsburgh la nơi sáng tạo ra mô hình

CMM (Capability Maturity Model). Nó bao gồm nhiều mức độ ma ngƣời

lập trình phải vƣợt qua để đạt hiệu quả cao:

Repeatable. Basic project management processes are established

to track cost, schedule, and functionality.

Defined. Management and engineering activities are documented,

standardized, and integrated into the organization.

Quantitatively managed. This level uses detailed measures.





Optimizing. Continuous process improvement is enabled by

quantitative feedback and from testing innovative ideas and

technologies

Initial

Repeatable: những tiến trình quản lý dự án đƣợc thiết lập thanh

lịch trình, chi phi va những chức năng cụ thể

Defined: các hoạt động đƣợc tai liệu hóa, chuẩn hóa va đƣợc kết

hợp thanh những tổ chức

Quantitatively managed: Mức độ nay sử dụng những tinh toán chi

tiết

Optimizing: Sự phát triển không ngừng dựa trên những phản hồi về

số lƣợng va từ những ý tƣởng mới hay những kĩ thuật khác

Initial. This level is ad hoc and chaotic.

An often quoted statistic is that 80 percent of us are sitting on top of

level one. Use of a methodology implies that the organization is at level

three — defined. A methodology enables the organization to implement a

standardized procedure for the development of systems so that the process





of developing these systems is standardized and can be repeated easily by

one or more project teams.

Thông thƣờng 80% chúng ta chỉ dừng lại ở mức độ một. Sử dụng

một phuơng pháp ngụ ý rằng tổ chức phải đạt mức độ ba – defined. Một

phƣơng pháp luận sẽ cho phép tổ chức thực hiện thủ tục chuẩn hóa cho sự

phát triển của hệ thống, nhƣ vậy quá trình phát triển những hệ thống nay sẽ

đƣợc chuẩn hóa va lặp lại một cách dễ dang bởi một hoặc nhiều đội dự án


7.1.4 Phƣơng pháp luận có thể tùy biến để tƣơng thich bới các yêu

cầu cụ thể của tổ chức hay không?

Every organization is unique in terms of its policies and procedures,

industry, and standards it applies to its practices. It makes sense, therefore,

that any methodology selected needs to be flexible so that it can

accommodate the way the organization works today — as well as the way

the organization will work tomorrow. The very best methodologies are

those that permit the organization full customization capabilities in terms

of:





Mỗi tồ chức duy nhất trong từng giai đoạn của chinh sách va thủ tục,

công nghiệp va những tiêu chuẩn nó áp dụng. Nghĩa la, mỗi phƣơng pháp

luận cần có độ phức tạp nhất định để phù hợp với cách hoạt động của

những tổ chức hiện nay cũng nhƣ sau nay. Phƣơng pháp luận tốt nhất cho

phép tổ chức những khả năng tùy biến với những giới hạn nhƣ:

Can the names of methodology components be changed to those

the organization is more familiar with?

Can the descriptions of methodology components be changed?

Can new components be added and related to existing components?

Can component definitions (designs) be altered, extended, or

deleted?

Can new paths be defined to describe unique uses of the

methodology?

Can the underlying methods and deliverables be changed?

Có thể đổi tên những phƣơng pháp luận thanh phần để quen thuộc

với hệ thống hơn?

Sự diễn tả của những phƣơng pháp luận thanh phần có thể bị thay

đổi?





Những thanh phần mới có thể đƣợc thêm vao va liên quan đến

những thanh phần cũ hay không?

Những định nghĩa (thiết kế) thanh phần có thể bị thay đổi, mở rộng

hoặc loại bỏ?

Những cách thức mới có thể đƣợc sử dụng để miêu tả những công

dụng riêng biệt của phƣơng pháp luận

Những cách thức quan trọng có thể bị thay đổi


7.1.5 Phƣơng pháp luận có phải la “trạng thái của nghệ thuật?”

Each month brings new innovations to the IT industry. The Internet

has been with us for less than a decade. Flat file systems have morphed into

relational database systems that have morphed into object-oriented

databases. Because the tools and techniques of developing systems are

continually improving, it makes sense that the methodology chosen needs

to have the capability of interacting with these newer tools and techniques

— in case the methodology becomes as obsolete as the tools it thinks you

are using. Tools that your methodology should support include:





Mỗi tháng lại có nhiều phát kiến mới trong lĩnh vực công nghệ thông

tin. Internet ra đời chƣa đầy một thập kỉ. Hệ thống tập tin chuyển dần sang

hệ thống cơ sở dữ liệu quan hệ, rồi lại chuyển sang sơ cở dữ liệu hƣớng đối

tƣợng.

Bởi vì công cụ va kĩ thuật để phát triển hệ thống vẫn không ngừng

đƣợc cải tiến, cho thấy rằng phƣơng pháp luận đƣợc chọn cần phải có khả

năng tƣơng tác với các công cụ va kĩ thuật mới nay – trong trƣờng hợp

phƣơng pháp luận va công cụ bạn đang dùng trở nên lỗi thời.

Những công cụ ma phƣơng pháp luận của bạn nên hỗ trợ:

Computer-assisted systems engineering (CASE), as well as visual

development tools such as Visual Basic, Visual C++, etc.

Data dictionaries, repositories, and data warehouses

Java and XML

Relational databases and object-oriented databases

Client-server

Cooperative and collaborative processing

Internet and Intranet





Accelerated and user-centered development such as JAD (joint

application development) and RAD (rapid application

development)

Integration (across business area, system data, and function

sharing)

Kĩ thuật hệ thống hỗ trợ máy tinh (Computer-assisted systems

engineering - CASE), cũng nhƣ các công cụ phát triển nhƣ: Visual

Basic, Visual C++, …

Từ điển dự liệu, kho lƣu trữ dữ liệu.

Java và XML

Cơ sở dữ liệu quan hệ va cơ sở dữ liệu hƣớng đối tƣợng.

Tƣơng tác máy khách-máy chủ

Quy trình cộng tác va hợp tác (cooperative and collaborative

processing)

Inernet và Intranet

Sự phát triển nhanh va tập trung vao ngƣời dùng (user-centered)

nhƣ: JAD (joint application development) and RAD (rapid

application development)





Sự tich hợp (Integration) (khu vực kinh doanh, dữ liệu hệ thống, va

chia sẽ chức năng)


7.1.6 Phƣơng pháp luận có hoan thiện không?

Most formal systems development activities are based around several

steps collectively known as the SDLC or systems development life cycle.

The SDLC consists of:

Hầu hết các hoạt động trong quá trình phát triển hệ thống đều dựa

trên các bƣớc của SDLC, bao gồm:

Planning. In this step we uncover the mission and goals of the

project and ascertain the resources required to implement the

system.

Feasibility. This step determines whether or not the project is

economically or technically feasible.

Analysis. In this step the business and technical requirements of

proposed systems are uncovered, modeled, and documented.





Design. During this phase system high-level as well as low-level

architectures are crafted that are traceable back to the business

requirements uncovered in the analysis phase.

Implementation. In this phase programs are coded and tested.

Production. Once the programs have been written and tested, this

phase will oversee the introduction of the system into the business.

Maintenance. No system is ever complete. During the maintenance

phase, modifications are made to the system to fix errors and to

enhance the system per new requirements.

Lập kế hoạch (Planning). Ở bƣớc nay chúng ta sẽ khám phá ra

nhiệm vụ va các mục tiêu của đề án va xác định nguồn tai nguyên

cần thiết để cai đặt hệ thống.

Tinh khả thi (Feasibility). Bƣớc nay quyết định dự án có khả thi về

mặt chi phi hay kĩ thuật không.

Phân tich (Analysis). Ở bƣớc nay, yêu cầu kĩ thuật va yêu cầu

nghiệp vụ của hệ thống đƣợc vạch ra, mô hình hóa va tai liệu hóa.

Thiết kế (Design). Ở bƣớc nay, các kiến trúc cấp cao cũng nhƣ cấp

thấp đƣợc thiết kế sao cho có thể chuyển ngƣợc về yêu cầu nghiệp

vụ đã đề ra ở bƣớc phân tich.





Cai đặt (Implementation). Các chƣơng trình đƣợc code va kiểm tra.

Đƣa ra sản phẩm (Production). Một khi các chƣơng trình đã đƣợc

viết va kiểm tra, bƣớc nay sẽ giám sát việc đƣa hệ thống vao thực

hiện các nghiệp vụ.

Bảo trì (Maintenance). Không có hệ thống nao la hoan thiện. Suốt

quá trình bảo trì, sẽ có những chỉnh sửa đối với hệ thống để sửa lỗi

va nâng cấp hệ thống theo nhƣng yêu cầu mới.

Some methodologies pertain only to the latter phases of the SDLC. A

preferred methodology will encompass the entire range of SDLC activities.

Một vai phƣơng pháp luận chỉ liên quan tới các bƣớc sau của SDLC.

Một phƣơng pháp đƣợc ƣa chuộng phải bao gồm toan bộ các bƣớc của

SDLC.

Hãy đánh giá thuộc tinh nay:





7.1.7 Phƣơng pháp luận có thể bị chia ra thanh các thanh phần nhỏ

không?

Although the methodology should cover all phases of the SDLC, the

preferred methodology will be object oriented in nature. For example, it

should be possible to extract the piece of the methodology relevant to the

feasibility study easily.

Mặc dù phƣơng pháp luận nên bao gồm tất cả các bƣớc trong SDLC,

nhƣng một phƣơng pháp luận đƣợc ƣa chuộng hơn sẽ la hƣớng đối tƣợng

trong tự nhiên. Vi dụ, nó phải cho phép ta rút ra một phần của phƣơng pháp

luận sao cho tƣơng ứng với việc nghiên cứu tinh khả thi một cách dễ dang.


7.1.8 Phƣơng pháp luận có thể thich ứng với nhiều lĩnh vực, nganh

nghề?

Organizations across industry boundaries exhibit different attributes.

A preferred methodology is adaptable to all industries, across all

boundaries.





Các tổ chức thuộc nhiều lĩnh vực, nganh nghề khác nhau sẽ đƣa ra

các thuộc tinh khác nhau. Một phƣơng đƣợc ƣa chuộng cần phải thich ứng

với tất cả các lĩnh vực, nganh nghề.


7.1.9 Phƣơng pháp luận có sản sinh ra tai liệu ?

A formal process necessitates the creation of deliverables at certain

predesignated milestones. For example, upon completion of the analysis

phase it is typical that a requirements specification be created. The

particular methodology will specify the format and timeliness of the

document.

Một qui trình chinh thức đòi hỏi phải có sự sáng tạo của việc phân

phối tại một thời điểm nao đó của việc thiết kế. Vi dụ sau khi hoan thanh

giai đoạn phân tich.Giai đoạn nay điển hình la 1 đặc tả yêu cầu đƣợc tạo

ra.Các phƣơng pháp cụ thể sẽ quyết định định dạng va nội dung của tai liệu






7.1.10 Phƣơng pháp luận có những phƣơng pháp riêng biệt cho mỗi

bƣớc trong từng giai đoạn của SDLC hay không ?

A formal methodology breaks down the systems development

process into phases (e.g., SDLC). Each phase, in turn, has its own unique

steps. A good methodology will supply methods that will instruct the

developer in applying that segment of the methodology to the particular

step in question. For example, a unique step of the analysis phase is to

interview end users. A good methodology will provide instructions on:

Phƣơng pháp luận chinh thức phân chia qui trình phát triển hệ thống

thanh từng giai đoạn.Mỗi giai đoạn lần lƣợt có các bƣớc riêng độc đáo của

nó.

Một phƣơng pháp luận tốt sẽ cung cấp các phƣơng pháp ma nó

hƣớng dẫn các nha phát triển trong việc ứng dụng phƣơng pháp phân đoạn

thanh các bƣớc cụ thể trong câu hỏi.Vi dụ bƣớc duy nhất của giai đoạn

phân tich la phỏng vấn ngƣời dùng cuối. Một phƣơng pháp luận tốt sẽ cung

cấp những hƣớng dẫn sau:

Who performs this task





How to perform this task

What tools to use to perform this task

What deliverable, if any, is required

Ngƣời nao thực hiện công việc nay.

Lam thế nao để thực hiện công việc nay

Công cụ nao đƣợc sử dụng để thực hiện công việc nay.

Chuyển giao cái gì, nếu có thì rất cần thiết.


7.1.11 Liệu các phƣơng pháp luận có cung cấp các phƣơng pháp kĩ

thuật ma mô tả lam cách nao để thực hiện các phƣơng pháp

của nó ?

For a methodology to be usable it must detail the techniques of

performing the tasks outlined within it. For example, for the task ―interview

end users‖ techniques should include:





Một phƣơng pháp luận đƣợc sử dụng thì nó phải chi tiết các phƣơng

pháp kĩ thuật để thực hiện các nhiệm vụ đƣợc vạch ra bên trong nó.Ví

dụ,đối với nhiệm vụ ―phỏng vấn ngƣời dùng cuối‖,các phƣơng pháp kĩ

thuật nên bao gồm:

How to select the end users

What sampling techniques to use

How to devise questionnaires and surveys

How to use a tape or video recorder effectively

Lam thế nao để chọn đƣợc ngƣời dùng cuối

Những cái mẫu kĩ thuật nao đƣợc sử dụng

Làm thế nao để nghĩ ra một bảng câu hỏi va khảo sát

Lam thế nao để sử dụng một băng ghi âm hoặc máy ghi hình có

hiệu quả






7.1.12 Các phƣơng pháp luận sẽ kết hợp chặt chẽ các tiêu chuẩn va

ngoai thực tiễn của tổ chức ?

All organizations are different. Each publishes its own set of policies

and procedures (i.e., naming conventions, tool usage guidelines, etc.),

which may or may not be consistent within the industry. A good

methodology enables the organization to maintain its unique set of

standards and practices.

Tất cả những tổ chức đều khác nhau.Mỗi tổ chức đều xuất bản,thiết

lập các chinh sách riêng của mình va các thủ tục (nhƣ đặt tên các hội

nghị,hƣớng dẫn cách sử dụng các tool hỗ trợ,…).Một phƣơng pháp luận tốt

cho phép các tổ chức để duy trì,thiết lập những tiêu chuẩn va thông lệ duy

nhất.


7.1.13 Phƣơng pháp luận có xác định đƣợc từng vai trò của những

thanh viên khác nhau trong team của dự án hay không ?

A wide variety of people constitutes a typically project team.

Project manager — manages one or more projects.





Project leader — manages a specific project.

Systems analyst — handles the analytical aspects of the system.

Designer — designs the systems (might be the same person as the

analyst).

Network administrator — is responsible for implementing the

network aspects of the system.

Database administrator — designs the database and file systems.

Web designer — handles the front end of any Internet or Intranet

systems.

An effective methodology links required skills with each method in

order to identify appropriate roles.

Có những vị tri sau đây trong team của dự án:

Project manager:quản lý một hay nhiều dự án.

Project leader: quản lý một dự án xác định nao đó.

Systems analyst: xử lý các khia cạnh, phân tich hệ thống





Designer: Thiết kế ra hệ thống (có thể công việc giống ngƣời phân

tích)

Network Administrator: Chịu trách nhiệm thi hanh mạng của hệ

thống

Database Administrator: thiết kế ra cơ sở dữ liệu va những file hệ

thống

Web Designer: thiết kế ra hệ thống web cho hệ thống.

Một phƣơng pháp luận hiệu quả la liên kết các kĩ năng cần thiết với

mỗi phƣơng pháp để ma xác định vai trò thich hợp.


7.1.14 Liệu đồng nhất phƣơng pháp có cung cấp công cụ phù hợp cho

việc thi hanh từng phƣơng pháp?

A wide variety of tools on the market will automate many of the

tasks delineated in the methodology (i.e., survey generation, program code

generation, model building).





It should be noted that many methodologies were developed by

software vendors for the express purpose of supporting a particular tool set.

In other words, the methodology was developed as a marketing vehicle for

the tool set.

Nhiều loại công cụ khác nhau trong chợ sẽ tự động hóa nhiều tác vụ

đƣợc mô tả trong phƣơng pháp luận. (vi dụ: khảo sát thế hệ, lập trình mã

thế hệ, xây dựng mẫu)

Nên ghi chú rằng nhiều phƣơng pháp luận đƣợc phát triển bằng

ngƣời bán phần mềm cho những mục tiêu rõ rang của việc cung cấp 1 nhóm

công cụ cụ thể. Mặt khác, phƣơng pháp luận đƣợc phát triển nhƣ la phƣơng

tiện tiếp thị cho nhóm công cụ đó.

Đánh giá thuộc tinh:

7.1.15 Phƣơng pháp luận có thể thực hiện đƣợc không?

A formal methodology must have a visible model. This model must

be able to be verified for correctness and completeness and modified as

needs dictate. Only methodologies that are coupled with automated tool sets

are capable of this.





Một phƣơng pháp luận bình thƣờng phải có một mẫu rõ rang. Mẫu

đó phải có thể thực hiện cho việc chỉnh sửa va hoan thanh va hiệu chỉnh khi

mệnh lệnh cần thiết. Chỉ những phƣơng pháp luận đƣợc ghép với nhóm

công cụ tự động thich hợp với nó.

Đánh giá thuộc tinh:

7.1.16 Phƣơng pháp luận có thể đƣợc tìm thấy?

Methodology is the road map to the development of a system. As

discussed, the methodology contains information on how to approach each

phase in the SDLC along with techniques and tools for executing the

methods specified for that particular phase. From the perspective of the

systems developer, the methodology is a knowledge base that instructs him

or her on the ―how-tos‖ as well as the ―why tos‖ and ―when tos‖ of systems

development. It makes sense, therefore, that the system developer be

permitted to search through this methodology knowledge base to retrieve

specific information.

Phƣơng pháp luận la một bảng chỉ đƣờng cho việc phát triển hệ

thống. Nhƣ đã đề cập, phƣơng pháp luận chứa thong tin lam sao tiếp cận

từng mặt trong SDLC theo những kỹ thuật va công cụ cho việc thực thi





phƣơng pháp đặc biệt cho từng mặt cụ thể. Từ tầm nhìn của ngƣời phát

triển hệ thống, phƣơng pháp luận la nền tảng kiến thức ma hƣớng dẫn ngƣời

phát triển về những câu hỏi nhƣ thế nao hay tại sao va khi nao của việc phát

triển hệ thống. Điều đó tạo nên ý nghĩa ma ngƣời phát triển hệ thống đƣợc

phép tìm kiếm qua các phƣơng pháp luận nền tảng kiến thức để tìm lại đƣợc

thong tin đặc thù.

Because it is a knowledge base, the information contained there

should be navigable from multiple perspectives. The systems developer

should be able to forward chain through the knowledge base from top to

bottom, as well as backward chain upward from the lowest level to the

highest level of abstraction.

Bởi vì đó la kiến thức nền tảng, nên thong tin chứa đựng ở đó nên

điều khiển đƣợc từ những tầm nhìn lien kết khác nhau. Ngƣời phát triển hệ

thống nên có khả năng xúc tiến dây chuyền thong qua nền tảng kiến thức từ

trên xuống dƣới, cũng nhƣ xem xét từ dƣới lên trên từ cấp thấp nhất đến

cấp cao nhất của trừu tƣợng hóa.

The methodology knowledge base should exhibit all of the features

of an end-user-oriented, windows- or browser-based system, including

search, print, save, edit, view, and help.





Nền tảng kiến thức phƣơng pháp luận nên nêu lên tất cả các điểm

đặc trƣng hƣớng tới ngƣời dung cuối, hệ thống dựa trên windows hoặc trình

duyệt, bao gồm tìm kiếm, in ấn, lƣu trữ, hiệu chỉnh, xem xét va giúp đơ.

Đánh giá phƣơng pháp nay:

7.1.17 Phƣơng pháp luận có duy trì giao diện tiêu chuẩn công nghiệp?

Although it is expected that the methodology chosen will be coupled

with one or more automated tools, a very strong possibility is that the

organization will already be using a wide variety of other tool sets that the

methodological tool set should be able to interface with. These interfaces

include:

Mặc dù đƣợc kỳ vọng rằng việc lựa chọn phƣơng pháp luận phù hợp

với 1 hoặc nhiều những công cụ tự động, 1 khả năng rất cao rằng tổ chức sẽ

sẵn sang sử dụng 1 nhóm những công cụ khác nhau ma những nhóm công

cụ theo phƣơng pháp đó nên có khả năng giao tiếp với chúng. Những giao

tiếp bao gồm:

Project management software

CASE and application development tool sets





Report writers

Desktop publishing and word processing software

Spreadsheets and databases

Phần mềm quản lý dự án

CASE va nhóm công cụ phát triển ứng dụng

Ngƣời viết báo cáo

Phần mềm in ấn va chữ viết

Bảng tinh va cơ sở dữ liệu


7.1.18 Sự đao tạo thich hợp có phù hợp với phƣơng pháp luận

Whether the training is vendor oriented, in-house oriented or

consultant/ training company oriented, it is imperative that staff be fully

trained on use of the methodology, as well as any tool sets, prior to use.





Khi sự đao tạo la hƣớng đến ngƣời quản lý, hƣớng đến 1 nhóm hoặc

1 tổ chức/ đao tạo hƣớng đến công ty, rất cấp bách rằng nhân viên đƣợc

huấn luyện đầy đủ để sử dụng phƣơng pháp luận, nhƣ la bất cứ nhóm công

cụ nao, trƣớc khi sử dụng.


7.1.19 Ngƣời quản lý giải thich rằng bộ công cụ, phƣơng pháp đƣợc

sử dụng trong tổ thức giống nhƣ trong tổ chức của bạn?

Seeing the methodology and tool set, if applicable, in use at a

comparable organization is reassuring and demonstrates the full range of

the methodology‘s capabilities. Additionally, it demonstrates the

capabilities of the vendor in terms of training, implementation, and support.

Nhìn thấy phƣơng pháp luận va nhóm công cụ, nếu thich hợp, đƣợc

sử dụng tại 1 tổ chức so sánh thì lam yên long va chứng minh đầy đủ khả

năng của phƣơng pháp luận. Thêm vao đó, nó chứng minh năng lực.






7.2 QUYẾT ĐỊNH MỨC ĐIỂM PHƢƠNG PHÁP LUẬN

Our questionnaire contained 19 questions or attributes. With a top

score of 4 points for each question or attribute, the highest rating a

methodology can receive is 76 points. An adequate rating, a point score of

at least 2 per question, would be 36 points. Obviously, the higher the score

is, the better the methodology.

Bảng khảo sát của chúng tôi bao gồm 19 câu hỏi hay thuộc tinh. Với

điểm cao nhất la 4 cho từng câu hỏi hoặc thuộc tinh, đánh giá cao nhất 1

phƣơng pháp có thể nhận đƣợc 76 điểm. Đánh giá trung bình, đƣợc it nhất 2

điểm 1 câu, sẽ la 36 điểm. Có thể thấy đƣợc, điểm cang cao, phƣơng pháp

cang tốt.

7.3 TÀI LIỆU THAM KHẢO

Holcman, S. (1993). A systems methodology: a rating and evaluation

guide, in Software Engineering Productivity Handbook, Keyes, J., Ed.,

McGraw-Hill, New York.




Chương 8: Lựa chọn, kết hợp thông tin để quản lý tài nguyên hiệu quả 289

CHƢƠNG 8 LỰA CHỌN VÀ KẾT HỢP THÔNG

TIN ĐỂ QUẢN LÝ TÀI NGUYÊN HIỆU QUẢ

Người dịch:



3. Lê Văn Chân

4. Lê Anh Khoa






8.1 QUẢN LÝ HIỆU QUẢ TÀI NGUYÊN THÔNG TIN

There are many roads to productivity. The one least traveled, but

perhaps most profitable, is the one where software tools are integrated in a

manner producing accessible and timely information.

Có nhiều con đƣờng để tăng năng suất. Con đƣờng ngắn nhất, nhƣng

có lẽ sinh lợi nhiều nhất, la khi các công cụ phần mềm đƣợc tich hợp với

nhau để cung cấp thông tin kịp thời va dễ tiếp cận.

The three keywords here are information, tools, and integration.

Information is really the most important asset a company owns. With

proper utilization, information becomes a potent competitive force. In

today‘s very global — and very competitive — economy, information may,

in fact, be the deciding factor in determining the color of the organization‘s

bottom-line.

Ba vấn đề quan trọng nhất ở đây la thông tin, công cụ, va sự kết hợp.

Thông tin thực sự la tai sản quan trọng nhất của một công ty. Với việc sử

dụng thich hợp, thông tin sẽ trở thanh một công cụ cạnh tranh rất mạnh.

Trong nền kinh tế toan cầu va cạnh tranh gay gắt hiện nay, trên thực tế

thông tin có thể la yếu tố quyết định trong việc xác định đặc trƣng của tổ

chức.

Understanding that information is a resource to be valued,

organizations have made a heavy investment in information technology.





This investment, to the tune of billions of dollars, included development of

new systems as well as purchase of a variety of software tools.

Hiểu rõ điều đó nên các tổ chức đã đầu tƣ mạnh vao công nghệ thông

tin. Sự đầu tƣ hang tỷ đô la nay bao gồm việc phát triển hệ thống mới va

mua một loạt các công cụ phần mềm.

Software tools are decidedly two-flavored. On the one hand are the

end user-oriented tools, which include report writers and 4GLs; on the other

hand are tools that specifically target the development function. These tools

run the gamut from compilers to data administration tools to visual

development tools. Common among all of these tools has been the decided

lack of interconnectivity, or integration.

Các công cụ phần mềm có hai loại rõ rệt. Một mặt la những công cụ

hƣớng đến ngƣời sử dụng cuối, nhƣ ngƣời viết báo cáo va 4GLs; mặt khác

la các công cụ hƣớng đến chức năng phát triển, nhƣ trình biên dịch, các

công cụ quản lý dữ liệu va các công cụ trực quan. Thông thƣờng tất cả

những công cụ nay đều thiếu sự gắn kết.

Lack of integration is a subtle defect with a powerfully negative

impact on the productivity and competitiveness of an organization. It

translates to an inability to manage information in a consistent and

nonredundant fashion. Because software tools have seams, information

cannot flow easily from one tool to anther, forcing organizations to move





the information manually between tools — or worse, to create redundant

and conflicting information stores.

Thiếu sự gắn kết la một thiếu sót khó thấy va có tác động tiêu cực rất

lớn đối với năng suất va khả năng cạnh tranh của một tổ chức. Nó đƣợc

hiểu la sự thiếu khả năng quản lý thông tin một cách bền vững va tinh gọn.

Thông tin không thể lƣu chuyển dễ dang giữa những công cụ với nhau,

buộc các tổ chức phải di chuyển thông tin theo cách thủ công - hoặc tệ hơn,

tạo ra các kho lƣu trữ thông tin dƣ thừa va xung đột với nhau.

Recognizing the ramifications of these problems, the industry has

begun to move in the direction of development frameworks. The goal of

these frameworks is to provide a boundaryless environment to spur the free

flow of information through the use of standards and guidelines for

development of software tools.

Sau khi nhận ra những vấn đề nay, nganh công nghiệp phần mềm đã

bắt đầu chuyển hƣớng, phát triển các khuôn khổ phát triển (khung phát triển

– development framework). Mục tiêu la cung cấp một môi trƣờng không

ranh giới để thúc đẩy sự lƣu thông tự do của thông tin thông qua việc sử

dụng các tiêu chuẩn va nguyên tắc phát triển của các công cụ phần mềm.

Metadata repositories, the focus of this chapter, have historically

focused on application development and data warehousing. Recently this

mission has been extended to support component middleware frameworks





and business objects. In the near future, knowledge management and

enterprise information portal environments will be supported as well.

Kho chứa siêu dữ liệu (metadata repository), trọng tâm của chƣơng

nay, trong quá khứ thƣờng đƣợc xem la việc phát triển ứng dụng va lƣu trữ

dữ liệu. Gần đây, nhiệm vụ nay đã đƣợc mở rộng để hỗ trợ các framework

middleware thanh phần va các đối tƣợng kinh doanh. Trong tƣơng lai gần,

quản lý kiến thức va cổng thông tin thƣơng mại cũng sẽ đƣợc hỗ trợ.

A metadata repository, which I will call a repository workbench, has

three functions. It is a repository, it provides tools, and it forms the

―connecting glue‖ of the development framework — in other words,

integration.

Một kho lƣu trữ siêu dữ liệu, ma ở đây gọi la một Repository

Workbench, có ba chức năng. Nó la một kho lƣu trữ, nó cung cấp các công

cụ, va nó tạo keo "kết nối‖- nói cách khác, gắn kết.

A short and standard definition of a repository is ―an organized

reference to the data content of something. That something could be a

system, a database, or a collection of all the files, program databases, and

manual records maintained by a large organization‖. Although the

definition of tools should be self-evident, in this context it is not.

Một định nghĩa ngắn của "kho lƣu trữ‖ la "một sự tham chiếu có tổ

chức đến nội dung dữ liệu của một cái gì đó. Cái gì đó ở đây có thể la một





hệ thống, một cơ sở dữ liệu, hoặc một tập hợp tất cả các file, chƣơng trình,

va các bản ghi đƣợc duy trì bởi một tổ chức lớn". Mặc dù định nghĩa các

công cụ la hiển nhiên, nhƣng trong bối cảnh nay thì không.

Tools in a repository workbench environment encompass a broad

spectrum of functionality that goes beyond what is commonly available.

The last component of the repository workbench equation is integration;

this component meshes the repository and the repository-based tools into an

organization‘s environment. The net sum of the repository equation is the

ability to better leverage the skill set of a wide range of the organization‘s

staff — from data administrators to programmers to analysts and end users.

This leveraging of skill sets leads to a dramatic increase in productivity.

Công cụ trong Repository Workbench bao gồm một phạm vi rộng

lớn các chức năng đi xa hơn thông thƣờng. Thanh phần cuối cùng của

Repository Workbench la sự gắn kết; thanh phần nay giúp kho lƣu trữ va

các công cụ hoạt động ăn khớp trong môi trƣờng của một tổ chức. Chức

năng quan trọng của Repository Workbench la khả năng tận dụng tốt hơn

các kỹ năng của một loạt các nhân viên của tổ chức - từ nha quản trị dữ liệu

đến lập trình viên, các nha phân tich va ngƣời dùng cuối. Điều nay tận dụng

các bộ kỹ năng, dẫn đến tăng năng suất mạnh mẽ.

The remainder of this chapter assists the reader in three areas:

evaluating the benefits of a repository workbench solution, planning for its

implementation, and measuring it.





Phần còn lại của chƣơng nay giúp ngƣời đọc trong ba lĩnh vực: đánh

giá những lợi ich của một giải pháp Repository Workbench, lập kế hoạch

cho việc cai đặt, va tinh điểm nó.

8.2 CÁCH SỬ DỤNG CHƢƠNG NÀY

In the first section — Evaluating the Repository Workbench — a

quantitative approach is taken to assist the reader in understanding the

features of a repository workbench and comparing these features across

competitive products. Twenty-three distinct criteria are divided into three

categories: repository, integration, and tools; each criterion is presented in

the form of a set of features. To quantify the assessment, each should be

rated in terms of its importance to the organization. A rating, or weight, of 1

to 3 should be used (1 = not important to the organization, 2 = required by

the organization, 3 = of high importance to the organization).

Trong phần đầu tiên - Đánh giá Repository Workbench - một cách

tiếp cận có tinh định hƣớng giúp ngƣời đọc hiểu các tinh năng của một sản

phẩm Repository Workbench va so sánh các tinh năng nay với các sản

phẩm cạnh tranh khác. 23 tiêu chuẩn khác nhau đƣợc chia thanh 3 loại: kho

lƣu trữ, sự kết hợp, va các công cụ; mỗi tiêu chuẩn đƣợc trình bay dƣới

hình thức một tập hợp các tinh năng. Để định lƣợng việc đánh giá, mỗi tinh

năng nên đƣợc đánh giá về tầm quan trọng cho tổ chức. Một thang điểm 1-3

nên đƣợc sử dụng (1 = không quan trọng cho tổ chức, 2 = cần thiết cho tổ

chức, 3 = có tầm quan trọng cao đối với tổ chức).





Each of the features describing the criteria should next be rated

according to how well the vendor fulfills the requirement. A scale of 1

through 5 should be used: (1 = fails, 2 = weak, 3 = adequate, 4 = good, 5 =

excellent).

Mỗi tinh năng mô tả tiêu chuẩn kế tiếp cần đƣợc xếp hạng theo khả

năng đáp ứng các yêu cầu. Một thang điểm từ 1 đến 5 nên đƣợc sử dụng: (1

= thất bại, 2 = yếu, 3 = đầy đủ, 4 = tốt, 5 = xuất sắc).

After you finish rating all 23 criteria, your scores can be transferred

to the charts at the end of this chapter. These charts allow you to add up

repository scores and to make overall evaluations and comparisons.

Sau khi hoan thanh tất cả 23 tiêu chi đánh giá, điểm số sẽ đƣợc đƣa

vao các bảng xếp hạng ở cuối chƣơng nay. Những biểu đồ cho phép chúng

ta cộng thêm điểm va để thực hiện việc đánh giá va so sánh tổng thể.

In the second section — Preparing for the Repository Workbench —

a series of checklists is provided to assist the reader in deciding whether or

not a repository workbench solution is desirable and in developing a plan

for repository workbench implementation.

Trong phần thứ hai - Chuẩn bị Repository Workbench - một loạt các

bảng kiểm mục đƣợc cung cấp để trợ giúp ngƣời đọc trong việc xác định

định liệu giải pháp về kho lƣu trữ đó có đáng lam va phát triển một kế

hoạch cho việc cai đặt.





In the third section — Repository Metrics — a series of

measurements is provided to assist the reader in determining how well the

repository is utilized.

Trong phần thứ ba - Repository Metrics - một loạt các phép đo đƣợc

cung cấp để trợ giúp ngƣời đọc trong việc xác định kho đƣợc sử dụng nhƣ

thế nao.

8.2.1 Đánh giá Repository Workbench

Selecting a repository workbench is not a simple process. Repository

workbench software is quite complex and the selection process mirrors this

complexity. Because a repository workbench offers a composite of

functionality, the evaluation team needs to review three discrete levels of

functionality: the repository component, the workbench component, and the

integrative component. What follows is a set of categories that will assist in

this process; each represents a different level of functionality that a product

of this type should have.

Lựa chọn một kho lƣu trữ không phải la một quá trình đơn giản.

Phần mềm kho lƣu trữ khá phức tạp va quá trình lựa chọn phản ánh sự phức

tạp nay. Bởi vì một kho lƣu trữ cung cấp một hỗn hợp của chức năng,

những ngƣời đánh giá cần xem xét ba cấp độ rời rạc của các chức năng:

thanh phần lƣu trữ, thanh phần công cụ, va các thanh phần kết hợp. Sau đó

tập hợp các hạng mục sẽ hỗ trợ cho quá trình nay; mỗi hạng mục đại diện





cho một cấp độ chức năng khác nhau ma một sản phẩm của loại hình nay

phải có.

The Repository workbench - Kho lƣu trữ

The repository is the heart of the repository workbench. It is much

more than a data dictionary or a data warehouse. It stores information about

objects — whether those objects are file definitions or process rules. The

sections below itemize the major attributes of a repository. An effective and

robust repository should meet the objects presented in this section:

Kho lƣu trữ la trung tâm của Repository workbench. Nó phức tạp

hơn la một từ điển hay một kho dữ liệu. Nó lƣu trữ thông tin về đối tƣợng -

cho dù những đối tƣợng nay la định nghĩa file hoặc các quy định trong quá

trình. Các phần dƣới đây liệt kê rõ từng thuộc tinh chinh của một kho lƣu

trữ. Một kho lƣu trữ hiệu quả va mạnh mẽ phải đáp ứng các đối tƣợng đƣợc

trình bay trong phần nay:

Initial Data Capture - Nhập dữ liệu ban đầu:

For the most part, objects required to be entered into the repository

already reside in catalogs, files, databases, and CASE encyclopedias, or as

part of a program (i.e., working storage as well as the procedure division).

Scanning enables an organization to populate the repository quickly

through the importation of objects from a pre-existing source. Among the

facilities that a robust repository product provides are:





Hầu hết các đối tƣợng cần đƣợc nhập vao kho lƣu trữ đã nằm trong

các catalog, file, cơ sở dữ liệu, va bách khoa toan thƣ CASE, hay nhƣ một

phần của một chƣơng trình. Chức năng ―Scan‖ cho phép một tổ chức xác

định kich thƣớc kho lƣu trữ một cách nhanh chóng thông qua việc nhập các

đối tƣợng từ những nguồn có trƣớc. Trong số các ich lợi ma một kho lƣu

trữ mạnh mẽ cung cấp có:

Tracking - Theo dõi:

A repository should have the ability to keep detailed information

about objects. The repository defines an object as more than the traditional

data definition; an object may be a field, file, procedure, or system. Because

the repository maintains detailed information about objects, the

organization has an excellent opportunity to track the status of many of the





formal processes that form the underpinnings of IT. A robust repository

should be able to:

Một kho lƣu trữ phải có khả năng lƣu giữ thông tin chi tiết về đối

tƣợng. Kho lƣu trữ định nghĩa ở mức đối tƣợng chứ không phải định nghĩa

dữ liệu truyền thống; một đối tƣợng có thể la một lĩnh vực, file, thủ tục,

hoặc hệ thống. Bởi vì kho lƣu trữ duy trì các thông tin chi tiết về đối tƣợng,

tổ chức có cơ hội tốt để theo dõi tình trạng của nhiều quá trình chinh thức

hình thanh nên nền tảng của công nghệ thông tin. Một kho lƣu trữ mạnh mẽ

có thể:

Source and Use - Nguồn va sử dụng:

All organizations are different in the policies, methods, and

procedures of their IT processes. The repository workbench must integrate

itself as well as act as an integrator of these policies, methods, and

procedures. The repository workbench must be flexible enough to:





Các tổ chức khác nhau về chinh sách, phƣơng pháp, va thủ tục quy

trình công nghệ thông tin. Kho lƣu trữ phải kết hợp các chinh sách, phƣơng

pháp, thủ tục va phải đủ linh hoạt để:

User Access - Sự truy cập của ngƣời dùng:

Studies on productivity have shown that the user interface has the

greatest impact on the usability of the system. For the function of data

administration, a flexible user interface is mandatory if the organization is

to leverage the resources of skilled professionals. The repository workbench

product should offer the following features:

Các nghiên cứu về năng suất đã cho thấy rằng giao diện ngƣời dùng

có tác động lớn nhất về tinh khả dụng của hệ thống. Đối với các chức năng

quản lý dữ liệu, một giao diện ngƣời dùng linh hoạt la bắt buộc, nếu tổ chức





nay muốn tận dụng nguồn lực các chuyên gia lanh nghề. Kho lƣu trữ phải

cung cấp các tinh năng sau đây:

Dialog - Sự tƣơng tác:

A robust repository dialog should provide a simple, intuitive means

for maintaining and querying information assets, as well as accessing tools.

Features should include:

Một kho lƣu trữ mạnh mẽ phải cung cấp một phƣơng tiện đơn giản,

trực quan để bảo trì va truy vấn thông tin cũng nhƣ các công cụ để truy cập.

Các tinh năng bao gồm:





Extensibility - Khả năng mở rộng:

A robust repository workbench is not rigid; it should support growth.

This growth should not be limited merely to data definitions. In an object-

based environment a repository workbench should have the flexibility to

add new sources of information as well as new tools, reports, and

procedures. Each of these is defined as an object. Extensibility features

should include:

Một kho lƣu trữ mạnh mẽ không đƣợc cứng nhắc, nó phải hỗ trợ việc

mở rộng. Sự mở rộng nay không nên giới hạn cho các định nghĩa dữ liệu.

Trong một môi trƣờng đối tƣợng một kho lƣu trữ phải có sự linh hoạt khi

thêm các nguồn thông tin mới cũng nhƣ các công cụ, báo cáo va thủ tục

mới. Tất cả đƣợc định nghĩa la đối tƣợng mới. Khả năng mở rộng bao gồm

các tinh năng:





Project Control - Kiểm soát dự án:

A repository workbench must provide facilities to automate the

enforcement of corporate and project standards and procedures, and to

control distribution of repository resources. Capabilities should include:

Một kho lƣu trữ phải cung cấp tiện ich để tự động áp dụng các tiêu

chuẩn va thủ tục, va để kiểm soát sự phân phối các nguồn tai nguyên. Các

tinh năng:





Versioning:

The repository workbench must provide a comprehen sive set of

facilities for supporting, monitoring, and auditing the evolution of

repository definitions. This feature makes it possible to plan and implement

the maintenance procedures that become necessary as systems mature and

require modifications. A robust repository workbench provides the

following capabilities:

Kho lƣu trữ phải cung cấp các tiện ich toan diện để hỗ trợ, giám sát,

kiểm toán va sự tiến triển của các định nghĩa. Tinh năng nay giúp ta có thể

lên kế hoạch va thực hiện các thủ tục bảo dƣơng trở nên cần thiết khi hệ

thống phát triển va cần chỉnh sửa. Một kho lƣu trữ mạnh mẽ cung cấp các

khả năng sau đây:

Life Cycle Phase Management - Quản lý các giai đoạn của vòng đời

(life cycle):





Supporting an organization‘s methodologies is an essential role of a

repository. A robust repository workbench provides an organization-

extensible means for defining the various stages of object evolution. These

stages are referred to as life cycle phases. Transition rules define the

movement of an object from one phase to another. Relationships between

entities based upon their respective life cycle phases should be verified to

ensure proper migration results. Managing life cycle phases and object

migration is a vital function within a repository if it is to control and

participate in an organization‘s development and maintenance

methodology. Features should include:

Hỗ trợ các phƣơng pháp của tổ chức la một vai trò thiết yếu của một

kho lƣu trữ. Một kho lƣu trữ mạnh cung cấp một phƣơng thức để xác định

các giai đoạn khác nhau của sự tiến triển của đối tƣợng. Những giai đoạn

nay đƣợc gọi la life cycle phase. Quy tắc chuyển tiếp xác định sự chuyển

động của một đối tƣợng từ một giai đoạn nay đến giai đoạn khác. Mối quan

hệ giữa các thực thể dựa trên những giai đoạn trong life cycle của chúng

cần đƣợc kiểm tra để đảm bảo kết quả thich hợp. Quản lý giai đoạn vòng

đời va sự di chuyển của đối tƣợng la một chức năng quan trọng trong kho

lƣu trữ một nếu nó kiểm soát va tham gia vao sự phát triển va bảo trì của tổ

chức. Tinh năng bao gồm:





Integration - Thanh phần tich hợp

Architecture - Kiến trúc:

A repository workbench is a unique hybrid of repository, tools, and

an integrative vehicle. In order to support this threefold functionality, the

underlying architecture of a repository workbench product must provide

openness and an extensible framework. The organization must be able to

easily integrate into and expand upon the framework. The architectural

features of a robust architectural framework include:

Một Repository Workbench la một sự kết hợp độc đáo của kho lƣu

trữ, các công cụ, va phƣơng tiện kết hợp. Để hỗ trợ chức năng gấp ba, các

kiến trúc tiềm ẩn của nó phải cung cấp sự cởi mở va một nền tảng có thể

mở rộng. Tổ chức phải dễ dang tich hợp va mở rộng dựa trên các nền tảng

này. Các tính năng kiến trúc của một nền tảng kiến trúc mạnh mẽ bao gồm:





Standards - Tiêu chuẩn:

The basis of any open framework is the standards that it rests on. For

this framework to be fully integrative with an organization‘s environment,

the framework must conform to and support the standards and guidelines

that the industry has embraced. Additionally, the repository workbench

must provide the organization with the ability to support the standards that

it has developed as part of its policies and procedures. This might includes

where applicable:

Cơ sở của nền tảng mở la những tiêu chuẩn ma nó phụ thuộc vao. Để

đƣợc tich hợp đầy đủ vao môi trƣờng của tổ chức, nền tảng phải phù hợp va

hỗ trợ các tiêu chuẩn va nguyên tắc ma đƣợc nganh công nghiệp chấp nhận.

Ngoai ra, Repository Workbench phải cung cấp cho tổ chức khả năng hỗ

trợ những tiêu chuẩn ma nó đã phát triển nhƣ một phần của chinh sách va

thủ tục của nó. Điều nay có thể bao gồm:





Gateways - Cổng giao tiếp:

The basis of a repository product is information; however,

information is not confined to a single source. A repository product must

provide the organization with a series of gateways that allow the

organization to export and import information among these information

sources (e.g., application development tools, various databases, and files).

Because the organization is expected to have multiple requirements for

gateways, the most robust repository workbenches will generically define a

gateway bridge that provides a commonalty of approach across diverse

products. Features should include:

Cơ sở của một sản phẩm lƣu trữ la thông tin, tuy nhiên, thông tin la

không hạn chế với một nguồn duy nhất. Một sản phẩm phải cung cấp cho tổ

chức một loạt các cổng cho phép lƣu thông thông tin giữa các nguồn thông

tin (vi dụ, các công cụ phát triển ứng dụng, cơ sở dữ liệu khác nhau, va các





tập tin). Vì tổ chức có thể có nhiều yêu cầu cho các cổng, các Repository

Workbench mạnh nhất sẽ xác định một giao thức chuẩn cho các sản phẩm

khác nhau. Tinh năng bao gồm:

CASE bridge:

CASE (application development) tools require a very specific

gateway that allows CASE objects to be integrated into the repository with

the goal of permitting CASE users to have a more efficient way of

controlling, securing, reporting, and distributing specifications captured in

their workstations. A robust repository can be thought of as a clearinghouse

between workstations and CASE products. The repository workbench





should provide management tools that enable the organization to share data

resources. This includes:

Các công cụ phát triển ứng dụng yêu cầu một cửa ngõ rất cụ thể cho

phép các đối tƣợng CASE đƣợc tich hợp vao kho với mục tiêu để ngƣời

dùng CASE có một cách hiệu quả hơn trong việc kiểm soát, bảo vệ, báo

cáo, va phân phối thông tin thu thập đƣợc. Một kho mạnh mẽ có thể đƣợc

dùng nhƣ một clearing-house giữa các máy trạm va các sản phẩm CASE.

Repository Workbench nên cung cấp công cụ quản lý cho phép các tổ chức

để chia sẻ tai nguyên dữ liệu. Điều nay bao gồm:

Services - Dịch vụ:

A product is only as good as the service provided by the product

vendor. Toward this end, the following features should be evaluated:

Một sản phẩm tốt khi có các dịch vụ đi kèm. Các tinh năng đƣợc

đánh giá:





Workbench Integration - Tich hợp các bộ công cụ:

The repository workbench creates a productive environment where

repository information is integrated with an extensible tool set. This

approach offers you the flexibility to incorporate your existing tools as well

as those you may consider in the future. Tool integration capabilities

include:

Repository Workbench tạo ra một môi trƣờng sản xuất nơi ma thông

tin đƣợc tich hợp với một bộ công cụ mở rộng. Cách tiếp cận nay cung cấp

cho bạn sự linh hoạt để kết hợp các công cụ hiện có của bạn cũng nhƣ

những công cụ trong tƣơng lai. Khả năng tich hợp công cụ bao gồm:





Tools - Các công cụ

Tool Integration - Tich hợp công cụ:

The ability to integrate tools to the workbench is only one side of the

coin. The other side is to have the facilities to develop in-house tools. A

tool development environment should possess the following capabilities:

Khả năng tich hợp các công cụ vao workbench chỉ la một mặt vấn

đề. Mặt khác la phải có tiện ich để phát triển các công cụ in-house. Một môi

trƣờng phát triển công cụ cần có các khả năng sau đây:

Groupware - Lam việc nhóm:





Productivity is greatly enhanced when a facility is provided for

project teams and users to communicate with each other. This is often

referred to as groupware. Within a repository environment, this can be

accomplished through the use of electronic mail. Features available should

include:

Năng suất đƣợc tăng cƣờng rất nhiều khi có các tiện ich giúp các

nhóm lam việc va ngƣời dùng giao tiếp với nhau. Trong một môi trƣờng

kho lƣu trữ, điều nay có thể đƣợc thực hiện thông qua việc sử dụng thƣ điện

tử. Tinh năng sẵn có bao gồm:

Reporting - Báo cáo:

Various levels of the organization require access to the repository for

reporting. On one level, the end users require access to find out the types of

information available within the organization. On another level, data

administration staff has a real need to control the transition of information

within the repository. Both levels of user access need to be supported.

Reporting features include:





Ngƣời dung ở nhiều mức độ khác nhau của tổ chức cần quyền truy

cập vao kho lƣu trữ các báo cáo. Ở một cấp độ, các ngƣời dùng cuối cần

truy cập để tìm thông tin trong tổ chức. Ở cấp độ khác, các nhân viên quản

lý dữ liệu có nhu cầu kiểm soát quá trình chuyển đổi thông tin trong kho.

Cả hai cấp độ của ngƣời sử dụng truy cập cần phải đƣợc hỗ trợ. Báo cáo các

tính năng bao gồm:

Impact Analysis - Phân tich tác động:

In nonrepository systems, a large percentage of nonproductive time

is spent in determining the impact of change. Analysts and programmers

must manually review documentation and program source listings to

evaluate the extent of change necessary as well as the length of time

required to make those changes. This can be a lengthy process. A





repository-based system automates this process through the function of

impact analysis. Automatic impact analysis deconstructs the repository to

determine the level of change required. The impact analysis function should

include the following capabilities:

Trong các hệ thống không có kho lƣu trữ, một tỷ lệ lớn thời gian vô

ich la danh cho việc xác định tác động của sự thay đổi. Các nha phân tich

va lập trình phải tự xem xét lại danh sách nguồn tai liệu va chƣơng trình để

đánh giá mức độ cần thiết của sự thay đổi cũng nhƣ thời gian cần thiết để

thực hiện những thay đổi đó. Điều nay có thể la một quá trình mất thời gian.

Một hệ thống có kho lƣu trữ tự động hóa quá trình nay thông qua chức năng

phân tich tác động. Phân tich tác động tự động phân tich kho để xác định

mức độ cần thiết của sự thay đổi. Các chức năng phân tich tác động nên bao

gồm các khả năng sau đây:

Scripting:

Database administrative procedures are extraordinarily complex. The

complexity of many of these tasks implies that the staff member involved

must have the highest degree of skill and exercise the utmost level of care.





Organizations that wish to leverage the skill set of the average user,

increase the speed at which a task may be completed, or deploy vast

functionality across differing layers of the organization require the means to

decrease the complexity level of the activity and thereby reduce the risk of

error. A repository-based scripting facility provides this functionality.

Capabilities should include:

Thủ tục cơ sở dữ liệu thƣờng phức tạp. Sự phức tạp của những công

việc nay ngụ ý rằng các nhân viên tham gia phải có kỹ năng rất cao va thực

hiện cẩn thận tối đa. Các tổ chức muốn tận dụng các kỹ năng của ngƣời

dùng bình thƣờng, tăng tốc độ một nhiệm vụ đƣợc hoan thanh, hoặc triển

khai các chức năng rộng lớn trên các lớp khác nhau của tổ chức cần có các

phƣơng tiện để giảm mức độ phức tạp của hoạt động nay va từ đó lam giảm

nguy cơ bị lỗi. Một tiện ich scripting dựa trên kho lƣu trữ cung cấp các

chức năng nay. Các khả năng bao gồm:





Forms - Biểu mẫu:

Forms provide the ability to establish external layout definitions that

present a modified view of the objects within the repository without altering

the object itself. Although the definitions of objects in the repository are not

altered, the user view can be modified to afford the greatest expediency in

utilization of the repository without needing to write code. Features should

include:

Các biểu mẫu cung cấp khả năng để thiết lập các biểu diễn bên ngoai

của đối tƣợng trong kho ma không thay đổi đối tƣợng. Mặc dù các định

nghĩa của các đối tƣợng trong kho không bị thay đổi, giao diện ngƣời dùng

có thể đƣợc sửa đổi để đủ khả năng sử dụng kho ma không cần viết code.

Tinh năng bao gồm:





Generation - Sự phát sinh:

The repository acts as the central clearinghouse for corporate

information resource management, so it must have the ability to act in

concert with definitions used by application development and end-user

tools. To enhance productivity, consistency, and security, the repository

workbench must have the ability to generate syntax. This includes the

ability to:

Kho lƣu trữ hoạt động nhƣ trung tâm đầu mối cho việc quản lý tai

nguyên thông tin, vì vậy nó phải có khả năng hanh động phối hợp với các

định nghĩa đƣợc sử dụng bởi việc phát triển ứng dụng va các công cụ ngƣời

dùng. Để nâng cao năng suất, nhất quán va bảo mật, Repository Workbench

phải có khả năng tạo ra cú pháp. Điều nay bao gồm khả năng:





Managing Relational Tables - Quản lý các bảng quan hệ:

A repository workbench needs to be more than just a repository.

Facilities to manage the underlying database should be fully integrated into

the tool set. These tools should provide the ability to:

Một Repository Workbench cần phải tốt hơn một cái kho. Tiện ich

quản lý cơ sở dữ liệu nằm bên dƣới nên đƣợc tich hợp hoan toan vao bộ

công cụ. Những công cụ nay nên cung cấp khả năng để:





8.2.2 Chuân bi Repository Workbench

Preparing for any software implementation requires careful planning

and control. In the case of a repository workbench, where information,

systems, and integration factors must be considered, even more care is

urged for a successful implementation. A series of checklists is provided for

this purpose.

Chuân bi cho viêc thi hanh cua bât cƣ phân mêm nao cung đoi

hỏi việc lên điều khiển va kế hoạch cẩn thận . Trong trƣơng hơp cua

Repository Workbench, thông tin, hê thông va nhƣng nhân tô kêt hơp phai

đƣơc xem xet , thâm chi sƣ cân thân la đông lƣc cho viêc thi han h thanh

công. Môt loat cac bang kiêm muc đƣơc cung câp cho muc đich nay.

8.2.2.1 Nhưng hanh đông cần lên kê hoach:

1. Standardize the names, definitions, and physical descriptions of

data elements used in all programs.





2. Document which data is kept in which files or databases or

schemas.

3. Document which reports and screens are produced by which

programs jobs and systems.

4. Document which programs, jobs, and systems access and update

which data elements in which files or databases or schemas.

5. Document which modules and subprograms are included in which

programs.

6. Document processing schedules, file back-up and retention, and

responsibilities for program and jobstream maintenance.

1. Chuân hoa tên , đinh nghia va nhƣng mô ta tƣ nhiên cua nhƣng

phân tƣ dƣ liệu đƣơc sƣ dung trong tât ca cac chƣơng trinh.

2. Lên tai liêu cho nhƣng dƣ liêu đƣơc giƣ trong những tâp tin , cơ sơ

dƣ liêu hay gian đô nao.

3. Lên tai liêu nhƣng ban bao cao va screen đƣơc sinh ra bơi nhƣng

hê thông hay nhƣng công viêc cua chƣơng trinh nao.

4. Lên tai liêu nhƣng hê thông , công viêc, chƣơng trinh nao truy xuât

va cập nhận những phần tử dữ liệu nao , trong những tâp tin hay cơ

sơ dƣ liêu nao.





5. Tai liệu những mô đun va những chƣơng trình con na đƣơc dùng

trong chƣơng trinh nao.

6. Tai liệu những mô đun xử lý, tâp tin sao lƣu va lƣu trƣ,va khả năng

đap ƣng cho viêc bao tri chƣơng trình va jobstream

8.2.2.2 Nhưng câu hoi đăt ra cho viêc đinh cơ nhưng nỗ lưc thu thâp tai

liêu:

1. How many systems are there?

2. What is the quality of system documentation?

3. If documentation is inadequate, can the required data be obtained

4. from the original developers or from users?

5. How many programs are in each system?

6. How good are the run books and program documentation?

7. Have these been kept up to date as changes have been made?

8. Are job control statements kept in a single file or library?

9. Are program source statements kept in a single file or library?

10. Is some type of source library maintenance system in use?





11. Is library content really kept up to date?

12. How many FILEs, DATABASEs, and SCHEMAs are in each

system?

13. How many different record types are there?

14. How many different relational tables are there?

15. Are standard record descriptions used?

16. Are they kept in a central library?

17. Are data element names standardized?

18. Are the names meaningful?

19. Are good definitions available?

20. Is there documentation of coding structures?

21. How well are reports, display screens, and input transactions

documented?

22. Can the data content be obtained from user manuals?

23. If the information above is not readily available, how will it be

obtained? Who will compile it?





24. Who will do the actual work of preparing repository input?

25. How will it be done?

26. Can part of the data be obtained by scanning source programs or

copy libraries?

27. Who will review edit lists and resolve naming discrepancies and

other problems?

1. Sô hê thông la bao nhiêu?

2. Chât lƣơng cua tai liêu hê thông la gi ?

3. Nêu tai liêu không thich hơp , có thể lấy dữ liệu đòi hỏi từ nha phải

triên gôc hay tƣ ngƣơi sƣ dung ?

4. Sô chƣơng trinh trong môi hê thông la bao nhiêu ?

5. Độ tốt của run books va tai liệu chƣơng trình nhƣ thế nao ?

6. Nhƣng cai nay đa đƣơc câp nhât khi co sƣ thay đôi xay ra chƣa ?

7. Nhƣng đê nghi điêu hiên công viêc co đƣơc giƣ trong nhƣng tâp

tin hay thƣ viên chƣa ?

8. Nhƣng đê nghi nguôn chƣơng trinh co đƣơc giƣ trong nhƣng tâp

tin đơn hay thƣ viên hay không ?





9. Môt sô kiêu cua thƣ viên nguôn co đƣơc hê thông bao dƣơng khi

sƣ dung không ?

10. Môt dung cua thƣ viên co thât sƣ đƣơc câp nhât ?

11. Bao nhiêu tâp tinh, cơ sơ dƣ liêu va gian đô trong môi hê thông ?

12. Có bao nhiêu kiểu hồ sơ khác nhau ?

13. Có bao nhiêu bảng quan hệ khác nhau ?

14. Mô ta hô sơ chuân co đƣơc sƣ dung không ?

15. Chúng có đƣợc giữ trong thƣ viện trung tâm không ?

16. Tên cua nhƣng phân tƣ dƣ liêu co đƣơc chuân hoa không ?

17. Tên co mang y nghia không ?

18. Nhƣng đinh nghia tôt co gia tri không ?

19. Đo co phai la tai liêu cua nhƣng câu truc coding không ?

20. Nhƣng bao cao, man hình hiển thi va sƣ giao dich vao co đƣơc lên

tai liệu ?

21. Nôi dung dƣ liêu co đƣơc lây tƣ hƣơng dân sƣ dung không ?





22. Nêu nhƣng thông tin trên không săn sang co hiêu lƣc , ta se lây no

nhƣ thê nao? Ai se dich no ?

23. Ai se lam nhƣng công viêc thât sƣ cua viêc chuân bi đâu vao kho

24. Nó sẽ đƣợc lam nhƣ thế nao ?

25. Môt phân cua dƣ liêu co thê đƣơc lây bơi viêc quet chƣơng trinh

nguôn hay nhƣng thƣ viên copy không ?

26. Ai se xem lai nhƣng danh sach liêt kê va giai quyêt lai nhƣng viêc

đăt tên sai va nhƣng vân đê khac ?

8.2.2.3 Nhưng câu hoi đăt ra liên quan đên vân đê ky thuât va thao tac:

1. Will the repository always be running? System initialization must

be amended to include this.

2. Will reports be produced automatically on some predetermined

schedule? Will they be triggered by specific events, such as the

implementation of a new system? Will they be on a run-on-request

basis? Who will initiate the jobs to produce the reports? How will

they be distributed? How will special requests be handled?

3. How will repository problems be reported and resolved?





4. Will computer operations think of the repository as a production

system?

5. Will procedures for the turnover of new systems or system changes

incorporate steps that will ensure that the repository has been

correctly updated?

1. Liêu kho lƣu trƣ se luôn hoat đông không ? Khơi tao hê thông phai

đƣơc sƣa đôi đê bao ham luôn vân đê nay

2. Liêu nhƣng bao cao se đƣơc sinh ra tƣ đông trên môt lich đa đƣơc

xác định sẵn từ trƣớc ? Liêu chung co đƣơc ki ch hoat bơi cac sƣ

kiên cu thê, chăng han nhƣ sƣ thi hanh cua môt hê thông mơi? Liêu

chúng sẽ chạy khi có yêu cầu ? Ai se khơi tao nhƣng công viêc đê

sinh ra nhƣng ban bao cao ? Họ sẽ phân nhƣ thế nao ? Nhƣng truy

vân đƣơc biêt se đƣơc xƣ ly nhƣ thê nao?

3. Nhƣng vân đê lƣu trƣ se đƣơc bao cao va giai quyêt nhƣ thê nao?

4. Nhƣng thao tac may tinh se xem xet kho lƣu trƣ nhƣ la môt hê

thông san xuât không?

5. Liêu nhƣng thu tuc cho doanh thu hê thông mơi hay nhƣng sƣ thay

đôi hê thông se kêt hơp chăt che nhƣng bƣơc ma chăc chăn kho lƣu

trƣ đa đƣơc câp nhât chinh xac không?





8.2.2.4 Nhưng câu hoi đăt ra về bảo mật

1. Who should be allowed to access what? Can project teams alter

data that they think of as their own?

2. Will passwords be controlled and changed from time to time? Will

they be changed when employees resign or are discharged?

3. Does repository software provide a mechanism to prevent access to

the repository via means other than the repository software?

1. Ai đƣợc phép truy cập cái gì? Liệu nhóm dự án có thể thay đổi

những dữ liệu ma họ cho la của mình không?

2. Mật khẩu có đƣợc kiểm soát va thay đổi liên tục theo thời gian

không? Liệu mật khẩu có thay đổi khi nhân viên từ chức hoặc bị sa

thải?

3. Liệu phần mềm kho lƣu trữ có cung cấp phƣơng thức để ngăn chặn

truy cập vao kho lƣu lữu bằng những cách ngoai cách sử dụng

phần mềm kho lƣu trữ?

8.2.2.5 Nhưng câu hoi đăt ra liên quan đến dữ liệu trùng lắp và không

thống nhất

1. Can you identify all occurrences of the same information?





2. Can you determine which elements are calculated or derived and

how?

3. Will you know the original sources of all elements?

4. Will you know the uses of the elements?

5. Can the repository implementation help to determine whether there

are procedures or programs to ensure consistency?

6. Will the repository implementation provide for validation rules and

criteria?

7. Does it provide for data consistency and integrity rules?

8. What about procedures to ensure that such rules are entered in the

repository?

1. Bạn có thể xác định đƣợc mọi sự tồn tại khác nhau của cùng một

thông tin?

2. Bạn có thể xác định những thanh phần nao thì có thể đƣợc tinh

toán hoặc suy ra? Va bằng cách nao?

3. Liệu bạn có biết đƣợc nguồn gốc của tất cả các thanh phần?





4. Liệu bạn có biết những mục đich sử dụng của tất cả các thanh

phần?

5. Liệu việc cai đặt kho lƣu trữ có giúp xác định những thủ tục hoặc

chƣơng trình đảm bảo tinh thống nhất?

6. Liêu sự cai đặt kho lƣu trƣ se cung câp cho nhƣng quy tăc xac nhân

hay nhƣng tiêu chi?

7. Liêu no co cung câp sƣ nhât quan dƣ liêu va cac quy tăc toan ven?

8. Cái gì của thủ tục đảm bảo những quy định nhƣ vậy đƣợc nhập vao

trong kho?

8.2.2.6 Nhưng câu hoi yêu câu vê đô phưc tap va phu thuôc lân nhau

1. Does the repository help us determine who actually uses the reports

or screens?

2. Does it help identify screens and reports that contain the same

information?

3. Does it help the user identify the tasks and procedures that require

use of the information contained in the reports and screens?

4. Will it help improve documentation?





5. Will it decrease complexity by providing reusability?

1. Kho lƣu trƣ co giup chung ta xac đinh ai thât sƣ dung nhƣng bao

cáo hay screens?

2. Liệu nó giúp nhận ra screen va các báo cáo có chứa các thông tin

nhƣ thế?

3. Liệu nó co giúp ngƣời dùng xác định các nhiệm vụ va các thủ tục

ma đòi hỏi sử dụng các thông tin có trong các báo cáo và screens?

4. Liêu no se giup cai thiên tai liêu không ?

5. Liêu no se giam phƣc tap vơi viêc cung câp kha năng tai sƣ dung?

8.2.3 Repository Metrics

These criteria measure how well a repository or data dictionary

collects, maintains, and retrieves information about data. The objectives of

these measures are to offer users cost-effective means of retrieving relevant

information and reducing information overload. Five criteria are proposed

to evaluate data dictionaries and repositories: relevance, consistency,

common use among information systems, degree of automation, and degree

of security.

Nhƣng tiêu chi nay đo đô tôt cua một kho lƣu trƣ hay tƣ điên dƣ liêu

trong viêc sƣu tâp , duy tri va lây thông tin vê dƣ liêu… Muc đich cua viêc





đo lƣơng nay la mang lai cho ngƣơi sƣ dung nhƣng phƣơng tiên hiêu qua

chi phi của việc lấy ra thông tin liên qua va giảm thông tin dƣ thừa . 5 tiêu

chi đƣợc soạn để đánh giá những từ điển dữ liệu va các kho lƣu trữ đó la: sƣ

xác đáng, tinh nhất quán, sƣ dung phô biên trong nhƣng hê thông thông tin ,

mƣc đô tƣ đông va mƣc đô bao mât.

DBA Objective Metrics: The following criteria measure how well

each commercial repository/repository product fulfills DBA objectives.

Nhƣng tiêu chuân sau đo nhƣng kho lƣu trƣ thƣơng mai thƣc hiên tôt

nhƣng muc tiêu cua DBA

8.2.3.1 Tính liên quan

This criterion measures the effectiveness of retrieving correct

information in response to a request. It is measured by two factors: recall

and precision.

Tiêu chuân nay đo tinh hiêu qua cua viêc lây thông tin chinh xác để

trả về khi có truy vấn. Nó đƣợc đo dựa trên 2 yêu tô: Độ thu hồi va độ chinh

xác





8.2.3.2 Viêc sư dung phô biên cac IS khac biêt

This criterion measures whether the product can be consistently

applied to standardize IS in different departments and operations within an

IS organization. Current trends toward integrating networks and

information systems to build integrated repository-network management

environments make it important that repositories handle multiple

environments. Deciding which repository to use as the central repository

may depend on its flexibility in handling a variety of software and

hardware. The common use criterion measures this flexibility:

Tiêu chuân nay đo sƣ kha năng mơ rông đê DBA co thê dê dang lƣu

trƣ va chuân hoa cac thao tac va linh vƣc khac biêt bên trong tô chƣc IS .

Các khuynh hƣớng hiện tại hƣớng về phia tich hợp những mạng va hiện

thông thông tin đê xây dƣng nhƣng môi trƣơng quan ly mang lƣu trƣ kêt

hơp. Quyêt đinh kho lƣu trƣ nao đê sƣ dung nhƣ kho lƣu t rƣ trung tâm co

thê phu thuôc vao kha năng linh hoat cua no trong viêc xƣ ly cac loai phân

cƣng va phân mêm. Tiêu chi sƣ dung phô biên đo kha năng linh hoat nay:

8.2.3.3 Độ tự động hóa

An active repository uses substantially less manpower than a passive

one. In response to an inquiry, an active repository can locate the elements





and find out who has access to them; it then directs the database

management system to obtain those data elements. On the other hand,

passive data dictionaries have no tie-ins to the operating system and require

the user to write programs to gain access to the elements. This criterion

measures the extent to which a product makes it easy for a DBA to

standardize and store elements.

Môt kho lƣu trƣ đang hoa t đông vê cơ ban sƣ dung it hơn 1 kho thu

đông. Đê đap ƣng môt yêu câu , kho đang hoat đông co thê đinh vi nhƣng

nhân tô va tim ra ai đa truy xuât tơi chung ; Sau đo no chi hê quan tri cơ sơ

dƣ liêu đê lây nhƣng phân tƣ dƣ liêu đo . Măt khac, Nhƣng tƣ điên dƣ liêu

thụ động không có tie-ins cho cac hoat đông hê thông va yêu câu ngƣơi

dùng để viết những chƣơng trình nhằm lấy việc truy cập đến những phần tử.

Tiêu chuân nay đo viêc mơ rông ma môt san phâm dê dang đƣơc DBA

chuân hoa va lƣu trƣ cac phân tƣ.

8.2.3.4 Độ bảo mật

Overall security depends on managing the access controls to various

data elements. Access control limits must be defined for each user and

violations acted upon.





Tỉnh bảo mật tổng thể dự vao việc quản lý những điều khiển truy cập

đễ những phần tử dữ liệu khác nhau . Nhƣng giơi han điêu khiên truy câp

phải đƣợc định nghĩa cho mỗi ngƣời sử dụng va việc xử lý vi phạm theo

8.2.3.5 Metrics kho lưu trư

Nhƣng metric sau đo nhƣng thuôc tinh phu thêm cua kho lƣu trƣ:

8.2.3.6 Tính nhất quán

One of the objectives of a repository solution is to act as the single

source for all information flows. To measure how successful the repository

implementation is requires knowledge concerning the number of objects

stored in the repository versus the number of objects stored, simultaneously,

in different sources.

Môt trong nhƣng muc đich cua giai phap kho lƣu trƣ la hoat đông

nhƣ môt nguôn đơn cua tât ca nhƣng dong thông tin . Đê đanh gia Viêc thƣc

hiên kho lƣu trƣ thanh công nhƣ thê nao la môt đoi hoi kiên thƣc liên quan

đến số lƣợng của những đối tƣợng đƣợc lƣu trữ trong kho với số lƣợng

nhƣng đôi tƣợng đƣợc lƣu trữ đồng thời trong những nguồn khác





8.2.3.7 Truy xuât trực quan

One of the most important, but underrated, features of a repository

workbench is its user interface. The more intuitive the dialog is, the more

the repository workbench will be used. Frequency of use translates into

higher productivity; a low rating implies need for tuning or training.

Môt trong nhƣng tinh năng quan trong nhât cua kho lƣu trƣ nhƣng

đƣơc đanh gia thâp đo la giao diên sƣ dung cua no . Hôp thoai trƣơc quan

cang nhiều thì kho lƣu trữ cang đƣợc sử dụng nhiều . Sƣ thƣơng hay cua

viêc sƣ dung chuyên sang năng suât cao hơn ; môt đanh gia thâp ngu y cân

thiêt cho sƣ chuyên đôi hay đao tao:

8.2.3.8 Mưc đô cua sư phân tich tác động

This metric measures how well the impact analysis function is

utilized.

Metric nay đo chƣc năng phân tich tac đông đƣơc sƣ dung tôt nhƣ

thê nao





8.2.3.9 Tính kết hợp

This metric determines the progress of the tool integration effort.

Because a repository workbench enables complete tool integration, the level

of integration implies progress — or lack of it.

Metric nay xac đinh qua trinh sƣ đi lên cua nô lƣc kêt hơp công cu .

Bơi vi kho lƣu trƣ cho phep hoan thiêt kêt hơp công cu , mƣc đông cua sƣ

kêt hâp ngâm đinh trong qua trinh- hoăc thiêu no

8.3 CHO ĐIỂM REPOSITORY WORKBENCH

The chart in Exhibit 8.1 provides a means to conduct a quantitative

evaluation of several repository products. To use this chart, simply transfer

the scores from each of the rating scales under the 23 criteria. To transfer

the score, multiply the rating (1 through 5) by the weighting (1 through 3).

Biêu đô ơ hinh 8.1 cung câp phƣơng tiên đê thƣc hiên môt đanh gia

đinh lƣơng của một vai sản phẩm kho lƣu trữ . Đê sƣ dung biêu đô nay , đơi





giản chuyển điểm từ những tỉ lệ đã đinh giá của 23 tiêu chuân. Đê chuyên

điêm, nhân ti lê (1 -> 5) vơi trọng số (1->3)


Martin, J. (1989). Information Engineering, Book I: Introduction,

Prentice Hall, Englewood Cliffs, NJ.





Martin, J. (1990). Information Engineering, Book II: Planning and

Analysis, Prentice Hall, Englewood Cliffs, NJ.




Chương 9: Structured Methodology Review 341

CHƢƠNG 9 STRUCTURED METHODOLOGY

REVIEW

Người dịch:





5. Nguyễn Bá Huy





A variety of methodologies is available to the systems analyst. Many

are proprietary methodologies utilized in conjunction with a software

application development tool set (CASE — computer assisted software

engineering).

The original and still frequently used systems development construct

dictates that systems are developed through a series of distinct stages. It is

necessary for each stage to be completed before going to the next. This is a

linear progression of system development, hence the name ―waterfall‖

method. Waterfall design methods are a one-way flow from the require-

ments process toward the working system (Coffee, 2001).Once a stage of

the project is complete, it is sent to the next stage with a ―deliverable‖,

which is evidence or documentation that the stage has been completed and

the project is ready for the next process. There are eight generally accepted

stages of a systems development life cycle tech-nique (see Exhibit 9-1):

Determination of scope and objectives — overall scope of the

project is agreed upon.

Systems investigation and feasibility study — a report on the

feasibility of a technical solution to the problem is prepared.

Systems analysis —a logical model of the existing system is built.





System design — the analyst develops two or three alternative

designs.

Detailed design — detailed physical specifications are made so that

the system can be built.

Implementation — the system is physically created.

Changeover — the old system is replaced by the new system.

Evaluation and maintenance —hardware and software are

maintained.

A real benefit of this approach is the division of a lengthy project

into stages, which makes it more manageable. This is realized throughout

the project in terms of better project control and communication, and during

the working life of the system in terms of its meeting user

requirements and

the ease with which it can be modified to take into account changes

in

these requirements (Curtis, 2000). However, many in the field feel

that the traditional waterfall method is outdated. The problem is that the

waterfall models a one-way flow from requirements. You must be able to





paddle upstream and take a different path if the one you first choose turns

out to be too long — to practice white-water kayaking, rather than just

going over the waterfall and hoping you will like where you land (Coffee,

2001). Today‘s business is fast paced and systems need to be developed as

quickly as possible to meet organizational needs, with early delivery of

the easy portions of an application for on-the-job testing and comments

(Coffee, 1994).Fast-changing requirements and shorter lead times might

require theuse of different methodologies.

Sự đa dạng của phƣơng pháp phát triển phần mềm có giá trị cho việc

phân tich hệ thống. Nhiều tiện dụng của phƣơng pháp luận liên kết với tập

phát triển phần mềm ứng dụng (CASE – computer assisted software

engineering).

Nguồn gốc va sự thƣờng xuyên sử dụng việc xây dựng phát triển

hệ thống buộc hệ thống phải đƣợc phát triển qua các bƣớc khác nhau. Nó

cần thiết cho mỗi bƣớc đƣợc hoan thanh trƣớc khi tiếp tục. Đây la đƣờng

thẳng tiến triển của sự phát triển hệ thống, có tên phƣơng pháp ―thác nƣớc‖

(waterfall). Phƣơng pháp thiết kế thác nƣớc la 1 cách xuất phát từ tiến trình

yêu cầu đến hoạt động hệ thống.

Khi giai đoạn hoan tất dự án, nó đƣợc gửi đến bƣớc tiếp theo với

khả năng phân phối, la bằng chứng hay có tai liệu chứng tỏ rằng giai đoạn

đó đƣợc hoan thanh va dự án sẵn sang cho bƣớc tiếp theo. Có 8 bƣớc thông

thƣờng đƣợc chấp nhận trong vòng kỹ thuật phát triển của hệ thống.





Xác định phạm vi va mục đich: phạm vi tổng quan của dự án đƣợc

duyệt ở trên.

Điều tra hệ thống va nghiên cứu tinh tiện lợi: báo cáo về tinh tiện

dụng của giải pháp kĩ thuật đến các vấn đề dc chuẩn bị trƣớc.

Phân tich hệ thống: mô hình luận lý của hệ thống đang tồn tại đƣợc

xây dựng.

Thiết kế hệ thống: nha phân tich phát triển 2 hay 3 thiết kế khác

nhau.

Chi tiết thiết kế: các chi tiết vật lý ghi rõ đƣợc lam để ma hệ thống

có thể đƣợc xây dựng.

Sự bổ sung: hệ thống đƣợc thiết lập vật lý.

Sự thay đổi: hệ thống cũ đƣợc thay thế bởi hệ thống mới.

Sự đánh giá va bảo trì: phần cứng va phần mềm đƣợc bảo trì.

Lợi ich thực từ việc tiếp cận nay la sự phân chia của dự án lớn thanh

nhiều giai đoạn, giúp tăng khả năng quản lý. Việc nay đƣợc nhận ra trong

việc tăng sự quản lý va liên lạc của dự án, suốt thời gian hoạt động của hệ

thống trong việc gặp yêu cầu của ngƣời dùng có thể bị thay đổi đƣa vao tài

khoản.





Tuy nhiên, nhiều lĩnh vực cảm thấy rằng phƣơng pháp thác nƣớc

truyền thống nay đã lạc hậu. Vấn đề la mô hình thác nƣớc lƣu thông 1 chiều

từ những yêu cầu. Bạn phải có thể đi ngƣợc dòng thác va lấy con đƣờng

khác nếu con đƣờng đầu tiên bạn chọn quá dai. Vấn đề kinh doanh ngay

nay đi từng bƣớc nhanh va hệ thống cần đƣợc phát triển nhanh nhất có thể

để bắt kịp với nhu cầu tổ chức, với sự phân phối sớm của phần dễ của ứng

dụng cho kiểm tra va bình luận.

Sự thay đổi yêu cầu nhanh chóng va thời gian chỉ đạo ngắn hơn có

lẽ yêu cầu phải sử dụng các phƣơng pháp luận khác nhau.

9.1 RAPID APPLICATIONS DEVELOPMENT (RAD):

It is no longer adequate to take two or three years to build a system.

Morethan ever, businesses are in a race against time (Glen, 1993). Directly

opposed to the traditional and lengthy life cycle approach is rapid

applications development, or RAD for short. RAD is a loosely used term

(like many`other design terms) that describes any approach to a fast-

designed system.

RAD has been described as a set of tactics and techniques to

minimize development time — a radical departure from the traditional

waterfall method (Glen, 1993). Essentially, RAD uses time boxing to

control develop-ment time for each phase of the project. If a deadline is in





danger of being missed, lower-priority requirements are moved back to a

later time box or the next phase of an incremental delivery (Tudhope,

2000). RAD requires management to accept consensus management and

joint application design (JAD). Specialists with advanced technology

(SWAT teams) work closely with the users to define and refine

applications.

SWAT (also referred to by Glen as ―slaves without any time‖) is an

effec-tive tactic in many RAD projects in that small, multidisciplined IT

teams work with users directly. This fosters team building. SWAT members

are not confined to separate floors or buildings. This approach is different

than assembling many systems specialists with inch-wide and mile-deep

knowl-edge in specific areas to build applications in IT ghettos (Glen,

1993).

RAD has four phases, as shown in Exhibit 9-2 (Curtis et al., 2000):

1. Requirements planning — joint requirements planning (JRP),

estab-lishes high-level objectives

2. Applications development — JAD follows JRP, involves users in

work-shops

3. Systems construction — design specifications, used to develop

detailed and generate code





4. Cutover — users trained and the system tested

According to Tudhope (2000), the majority of developers who are

aware of RAD tend to select elements of the methodology rather than

following it strictly. Others use generally similar techniques without

identifying them as RAD.

Proponents of the RAD design methodology say that business needs

can change substantially during long development times, and meeting

current needs when the system comes into operation is a better aim than

meeting a ―long-frozen‖ specification (Tadhope, 2000). However, others

say you should never let developers write a line of code until the

specifications are approved by all parties. Prudent managers might therefore

follow the ―waterfall‖ model, in which requirements are completed and

flow down-stream to design (Coffee, 1994).

A variation of the RAD technique dictates that design technique is to

be deliberate in the systems foundation, but one should design some parts

ahead of time. The foundation is the data model, which should be designed

in partnership with the business side of the organization. A logical data or

object design process allows definition of how business is currently

conducted and plans for future changes. RAD is used for screens, reports,

business rules, and communications, but only after the database or object

model is in place. Involving users in the process that takes the longest

makes development time less of an issue; end users see the prototype in





days or hours once the foundation is laid (Boyer, 1995). Boyer

recommends that we build the walls of the application and roof as quickly

as possible, but to make sure the foundation is in place first.

Sẽ la không đủ nếu mất 2 hoặc 3 năm để xây dựng một hệ thống.

Hơn bao giờ hết, kinh doanh la một cuộc đua chống lại thời gian (Glen,

1993). Đối lập trực tiếp với cách tiếp cận truyền thống va dai hạn ―vòng

sống‖ (life cycle) la phát triển nhanh ứng dụng (RAD), đây la một thuật ngữ

sử dụng cho cho bất kì cách tiếp cận nao đến một hệ thống thiết kế nhanh.

RAD đƣợc mô tả nhƣ la một hệ thống các chiến thuật va kĩ thuật để giảm

thiểu tối đa thời gian phát triển sản phẩm – la một khác biệt cơ bản so với

mô hình thác nƣớc (Glen, 1993). Về cơ bản, RAD sử dụng hộp thời gian để

điều khiển thời gian phát triển triển cho mỗi giai đoạn của dự án. Nếu hạn

chót của một giai đoạn nao đó sắp sửa đến thì những yêu cầu với độ ƣu tiên

thấp hơn sẽ đƣợc dời đến hộp sau – thời điểm sau hoặc giai đoạn tiếp theo

của quá trình phân phối (Tudhope, 2000). RAD yêu cầu những ngƣời quản

lý phải tán thanh với việc đồng lòng trong quản lý va kế hoạch lam việc

cùng nhau (join application design – JAD). Đặc biệt với những công nghệ

mới, lam việc gần với ngƣời dùng (users) để xác định rõ va cải tiến ứng

dụng.

SWAT (slaves without any time) la một chiến thuật hiệu quả trong

nhiều dự án sử dụng cách tiếp cận RAD ma trong đó những nhóm IT nhỏ

lam việc trực tiếp với ngƣời dùng. Điều nay khuyến khich việc xây dựng

nhóm. Những thanh viên SWAT không lam việc cố định trong mỗi tòa nha





hay mỗi tầng riêng biệt. Cách tiếp cận nay khác với tập hợp nhiều chuyên

gia hệ thống với nhừng kiến thức rộng va sâu trong một lĩnh vực nao đó để

xây dựng những ứng dụng trong công nghệ thông tin.

RAD có 4 giai đoạn (hình 9-2):

1. Lập kế hoạch cho những yêu cầu: tham gia lập kế hoạch cho những

yêu cầu (JRP – joint requirements planning), thiết lập những đối

tƣợng cấp cao.

2. Phát triển ứng dụng: quá trình lam việc cùng nhau, liên quan đến

ngƣời dùng trong những cuộc hội thảo.

3. Xây dựng hệ thống: xác định thiết kế, đƣợc sử dụng để phát triển

mã chi tiết va tổng quát.

4. Huấn luyện ngƣời dùng va kiểm thử hệ thống.

Theo Tudhope (2000), phần lớn những ngƣời có kiến thức về RAD

có xu hƣớng lựa chọn những nhân tố của phƣơng pháp hơn la tuân thủ theo

nó một cách nghiêm ngặt. Số khác sử dụng những kĩ thuật chung tƣơng tự

ma không ý thức rằng chúng la RAD.





Những ngƣời đề xuất tập các phƣơng pháp thiết kế RAD chỉ ra

rằng những yêu cầu thƣơng mại có thể thay đổi về căn bản trong thời đại

phát triển lâu dai, va xây dựng một hệ thống linh động thì tốt hơn la lập kế

hoạch‘cứng‘ để xây dựng hệ thống với những yêu cầu xác định sẵn. Tuy

nhiên, số khác lại cho rằng không nên để cho những ngƣời phát triển phần

mềm viết một dòng code nao cho đến khi đạt đƣợc sự nhất tri toan đội khi

xác định yêu cầu. Những ngƣời quản lý có kế hoạch do đó cũng có thể theo

mô hình thác nƣớc, trong đó những yêu cầu đƣợc hoan thanh trƣớc va sau

đó cứ tiếp tục theo luồng (thác nƣớc) để thiết kế các giai đoạn tiếp theo.





Một mức độ biến đổi của kĩ thuật RAD nói rằng thiết kế kĩ thuật

phải đƣợc tiến hanh thận trọng trong những hệ thống nền tảng, nhƣng nên

thiết kế một vai phần trƣớc. Nền tảng la mô hình dữ liệu, cái ma nên đƣợc

thiết kế với sự cộng tác của các bộ phận khác trong tổ chức. Một dữ liệu

logic hoặc đối tƣợng của quá trình thiết kế cho phép định nghĩa cách ma

những nhiệm vụ hiện tại đƣợc thiết kế va lập kế hoạch cho những thay đổi

trong tƣơng lai. RDA đƣợc sử dụng cho hiển thị, báo cáo, những nguyên tắc

kinh doanh va giao tiếp, nhƣng chỉ sau khi cơ sở dữ liệu hay mô hình đối

tƣợng sẵn sang. Những quá trình liên quan đến ngƣời dùng phải đƣợc tập

trung nhiều thời gian nhất để giảm thiểu những vấn đề phát sinh về sau;

ngƣời dùng cuối phải xem xét nguyên mẫu một cách kĩ lƣơng một khi

những nền tảng đƣợc đặt vao (Boyer, 1995). Boyer khuyến cáo rằng chúng

ta nên đặt những nền móng vững chắc trƣớc, rồi xây dựng những bức tƣờng

va mái nhanh nhất có thể.

JOINT APPLICATION DESIGN (JAD)

In joint application design, analysts work with groups during the

devel-opment of the system; they integrate groups of technical and business

experts (Exhibit 9-3). These groups may include programmers, designers,

and project managers, as well as user reps, department management people,

and the controller or CIO. These JAD sessions are usually run by a trained

facilitator.





The JAD process has four stages: framework presentation, project

scop-ing, preliminary definitions development, and detailed requirements

devel-opment (Dodson, 1994).

In the framework presentation stage the facilitator sets the tone for

the project, explaining the JAD approach. Usually this stage involves a core

team of business experts and will last between one half to a full day. Project

scoping involves the same group of people identifying project priorities

across department lines. This should take a total of 6 to 12 hours. The pre-

liminary definitions stage produces the context diagram; the entire core

team participates in this phase. The context diagram shows the system‘s

place in the flow of the organization‘s information, which should take about

one day. The detailed requirements stage should take five to ten days in

session; however, the detailed requirements can take weeks to develop.

Attending all of these sessions is the ―scribe‖ responsible for

document-ing all the information gathered during each meeting and

providing it to theteam as needed. This relieves other participants from

taking notes, which diverts their attention from the matters at hand.

Trong thiết kế ứng dụng chung, ngƣời phân tich lam việc với

nhóm trong suốt quá trình xây dựng của hệ thống. Họ kết hợp những nhóm

của kỹ thuật va kinh doanh. Những nhóm nay có thể bao gồm: lập trình

viên, ngƣời thiết kế, quản lý dự án cũng nhƣ ngƣời dùng thử sản phẩm, ban





quản lý nhân sự, va ngƣời kiểm soát hoăc CIO. Phần JAD nay thƣờng đƣợc

tiến hanh bởi một ngƣời tổ chức.

Quá trình JAD có 4 giai đoạn: đƣa ra khung, xem xét dự án, xác

định sơ bộ quá trình tiến hanh, va chi tiết yêu cầu phát triển

Trong giai đoạn khung đƣa ra, ngƣời tổ chức đặt một tiếng cho dự

án, giải thich JAD cần đạt, Thƣờng thì đây la giai đoạn dinh liu tới một

nhóm nồng cốt thông thạo kinh doanh,va sẽ mất giữa nữa ngay hay cả ngay.

Xem xét dự án sẽ liên quan đến một nhóm ngƣời xác định ƣu tiên của dự án

trong cùng những lĩnh vực. Điều nay mất tổng cộng khoảng từ 6 tới 12

giờ.Giai đoạn xác định sơ bộ tạo ra một biểu đồ khung cảnh, toan bộ nhóm

nòng cốt đều tham gia giai đoạn nay. Cái biểu đồ khung cảnh cho thấy vị tri

của hệ thống tuân theo sự tổ chức của thông tin,việc nay mất khoảng 1

ngày.Giai đoạn chi tiết yêu cầu mất khoảng 5 tới mƣời ngay trong phần

này.Tuy nhiên giai đoạn chi tiết yêu cầu có thể mất nhiều tuần để có thể

hoàn thành.

Sự có mặt của tất cả các phần nhƣ la một bản sao chép cho một văn

bản ma tất cả thông tin đều hội tụ lại trong mỗi cuộc họp va cung cấp nó tới

một nhóm đang cần.Điều nay lam an tâm những ngƣời khác tham gia từ

những ghi chú,điều nay chuyển hƣớng sự chú ý từ những vấn đề cần chú ý.





9.2 CASE TOOL

The broadest definition of a CASE tool is any software tool that

provides automated assistance for software development, maintenance, or

project management activities (McMurtrey et al., 2000). CASE tools are not

end-user oriented; they are used by professionals for carrying out part of the

design and helping to speed the development process. They have been

trumpeted as the ―silver bullet‖ of applications development but have not

necessarily lived up to that name because they are not a ―fix-all‖ solution to

systems design. However, they are a feasible option for practitioners of

systems development.

Case tools assist in (Curtis et al., 2000):

Corporate planning of info systems — used to track relationships

between various components.

Creating specification requirements — information system is

analyzed into its data requirements.

Creating design specifications —tools are used to specify a design

for the system.

Code-generation tools — accept output of the design specification

and produce code for direct execution.





Information repository — stores information on entities,

processes,data structures, business rules, source code, and project

management.

Development methodology — provides automated diagramming

facilities for data-flow diagrams.

The many benefits of CASE include increased productivity,

restructuring of poorly written code, decrease of application development

time, and aid in project management. However, with benefits there are

usually drawbacks, and CASE is no exception. Some of the drawbacks are a

reliance on structured methodologies, a lengthy learning curve, possible

user resistance, limited functions, and a required working knowledge of the

underly ing methodology.

Định nghĩa rộng nhất của CASE TOOL: Case Tool la bất ký một

công cụ phần mềm nao hỗ trợ sự giúp đơ tự động cho việc phát triển phầm

mềm, sự duy trì ổn định, hay bất kỳ họat động quản lý phần mềm nao

(McMurtrey et al.2000). Case tool không phải công cụ phần mềm hỗ trợ

ngƣời dùng cuối (end-user oriented) ma nó đƣợc sử dụng bởi những ngƣời

chuyên nghiệp để tiến hanh những phần của thiết kế va giúp tăng tốc độ quá

trình phát triển.

Nó đƣợc gọi la ―viên đạn bạc‖ (silver bullet) của sự phát triển ứng

dụng nhƣng thật sự ta không cần thiết đặt ra cách gọi nay bời vì nó không





đƣa ra cách giải quyết cho tất cả vấn đề trong thiết kế hệ thống. Tuy nhiên,

nó la lựa chọn feasible cho những ngƣời bắt đầu lam công việc phát triển hệ

thống.

CASE tool hỗ trợ trong việc:

Corporate planning of info systems – đƣợc sử dụng để tìm ra mối

quan hệ giữa các thanh phần khác nhau.

Tạo ra những yêu cầu cụ thể - hệ thống thông tin đƣợc phân tich

thanh những yêu cầu dữ liệu.

Tạo ra những thiết kế cụ thể (design specificaiton) – công cụ đƣợc

sử dụng để thiết kế giao diện cho hệ thống

Code –generation tool – chấp nhận output của thiết kế cụ thể va tạo

ra code cho việc thực thi trực tiếp.

Kho lƣu trữ thông tin – lƣu trữ thông tin dạng thực thể, tiến trình,

cấu trúc dữ liệu, luật kinh doanh (business rule), mã nguồn, va

quản lý dự án.

Phƣơng thức phát triển – cung cấp thiết bị đồ họa tự động cho data-

flow diagram.





Những tiện ich của CASE tool nhƣ tăng chất lƣợng sản phẩm, cấu

trúc lại những đọan mã tồi, giảm thời gian phát triển dự án, va giúp đơ

trong việc quản lý dự án. Tuy nhiên, với những tiện ich nhƣ vậy vẫn tồn tại

những sự bất lợi. Một số sự bất lợi nhƣ la quá dựa vao phƣơng thức đƣợc

cấu trúc, chức năng bị hạn chế, yêu cầu kiến thức về phƣơng thức.

9.3 VARIETY OF STRUCTURED METHODOLOGIES

As mentioned, a wide variety of systems development methodologies

can be chosen from, some accompanied by CASE tools and some without

them. Most are based on the methodologies discussed previously. A list of

eferences to some of the most common structured methodologies follows:

1. Yourdon, E.E. and Constantine L.L. (1977). Structured Design:

Funda-mentals of a Discipline of Computer Program and System

Design, Your-don Press

2. DeMarco, T. (1979). Structured Analysis and Systems

Specification, Prentice Hall, Englewood Cliffs, NJ.

3. Gane, G. and Sarson, T. (1979). Structured Systems Analysis,


4. Jackson, M. (1975). Principles of Program Design, Academic

Press, New York.





5. Jackson, M. (1983). System Development, Prentice Hall,

Englewood Cliffs, NJ.

6. Martin, J. (1988). Information Engineering: Book 1 Introduction,

Book2 Planning and Analysis, Book 3 Design and Construction,


James Martin worked with Clive Finkelstein in designing

information engineering. Interestingly, two models were actually derived

from this exercise. Martin‘s model is IT-driven while Finkelstein‘s model is

enter-prise, or business, driven. I find Finkelstein‘s the more useful of the

two and have included a brief summary here.

Nhƣ đã đƣợc nhắc đến, nhiều phƣơng thức phát triển hệ thống có thể

đƣợc lựa chọn từ những Case Tool đi kèm hoặc không. Hấu hết đều dựa

trên những phƣơng thức đã đƣợc ban đến ở trên.Sau đây la những phƣơng

thức thông dụng nhất:

Yourdon, E.E. and Constantine L.L. (1977). Structured Design:

Funda-mentals of a iscipline of Computer Program and System

Design, Yourdon Press

DeMarco, T. (1979). Structured Analysis and Systems

Specification, Prentice Hall, Englewood Cliffs, NJ.





Gane, G. and Sarson, T. (1979). Structured Systems Analysis,


Jackson, M. (1975). Principles of Program Design, Academic

Press, New York.

Jackson, M. (1983). System Development, Prentice Hall,


Martin, J. (1988). Information Engineering: Book 1 Introduction,

Book 2 Planning and Analysis, Book 3 Design and Construction,


James Martin đã lam việc với Clive Finkelstein về công nghệ thiết kế

thông tin (designing information engineering). Cả hai mô hình đều đƣợc bắt

nguồn từ bai tập nay.Mô hình của Martin la IT-driven trong khi mô hình

của Finkelstein la enterprise, hoặc la bussiness, driven. Tôi thấy la mô hình

của Finkelstein hữu ich hơn nên đã tóm lƣợc vai dòng về nó sau đây.

9.4 FINKELSTEIN INFORMATION ENGINEERING

Clive Finkelstein‘s (1989) version of information engineering starts

with a business strategic planning exercise to identify important

information systems required by the business. Then it develops chosen





priority systems through successively detailed analysis and design, through

to imple-mentation.

Strategic planning consists of the following stages:

Stage 1. Identifying the current plan. Use any existing strategic or tac-

tical statements that may exist or a management questionnaire to gather

information about business strategy

Stage 2. Evaluation of current status consists of eight steps:

1. Analyze mission and purpose to identify major data subjects that

are represented in a high level mission model

2. Identify potential goals (critical success factors)

3. Define goals

4. Identify issues

5. Define strategies to deal with each issue

6. Identify current functions (e.g., personnel, finance, etc.)

7. Allocate strategies to functions

8. Define functional responsibility (a detailed functional specification

for each functional manager)





Stage 3: Setting strategic direction consists of three steps:(1, 2) internal,

and external appraisal: analysis of business, and business envi-ronment

(3) strategic evaluation: create the strategic agenda; devise proactive

strategic options and select; define strategic statement: formal

documentation of strategic decisions, rational, assumptions,

conclusions and alternatives.

Once we complete the strategic plan we can proceed to the

development of more detailed data models and process models. These are

built up in three successive levels:

Strategic modeling: a high-level schematic data model, of interest to

senior managers. Steps involve:

1. Identifying data subjects

2. Identifying data entities from mission

3. Identifying preliminary functions

4. Identifying data entities from strategies

5. Identifying potential functions

6. Identifying strategic attributes

7. Defining purpose descriptions





Tactical modeling: the strategic model is refined into areas of more

detail to describe data of more interest to middle managers. Typically

approximately 20 of these tactical areas exist for any one strategic

model.

Operational modeling: any one tactical area may have typically three

operational systems that need to be developed. Operational modeling

develops the data and process models for a particular operational area

to a level of detail to enable implementation.

The final phase of the Finkelstein methodology is implementation.

Implementation is technology dependent and is carried out using

suitable DBMS, CASE, and other development tools. The major

techniques used are:

Business data modeling: a ―business oriented‖ version of data

modeling

Process modeling: modeling of processes acting on ―data‖,

especially generic, reusable processes such as: Verify, Add,

Read, Display, Change, Delete.

Dynamic performance monitoring: the use of a generic

approach to performance monitoring (a common requirement

for most systems).





Phiên bản năm 1989 của Clive Finkelstein về kỹ thuật thông tin bắt

đầu với một kế hoạch cho việc xác định các thông tin quan trọng trong hệ

thống theo yêu cầu của doanh nghiệp. Sau đó nó phát triển các hệ thống

đƣợc lựa chọn ƣu tiên thông qua phân tích và thiết kế

Việc lập kế hoạch bao gồm các giai đoạn sau đây:

Giai đoạn 1: Xác định các kế hoạch hiện hanh. Sử dụng bất kỳ chiến

lƣợc hiện hanh hoặc chiến thuật phát biểu rằng có thể tồn tại hoặc một

bảng câu hỏi quản lý để thu thập thông tin về chiến lƣợc kinh doanh.

Giai đoạn 2. Đánh giá về tình trạng hiện tại bao gồm tám bƣớc sau:

1. Phân tich nhiệm vụ va mục đich để xác định các dữ liệu lớn

đối tƣợng đƣợc đại diện trong một mô hình nhiệm vụ cao cấp

2. Xác định mục tiêu tiềm năng (các yếu tố thanh công quan

trọng)

3. Xác định mục tiêu

4. Xác địn hcác vấn đề





5. Xác định các chiến lƣợc để đối phó với từng vấn đề

Xác định các chức năng hiện hanh (vi dụ, nhân sự, tài chính,

vv)

6. Phân bổchiến lƣợc chứcnăng

7. Xác định chức năng trách nhiệm (một chi tiết đặc tả chức năng

cho từng chức năng quản lý)

Giai đoạn 3. Thiết lập hƣớng chiến lƣợc bao gồm ba bƣớc sau: (1, 2)

đánh giá trong va ngoai: phân tich khả năng kinh doanh va môi trƣờng

kinh doanh (3) chiến lƣợc đánh giá: tạo ra các chƣơng trình nghị sự

chiến lƣợc, chủ động lựa chọn chiến lƣợc, xác định các chiến lƣợc:

chinh thức tai liệu hƣớng dẫn của các quyết định chiến lƣợc, giả định

hợp lý, kết luận va tìm lựa chọn thay thế.

Sau khi hoan thanh kế hoạch ta có thể tiến hanh phát triển dữ liệu

về chi tiết các mô hình va các mô hình quy trình. Đây la những xây dựng

trong ba cấp độ kế tiếp.Chiến lƣợc lam mẫu: một cấp cao schematic dữ liệu

mô hình, quan tâm đến cao cấp quản lý. Các bƣớc liên quan đến:

1. Xác định đối tƣợng dữ liệu

2. Xác định các thực thể dữ liệu từ các nhiệm vụ

3. Xác định sơ bộ chức năng





4. Xác định các thực thể dữ liệu từ các chiến lƣợc

5. Xác định các chức năng tiềm năng

6. Xác định những thuộc tinh chiến lƣợc

7. Xác định các mô tả mục đich

Chiến thuật mô hình hóa: mô hình chiến lƣợc đƣợc tinh chế thanh

các khu vực của chi tiết hơn để mô tả dữ liệu quan tâm nhiều hơn nhằm

quản lý cấp trung. Điển hình la khoảng 20 chiến thuật của các khu vực nay

tồn tại cho bất kỳ một chiến lƣợc mô hình.

Mô hình hoạt động: bất kỳ một trong những khu vực có thể có chiến

thuật thƣờng la ba hệ thống hoạt động cần đƣợc phát triển. Mô hình hoạt

động phát triển các mô hình dữ liệu va quy trình cho một hoạt động cụ thể

khu vực với một mức chi tiết để cho phép thực hiện.

Giai đoạn cuối cùng của phƣơng pháp Finkelstein đƣợc thực hiện

công nghệ phụ thuộc va đƣợc thực hiện bằng cách sử dụng phù hợp DBMS,

Case, va các công cụ phát triển khác. Các kỹ thuật chinh đƣợc sử dụng la:

Kinh doanh mô hình hóa dữ liệu: một doanh nghiệp "theo định

hƣớng‖ phiên bản của dữ liệu mẫu





Quy trình lập mô hình: mô hình hóa các quá trình diễn xuất trên

dữ liệu, đặc biệt la các quá trình sử dụng lại nhƣ: xác minh, thêm,

đọc, hiển thị, thay đổi, xóa.

Năng động, hiệu quả giám sát: việc sử dụng một phƣơng pháp tiếp

cận chung để thực hiện theo dõi (một yêu cầu chung cho hầu hết hệ

thống).

9.5 EXTREME PROGRAMMING

Extreme programming (XP) is a new programming methodology that

is getting fairly heavy notice these days. Kent Beck (1999) is one of its

main proponents and seems to have coined the term, so it seems reasonable

to treat his book as the defining standard of the field. XP is the application

a group of practices to software development projects:

The planning game: collaboration of business and programming

professionals to estimate the time for short tasks (called ―stories‖ in

XP)

Small releases: a ship cycle measured in weeks rather than years

Metaphor: ―a single overarching metaphor‖ to guide development

substitutes for a formal architectural specification





Simple design: no provision in the code for future changes or

flexibility

Testing: every piece of code exercised by unit tests when written,

and the full suite of tests when integrated

Refactoring: any piece of code subject to rewriting to make it

simpler

Pair programming: all production code jointly written by two

developers

Collective ownership: the right of any developer to change any

piece code on the project

Continuous integration: code integrated to the main line every few

hours

40-hour week: no overtime

On-site customer: a business person dedicated to the project

Coding standards: one standard per project

XP amounts to abandoning the traditional ―waterfall model‖ of

development entirely in favor of what has often been called ―cowboy

coding‖. Beck argues that it is no longer vastly more expensive to fix





problems in production than in planning; as a result, it is not necessary to

plan. Instead, let your programmers program, trust them to solve problems

as they come up, and plan and ship frequently so that you get feedback

from the customer on a regular basis.

Extreme Programming (XP) la một phƣơng pháp lập trình mới

đang rất đƣợc quan tâm. Kent Beck (1999) la ngƣời ủng hộ va dƣờng nhƣ

đã đặt ra thuật ngữ về lĩnh vực nay, điều nay cũng hơp lý khi coi cuốn sách

của ông nhƣ la tiêu chuẩn để đánh giá trong lĩnh vực nay. XP la áp dụng

một nhóm các thực hanh cho các dự án phát triển phần mềm:

Các kế hoạch trò chơi: sự hợp tác của doanh nghiệp va lập trình

chuyên nghiệp để ƣớc tinh thời gian cho công việc ngắn (gọi la

"câu chuyện‖ trong XP)

Phát hanh các phiên bản nhỏ

Metaphor: "một đơn bao quát ẩn dụ‖ để hƣớng dẫn thay thế phát

triển cho một đặc điểm kỹ thuật kiến trúc chinh thức.

Thiết kế đơn giản: không có điều khoản trong mã cho những thay

đổi trong tƣơng lai hay sự linh hoạt

Thử nghiệm: mỗi đoạn mã thực hiện bởi các xét nghiệm, va các bộ

đầy đủ các xét nghiệm khi tich hợp.





Refactoring: bất kỳ đoạn mã nao cũng thể viết lại để lam cho nó

đơn giản

Lập trình đôi: tất cả mã sản xuất chung đƣợc viết bởi hai nha phát

triển

Tập thể quyền sở hữu: quyền của các nha phát triển bất kỳ thay đổi

nao mảnh mã trên dự án

Liên tục hội nhập: mã tich hợp vao dòng chinh của mỗi vai giờ

40-hour tuần: không có thêm giờ

Trên trang web của khách hang: một ngƣời chịu trách nhiệm quản

lý cho dự án

Mã tiêu chuẩn: một tiêu chuẩn cho mỗi dự án




Chương 10:Khái niệm lập trình Extreme 371

CHƢƠNG 10 KHÁI NIỆM LẬP TRÌNH

EXTREME

Người dịch:

1. Phạm Ngọc Vân Anh

2. Trần Ngọc Hiệu

3. Trần Duy Khang

4. Huỳnh Lâm Linh

5. Nguyễn Thị An Nhơn





Extreme programming is a software methodology developed by Kent

Beck to help software developers to design and build a system more

efficiently and successfully. Extreme programming is a disciplined and

well-planned approach to software development. What makes this

programming so popular is that it is one of the first lightweight

methodologies. A lightweight methodology has only a few rules and

practices or ones that are easy to follow. Extreme programming does not

require any additional paperwork and programmers do not need to go

through tons of methods. It stresses customer satisfaction and can be used

when the customer is not certain of his requirements or when new

technology is to be introduced.

Lập trình Extreme la một hệ phƣơng pháp phầm mếm đƣợc phát

triển bởi Kent Beck nhằm giúp đơ những nha phát triển phần mềm thiết kế

va xây dựng một hệ thống có năng suất cao va thanh công hơn. Lập trình

Extreme la cách tiếp cận có kỷ luật va có kế hoạch của việc phát triển phan

mềm. Điều lam cho kiểu lập trình nay trở nên nổi tiếng la nó có một trong

những phƣơng pháp luận gọn nhẹ đầu tiên. Một phƣơng pháp luận gọn nhẹ

chỉ có một vai luật lệ để thực hiện hay vai điều dễ hiễu. Lập trình Extreme

không yêu cầu bất cứ việc thêm vao paperwork vao ngƣời viết chƣơng trình

không cần thiết phải sử dụng nhiều phƣơng pháp khác nhau. Nó nhấn mạnh

việc lam thỏa mãn khách hang va có thể đƣợc sử dung khi khách hàng

không chắc chắn những yêu cầu của mình hoặc khi kỹ thuật mới đƣợc giới

thiệu





10.1 NHỮNG LUẬT LỆ CỦA LẬP TRÌNH EXTREME

Extreme programming applies four rules in developing the software

project:

Communication. The programmer must communicate with the

customer and elicit his requirements, thus the emphasis on

customer satisfaction. The programmer also needs to communicate

with fellow workers, thus the emphasis on team work.

Simplicity. The design is maintained as simply as possible.

Feedback. The software is tested from its early stages, feedback is

obtained, and changes are made. This is a cyclical process.

Courage. The programmer can make changes even at the last

stages and implement new technologies as and when they are

introduced.

Lập trình Extreme áp dụng 4 điều lệ trong việc pháp triển đề án phần

mềm:

Sự liên lạc: ngƣời viết chƣơng trình phải liên lạc với khách hang va

thu thập những yêu cầu của khách, nó nhấn mạnh việc lam thỏa

mãn khách hàng.





Tinh đơn giản: bản thiết kế phải cang đơn giản cang tốt.

Thông tin phản hồi: phần mềm phải đƣợc kiểm tra từ nhƣng bƣớc

ban đầu, tiếp nhận thông tin phản hồi va thực hiện thay đổi. Đây la

một vòng sử lý tuần hoan.

Tinh dũng cảm: ngƣời viết chƣơng trình có thể phải thay đổi ở giai

đoạn cuối va thực thi kỹ thuật mới nhƣ khi chúng đƣợc giới thiệu.

Extreme programming is a process of project development, as shown

in Exhibit 10-1. Customer requirements are obtained in the form of user

stories; the programmer selects the user stories to be implemented first with

help from the customers. A plan is released that indicates how many user

stories can be implemented in a single iteration, thus starting iterative

development. The user stories are broken down into programming tasks and

assigned to programmers. The time required to complete these tasks is

estimated first; these initial estimates are referred to as uncertain estimates.

By using feedback, the programmer can adjust the estimates and make them

more certain.

Extreme lập trình la một quá trình phát triển dự án, nhƣ thể hiện

trong hình 10-1. Yêu cầu khách hang sau khi thu đƣợc ở dạng câu chuyện

ngƣời dùng; lập trình viên sẽ chọn những câu chuyện ngƣời dùng để triển

khai thực hiện với giúp đơ từ các khách hang. Đƣa ra kế hoạch chỉ ra những

câu chuyện nao của khách hang đƣợc đƣa vao cai đặt trong 1 đơn vị riêng





rẻ, do đó bắt đầu phát triển các thanh phần riêng rẻ. Những câu chuyện của

ngƣời dùng đƣợc chia nhỏ thanh các công việc lập trình va phân công cho

các lập trình viên. Thời gian cần thiết để hoan thanh các nhiệm vụ nay đƣợc

ƣớc tinh đầu tiên; các ƣớc lƣợng ban đầu đƣợc gọi la các ƣớc tinh không

chắc chắn. Bằng cách sử dụng thông tin phản hồi, các lập trình viên có thể

điều chỉnh các ƣớc tinh nay va lam cho chúng cang chinh xác hơn.





Hình 10 – 1

Once these programming tasks have been implemented, they are sent

for acceptance testing. If these tasks produce an error or indicate a bug, they

are sent back to be recoded in the next iteration. Once the programming

tasks are approved by the customer, a small release of the tasks is made to

check functionality.

Một khi các công việc lập trình đã đƣợc cai đặt, chúng đƣợc gửi đi

để thử nghiệm(acceptance testing). Nếu những công việc xuất hiện sai số

hay thiếu sót kỹ thuật, chúng sẽ đƣợc đƣa trở lại để sửa chửa va vòng lặp

kiểm tra – sửa chửa đƣợc lặp lại. Một khi việc lập trình đƣợc sự chấp thuận

của khách hang, một thông cáo nhỏ của công việc la thực hiện kiểm tra

chức năng hoan tất.

The components of extreme programming include:

User stories. User stories are written by the customer and describe

the requirements of a system. The customer need not specify his

requirements using any particular format or technical language; he

merely writes these in his own words. Aside from describing what

the system must be, the user stories are used to calculate the time

estimates for release planning. At the time of the implementation of

the user stories the developer obtains detailed information from the

customer. The time estimate is usually in the form of ideal





development time — defined as how long it would take to

implement the story in code if there were no distractions, no other

assignments, and the programmer knew exactly what to do.

Typically, each story will get one to three weeks. The user stories

are also used to produce test scenarios for acceptance testing by the

customer as well as to verify that the user stories have been

implemented correctly.

Release planning. Release planning produces the release plan

followed during development of the system; it is also called the

―planning game‖. During release planning a meeting is set up with

the customers and the development team. During this meeting a set

of rules is set up by the customers and developers to which all

agree. A schedule is then prepared. A development team is selected

to calculate each user story in terms of ideal programming weeks,

which is how long it would take to implement that story if

absolutely nothing else needed to be done.

Các thanh phần của lập trình Extreme bao gồm:

Câu chuyện ngƣời dùng(User stories): Câu chuyện ngƣời dùng

đƣợc khách hang viết va mô tả các yêu cầu của một hệ thống. Các

khách hang không cần phải xác định các yêu cầu của mình bằng

cách sử dụng bất kỳ hình thức cụ thể hoặc ngôn ngữ kỹ thuật; họ

chỉ cần miêu tả theo khả năng ngôn ngữ riêng của mình. Ngoai mô





tả những gì hệ thống cần phải có, những câu chuyện ngƣời

dùng(User stories) đƣợc sử dụng để tinh toán ƣớc lƣợng thời gian

cho việc lập kế hoạch phát hanh. Vao thời điểm việc cai đặt các

câu chuyện ngƣời dùng(User stories), ngƣời phát triển phần mềm

lấy thông tin chi tiết từ khách hang. Ƣớc tinh thời gian nay thƣờng

ở dạng thời gian lý tƣởng – nghĩa la thời gian nay đƣợc tinh trong

trƣờng hợp không có trở ngại nao, không có sự thay đổi yêu cầu

của khách hang va ngƣời lập trình biết chinh xác những điều mình

cần lam. Thông thƣờng, đối với mỗi câu chuyện(User stories) sẽ

mất 1-3 tuần. Những câu chuyện ngƣời sử dụng(User stories) cũng

đƣợc sử dụng để sản xuất các bản tét để kiểm tra sự chấp nhận của

khách hang cũng nhƣ để xác minh rằng những câu chuyện ngƣời

(User stories) đƣợc triển khai chinh xác

Lập kế hoạch phát hanh: tiến hanh lập kế hoạch cho ra các bƣớc

tiếp theo trong quá trình phát triển của hệ thống, nó cũng đƣợc gọi

la "kế hoạch trò chơi‖ Trong quá trình lập kế hoạch tiến hanh một

cuộc họp đƣợc tham gia bởi các khách hang va đội ngũ phát triển.

Trong cuộc họp nay một số các quy tắc đƣợc tất cả đồng ý. Sau đó

chuẩn bị một lịch trình. Một nhóm phát triển đƣợc chọn để tinh

toán mỗi câu chuyện ngƣời sử dụng(User stories) đƣợc cai đặt

trong thời gian lý tƣởng la bao lâu.

Release planning is guided by four values:





Scope — how much needs to be done?

Resources — how many people are available?

Time — when will the project or release be done?

Quality — how good and how well tested will the software be?

Việc lập kế hoạch dựa trên 4 tiêu chi sau:

Phạm vi – Có bao nhiêu việc phải lam?

Tài nguyên – Có bao nhiêu có thể lam?

Thời gian – Khi nao dự án đƣợc thực hiện va thực hiện trong bao

lâu?

Chất lƣợng – Nhƣ thế nao la đạt chất lƣợng tôt va lam thế nao để

có chất lƣợng tốt?

Candidate systems for XP are those that are reusable, testable, and

have good business values.

Các hệ thống dùng cho XP la những hệ thống có tinh tái sử dụng, dễ

kiểm tra va có giá trị kinh doanh tốt.





10.1.1 Vòng lặp

At the beginning of every iteration, an iteration planning meeting is

held at which the user stories to be implemented during that iteration are

chosen; the customer selects the user stories. The selected stories are broken

down into discrete programming tasks during the planning session. The

programming tasks are specified in the programmer‘s language.

Vao đầu mỗi vòng lặp (iteration), một cuộc họp lập kế hoạch đƣợc

tổ chức để ban bạc những câu chuyện ngƣời dùng nao sẽ đƣợc thực hiện

trong vòng lặp nay, khách hang sẽ chọn User Stories. User Stories đƣợc

chọn sẽ đƣợc chia thanh các công việc lập trình riêng biệt trong bản kế

hoạch. Nhƣng yêu cầu nay đƣợc xác định bằng ngôn ngữ của ngƣời lập

trình.

The number of selected user stories or programming tasks increases

or decreases the project velocity. Each programming task is estimated based

on ideal programming days, which are the number of days it would take to

program a task if no distractions or interruptions occurred.

Số lƣợng User Stories đƣợc lựa chọn cai đặt lam tăng hoặc giảm tốc

độ dự án. Mỗi công việc lập trình đƣợc ƣớc tinh dựa vao thời gian lập trình

lý tƣởng – đó la thời gian thực hiện lập trình nếu không có phiền nhiễu hay

gián đoạn xảy ra.





After these programming tasks have been developed, they are tested.

If bugs are found, the offending programming tasks are added back into the

release plan to be handled by the next iteration.

Sau khi các yêu cầu đã đƣợc lập trình chúng sẽ đƣợc kiểm tra. Nếu

tìm thấy lỗi, những yêu cầu nay sẽ đƣợc đƣa ra ban bạc xử lý lỗi ở vòng lặp

(iteration) tiếp theo.

During each iteration (see Exhibit 10-2), the plan is checked to detect

duplicate programming tasks. If such tasks are found, they are removed or

consolidated. If a single iteration has too much to do, several user stories

are dropped; if the iteration has too little to do, a few are added.

Trong mỗi vòng lặp (iteration) (xem hình 10-2), kế hoạch đƣợc kiểm

tra để phát hiện các công việc lập trình bị trùng lặp. Nếu công việc nhƣ vậy

đƣợc tìm thấy, chúng sẽ bị loại bỏ hoặc hợp nhất. Nếu một vòng lặp duy

nhất có quá nhiều việc phải lam, các câu chuyện một số ngƣời sử dụng đang

bị bỏ; nếu lặp có quá it để lam, một số it đƣợc thêm.

10.1.2 Phát triển

During the development phase, stand-up meetings are held every

morning to discuss the problems faced during the development effort, to

devise a solution to these problems, and, perhaps most importantly, to

promote focus. No individual programmer owns his or her code. Instead,

the code is collectively owned and collaboratively worked upon. The focus





of development is on small, manageable releases that can be thoroughly

tested.

Trong giai đoạn phát triển, các cuộc họp đƣợc tổ chức vao mỗi ngay

để thảo luận về các vấn đề phải đối mặt trong khi phát triển, để đƣa ra các

giải pháp cho những vấn đề nay, va quan trọng nhất, để thúc đẩy tập trung ý

tƣởng. Không có việc mỗi lập trình viên sở hữu code của họ. Thay vao đó

la sử dụng chung tập hợp code va lam lam việc cùng với nhau. Việc cai đặt

it đƣợc chú trọng, nhƣng sau đó bản release sẽ đƣợc test toan bộ.

Hình 10-2





10.1.3 Thẻ CRC

CRC stands for class, responsibilities, and collaboration. CRC cards

(Exhibit 10-3) contain information about the class, responsibilities and

collaboration for designing the system as a team. CRC cards allow all the

members of the project team to contribute to the project which will provide

a number of good ideas which can then be incorporated in the design.

CRC la viết tắt của Class(lớp), Responsibilities (trách nhiệm),

Collaboration (hợp tác). Thẻ CRC (Hình 10-3) chứa thông tin về các lớp,

trách nhiệm va sự hợp tác để thiết kế hệ thống nhƣ la 1 đội. Thẻ CRC cho

phép tất cả các thanh viên của nhóm dự án có thể đóng góp ý tƣởng tốt cho

thiết kế của dự án.





Hình 10-3

Each CRC card is used to represent an object. The class name of the

object can be written at the top of the CRC card; the responsibilities of the

class are written on the left side of the card and the collaborating classes are

written to the right of each responsibility. A CRC session consists of a

person simulating the system by speaking about the relationships between

the objects and the process. In this way, weaknesses and problems can be

easily discerned and the various design alternatives can be explored quickly

by simulating the proposed design.

Mỗi thẻ CRC đƣợc sử dụng để đại diện cho một đối tƣợng(object).

Tên lớp của đối tƣợng có thể đƣợc viết ở trên cùng của thẻ CRC; trách

nhiệm của lớp đƣợc viết ở phia bên trái của thẻ va các lớp cộng tác

(collaborating classes) đƣợc ghi vao bên phải của mỗi trách nhiệm. Một

CRC bao gồm giả lập hệ thống bằng cách nói về mối quan hệ giữa các đối

tƣợng (object) va quá trình (process). Bằng cách nay, những vấn đề yếu

kém có thể dễ dang đƣợc nhận thức va các thiết kế thay thế có thể đƣợc tìm

thấy một cách nhanh chóng bằng cách giả lập thiết kế đề xuất.

10.1.4 Hệ thống ẩn

Classes, objects, and methods coded by the programmer can be

reused. Instead of writing the code for a class, object, or method that

already exists, it is important to name the objects in a standardized manner





that enables other programmers to seek and reuse these objects. Thus, a

common system or common system description is used by all programmers.

Các lớp, đối tƣợng, va các phƣơng pháp đƣợc lập trình viên cai đặt

có thể đƣợc tái sử dụng. Thay cho việc code lại một lớp, đối tƣợng, hoặc

phƣơng pháp ma đã tồn tại, tên các đối tƣợng phải đƣơc tiêu chuẩn hóa để

lập trình viên viên khác tìm kiếm va sử dụng lại những các đối tƣợng. Vì

thế, một hệ thống chung hay các mô tả hệ thống chung đƣợc sử dụng bởi tất

cả các lập trình viên.

10.1.5 Mã sỡ hữu chung

Collective code ownership is a contribution of the programmers to

the project in the form of ideas to any segment of the project. Any

programmer can add or change code, fix bugs, or refactor — i.e., reuse the

code. The entire team is responsible for the system‘s architecture. Although

it is hard to believe that a whole team can have authority over the entire

project, it is actually possible. Each developer creates unit tests for his or

her code as the code is developed. Code is released into a source code

repository after being thoroughly tested.

Mã sở hữu chung la một sự đóng góp của các lập trình viên cho dự

án theo hình thức các ý tƣởng vao bất kỳ phân đoạn của dự án. Bất kỳ lập

trình viên có thể thêm hoặc thay đổi code, sửa chữa lỗi, hoặc tái sử dụng.

Rất khó để toan bộ đội ngũ có toan quyền trên toan bộ project, thực ra đó la





điều có thể. Mỗi nha phát triển tạo ra các bộ test cho các đơn vị mã của

mình khi cai đặt code. Code đƣợc thảy vao kho lƣu trữ source code sau khi

đƣợc test hoan toan.

10.1.6 Bộ Test

Unit tests are written by the programmer before he starts coding.

Writing the unit tests first gives the programmer a better understanding of

the requirements specified by the customer. In addition, writing unit tests

prior to coding helps programmers write the code more easily and faster.

Bộ Test đƣợc viết bởi các lập trình viên trƣớc khi anh ta bắt đầu viết

code. Việc viết các bộ test trƣớc khi tiến hanh cai đặt code lam cho lập trình

viên hiểu rõ hơn vầ yêu cầu của khách hang. Ngoai ra, viết bộ Test trƣớc

khi cai đặt code giúp lập trình viên viết code dễ dang hơn va nhanh hơn.

10.1.7 Test chấp thuận

Within the XP methodology, ―functional‖ tests have been renamed

―acceptance‖ tests to indicate that the system is accepted by the customer.

The customer specifies the test scenarios during specification of the user

stories; each story will have one or more acceptance tests. The acceptance

tests are the expectation of the customer for the system. These acceptance

tests are black box system tests, which enable the programmer to derive sets

of input conditions that will fully exercise all functional requirements for a





program. The user reviews the results of the acceptance tests and

determines the priorities of the test failures. The team schedules time to fix

the failed test for every iteration.

Trong phƣơng pháp XP, ―functional ―tests đã đƣợc đổi tên thanh

―acceptance ―test để chỉ ra rằng hệ thống đƣợc chấp nhận bởi khách hang.

Khách hang chỉ định các bản thử nghiệm trong quá trình xác định User

stories; mỗi User stories có thể đƣợc một hoặc nhiều bài ―acceptance ―test.

Các bản ―acceptance ―test la những kỳ vọng của khách hang cho hệ thống.

Những ―acceptance ―test đƣợc thử nghiệm hộp đen(black box system test),

cho phép lập trình viên rút ra các trƣờng hợp đầu vao, những trƣờng hợp

nay sẽ kiểm tra đầy đủ tất cả các yêu cầu chức năng của chƣơng trình.

Ngƣời sử dụng đánh giá các kết quả của sự ―acceptance ―test va xác định

những lỗi nao la quan trọng. Nhóm phát triển lên lịch sửa chữa lỗi cho tất

tất cả các vòng lặp (iteration)

10.1.8 Tốc độ dự án:

The project velocity is used to measure how much work is being

completed on the project; it is obtained by adding up the estimates of user

stories completed during the iteration. Project velocity can also be obtained

by adding up the estimates for tasks during the iteration. If the project

velocity shows significant variations, a release planning meeting is

conducted and a new plan is released. Project velocity is a measure of





accuracy. How accurately are we able to produce results on time? How well

are we able to make estimates?

Tốc độ dự án đƣợc sử dụng xác định bao nhiêu công việc của dự án

đã đƣợc hoan thanh, nó đƣợc tinh bằng cách cộng thêm vao ƣớc tinh hoan

thanh các User stories trong suốt vòng lặp. Tốc đọ dự án cũng có thể thu

đƣợc bằng cách cộng thêm vao các dự toán cho các công việc trong suốt

vòng lặp. Nếu tốc độ dự án cho thấy sự biến thiên đáng kể, cần tở chức

cuộc họp lập kế hoạch va đƣa ra một kế hoạch mới. Tốc độ dự án la thƣớc

đo chinh xác. Chúng ta có thể đƣa ra kết quả đúng hạn chinh xác đến mức

nao? Lam thế nao chúng ta có thể ƣớc lƣợng?

10.1.9 Phiên bản nhỏ

The development team releases small iterative versions of the system

to the customer. It is essential to get customer feedback on time instead of

waiting until the last moment, which results in making changes at the last

minute as well.

Các nhóm phát triển cung cấp phiên bản của 1 vòng lặp(iteration)

của cả hệ thống cho khách hang. Việc lấy thông tin phản hồi của khách

hang đúng lúc thay vì chờ cho đến thời điểm cuối la cần rất cần thiết, vì

cuối cùng việc thay đổi cũng phải đƣợc tiến hanh nhƣng thay đổi vao thời

điểm cuối la không hay.





10.1.10 Bản thiết kế đơn giản

The design is kept as simple as possible. A complex design is hard to

understand when changes are to be made in the future.

Bản thiết kế phải cang đơn giản cang tôt. Một bản thiết kế cang phức

tạp sẽ tạo ra sự khó khăn cho các thay đổi trong tƣơng lai.

10.1.11 Tiêu chuẩn viết code

Programmers follow a specific set of standard rules in writing code.

This helps in communication among teams and enables a programmer to

understand the code written by any other programmer easily.

Lập trình viên theo một tập hợp các tiêu chuẩn viết mã cụ thể. Điều

nay giúp trong giao tiếp giữa các đội lập trình viên va cho phép một lập

trình viên có hiểu những mã đƣợc viết bởi bất kỳ lập trình viên khác một

cách dễ dang.

10.1.12 Refactoring

Refactoring is the art of removing any duplicate code — i.e., the

reuse of code that is already present. This helps in keeping the system

design simple. Refactoring also saves a lot of time and increases the quality

of the system.





Refactoring la cách loại bỏ các mã trùng lặp, tái sử dụng mã đã có.

Điều nay giúp trong việc duy trì các hệ thống thiết kế đơn giản. Refactoring

cũng giúp tiết kiệm rất nhiều thời gian va lam tăng chất lƣợng của hệ thống.

10.1.13 Lập trình cặp đôi

Pair programming specifies that a pair of programmers work

collaboratively on a task. This helps assess the code as it is written. Pair

programming increases software quality and takes the same time to deliver

the system as a single programmer working on a single machine.

Pair programming xác định rằng một cặp lập trình viên lam việc

cộng tác vao việc nao đó. Điều nay giúp đánh giá các mã khi nó đƣợc viết.

Pair programming phần mềm lam tăng chất lƣợng va tốn cùng 1 thời gian

cung cấp hệ thống nhƣ khi một lập trình viên duy nhất lam việc trên một

máy tinh duy nhất.

10.1.14 Continuos Intergration

Coding is done by dividing big projects into small, manageable

programming tasks. After coding, the discrete programming tasks are

joined together; however, each of these tasks is tested individually for bugs.

During integration of the programming tasks, it is quite possible that new

bugs will arise. Therefore, after every integration, the integrated code is

retested for bugs.





Việc viết code đƣợc thực hiện bằng cách chia dự án thanh các công

việc lập trình đƣợc quản lý. Sau khi viết code, các công việc riêng rẽ sẽ

đƣợc kết hợp với nhau, tuy nhiên, mỗi công việc nhỏ nay phải đƣợc Test

riêng rẽ để kiểm tra các lỗi. Trong quá trình kết hợp của các công việc, có

thể sẽ phát sinh lỗi mới. Vì vậy, sau khi hội nhập hang, mã tich hợp phải

đƣợc kiểm tra lỗi một lần nữa.

Changes may be made on the request of the customer. All the

changes made to the code are integrated at least daily. The tests are then run

before and after the changes. The code is not released if any bugs are found.

Thay đổi có thể đƣợc thực hiện theo yêu cầu của khách hang. Tất cả

những thay đổi cần đƣợc tich hợp vao code mỗi ngay. Các bộ test cần đƣợc

chạy trƣớc va sau khi thay đổi. Bản code nay không đƣợc phát hanh nếu tìm

thấy lỗi.

10.1.15 40 giờ mỗi tuần

Each programmer works for only 40 hours per week. This helps the

productivity of the project in the long term. No programmer is overloaded

with work and no overtime is allowed. Overtime usually exhausts the

programmer and chances are he or she will make mistakes.

Mỗi lập trình viên lam việc cho chỉ 40 giờ mỗi tuần. Điều nay có ich

cho năng suất của các dự án trong dai hạn. Lập trình viên không nên lam





việc quá thời gian va thêm giờ khi không cần thiết. Tăng ca thƣờng lam cho

các lập trình viên mệt mỏi dẫn va đến gây ra lỗi.

10.1.16 On-site customer

A single customer or a group of customers is available at all times

for the programmers. This helps in resolving the ambiguities that

developers encounter during development of the project, in setting

priorities, and in providing live scenarios.

Một khách hang đơn lẻ hoặc một nhóm khách hang cần sẵn sang cho

các buổi gặp mặt với lập trình viên. Điều nay giúp trong việc giải quyết

thắc mắc các nha phát triển gặp phải trong quá trình phát triển của dự án,

trong việc thiết lập các ƣu tiên, va trong việc cung cấp các bản thử nghiệm

10.2 KẾT LUẬN

Extreme programming can be stated as a fast and highly organized

process for development of a software system. XP emphasizes

communication, which is essential in order to encourage new ideas.

Because pair programming is stressed in this method, the fear of losing any

programmer in the middle of the project is substantially decreased.

Theoretically, XP reduces competition among programmers by insisting

that they all work as a single team.





Lập trình Extreme có thể đƣợc coi nhƣ la một quá trình nhanh va có

tổ chức để phát triển một hệ thống phần mềm. Lập trình EXTREME nhấn

mạnh việc giao tiếp, đó la điều cần thiết để khuyến khich những ý tƣởng

mới. Vì lập trình cặp đƣợc nhấn mạnh trong phƣơng pháp nay, sự lo sợ về

việc mất đi bất kỳ lập trình viên ở giữa của dự án sẽ đƣợc giảm đáng kể. Về

lý thuyết, Lập trình EXTREME lam giảm cạnh tranh giữa các lập trình

bằng cách nhấn mạnh rằng tất cả họ lam việc nhƣ một đội bóng duy nhất.

Extreme programming can be used where the requirements change

rapidly and the customer is not sure of those requirements. Feedback is

integral to this process; thus, the end product will be developed according

to customer requirements.

Extreme lập trình có thể đƣợc sử dụng, nơi các yêu cầu thay đổi

nhanh chóng va các khách hang không chắc chắn về những yêu cầu của họ.

Thông tin phản hồi la một phần của quá trình nay, vì thế, các sản phẩm cuối

cùng sẽ đƣợc phát triển theo yêu cầu của khách hang


Beck, K. (1999). Extreme Programming Explained, Addison-

Wesley, Reading, MA.

http://www.extremeprogramming.org. Extreme programming: a

gentle introduction.




Chương 11: Kỷ thuật phát triển trước khi tiến hành công việc 394

CHƢƠNG 11 KỶ THUẬT PHÁT TRIỂN TRƢỚC

KHI TIẾN HÀNH CÔNG VIỆC

Người dịch:



8. Nguyễn Tấn


10. Lê Hoang Vũ





11.1 SAI SÓT TRONG HỆ THỐNG LÀ GÌ

Today's traditional system engineering and software development

envi-ronments support their users in ―fixing wrong things‖ rather than in

―doing them the right way in the first place‖. Things happen too late, if at

all. Sys-tems are of diminished quality and an unthinkable amount of

dollars is wasted. This becomes apparent when analyzing the major

problems of sys-tem engineering and software Development.

Những môi trƣớng phát triển phần mềm va máy hệ thống truyền

thống ngay nay đều chống đở với ngƣời dùng của họ trong việc ―sửa chửa

nhửng sai lầm‖ hơn ―lam nó chạy đúng trong lần đầu tiên‖. Những thứ nay

xảy ra quá trể. Những hệ thống giảm bớt phẩm chất va tổng số tiền phải

lãng phi la một con số không thể nao tƣởng tƣợng nổi. Điều nay rất rõ rang

khi chúng ta phân tich những vấn đề chinh phấn mềm va sự phát triển phần

mềm

In defining requirements, developers rely on many different types of

mis-matched methods to capture aspects of even a single definition. In fact,

the universal modeling language (UML) resurrects and supports this very

practice. Among other things, data flow is defined using one method, state

transitions another, dynamics another, data types another, and structures

using still another method. Once these aspects of requirements are defined,

there is no way to integrate them. Designers are forced to think and design

this way because of limitations of technologies available to them.





Trong những yêu cầu hạn chế về từ ngữ, những ngƣời phát triển

trông cậy vao nhiều loại khác nhau cách thức ghép đôi không tƣơng thich

để bắt diện mạo của định nghĩa riêng rẻ. Thực ra, mô hình UML phục hồi

va chống đở thực tiễn nay. Một thứ khác, luồng dữ liệu đƣợc định nghĩa sử

dụng một phƣơng thức, chuyển đổ trạng thái khác, động lực khácm loại dữ

liệu khác, va sử dụng những cấu trúc vẫn phƣơng thức khác nhau. Khi bề

ngoai của yêu cầu đƣợc định nghĩa, không có cách để kết hợp chúng nó lại.

Ngƣời thiết kế phải nổ lực suy nghĩ va thiết kế phƣơng cách nay bởi vì giới

hạn những kỷ thuật sẵn có của chúng nó.

This leads to further problems. Integration of object to object,

module to module, phase to phase, type of application to type of

application, or systems to software become even more of a challenge than

solving the problem at hand. This is compounded by a mismatch of

products used for design and development. Integration of all forms is left to

the devices of a myriad of developers well into the development process.

The resulting sys-tem is hard to understand, objects cannot be traced, and

there is little cor-respondence to the real world.

Sự tich hợp đối tƣợng với đối tƣợng, modun với mudun, giai đoạn

với giai đoạn, loại ứng dụng với loại ứng dụng, hoặc những hệ thông với

phần mềm trở nên nhiều thách thức hơn giải quyết vấn đề sắp tơi. Đây la sự

kết hợp bởi không tich hợp giữa các sản phẩm sử dụng thiết kế va phát

triển. Sự tich hợp tất cả forms cho ta cách của thức vô số những ngƣời phát

triển giỏi về tiến trình phát triển. Hệ thống cuối cùng khó ma hiểu, đối





tƣợng không thể nao tìm thấy dấu vết, va có it sự phù hợp trong thế giới

thực.

With these traditional methods, systems are actually encouraged by

informal (or semiformal) languages to be defined as ambiguous and incor-

rect. Interfaces are incompatible and errors propagate throughout devel-

opment. Once again the developers inherit the problem. The system and its

development are out of control.

Với những phƣơng thức truyền thống, những hệ thông thật sự đƣợc

khuyến khich những ngôn ngữ không nghi thức để đƣợc chỉ ra không rõ

rang vá không chinh xác. Những giao diện sản sinh ra những lỗi va sự

không thich hợp. Môt lần nữa những ngƣời phát triển thừa kế những vấn đề.

Hệ thông va sự phát triển hệ thống ra khỏi phạm vi quản lý

Requirements are defined to concentrate on the application needs of

the user, but they do not consider that the user changes his mind or that his

environment changes. Developers are forced to use a technology without an

open architecture. The result is ―locked in‖ designs, such as being locked

into a specific database schema or GUI; the user is forced to make resource

allocation a part of the application. Porting becomes a new devel-opment

for each new architecture, operating system, database, GUI envi-ronment,

language, or language configuration; critical functionality is avoided for

fear of the unknown and maintenance is both risky and the most expensive

part of the life cycle. When a system is targeted for a dis-tributed





environment, it is often defined and developed for a single proces-sor

environment and then redeveloped for a distributed environment —another

unnecessary development.

Những yêu cầu đƣợc chỉ rõ tập trung vao những ứng dụng cần thiết

cho ngƣời dùng, nhƣng chúng nó không xem xét việc ngƣời dùng có thay

đổi suỷ nghĩ hay môi trƣờng. Những ngƣời phát triển ra sức sử dụng những

kỹ thuật không có kiến trúc mở. Kết quả thiết kế bị khoá lại, chẳng hạn nhƣ

khoá mô hình dữ liệu hay giao diện đồ hoạ; ngƣời dùng ra sức lam tai

nguyên kết hợ các phần ừng dụng. Trở thanh sự phát triển mới cho mỗi kiến

trúc mới, hệ điều hạnh, cơ sở dữ liệu, một trƣờng giao diện ngƣời dùng,

ngôn ngữ, hay ngôn ngữ hình thức; chức năng bị phê bình thì đƣợc trách xa

lo âu thiếu kiến thức hay bao trì cả hai đều ạo hiểm va chi phi nặng nhất

tron vòng đời sống; khi một hệ thống đƣợc chỉ định cho môi trƣơng đƣợc

phân ổ theo một kiểu nao đó, nó thƣờng đƣợc định nghĩa va phát triển môi

trƣờng chế biến riêng va sau đó tái phát triển cho môi trƣờng phát triển theo

một mô hình nao đó – sự phát triển không cần thiết khác

Insufficient information about a system‘s run-time performance,

includ-ing that concerning the decisions to be made between algorithms or

archi-tectures, is incorporated into a system definition. This results in

design decisions that depend on analysis of outputs from exercising a

multitude of ad hoc implementations and associated testing scenarios. A

system is defined without considering how to separate it from its target





environ-ment. It is not known if a design is a good one until its

implementation has failed or succeeded.

Tin tức không hiệu quả về thực hiện thực thi của hệ thống, bao gồm

nhừng thứ liên quan những quyết định đƣợc lam giữa hệ thống va kiến

trúc, thì kết hợp chặt chẽ sự định nghĩa hệ thống. Những kết quả nay trong

quyết định thiết kế phụ thuộc vao việc phân tich đầu ra từ phân tich va vố

số cách thực hiện va kết hợp kiểm tra kịch bản. Một hệ thống đƣợc định

nghĩa không xem xét nhƣ thế náo để phân chia từ môi trƣờng mộc nhỏ,

không biết nếu thiết kế la tốt cho đến khi nao sự thực hiện gặp thất bại hoặc

thành công.

The focus for reuse is late into development during the coding phase.

Requirements definitions lack properties to help find, create, and inher-ently

make use of commonality. Modelers are forced to use informal and manual

methods to find ways to divide a system into components natural for reuse.

Why reuse something in today‘s changing market if it is not able to be

integrated, not portable or adaptable, and error prone? The result is little

incentive for reuse, and redundancy is a way of life. Again, errors propagate

accordingly.

Tập trung tái sử dụng phần mềm thì trễ việc phát triển trong suốt

thời ki coding. Những định nghĩa về các yêu cầu thiết thuộc tinh giúp đở

tìm kiếm, tạo ra, vốn đã sử dụng tƣơng đồng. Những ngƣời thiết kế mô hình

tập trung sử dụng những phƣơng thức thủ không hoặc không nghi thức để





tìm chia hệ thống thanh cấu thanh tự nhiên cho việc dùng lại. Tại sao dùng

lại một thức gì đó trong thị trƣờng thay đổi ngay nay nếu nhƣ nó không thể

hợp nhất, không dễ di động hay lắp vao va dễ xảy ra lỗi? kết quả la nó it

đƣợc khuyến khich cho việc dùng lại, va thửa cách thức cho sự sống của nó.

Một lần nữa la những lỗi đã đƣợc biết đến.

Automation is an inherently reusable process. If a solution does not

exist for reuse, it does not exist for automation. Systems are defined with

insufficient intelligence for automated tools to use them as input. Too often,

automated tools concentrate on supporting the manual process instead of

doing the real work.

Sự tự động hoá la tiến trình dùng lại. Nếu một cách giải quyết không

tồn tại việc dùng lại, nó không tồn tại sự tự động hoá, Hệ thống đƣợc định

nghĩa với sự thông minh kém hiệu quả cho những công cụ tự động sử dụng

nhƣ đầu vao. Quá bình thƣờng, những công cụ tự đông tập trung chông đở

tiến trình thủ công thay vì lam việc thực

Definitions supported by ―make work‖ automation are given to

develop-ers to turn into code manually. A process that could have been

mechanized once for reuse is performed manually over and over again.

When automa-tion attempts to do the real work, it is often incomplete

across application domains or even within a domain, resulting in

incomplete code such as skeleton or shell code. Manual processes are

needed to complete unfin-ished automations. An automation for one part of





a system (e.g., the GUI) needs to be integrated manually with an

automation for another part of the system (e.g., communications

algorithms) or with the results of a manual process. The code generated is

often inefficient or hardwired to a particular architecture, language, or even

a particular version of a language. Most of the development process is

needlessly manual. Again, all these manual processes are creating new

errors each time.

Những định nghĩa tự đông lam việc đƣợc đƣa ra cho ngƣời phát triển

coding bằng tay. Một tiến trình có thể đƣợc cơ khi hoá cho việc dùng lại thì

các thể hiện thủ công hơn một lần. khi những nổ lực tự động hoá công việc

thực, nó thƣờng la không hoán thanh xuyến qua những miền ứng dụng

hoặc ngay cả trong miền đó. Kết quả coding không hoán thanh sự tự động

hoá hoan tất. Sự tự động hoá la một phần của hệ thống cần thiết để đƣợc

tich hợp thủ công với việc tự động hoá cho phẩn khác của hệ thống(.., thuật

toán truyền thông) hoặc với những kết quả tiến trình thủ công. Tạo ra code

thƣơng không hiệu quả cho những kiến trúc chung, ngôn ngữ, ngay cả

những phên bản khác nhau của ngôn ngữ. Hầu hết tiến trình phát triển thì

không cần thiết lam việc thủ công. Nhắc lại, tất cả tiến trình thủ công thì tạo

ra nhựng lỗi mời ở mổi thời điểm

A promising solution to these problems is DBTF. Whereas the

traditional approach is after the fact, or curative, the DBTF approach is

preventative.





Giải quyết đầy triển vọng cho vấn đề nay la DBTF. Trong khi tiết

cận sau sự việc, hoặc chữa trị, DBTF tiếp cận bằng cách ngăn ngửa

11.2 DEVELOPMENT BEFORE THE FACT

With DBTF, each system is defined with properties that control its

own design and development. With this paradigm, a life cycle inherently

pro-duces reusable systems, realized in terms of automation. Unlike before,

an emphasis is placed on defining things the right way the first time.

Problems are prevented before they happen. Each system definition not

only models its application but also models its own life cycle.

Với DBTF, mỗi hệ thống định nghĩa những thuộc tinh để điều khiển

những thiết kế riêng của nó. Với hệ biến hoá nay, vòng đời sống vốn đã hệ

thống tai sử dụng., nhận ra đƣợc giới hạn sự tự đông hoá. Không giống

trƣớc, nhấn mạnh định nghĩa các thứ đúng lần đâu tiên. Nhựng vấn đế đƣợc

ngăng ngừa trƣớc khi nó xảy ra. Mỗ định nghĩa hệ thống không chỉ mô hình

ứng dụng của nó ma còn vòng đồi sống của riêng nó

From the very beginning, a system inherently integrates all of its

own objects (and all aspects of and about these objects) and the

combinations of functionality using these objects. It maximizes its own

reliability and flexibility to change and the unpredictable; capitalizes on its

own parallel-ism; supports its own run-time performance analysis and the

ability to understand the integrity of its own design; and maximizes the





potential for its own reuse, automation, and evolution. The system is

developed with built-in quality and built-in productivity.

Từ khởi đầu, hệ thông tich hợp tất cả đối tƣợng riêng(va tất cả bề

ngoai về đối tƣợng nay) va kết nối các chức năng sử sụng các đối tƣợng

nay. Nó đƣợc tối ƣu hoá sự tin tƣơng va tinh mềm dèo của riếng nó để thay

đổi hay không dự đoán trƣớc, lợi dùng tinh song song của từng thanh viên,

chông đở sự phân tich thể hiện thƣc thi của nó va khả năng hiểu đƣơc sự

tich hợp của thiết kế riêng của nó va tối ƣu hoá tìm năng sử dụng lại, sự tự

động hoám va sự tiến hoá. Hệ thống thì phát triển gắn liến với chất lƣợng

và hiệu suất.

A curative means to obtain quality is to continue testing the system

until the errors are eliminated; a preventative (i.e., DBTF) means is to not

allow errors to creep in, in the first place. Whereas a curative means to

acceler-ate a particular design and development process is to add resources

such as people or processors, a preventative approach would find a more

effi-cient way to perform this process, such as capitalizing more on reuse or

eliminating parts of it altogether, yet still reaching the desired results.

Effective reuse is a preventative concept. Reusing something with no errors,

to obtain a desired functionality, avoids the errors of a newly devel-oped

system; time and money will not be wasted in developing that new system.

For successful reuse, a system must be worth reusing and must be reused

for each user requiring functionality equivalent to it. This means starting

from the beginning of a life cycle, not at the end, which is typically the case





with traditional methods. Then a system is reused for each new phase of

development. No matter what kind, every ten reuses save ten unnecessary

developments.

Phƣơng tiện chữa trị đạt đƣợc chất lƣợng sẽ tiếp tục kiểm thử hệ

thống cho đến khi lỗi bị khử; một phƣơng tiện ngăng ngừa sẽ không đƣợc

phéo xảy ra lỗi, ở chổ đầu tiên. Khi một phƣơng tiện trị thúc dục thực hiện

gấp thiết kế đặc biệt va tiến trình phát triển sẽ thêm tai nguyên chẳng hạn

ngƣời hay bộ xử lý máy tình. Việc ngăn ngừa sẽ la cách thực hiệu quả hơn

đê thực hiện tiến trình nay, giống nhƣ sử dụng lại hay loại trừ một phần nao

đó của tổng thể, tuy nhiên nó vẫn tiến tới những kết quả mong muốn. Việc

dùng lại nhiệu quả la một quan niệm ngăn ngừa. Một thứ nao đó dùng lại

thì không có lỗi, đạt đƣợc những chức năng mong muốn, tránh đƣợc những

lỗi hệ thông phát triển gần đây, thời gian va tiền bạc không lãn phi trong

việc phát triển hệ thống mới. Để việc dùng lại thanh công, một hệ thống cần

đáng giá trong việc dùng lại va cần đƣợc dùng lại cho mỗi chức năng yệu

cầu của ngƣời dùng tƣơng đƣơng với nó. Điều nay có nghĩa la bắt đầu từ

giai đoạn bắt đầu của vòng đời sông, không la cuối cùng, rõ rang đây la một

phƣơng thức truyền thống. Sau đó hệ thống đƣợc dùng lại cho mỗi thời kì

mới của phát triển, không có chuyện gì xảy ra, mỗi 10 lần dùng lại sẽ tiết

kiệm đƣợc 10 sự phát triển không cần thiết.





11.3 THE TECHNOLOGY

The DBTF technology embodies and is based on a formal theory; it

has a formal systems language, a generic process, and an automation, all

based on the formal theory. Once understood, the characteristics of good

design can be reused by incorporating them into a language for defining any

sys-tem. The language is the key to DBTF. It has the capability to define

any aspect of any system (and any aspect about that system) and integrate it

with any other aspect. These aspects are directly related to the real world.

Kỹ thuật DBFT la một tiêu biểu va va căn bản cho lý thuyết chinh

qui, nó có ngôn ngữ hệ thống chinh qui, một tiến trình chung, va một tự

động hoá, tất cả la cơ bản cho lý thuyết chinh qui, Khi hiểu những đặc tinh

của thiết kế tốt có thể đƣợc dùng lại bởi hợp nhất chúng nó thanh ngôn ngữ

để chỉ rõ một vai hệ thống. Ngôn gnu74 la khoá của DBTF. Nó có khả năng

chỉ rõ một vai diện mạo bên ngoai của hệ thốn va tƣơng thich nó với diện

mạo ngoai của hệ thống khác. Những diện mạo ngoai nay la hƣớng dẫn có

liên quan thế giới thực

This same language can be used to define and integrate system

require-ments, specifications, design, and detailed design for functional,

resource, and resource allocation architectures throughout all levels and

layers of ―seamless‖ definition, including hardware, software, and

peopleware. It could be used to define missile or banking systems as well as

real-time, Internet, or database environments.





Ngôn ngữ giống nhau có thể đƣợc dùng để chi ra va hoa nhập với

yêu cầu hệ thống, chi tiết kỹ thuật, thiết kế, va chi tiết thiết kế cho chức

năng, tai nguyên, va tại nguyên kết hợp kiến trúc thông qua tất cả cấp độ

tầng của ―liền một mảnh‖, bao gồm phần cƣng, phần mềm va ngƣời dùng.

Nó có thể đƣợc dùng chỉ ra hệ thống nghiêp vụ ngân hang giống nhƣ thời

gian thực, Internet, hoặc những môi trƣờng cơ sở dữ liệu

With this language, every object is a system-oriented object (SOO)

developed in terms of other SOOs. An SOO integrates all aspects of a sys-

tem including that which is function, object, and timing oriented. Every

system is an object; every object is a system. Instead of object-oriented

systems, DBTF has system-oriented objects and can be used to define sys-

tems with diverse degrees of fidelity and completeness. Such a languagecan

always be considered a design language because design is relative: one

person‘s design phase is another person‘s implementation phase.

Với ngôn ngữ nay, một đối tƣợng la một đó tƣợng hƣớng hệ thống

đƣợc phát trển trong nhóm SSOs khác nhau, một sự hoá nhập SOO tất cả bể

ngoai của một hệ thốngbao gồm ham, đối tƣợng, hƣớng thời gian. Mỗi hệ

thông la một đối tƣợng,, mỗi đối tƣợng la một hệ thống. Thay vì hệ thống

hƣớng đối tƣợng, DBTF có đối tƣợng hƣớng hệ thống có thể đƣợc dùng

định nghĩa hệ thống với độ thay đổi khác nhau độ tin va sự hoan thanh.

Giông nhƣ la ngôn ngữ có thể luôn luôn đƣợc xem xét một ngôn ngữ thiết

kế bởi vì thiết kế la một quan hệ: giai đoạn một ngƣời thiết kế la giai đoạn

thực thi của một ngƣời khác.





This implementation-independent language has mechanisms to

define mechanisms for defining systems. Although the core language is

generic, the user ―language‖, a by-product of a development, can be

application specific because the language is semantics dependent but syntax

indepen-dent. Unlike formal languages that are not friendly and friendly

languages that are not formal, this language is formal and friendly.

Ngôn ngữ thi hanh độc lập có kỹ thuật để định nghĩa cơ chế để chỉ rõ

hệ thống. Mặc dù ngôn ngữ cốt la chúng, ngƣời dùng ―ngôn ngữ‖ có thể

ứng dụng tạo ra sự phát triển, có thễ ứng dụng rõ rang bởi vì ngôn ngử phụ

thuộc kịch bản nhƣng cú pháp không phụ thuộc. Không giống ngôn ngữ

chinh qui thì không thân thiệt va những ngon ngữ thân thiện thì không

chinh qui, Ngôn nhữ nay la chinh qui va thân thiện

The first step in building a DBTF system is to define a model

(without concern for resource allocation details such as how many

processes are needed) with the language. This process could be in any

phase of develop-ment, including problem analysis, operational scenarios,

and design. The model is automatically analyzed to ensure it was defined

properly. This includes static analysis for preventative properties and

dynamic analysis for user-intent properties.

Bƣớc đầu tiên xây dựng hệ thông 1DBTF la chỉ rõ mô hình (không

liênq aun những tai nguyên liên kết chi tiết chẳng han nhƣ bao nhiêu tiến

trình la cần thiết) với ngôn ngữ. Tiến trình có thể có một vai giai đoạn phát





triển, bao gồm phân tich vấn đề, kịch bản chức năng, va thiết kế. Mô hình

đƣợc phân tich một cách tự động để đảm bảo nó chỉ định một cách thich

hợp. Nó bao gồm những phân tich tĩnh cho những thuộc tinh ngăn ngừa va

phân tich động các thuộc tinh mục đich ngƣời dùng

A complete and fully production-ready and fully integrated software

implementation (and documentation) for any kind or size of application,

consistent with the model, is then automatically generated by the generic

generator for a selected target environment in the language of choice (e.g.,

C, Java, or XML) and the architecture of choice. If the selected

environment has already been configured, it is selected directly; if not, the

generator is configured for a new language and new architecture before it is

selected.

Để có một sản phẩm sẳn sang va đầy đủ hợp nhất sự thi hanh cho

một vai loại hoặc kich thƣớc ứng dụng, nhất quán các mô hình, va sau đó la

tự động tạo ra bởi ngƣời tạo chungcho một môi trƣờng mộc nhỏ trong ngôn

ngữ lựa chọn (C, Java, hay XML) va kiến trục sự lựa chọn. Nếu môi

trƣờng đƣợc lựa chọn sẳn sang cho đƣợc định hình, nó sẽ đƣợc lựa chọn

ngay lập tức, nếu không ngƣời tạo định hình cho một vai ngôn ngữ va kiến

trúc mới trƣớc khi lựa chọn

The resulting system can then be executed. If the desired system is

soft-ware, the system can now be tested for further user-intent errors. It

becomes operational after testing. Before the fact testing is inherently part





of every DBTF development step. Errors are prevented simply by construc-

tion with the language and because of that which is inherent or automated;

for example, since the generator automatically generates all the code, no

manual coding errors will be made. Target changes are made to the defini-

tion, not to the code. Target architecture changes are made to the configu-

ration of the generator environment, not to the code. If the real system is

hardware or peopleware, the generated software system can serve as a form

of simulation upon which the real system can be based.

Hệ thông kết quả sẽ đƣợc thực thị. Nếu hệ thống nhƣ mong muốn la

phần mềm, thì hệ thống bây giờ có thể đƣợc kiểm tra cho những lổi xảy ra

trong tƣơng lai, nò trở nên sẳn sang sau khi kiểm tra. Trƣớc khi kiểm tra

thật sự vốn đã la một phần của bƣớc phát triển DBTF. Lỗi đƣợc ngăn ngừa

đơn gian bởi cấu trúc với ngôn ngữ va bởi vì nó vốn ó va tự động, vi dụ, từ

khi ngƣời tạo tạo ra tất cả code, không có lỗi coding thủ công nao phát sinh.

Những kiến trúc nhỏ thay đồi lam hình dạng của môi trƣờng tạo ra, không

đƣợc code. Nếu hệ thống la phần cứng, hệ thống phần mềm tạo ra có thể

đƣợc phục vụ nhƣ một hình thức của mô phỏng trên hệ thống thực nền tảng

DBTF is a system-oriented object approach based upon a unique

con-cept of control. The foundations are based on a set of axioms and on

the assumption of the existence of a universal set of objects. Each axiom

defines a relation of immediate domination; the union of the relations

defined by the axioms is control. Among other things, the axioms establish

the relationships of an object for invocation, input and output, input and





output access rights, error detection and recovery, and ordering during its

developmental and operational states.

DBTF là một đối tƣợng hƣớng hệ thống gần nến tảng trên quan niệm

điều khiển. Nền tang la căng ban thiết lập chân lý va giả định tình trạng của

tập hợp phố biến của đối tƣợng. Mỗi chân lý chỉ rõ mối quan hệ sự thống trị

ngay tức thì; sự kết hợp các quan hệ chỉ rõ chân lý thì điều khiển. Giữa

những thứ khác, thiết lập tiền đề mốt quan hệ của một đối tƣợng để dẫn

chứng, đầu vao va đầu ra, truy cập vao va ra, xoá hoặc phục hồi lỗi, va suốt

trạng thái phát triển va sẳn sang để dùng.

This approach is used throughout a life cycle, starting with require-

ments and continuing with systems engineering, specification, analysis,

design, implementation, testing, and maintenance. Its users include man-

agers, system engineers, software engineers, and test engineers, as well as

end users.

Sự gần lại đƣợc dùng thông qua chu trình sống, bắt đấu với những

yêu cầu va tiếp tục với máy hệ thống,, phân tich chỉ rõ, thiết kế, sự thi hanh,

kiểm thử, va bảo trì. Ngƣời dùng của nó bao gồm ngƣời quản lý, những kỷ

sƣ hệ thống, những kỷ sƣ phần mềm, va kỷ sƣ kiểm thử va ngƣời dùng cuối

In addition to experience with real-world systems, 001 takes its roots

in many other areas, including systems theory, formal methods, formal

linguis-tics, and object technologies. It would be natural to make





assumptions about what is possible and impossible based on its superficial

resemblance to other techniques such as traditional object technologies. It

helps, how-ever, to suspend any and all preconceived notions when first

introduced to it because it is a world unto itself — a completely new way to

think about systems and software.

Thêm vao từng trải với những hệ thống thế giới thực, 001 la gốc của

nó trong nhiều vùng khác nhau, bao gồm lý thuyết hệ thông, những phƣơng

thức chinh qui, ngôn ngữ chinh qui va những kỹ thuật đối tƣợng. Tuy nhiên

nó trợ giúp, để hoãn lại một vai va tất cả khái niệm nhận thức đƣợc khi đầu

tiên đƣợc giới thiệu với nó nó la một thề giới thực đén chinh nó, một cách

thức mới hoan thanh để suy nghĩ về hệ thống va phần mềm.

The DBTF approach had its beginnings in 1968 with the Apollo

space missions when research was performed for developing software for

manrated missions. This led to the finding that interface errors accounted

for approximately 75 percent of all errors found in the flight software

during final testing. These include data flow, and priority and timing errors

at the highest and lowest levels of a system to the finest grain detail. Each

error was placed into a category according to the means taken to prevent it

by the very way a system was defined. A theory was derived for defining a

sys-tem such that this entire class of interface errors would be eliminated.

DBTF gần có sự bắt đầu vao nămg 1968 với nhiệm vụ không gian

Apollo khi nghiên cứu đƣợc thực hiện phát triển phần mềm cho sứ mễnh





đƣợc bảo hiểm. Đây la chỉ dẫn để tìm lỗi giao diện đƣợc thống kê gần 75%

của tất cả lỗi đƣợc tìm thấy trong phần mềm va việc kiểm thử cuối cùng.

Bao gồm luống dữ liệu, ƣu tiên va lỗi thời gian ở cấp độ thấp nhất va cao

nhất của hệ thống. Mỗi lỗi đƣợc định vị một mục lục để ngăn ngừa nó bởi

hệ thống đƣợc chỉ rõ. Một lý thuyết đƣợc nhận từ định nghĩa hệ thống

giống nhƣ la toan bộ lớp của lỗi giao diện sẽ loại trứ.

11.4 PRIMITIVE STRUCTURES (CẤU TRÖC MẪU)

Tất cả Fmap va Tmap đƣợc định nghĩa về mặt 3 cấu trúc quản lý

gốc (three primitive control structures) la: một cấu trúc cha quản lý các cấu

trúc con của nó để có đƣợc một quan hệ phụ thuộc, quan hệ độc lập, quan

hệ quyết định (decision-making relationship). Môt tập hợp những luật (điều

khoản) điển hình đƣợc gắn kết với các cấu trúc mẫu. Nếu những luật đó

đƣợc tuân theo, những lỗi bề mặt sẽ đƣợc ―loại bỏ‖, trƣớc thực tế la phải

tránh những lỗi nay đầu tiên. Kết quả la những lỗi bề mặt (75 – 90 % những

lỗi thƣờng thấy khi kiểm tra theo các truyền thống) đƣợc loại trừ ở phƣơng

diện lý thuyết. Sữ dụng những cấu trúc mẫu cung cấp cho hệ thống một sự

định nghĩa rõ rang để tăng tinh chống chịu lỗi của nó.

Việc sử dụng những hệ thống mẫu đƣợc thể hiện ở ―sự định nghĩa

cách áp dụng FMap cho hệ thống ―hình 11-2. Ham đầu tiên nhân

FLATwood and ROUNDwood nhƣ tham số đầu vao va trả ra một table.

MakeATable là (hàm cha) đƣợc tách rời thanh ham con MakeParts va

Assemble bằng phép Join.. MakeParts nhận FLATwood va ROUNDwood





từ cha va tạo ra Top,Legs. Top,Legs đƣợc đƣa cho Assemble nhƣ tham số

đầu vao. Assemble đƣợc quản lý bởi cha của nó để phụ thuộc vao những

tham số đầu vao từ MakeParts. Assemble tạo ra Table va đua cho cha.

Nhƣ la một ham cha, MakeParts đƣợc tách ra thanh các ham nhỏ

hơn. MakeTop va Make Legs đƣợc điều chỉnh để độc lập với nhau với phép

Include của cấu trúc điều khiển gốc. MakeTops nhận vao một phần đầu vao

của cha va MakeLegs nhận vao phần con lai. MakeLegs cung cấp một phần

của output (Leg) cho ham cha, va MakeTop cung cấp phần con lai.

MakeTop điều khiển những ham con của nó la FinishSoftWood va

FinishHardWood với phép Or. Ở đây, cả 2 ham con đều nhận vao tham số

đầu vao giống nhau va có cung một kết quả trả về bởi vì chỉ có một trong 2

ham đƣợc thực hiện để cho ra kết quả. FinishSoftWood chạy nếu ham

―is:Soft,Wood‖ cho kết quả la Đúng,ngƣợc lại FinishHardWood sẽ chạy.

Chú ý rằng trong hệ thống các tham số đầu vao(input)(VD FLATwood) có

thể đƣợc tra (truy) xuống từ các ham cha đến các ham con va các kết quả

đầu ra (output) (VD Table) có thể đƣợc tra (truy) lên từ những ham con đến

hàm cha.

Ham MakeATable của Tmap,Table, không sử dụng những cấu trúc

mẫu gọi la cấu trúc type (type structures). La một khái niệm đƣợc thảo luận

ở phần sau.





Hình 11-2 The Three Primitive Structures. Đƣợc sử dụng để tách rời

một Map.Phần FMap của hệ thống, MakeATable,đƣợc lam bằng cách sử

dụng JOIN, INCLUDE, and OR để quản lý những ham độc lập, phụ thuộc

va ham quyết định.

Mỗi type ở Tmap có thể đƣợc tách rời tách rời các phần của cấu trúc

gốc (primitive structures) thanh những type con nơi ma mối quan hệ giữa

các type rõ ràng. Ở hình 11-3 Table với vai trò la cha đƣợc tách thanh các

ham nhỏ hơn, Top va Legs, tại đó mối quan hệ giũa Top va Legs la on-1

and on-2. theo thứ tự, quan hệ giữa Table va legs la r-1 va quan hệ của

Table và Top là r-0. Chú ý rằng việc tạo ra một Table Top (dependen)dựa

vào Legs hình 11-3 a. Mặt khác, quan hệ độc lập(independen) tồn tại giữa

FrontLegs va BackLegs thể hiện ở bảng B. The Table (ý la bảng B) có thể





có FrontLegs hay BackLegs (bên phải), hoặc cả 2 cái (ỏ bên trái). Hình 11-

3.c Minh hoạ một cấu trúc quyết định(hay ham quyet dinh) (a decision

Structure) với các đối tƣợng không giống với các cấu trục phụ thuộc hay

không phụ thuộc, mô hình của OMap luôn khác với mô hình của TMap bởi

vì chỉ có một đối tƣợng đƣợc chọn để cung cấp cho các ham cha nhƣ vi dụ

trên.

Exhibit 11-3. A TMap(va cấu trúc Omaps tƣơng ứng) có thể tách the

Three Primitive Control Structures thanh những quan hệ rõ rang.

Điều đó nói lên, một hệ thống đã đƣợc định nghĩa theo những cấu

trúc đó ở các tinh chất(mặt bản chất), hổ trợ một môi trƣờng phân phối

thực. Mỗi hệ thống đƣợc cắt nhỏ, mỗi đối tƣợng có thể đƣợc truy vết (kiểm

tra) va cấu hình lại va có một thứ tự ƣu tiên duy nhất. Sự phụ thuộc va

không phụ thuộc có thể đƣợc phát hiện va sử dụng để quyết định xem viêc





xử lý song song hay tuần tự la tốt hơn. Với những tinh chất đó, một hệ

thống đƣợc định nghĩa từ sớm để tăng tối đa khả năng chống chịu với sụ

thay đổi va lợi dụng khả năng sử lý song song của hệ thống.

11.5 DEFINED STRUCTURES

Tất cả các hệ thống có thể định nghĩa hoan toan chỉ dựa trên cấu trúc

mẫu nhƣng it cấu trúc mẫu có thể đƣợc tìm thấy từ các cấu trúc mẫu khác

va thúc đẩy quá trình định nghĩa va hiểu hệ thống. Các cấu trúc không mẫu

có thể đƣợc định nghĩa cho FMap va TMap điều nay có thể tạo ra sự không

đồng bộ, lam mất đi khả năng sử dụng trong thời gian thực. Một các tƣơng

tự, cấu trúc truy vấn va tìm kiếm (retrieval and query structures) có thể

đƣợc định nghĩa cho hệ thống quản lý cơ sở dữ liệu client-server.!





Hình 11-4 Sử dụng các cấu trúc đƣợc định nghĩa để định nghĩa các

cấu trúc không dùng để định nghĩa. CO-INCLUDE la một vi dụ của ở hệ

thống trên, cái đƣợc biến thanh một cấu trúc đƣợc định nghĩa

CoInclude la một vi dụ ở hệ thống trên, điều thƣờng thấy (hình 11-

4). Mô hình FMap của nó đã đƣợc định nghĩa với các cấu trúc mẫu. Bên

trong CoInclude, mọi giữ nguyên cho mỗi lần sử dụng trừ nút A va B của

ham con. Mẫu CoInclude có thể đƣợc định nghĩa từ nhƣ một cấu trúc không

chuẩn về nhiều cấu trúc mẫu bằng việc vân dụng các cấu trúc đã định nghĩa.

Ý tƣởng nay la một vi dụ những mẫu có thể tái sử dụng cho FMaps va

Tmaps.

Kèm với sự định nghĩa cấu trúc la sự định nghĩa về mặt cú pháp để

sử dụng (hình 11-4.b). hình 11-4.c cung cấp một cách dùng ẩn (một vi dụ)

(―hidden reuse‖) của toan bộ hệ thống nhƣ đƣợc định nghĩa, nhƣng chỉ trình

bay những yếu tố cơ bản một cách rõ rang (đó la ham A va B). Cấu trúc

Coinclude đƣợc sử dụng tƣơng tự nhƣ cấu trúc Include nhƣng với

Coinclude user đƣợc linh động hơn ở những chi tiết đƣợc sử dụng thƣờng

xuyên,những yêu cầu va những sự lựa chọn. Mỗi cấu trúc đƣợc định nghĩa

có những quy tắc (rules) gắn với nó để sử dụng cũng nhƣ ở các cấu trúc

quản lý mẫu. những quy tắc của các cấu trúc không mẫu (the nonprimitives)

thật ra cũng la sự thừa kế các quy tắc của cấu trúc mẫu (the primitives).

Async (hình 11-5) la một cấu trúc thời gian thực, chia sẽ, giao tiếp

với cách hoạt động đồng bộ hoặc không đồng bộ. Hệ thống Async đƣợc





định nghĩa với các hám gốc nhƣ Or, Include, va cấu trúc ngƣời dùng định

nghĩa CoInclude. Nó không thể đƣợc phân rã sâu hơn vì những ham sâu

nhất của nói đã la những ham gốc (primitive function) ở những dạng đã

đƣợc định nghĩa (xem lại đặc điểm 2: Any và Clone1: Any under End: là

những thao tác cơ bản trên kiểu Eny) đệ quy (xem Async phia dƣới

DoMore), hoặc một vai ham cho những cấu trúc đã đƣợc định nghĩa (xem

A va B ở dƣới quá trình). Nếu một nốt la không rơi vao những dạng đó, nó

có thể đƣợc phân rã sâu hơn hoặc nó có thể đƣợc thay thế bằng các ham

trong thƣ viện (library) hoăc các ngoại ham ở từ môi trƣờng ngoai.





Hình 11-5. Async la một cấu trúc đƣợc định nghĩa có thể dƣợc sử

dụng để định nghĩa một hệ thống chia sẻ (hệ thống song song) với cách hoạt

động đồng bộ hoặc không đồng bộ.

CoordinateTasks sử dụng Async nhƣ la một nơi để TurnAndPlan va

Move phụ thuộc lẫn nhau, sự giao tiếp, các thao tác đồng bộ va tuần tƣ. 2

robots ở hệ thống lam việc với nhau để thực hiện đƣợc tác vụ nay, tƣơng tự

nhƣ việc xây dựng một cái bảng (table). Đây la một giai đoạn của việc lập

kế hoạch robot, RB is coordinated với cái giai đoạn tiếp theo của RA.

Khả năng tái sử dụng có thể đƣợc dùng với một Mẫu TMap (TMap

model) bằng cách sử dụng những kiểu cấu trúc định nghĩa bởi ngƣời dùng,

các cấu trúc đó cung cấp cơi chế để định nghĩa một TMap bỏ qua các ràng

buộc đơn lẻ. Bảng TMap (hình 11-2) sử dụng một tập các cấu trúc định

nghĩa bởi ngƣời dùng. Table nhƣ dạng cha quản lý những dạng con Legs va

Top về mặt cấu trúc TupleOf,Legs cũng quản lý những con của nó Leg về

mặt OsetOf, Wood quản lý Hard va Soft ở OneOf. TupleOf la một bộ với

số lƣợng xác định những kiểu khác nhau có thể có của đối tƣợng. OSetOf la

một bộ với số lƣợng thay đổi những kiểu tƣơng tự nhau của đối tƣợng va

one of la một sự phân lớp những kiểu khác nhau của một đối tƣợng, từ đó

bất cứ đối tƣợng nao cũng có thể đƣợc sắp vao các class. Các cấu trúc phia

trên độc lập với TreeOf cái có thể đƣợc sử dụng để thiết kế nhiều dạng của

TMap. TreeOf la một tập các kiểu giống nhau của cac đối tƣợng có sắp thứ

tƣ, nó sử dụng hệ thống cây đánh chỉ mục. Với việc sử dụng các cơ chế nhƣ





các cấu trúc đã đƣợc định nghĩa, một hệt thống có thể tăng cƣờng tối đa khả

năng của nó từ ban đâu cho việc tái sử dụng.

11.6 FMAPS, TMAP VÀ SỰ KẾT HỢP CỦA CHÖNG

Hình 11-6 thể hiện sự định nghĩa cho một hệ thống hoan chình cho

môt công ty với sự kết hợp của một tập các FMap va TMap. Tác vụ của

Công ty nay có thể đƣợc thiết lập thanh một bảng – với sự giúp đơ của

robot để hoan thanh các công việc- sử dụng những cấu trúc đã đƣợc định

nghĩa nhƣ ở trên. Bởi vì hệ thống trên đã đƣợc định nghĩa xong, nó sẵng

sang để phát triển, hoan thanh va kết hợp các thao tác lại thanh sản phẩm

cuối. FMap của hệ thống Is_FullTime_Employee đƣợc phận rã cho đến khi

đạt đƣợc những hảm gốc ở phần TMap, MfgCompany. (ở vi dụ

Emps=Moveto:Employees (MfgC) Nơi ma MfgC kiểu MfgCompany va

Emps thuộc kiểu Employees.). MfgCompany đƣơc phân rã cho đến khi

những lá của nó la các kiểu gốc hay la một kiểu đƣợc định nghĩa bởi TMap

khác.





Hình 11-6 Một hệ thống hoan chỉnh la một sự kết hợp Fmaps Tmaps,

nơi FMap đƣợc phân rã đến những ham gốc trong các kiểu của TMaps.

TMaps đƣợc phân rã tới những kiểu gốc. Cụ thể những kiểu trừu tƣợng

những cấu trúc ngƣời dùng tự định nghĩava áp dụng vao trong các node lá

của FMap.

Trên hệ thông, Is_FullTime_Employee sử dụng các đối tƣợng định

nghĩa bởi TMap, MfgCompany, để kiểm tra xem một công nhân la lam việc

Fulltime hay part time. Đầu tiên, tạo đối tƣợng kiểu MfgCompany, MfgC,

một va một đối tƣợng kiểu Employees, Emps. Cấu trúc LocateUsing:Name

(một cấu trúc đã đƣợc định nghĩa) tìm một Employee dựa vao tên. Môt khi

tìm thấy, ta chuyển từ Emp đến PS. Thao tác YN=is:FullTime(PS) đƣợc sử

dụng để tìm ra từ PS ngƣời Emp la lam việc toan bộ thời gian hay không.

Nếu la có YN = true.





Mỗi cấu trúc đam nhận một tập các quan hệ với cấu truc cha và con

của nó. Ở vi dụ trên: TMaps MfgCompany đƣợc phân rã thanh Departments

va Employees TupleOf. Departments đƣợc phân rã thanh Purchasing,

Production, va Marketing về mặt ManagementOf (a user-defined type

structure). Employee đƣợc phân rã về mât OsetOf. Một nhánh con của

Employee, PayScale đƣợc phận rã về mặt OneOf.

Các kiểu trừu tƣợng đƣợc phân rã với các cấu trúc tƣơng ứng ở

TMaps kế thừa (hay tái sử dụng) những thao tác cơ bản (primitive

operations) nên có cách hoạt đông giống nhau. VD: MfgCompany và

Employee cùng kế thừa những thao tác cơ bản của kiểu cấu trúc, TupleOf.

ở vi dụ, ta thấy ở FMap, cả 2 kiểu đều sử dụng các thao tác gốc MoveTo cái

đƣợc kế thừa từ TupleOf.

Mỗi cách sử dụng MoveTo la một vi dụ Child = MoveTo: la thao tác

con của cấu trúc kiểu TupleOf. Vd: Emps=MoveTo:Employees(MfgC) cho

phép tìm vị tri của một nhân viên ở trong đố tƣợng MfgCompany. Một kiểu

có thể la cấu trúc không gốc (Departments), cấu trúc gốc (e.g., FullTime),

một định nghĩa cái đƣợc định nghĩa ở những cây con khác (Employee). Khi

một nút lá chứa tên cũa một cấu trúc ở cây con khac, các đối tƣợng con

(child object) sẽ đƣợc thêm vao nơi đối tƣợng cha (parent object) điều kiển

hoặc một tham chiếu ra đối tƣợng ngoai (external object) sẽ đƣợc thêm vao

nơi của đối tƣợng con (đê có thể định hình mối quan hệ của một đối tƣợng

cha va đối tƣợng ngoai)





11.7 NHỮNG PHÉP TOÁN NGUYÊN THỦY THÔNG DỤNG

The TMap provides universal primitive operations, which are used

for controlling objects and object states inherited by all types. They create,

destroy, copy, reference, move, access a value, detect and recover from

errors, and access the type of an object. They provide an easy way to

manipulate and think about different types of objects. With universal

primitive operations, building systems can be accomplished in a more

uniform manner. TMap and OMap are also available as types to facilitate

the ability of a system to understand itself better and manipulate all objects

the same way when it is beneficial to do so.

TMap cung cấp các phép toán nguyên thủy thông dụng, đƣợc sử

dụng cho việc kiểm soát các đối tƣợng va các trạng thái của đối tƣợng đƣợc

kế thừa bởi tất cả các loại (types). Chúng tạo, hủy, sao chép, tham chiếu, di

chuyển, truy cập một giá trị, phát hiện va truy cập các loại đối tƣợng. Với

các phép toán nguyên thủy phổ thông,việc xây dựng hệ thống có thể đƣợc

thực hiện một cách thống nhất hơn. TMap va OMap cũng sẵn sang nhƣ la

các loại (types) tạo điều kiện thuận lợi cho khả năng hệ thống tự hiểu tốt

hơn va thuận lợi hơn khi thao tác tất cả các đối tƣợng theo cùng một cách

TMap properties ensure the proper use of objects in an FMap. A

TMap has a corresponding set of control properties for controlling spatial

relationships between objects. One cannot, for example, put a leg on a table

where a leg already exists; conversely, one cannot remove a leg from the





table where there is no leg. A reference to the state of an object cannot be

modified if there are other references to that state in the future; reject values

exist in all types, allowing the FMap user to recover from failures if they

are encountered.

Những tinh chất của TMap đảm bảo sử dụng đúng đối tƣợng trong

FMap. TMap có một bộ tƣơng ứng của các thuộc tinh điều khiển cho việc

kiểm soát các mối quan hệ không gian giữa các đối tƣợng. Vi dụ: một chân

của cái ban không thể đặt lên ban khi ma cái ban chỉ có một chân; ngƣợc

lại, ngƣời ta không thể gơ bỏ một chân của ban khi ma cái ban không có

chân. Sự tham chiếu đến trạng thái của một đối tƣợng không thể bị sửa đổi

nếu có sự tham chiếu khác đến trạng thái trong tƣơng lai; việc từ chối các

giá trị tồn tại trong tất cả các loại(types), cho phép ngƣời sử dụng FMap để

phục hồi từ lỗi nếu họ gặp phải.

The same types of definition mechanisms are used to define

RotateRotateArm, a hardware system (Exhibit 11-7), as were used to define

the preceding software system. Note that this system also includes the use

of primitives for numeric calculation. In this system, the rotation of the

robot arm is calculated to move from one position to another in a

manufacturing cell to transfer a part. The universal operation (an example

of another form of reusable with polymorphism), Replace, is used twice in

this example. Each use of a universal operation has function qualifiers that

select a unique TMap parent–child combination to be used during the

application of the function.





Cùng loại của các định nghĩa kĩ thuật đƣợc sử dụng để định nghĩa

RotateRotateArm, một hệ thống phần cứng (hình 11-7), nhƣ đã đƣợc sử

dụng để định nghĩa hệ thống phần mềm trƣớc đó. Lƣu ý rằng hệ thống nay

cũng bao gồm việc sử dụng nguyên thủy để tinh số. Trong hệ thống nay,

luân chuyển của các cánh tay robot đƣợc tinh toán để chuyển từ một vị tri

tới một vị tri khác trong một tế bao đang đƣợc sản xuất để chuyển giao một

phần. Các phép tinh phổ thông (một vi dụ về một hình thức khác có thể tái

sử dụng với tinh đa hình), thay thế, đƣợc sử dụng 2 lần trong vi dụ nay. Mỗi

sử dụng của một phép tinh phổ thông có vòng loại chức năng ma chọn một

sự kết hợp TMap parent-child duy nhất đƣợc sử dụng trong việc áp dụng

các chức năng.





Exhibit 11-8 has a definition that takes further advantage of the

expressive power of a TMap with the option of using explicitly defined

relations. In this example, a stack of bearings is described. A bearing in the

stack may be under (with relation on-0) or on (with relation on-1) another





bearing object in the stack as defined by the DSetOf structured type. A

bearing object is decomposed into a Cap, a RetainerWith Balls, and a Base.

Object relationships at this level show that the Cap is above the

RetainerWithBalls, which is, in turn, above the Base. Further detail reveals

that a Retainer has (with the has-n relation) some number of

RetainerHoleWithBall objects. The set of RetainerHoleWithBall objects are

independent of each other, defined by the ISetOf structured type. This

structure allows for physically independent relations on the objects in the

set. Here, different portions of the Cap surface are independently related

(with the on-Balls relation) to each individual Ball object (with the on-Ball

relation).

Hình 11-8 có một định nghĩa cho thấy sự thuận lợi xa hơn nữa của

sức mạnh diễn đạt của một TMap với quyền lựa chọn sử dụng rõ rang các

mối quan hệ đã đƣợc định nghĩa. Trong vi dụ nay, một chồng các bearing

(góc, phƣơng vị, định hƣớng, có thể nghĩa la ổ trục) đƣợc mô tả. Một

bearing trong ngăn xếp có thể la dƣới (với mối quan hệ trên-0) hoặc trên

(với mối quan hệ trên-1) một đối tƣợng bearing trong ngăn xếp đƣợc định

nghĩa bởi các kiểu cấu trúc DSetOf. Một đối tƣợng bearing bị phân hủy

thanh một Cap – RetainerWithBalls - Base.





Những mối quan hệ của đối tƣợng ở level nay cho thấy rằng Cap thì

ở trên RetainerWithBalls, ma la, lần lƣợt, phia trên Base. Thêm chi tiết cho

thấy rằng một Retainer có (với quan hệ n) một số đối tƣợng

RetainerHoleWithBall. Tập các đối tƣợng RetainerHoleWithBall la độc lập

của nhau, định nghĩa bởi các kiểu cấu trúc ISetOf. Cấu trúc nay cho phép

các mối quan hệ vật lý độc lập về các đối tƣợng trong bộ nay. Ở đây, các

phần khác nhau của bề mặt Cap độc lập quan hệ (với trên-quan hệ Ball) với

mỗi đối tƣợng Ball riêng lẻ (với trên-quan hệ Ball).





As experience is gained with different types of applications, new

reusables emerge for general or specific use. For example, a set of reusables

has been derived to form a higher level set of mechanisms for defining

maps of interruptable, asynchronous, communicating, distributed

controllers. This is essentially a second-order control system (with rules

that parallel the primary control system of the primitive structures) defined

with the formal logic of user-defined structures that can be represented

using a graphical syntax (Exhibit 11-9).

Theo kinh nghiệm đã có đƣợc với các loại khác nhau của ứng dụng,

Resables mới xuất hiện (nổi lên) cho tổng thể hoặc việc sử dụng kĩ thuật. Vi

dụ, một bộ reusables đã đƣợc suy ra để tạo thanh một bộ kĩ thuật, cơ

chế(mechanisms) cấp cao hơn để xác định các bản đồ của interruptable,

không đồng bộ, giao tiếp, phân phối các bộ điều khiển. Điều nay về bản

chất la một hệ thống điều khiển lệnh thứ 2 (a second-order control system)

(với các quy tắc song song với hệ thống điều khiển chinh của các cấu trúc

nguyên thủy) đƣợc định nghĩa theo hình thức logic của cấu trúc xác định

ngƣời dùng, có thể đại diện cho cách sử dụng cú pháp đồ họa (Hình 11-9).





In such a system, each distributed region is cooperatively working

with other distributed regions and each parent controller may interrupt the

children under its control. In this example, the robot controller may apply

an arm controller or a sensor controller. If the arm controller is activated,

the two grippers may concurrently use an Include to hold two ends of some

object. If the sensor controller is activated, a sensor unit uses a Join to sense

some image, followed by an image unit matcher. These reusables can also

be used to manage other types of processes such as those used to manage a

software development environment or a corporation.

Trong hệ thống nhƣ vậy, mỗi vùng đƣợc phân phối đang lam việc

hợp tác với các vùng khác phân phối va mỗi điều khiển parent có thể lam





gián đoạn children dƣới sự kiểm soát của nó. Trong vi dụ nay, bộ điều

khiển robot có thể áp dụng một bộ điều khiển cánh tay hoặc bộ điều khiển

cảm biến. Nếu bộ điều khiển cánh tay(cái arm controller) đƣợc kich hoạt,

hai grippers(chắc la tên 1 bộ phận nao đó của ngƣời máy) đồng thời có thể

sử dụng một Include (không biết danh từ la gì?) để giữ hai đầu của một số

đối tƣợng. Nếu bộ điều khiển cảm biến đƣợc kich hoạt, một đơn vị cảm

biến sử dụng một Join(hợp,nối) để tham gia vao một số hình ảnh, theo sau

la một đơn vị Matcher hình ảnh. Những reusables nay cũng có thể đƣợc sử

dụng để quản lý các loại khác của tiến trình giống nhƣ những cái đó đƣợc

sử dụng để quản lý một môi trƣờng phát triển phần mềm hoặc một tập đoan

The extent to which reuse is provided is a most powerful feature of

DBTF. Everything developed is a candidate — reusable (and inherently

integratable) within the same system, other systems, and these systems as

they evolve. Commonality is ensured simply by using the language. The

designer models the objects and their relationships and the functions and

their relationships; the language inherently integrates these aspects as well

as takes care of making those things that should be objects become objects.

In fact, FMaps are defined in terms of TMaps and use TMaps as reusables,

while TMaps are defined in terms of FMaps and use FMaps as reusables.

Mức độ sử dụng lại đƣợc cung cấp nhƣ la một tinh năng mạnh của

DBTF.Mọi thứ đƣợc phát triển một ứng cử viên - reusable (có thể sử dụng

lại) (va vốn có thể cấu thanh)(inherently integratable) trong cùng một hệ

thống, các hệ thống khác, va các hệ thống nay khi họ phát triển. Sự tƣơng





đồng đƣợc đảm bảo chỉ đơn giản bằng cách sử dụng ngôn ngữ. Các nha

thiết kế các mô hình các đối tƣợng va mối quan hệ của chúng va các chức

năng va các mối quan hệ của chúng; ngôn ngữ vốn có thể cấu thanh các

khia cạnh nay cũng nhƣ bảo đảm lam những điều đó, thứ nên la đối tƣợng

trở thanh đối tƣợng. Trong thực tế, FMaps đƣợc định nghĩa trong điều

khoản của TMaps va TMaps sử dụng nhƣ la reusables, trong khi TMaps

đƣợc định nghĩa trong điều khoản của FMaps va FMaps sử dụng nhƣ la

reusables.

11.8 XEM XÉT THỰC HIỆN

When designing a system environment, it is important to understand

the performance constraints of the functional architecture and to have the

ability to change configurations rapidly. A system is flexible to changing

resource requirements if the functional architecture definition is separated

from its resource definitions.

Khi thiết kế môi trƣờng hệ thống, quan trọng la phải hiểu đƣợc

những thi hanh hạn chế của các kiến trúc chức năng va phải có khả năng

phải thay đổi cấu hình nhanh chóng. Một hệ thống phải linh động trong việc

thay đổi các yêu cầu về tai nguyên nếu việc định nghĩa kiến trúc chức năng

đƣợc tách ra các định nghĩa tai nguyên của nó.

To support such flexibility with the necessary built-in controls, with

DBTF the same language is used to define functional, resource, and





allocation architectures. The meta-language properties of the language can

be used to define global and local constraints for FMaps and TMaps.

Constraints can be defined in terms of FMaps and TMaps. If we place a

constraint on the definition of a function (e.g., Where F takes between two

and five seconds), then this constraint influences all functions that use this

definition. Such a constraint is global with respect to the uses of F.

Để hỗ trợ tinh linh hoạt nhƣ vậy với sự cần thiết đƣợc xây dựng

trong sự điều khiển, với DBTF cùng một ngôn ngữ đƣợc sử dụng để xác

định chức năng, nguồn tai nguyên, va kiến trúc phân bổ. Những tinh chất

siêu ngôn ngữ của ngôn ngữ có thể đƣợc sử dụng để xác định những hạn

chế trên toan cục va cục bộ cho FMaps va TMaps. Những rang buộc có thể

đƣợc xác định trong điều khoản của FMaps va TMaps. Nếu chúng ta đặt ra

một sự rang buộc về định nghĩa của một chức năng(ham) (vi dụ, ở đâu F

mất từ hai đến năm giây), sau đó rang buộc nay ảnh hƣởng đến tất cả các

chức năng (ham) sử dụng định nghĩa nay. Đó la một hạn chế toan cục đối

với việc sử dụng của F

A global constraint of a definition may be further constrained by a

local constraint placed in the context of the definition using that definition;

e.g., when function G uses F, where F takes six seconds (not two to five

seconds). The validity of constraints and their interaction with other

constraints can be analyzed by static or dynamic means. The property of

being able to trace an object throughout a definition supports this type of

analysis and provides the ability to collect information on an object as it





transitions from function to function. As a result, one can determine the

direct and the indirect effects of functional interactions of constraints.

Một rang buộc toan cục của một định nghĩa có thể đƣợc thêm hạn

chế bởi một hạn chế của cục bộ, đặt trong bối cảnh của việc định nghĩa

bằng cách sử dụng định nghĩa đó; vi dụ, khi chức năng G sử dụng F, nơi ma

F mất sáu giây (không phải 2-5 giây). Thời hạn hiệu lực của các rang buộc

va sự tƣơng tác của chúng với những rang buộc khác có thể đƣợc phân tich

bằng phƣơng pháp tĩnh hoặc động. Các tinh chất (thuộc tinh) của việc có

thể truy dấu vết một đối tƣợng trong suốt một định nghĩa hỗ trợ các loại

phân tich nay va cung cấp khả năng thu thập thông tin trên một đối tƣợng

khi nó chuyển tiếp giữa các chức năng(các ham)(từ các chức năng đến chức

năng). Kết quả la, ngƣời ta có thể xác định những ảnh hƣởng trực tiếp va

gián tiếp của sự tƣơng tác chức năng(ham) của các rang buộc

11.9 HÕA HỢP VỚI HỆ THỐNG HƢỚNG ĐỐI TƢỢNG

A DBTF system is by nature an inherent integration of function

(including timing) and object orientation from the beginning, i.e., it is a

system-oriented object. The definition space is a set of real-world objects,

defined in terms of FMaps and TMaps.

Một hệ thống DBTF la do sự thống nhất bản chất vốn có của chức

năng (ham) (bao gồm cả thời gian) va sự định hƣớng đối tƣợng từ đầu,

nghĩa la, nó la một hệ thống theo hƣớng đối tƣợng. Không gian định nghĩa





la một tập các đối tƣợng trong thế giới thực, đƣợc xác định trong điều

khoản của FMaps va Tmaps

Objects, instantiations of TMaps, are realized in terms of OMaps. An

execution, which is an instantiation of an FMap, is realized in terms of an

EMap. Definitions are independent of a particular implementation — e.g.,

building block definitions with a focus on objects are independent of

particular object-oriented implementations. Properties of classical object-

oriented systems such as inheritance, encapsulation, polymorphism, and

persistence are supported with the use of generalized functions on OMaps

and TMaps.

Đối tƣợng, instantiation(sự thuyết minh(cai đặt)) của TMaps, đƣợc

thực hiện trong điều khoản của OMaps. Sự thực hiện, đó la một

instantiation của một FMap, đƣợc thực hiện trong điều khoản của một

EMap. Định nghĩa thì độc lập với một việc thi hanh cụ thể - vi dụ nhƣ, xây

dựng các định nghĩa block với một sự tập trung vao đối tƣợng thì độc lập

đối với sự thi hanh riêng của hƣớng đối tƣợng. Tinh chất kinh điển (cổ

điển) của hƣớng đối tƣợng nhƣ sự thừa kế, đóng gói, đa hình, va cứng

nhắc(bền bỉ,cố chấp) đƣợc cung cấp với việc sử dụng các chức năng tổng

quát về OMaps va TMaps.

The DBTF approach derives from the combination of steps taken to

solve the problems of the traditional ―after the fact‖ approach. Collective

experience strongly confirms that quality and productivity increase with the





increased use of DBTF properties. A major factor is the inherent reuse in

these systems, culminating in ultimate reuse, which is either inherent or

automation itself.

Cách tiếp cận DBTF xuất phát từ sự kết hợp của các bƣớc thực hiện

để giải quyết những vấn đề của phƣơng pháp tiếp cận truyền thống "sau cơ

sở lập luận‖ (after the fact). Tập hợp kinh nghiệm vững chắc cho thấy rằng

chất lƣợng va tăng năng suất tăng lên với việc sử dụng tinh chất DBTF.

Một yếu tố chủ yếu la tái sử dụng cái vốn có trong các hệ thống nay, ma

đỉnh cao nhất la trong tái sử dụng cuối cùng, đó la hoặc cố hữu hoặc tự

động hóa của chinh nó.

From FMaps and TMaps, any kind of system can be automatically

developed, resulting in complete, integrated, and production-ready target

system code and documentation. This is accomplished by the 001 Tool

Suite, an automation of the technology. The tool suite also has a means to

observe the behavior of a system as it is evolved and executed in terms of

OMaps and EMaps.

If asked if there were a way to develop any kind of software with:

• Seamless integration, including systems to software

• Correctness by built-in language properties

• No interface errors





• Defect rates reduced by a factor of ten

• Guarantee of function integrity after implementation

• Complete traceability and evolvability (changing applications,

archi-tectures, and technologies)

• Full life cycle automation

• No manual coding

• Maximized reuse including that which is automated or inherent

• Minimum time and minimum effort

• A tool suite

Từ FMaps va TMaps, bất kỳ loại hệ thống có thể đƣợc tự động phát

triển, kết quả hoan thanh, tich hợp, va sản xuất-mã sẵn sang hệ thống đich

va tai liệu. Điều nay đƣợc hoan thanh bởi bộ công cụ 001 (001 Tool Suite),

sự tự động hóa của công nghệ. Các bộ công cụ nay cũng có một phƣơng

tiện để quan sát hanh vi của một hệ thống nhƣ la nó đƣợc phát triển va thực

hiện trong điều khoản của OMaps va EMaps.

Nếu đƣợc hỏi nếu có một cách thức để phát triển bất kỳ loại phần mềm với:

• Sự hợp nhất liền lạc, bao gồm hệ thống phần mềm





• Sự đúng đắn trong các tinh chất của ngôn ngữ đƣợc xây dựng

• Không có lỗi giao diện

• Thiếu số giảm gấp mƣời

• Bảo đảm tinh toan vẹn chức năng sau khi thực hiện

• Bổ sung dấu vết(nguồn gốc)va tiến hóa (khi thay đổi các ứng

dụng, kiến trúc, va công nghệ)

• Cuộc sống đầy đủ chu kỳ tự động hóa

• Không mã hóa (code) bằng tay

• Tối đa hóa việc tái sử dụng bao gồm rằng đó la tự động hoặc

không tách ra đƣợc (cố hữu)

• Tối thiểu thời gian va tối thiểu công sức (nỗ lực)

• Một công cụ bộ

— all defined and automatically generated by itself, most people

would say this is impossible, at least in the foreseeable future. This is not

impossible; in fact, it is possible today with the 001 systems design and

software development environment (Exhibit 11-10 contains a summary that

compares the traditional ―after the fact‖ environment with a DBTF





environment). Why can it do what it does? It is not magic. Simply put, it is

because this environment automates and is based on the Development

Before The Fact paradigm.

- Tất cả các quy định va tự động tạo ra bởi chinh nó, hầu hết mọi

ngƣời sẽ nói điều nay la không thể, it nhất la trong tƣơng lai gần. Điều nay

không phải la không thể trong thực tế, có thể hôm nay với thiết kế hệ thống

001 va môi trƣờng phát triển phần mềm (hình 11-10 có chứa một bản tóm

tắt so sánh truyền thống "sau khi thực tế‖ (―after the fact‖) môi trƣờng với

môi trƣờng DBTF). Tại sao nó có thể lam những gì nó lam? Nó không phải

la kỳ diệu. Một cách đơn giản, đó la vì môi trƣờng nay tự động hóa va đƣợc

phát triển dựa trên mẫu ―sự phát triển trƣớc thực tế‖ (Development Before

The Fact)

Traditional (After the Fact) DBTF (Before the Fact)

Integration ad hoc, if at all

~Mismatched methods, objects,

phases, products architectures,

applications, and environment

~System not integrated(thống

nhất,nhóm lại) with software

~Function oriented or object

Integration

~Seamless life cycle: methods,

objects, phases products,

architectures, applications, and

environment

~System integrated(thống nhất, hợp

nhất) with software





oriented

~GUI not integrated with

application

~Simulation not integrated with

software code

~System oriented objects:

integration of function, timing, and

object oriented

~GUI integrated with application

~Simulation integrated with

software code

Behavior uncertain until after

delivery

Correctness by built-in language

Interface errors abound and infiltrate

the system (over 75% of all errors)

~Most of those found are found

after implementation

~Some found manually

~Some found by dynamic runs

analysis

~Some never found

No interface errors

~All found before implementation

~All found by automatic and static

analysis

~Always found

Ambiguous requirements, Unambiguous requirements,





pecifications, designs introduce

chaos, confusion and complexity

~Informal or semi-formal language

~Different phases, languages and

tools

~Different language for other

systems than for Software

specifications, designs remove

chaos, confusion, and complexity

~Formal, but friendly language

~All phases, same language and

tools

~Same language for software,

hardware and any other system

No guarantee of function integrity

after implementation

Guarantee of function integrity after

implementation

Đảm bảo tinh toan vẹn của công

thức

Inflexible: Systems not traceable or

evolvable

~Locked in bugs, requirements

products, architectures, etc.

~Painful transition from legacy

~Maintenance performed at code

Flexible: (linh động) Systems

traceable and evolvable

~Open architecture

~Smooth transition from legacy

~Maintenance performed at

specification level





level

Reuse not inherent

~Reuse is ad hoc

~Customization and reuse are

mutually exclusive

Inherent Reuse

~Every object a candidate for reuse

~Customization increases the reuse

pool

Automation supports manual

process instead of doing real work

~Mostly manual: documentation,

programming, test generation,

traceability, integration

~Limited, incomplete, fragmented,

disparate, and inefficient

Automation does real work

~Automatic programming,

documentation, test generation,

traceability, integration

~100% code automatically

generated for any kind of software

Product x not defined and developed

with itself

001 defined with and generated by

itself

~#1 in all evaluations

Dollars wasted, error prone systems

~High risk

Ultra-reliable systems with

unprecedented productivity in their





~Not cost effective

~Difficult to meet schedules

~Less of what you need and more of

what you don t need

development

~Low risk

~10 to 1, 20 to 1, 50 to 1 dollars sa

ved/dollars made

~Minimum time to complete

~No more, no less of what you need

Cách truyền thống DBTF

Sự phân tich ad hoc, nếu ở tất cả

~Phƣơng pháp ghép đôi, đối tƣợng,

giai đoạn, kiến trúc sản phẩm, ứng

dụng, va môi trƣờng

~Hệ thống không thống nhất với

phần mềm

~Hƣớng chức năng hay hƣớng đối

tƣợng

Sự phân tich

~Vòng sự sống: phƣơng pháp, đối

tƣợng, giai đoạn sản phẩm, kiến

trúc, những ứng dụng va môi trƣờng

~ Hệ thống thống nhất với phần

mềm

~Hệ thống hƣớng đối tƣợng: thống

nhất chức năng, thời gian, va hƣớng





~GUI không thống nhất với ứng

dụng

~Sự mô phỏng thì không thống nhất

với code phần mềm

đối tƣợng

~GUI thống nhất với ứng dụng

~Sự mô phỏng thống nhất với code

phần mềm

Trạng thái không chắc chắn cho đến

khi phân phối

Việc sửa lỗi bằng ngôn ngữ xây

dựng

Lỗi giao diện Interface còn tồn tại

nhiều va xâm phạm đến hệ thống

(hơn 75% của tất cả các lỗi)

~Most of those found are found after

implementation (thực thi)

~Một số lỗi đƣợc tìm bằng tay

~một số tìm bằng cách phân tích

động

~Một số không bao giờ đƣợc tìm

thấy

Không có lỗi giao diện

~Tất cả đƣợc tìm thấy trƣớc khi thi

hành

~Tất cả đƣợc tìm thấy tự động va

phân tich tĩnh

~Luôn tìm đƣợc tất cả

Yêu cầu mơ hồ, không cụ thể, theo

hƣớng thiết kế hỗn loạn, rắc rối va

Yêu cầu không mơ hồ, cụ thể, thiết

kế specifications, rơ bỏ thiết kế hỗn





phức tạp

~Ngôn ngữ không trang trọng, hoặc

bán trang trọng

~Các công cụ va ngôn ngữ khác

nhau ở các giai đoạn khác nhau

~Khác ngôn ngữ cho những hệ

thống khác nhau cho phần mềm

loạn, rắc rối va phức tạp

~Ngôn ngữ trang trọng, nhƣng thân

thiện

~Tất cả giai đoạn có cùng các ngôn

ngữ va công cụ

~Cùng ngôn ngữ cho phần mềm,

phần cứng va những hệ thống khác

Không đảm bảo tinh toan vẹn của

công thức

Đảm bảo tinh toan vẹn của công

thức

Không linh động: Các hệ thống

không thể truy vết va không thể tiến

hóa

~Bị khóa trong bugs, yêu cầu sản

phẩm, kiến trúc, etc.

~Khó chuyển đổi từ kế thừa

~Bảo trì ở mức độ code

Linh động: có thể truy vết va tiến

hóa

~Kiến trúc mở

~Chuyển đổi dễ từ kế thừa

~ Bảo trì ở mức độ kĩ thuật

Không dùng lại đƣợc Thửa hƣởng dùng lại





~Dùng lại ad hoc

~Chỉnh sửa va tái sử dụng thì riêng

biệt nhau

~Mỗi đối tƣợng đều có thể dùng lại

~Chỉnh sửa lam tăng tinh tái sử

dụng

Tự động hóa hỗ trợ quá trình bằng

tay thay vì lam công việc thực sự

~ Hầu hết lam bằng tay: tai liệu,

chƣơng trình, kiểm tra chung, kiểm

tra thế hệ, khả năng truy vết, sự phân

tích

~Hạn chế, không hoan chỉnh, không

đầy đủ, phân mãnh, Limited,

incomplete, fragmented, tạm nham,

va không hiệu quả

Sự động lam việc thật

~ Tự động ở chƣơng trình, tai liệu,

kiểm tra thế hệ, khả năng truy vết,

sự phân tich

~100% code tự động tạo ra cho

nhiều loại phần mềm

Sản phẩm x không đƣợc tự định

nghĩa va phát triển

001 đƣợc tự định nghĩa va tạo ra

~#1 trong sự ƣớc lƣợng

Lãng phi nhiều đô la, hệ thống nhiều

lỗi

~Rủi ro cao

Hệ thống tin cậy va năng suất sản

phẩm cao trong sự phát triển

~Rủi ro thấp





~Không hiệu quá

~Khó đáp ứng lịch trình

~Ít hơn cái bạn cần va nhiều hơn cái

bạn không cần

~10 - 1, 20 tới 1, 50 - 1 Đô la tiết

kiệm trên những đô la đƣợc lam ra

~Thời gian tổi thiếu để hoan thanh

~Không nhiều, không it hơn cái bạn

cần

Note:

001, 001 Tool Suite, DBTF, Development Before the Fact,

FunctionMap, FMap, TypeMap, TMap, ObjectMap, OMap, RoadMap,

RMap, ExecutionMap, EMap, RAT, System Oriented Object, SOO,

001AXES, are all trademarks of Hamilton Technologies, Inc.

Selected Bibliography (Nguồn tham khảo)

Hamilton, M. (1986). Zero-defect software: the elusive goal, IEEE

Spectrum, 23, 48–531986.

Hamilton, M. and Hackler, R. (1990). 001: a rapid development

approach for rapid prototyping based on a system that supports its own life

cycle, IEEE Proc.1st Int. Workshop Rapid Sys. Prototyping, Research

Triangle Park, NC, June 4, 1990.





Hamilton, M. and Hackler, W.R. (in press). System Oriented

Objects: Development Before the Fact

Hamilton, M. and Hackler, W.R. (2000). Towards cost effective and

timely end-to-end testing, HTI, prepared for Army Research Laboratory,

Contract No. DAKF11-99-P-1236.

Hamilton, M. (1994). Inside Development Before the Fact, Electron.

Design, 31.

Hamilton, M. (1994). Development Before the Fact in action,

Electron. Design, (ESSoftware Engineering Tools Experiment-Final

Report, Vol. 1, Experiment Summary, Table 1, p. 9, Department of

Defense, Strategic Defense Initiative, Washington, D.C.)

Hornstein, R. and Hamilton, M. (in preparation). Realizing the

potential for COTS utilization: creating and assembling reusable

components right the first time, NASA, Washington, D.C., Hamilton

Technologies, Inc., Cambridge, MA.

Krut, Jr., B. (1993). Integrating 001 tool support in the feature-

oriented domain analysis methodology (CMU/SEI-93-TR-11, ESC-TR-93-

188), Pittsburgh, Software Engineering Institute, Carnegie Mellon

University.





Ouyang, M. and Golay, M.W. (1994). An integrated formal approach

for developing high quality software of safety-critical systems,

Massachusetts Institute of Technology, Cambridge, MA, Report No. MIT-

ANP-TR-035.

001 Tool Suite. Hamilton Technologies, Inc. Version 3.3.1 (1986-

2002) [www. htius.com]




Chương 12: Bản đặc tả thiết kế 443

CHƢƠNG 12 BẢN ĐẶC TẢ THIẾT KẾ

Người dịch:


2. Lê Anh Dũng


4. Lê Văn Huy


The process of information systems development must pass through

a number of distinct phases in order to be successful. This process is





commonly known as the systems development life cycle (SDLC) and the

design specification is an essential and integral component of it. Design

specifications are blueprints showing what to build and how to build it.

Quy trình phát triển hệ thống thông tin phải qua một số bƣớc riêng

biệt để hoan thiện. Quá trình nay thƣờng đƣợc biết đến với tên Chu trình

phát triển hệ thống (System Development Life Cycle – SDLC) va bản đặc

tả thiết kế la một phần cần thiết va không thể thiếu trong đó. Bản đặc tả

thiết kế la những bản thiết kế cho biết phải lam cái gì va lam nhƣ thế nao.

12.1 QUY TRÌNH

By the time the systems designer comes to the design phase of the

system life cycle, he or she has a pretty clear understanding of what the new

system should do and why. This information is recorded in several

documents:

The feasibility study discusses the pros, cons, and costs of building

the system (see Appendix C).

The project plan provides preliminary information about the project,

its mission and goals, its schedule, and its cost estimate (see Appendix F).

The system requirements specification (SRS) contains detailed

information about the requirements of the system (see Appendix G).





Khi ngƣời thiết kế hệ thống đi đến bƣớc thiết kế trong Chu trình phát

triển hệ thống, ông ta/ba ta có một hiểu biết khá rõ rang rằng hệ thống mới

phải lam gì va tại sao. Những thông tin nay đƣợc ghi lại trong một số tai

liệu:

Bản nghiên cứu tinh khả thi nói đến thuận lợi, bất lợi, chi phi để xây

dựng hệ thống (xem Phụ lục C).

Bản kế hoạch dự án cung cấp thông tin sơ bộ về dự án, nhiệm vụ va

mục tiêu của nó, thời gian biểu, chi phi dự kiến của nó (xem Phụ lục F)

Bản đặc tả yêu cầu hệ thống (System Requirements Specification –

SRS) chứa những thông tin chi tiết về yêu cầu hệ thống (xem Phụ lục G)

In spite of this detailed documentation, there may still be some

uncertainty regarding future capabilities of the new system due to the

different and changing perspectives of the end users and other stakeholders.

Different people will see different possibilities for the new system, which is

why a push to propose alternative solutions may take place. The designer

must then consider the different views, covering all structured

requirements, and transform them into several competing design strategies.

Only one design will eventually be pursued.





Dù đã có những tai liệu chi tiết nay, vẫn có thể có vai điều không

chắc chắn về những khả năng tƣơng lai của hệ thống mới do những góc

nhìn khác nhau va thay đổi từ ngƣời dùng cuối va những bên liên quan.

Những ngƣời khác nhau sẽ nhìn thấy những triển vọng khác nhau cho hệ

thống mới, chinh la li do tại sao ngƣời ta cố gắng đƣa ra những giải pháp

khác nhau. Ngƣời thiết kế sau đó phải xem xét dƣới những góc nhìn khác

nhau, bao gồm mọi yêu cầu đã đƣợc cấu trúc hoá, va chuyển chúng thanh

một vai chiến lƣợc thiết kế có tinh cạnh tranh. Cuối cùng, chỉ một bản thiết

kế đƣợc chọn.

12.2 CHI TIẾT BẢN THIẾT KẾ

A variety of models were used in the analysis phase to help create a

high-level process model. These tools, which include data flow diagrams

(Exhibit 12-1), entity relationship diagrams (Exhibit 12-2), and state

transition diagrams (Exhibit 12-3), are invaluable in producing program

specifications as the move is made from logical models toward the physical

design of the system.

Nhiều mẫu khác nhau đƣợc dùng trong bƣớc phân tich để tạo ra một

mẫu cấp cao. Những công cụ nay, bao gồm những sơ đồ luồng dữ liệu (thể

hiện trong hình 12-2), va những sơ đồ chuyển đổi trạng thái (thể hiện trong

hình 12-3), đƣợc dùng để tạo ra các đặc tả kĩ thuật cho chƣơng trình khi

chuyển từ mẫu logic sang mẫu cai đặt trên hệ thống.





Newcomers to the field often insist that analysis tools and

deliverables be different from the design phase tools and deliverables. More

commonly, many of the modeling tools and techniques used in the analysis

phase are also used during the design stage. In addition, there is definitely

an overlap between information contained within the SRS and information

contained within the SDS. For example, when developing structured

systems, analysts frequently use the DFD to describe the flow of

information throughout the system for the analysis phase — the logical

DFD. A more detailed set of DFDs is then created for the design phase —

the physical DFD. The same can be said for ERDs, STDs, data dictionaries,

and even process specifications.

Những ngƣời mới tiếp xúc với lĩnh vực nay thƣờng cho rằng những

công cụ phân tich va các thanh phần chuyển giao la khác với ở bƣớc thiết

kế. Thông thƣờng hơn, nhiều công cụ va kĩ thuật thiết kế mô hình đƣợc sử

dụng trong bƣớc phân tich cũng đƣợc dùng trong giai đoạn thiết kế. Thêm

vao đó, hẳn la có những phần giao nhau giữa thông tin chứa trong SRS va

thông tin của SDS. Vi dụ, khi phát triển một hệ thống có cấu trúc, các nha

phân tich thƣờng dùng sơ đồ luồng dữ liệu (Data Flow Diagram – DFD) để

mô tả luồng thông tin chuyển qua hệ thống trong bƣớc phân tich – gọi la sơ

đồ luồng dữ liệu logic. Một tập hợp các DFD chi tiết hơn sau đó đƣợc dùng

trong bƣớc thiết kế - bản DFD vật li. Cũng tƣơng tự nhƣ vậy đối với ERD,

STD, từ điển dữ liệu, thậm chi la các đặc tả của quy trình.





Hình 12-2





The DFD provides a good example of how a document created

originally during the analysis phase can be expanded during the design

phase. In the analysis phase a DFD is developed that shows a conceptual —

or context — view of the system as shown in Exhibit 12-4. The Level 0

diagram serves as a ―table of contents‖ for subsequent DFDs. Note that it

shows a generic ―0‖ process with attendant data flows.

Những bản DFD cung cấp một vi dụ rất tốt về cách một tai liệu đƣợc

tạo ra trong bƣớc phân tich, có thể đƣợc mở rộng nhƣ thế nao trong bƣớc

thiết kế. Trong bƣớc phân tich, một bản DFD đƣợc phát triển để thể hiện

một góc nhìn mang tinh khái niệm – hay la ngữ cảnh – của hệ thống nhƣ

trong hình 12-4. Sơ đồ cấp 0 đóng vai trò nhƣ la ―mục lục‖ của cho những

DFD sau. Chú ý rằng nó biểu diễn một quy trình có ―0‖ luồng dữ liệu kèm

theo.





Hình 12-3

When drawing a DFD, a top–down approach is the most effective.

Steps include (Kendall, 2002):

Develop a list of typical business activities and use it to determine

external entities, data flows, processes, and data stores.





Draw a context diagram that depicts external entities and data flows

to and from the system. The context diagram should be abstract — i.e., do

not show any detailed processes or data flows.

Khi vẽ một bản DFD, hƣớng tiếp cận từ trên xuống (top-down) là

hiệu quả nhất. Các bƣớc bao gồm (theo Kendall, 2002):

Phát triển 1 danh sách các hoạt động nghiệp vụ điển hình va dùng nó

để xác định các thực thể ngoai, luồng dữ liệu, các quy trình, va kho dữ liệu.

Vẽ ra một sơ đồ ngữ cảnh thể hiện các thực thể ngoai va luồng dữ

liệu từ hệ thống. Sơ đồ ngữ cảnh nên la trừu tƣợng – vi dụ, không thể hiện

những quy trình chi tiết hay luồng dữ liệu

Now draw diagram 0, which can be likened to a table of contents.

Diagram 0 is the next level of detail when using a top–down approach. As

we move down the hierarchy, we move from abstract and less detailed to

more detailed and more concrete.

Create a child diagram for each process depicted in diagram 0.

Check for any errors and make sure the labels assigned to processes

and data flows are logical and meaningful.

Now develop a physical data flow diagram from the logical data flow

diagram.





Partition the physical data flow by separating the parts of the

diagram to facilitate programming and implementation.

Tiếp theo vẽ sơ đồ cấp 0, giống nhƣ một mục lục. Sơ đồ cấp 0 la cấp

chi tiết kế tiếp khi sử dụng cách tiếp cận từ trên xuống. Khi chúng ta dần

xuống cây thừa kế, chúng ta đi từ cấp trừu tƣợng, xuống cấp it chi tiết đến

nhiều chi tiết rồi cụ thể hơn.

Tạo một sơ đồ con cho mỗi quy trình đƣợc thể hiện trong sơ đồ cấp 0

Kiểm tra mọi lỗi va bảo đảm rằng các nhãn đƣợc gắn cho các quy

trình va luồng dữ liệu la logic va có nghĩa.

Phát triển luồng dữ liệu vật lý từ luồng dữ liệu logic.

Phân vùng luồng dữ liệu vật li bằng cách phân chia các phần của sơ

đồ để dễ lập trình va cai đặt.

In the design phase the designer analyzes the DFD and determines

how the data processes can be segregated into groups, each associated with

a type of process, as shown in Exhibit 12-5. Note that now far more detail is

specified.

Trong bƣớc thiết kế, ngƣời thiết kế phân tich bản DFD va xác định

cách các xử li dữ liệu đƣợc phân tách thanh các nhóm, mỗi nhóm gắn với





một kiểu xử li, nhƣ trong hình 12-5. Chú ý rằng giờ đây nhiều chi tiết cụ

thể hơn đƣợc thể hiện.





Hình 12-4





Hình 12-5





Hình 12 – 6: Chi tiết tiến trình

Tiến trình #1

Tên: (Đăng nhập)

Số: 1





Tên: Đăng nhập

Mô tả: Những ngƣời lấy bai kiểm tra đã đăng ký sẽ đăng nhập vao tai

khoản của họ với tên đăng nhập va tai khoản của họ thông qua tiến trình

nay. Họ không cần phải đăng ký một lần nữa. Một khi đã đăng nhập, họ có

thể truy cập vao chủ đề bai kiểm tra của mình va sau đó có thể lấy bai kiểm

tra.

Dữ liệu nhập: tên ngƣời dùng va mật khẩu từ ngƣời lấy bai kiểm tra,

tên ngƣời dùng va mật khẩu lấy từ bảng đăng ký.

Dữ liệu xuất: tên ngƣời dùng đến cookie

Kiểu tiến trình: kiểm tra thủ công

Logic tiến trình:

Lấy tên đăng nhập và mật khẩu từ người dùng

if đúng then

Cho phép người dùng lấy bài kiểm tra

else

thông báo lỗi





endif

Key functions of each group are determined and these functions are

then broken down (i.e., decomposed) in order to obtain cohesive modules.

Each module is then specified separately (i.e., the process specification or

PSPEC), as shown in Exhibit 12-6, to ensure that data collections are

recorded, and that data produced by the modules corresponds to the data

passed between processes in the data flow diagrams.

Những chức năng khóa của mỗi nhóm đƣợc xác định va sau đó đƣợc

chia nhỏ (vd: phân tích – decomposed) nhẳm đạt đƣợc những module liên

kết. Những module sau đó đƣợc ghi chú chi tiết một cách tách biệt (vd: chi

tiết kỹ thuật tiến trình hoặc PSPEC), nhƣ trong hình 12 – 6, để chắc rằng

những bộ dữ liệu thu thập đƣợc ghi lại, va những dữ liệu đó đƣợc sinh ra

bởi module tƣơng ứng với dữ liệu đƣợc truyền qua giữa các tiến trình trong

sơ đồ luồng dữ liệu.

DFDs are very flexible and are used during the analysis and design

phases. As discussed, you may draw logical or physical DFDs. The logical

set of DFDs diagrams how a business operates and details its business

activities. Logical DFDs show collections of data but not the detail of how

that data is stored or where it is stored. On the other hand, a physical set of

DFDs tries to diagram exactly how the system will or does operate.





Physical DFDs show programs, databases, and other information necessary

for the implementation of a particular system.

Những sơ đồ luồng dữ liệu rất linh động va đƣợc sử dụng suốt giai

đoạn phân tich va thiết kế. Nhƣ đã ban, bạn có thể vẽ những sơ đồ luồng dữ

liệu logic hay vật lý. Tập logic của những sơ đồ luồng dữ liệu cho thấy

cộng việc đƣợc thực hiện nhƣ thế nao va chi tiết những hoạt động của công

việc đó. Tập logic nay cho thấy những bộ dữ liệu nhƣng không nói chi tiết

lam cách nao những dữ liệu nay đƣợc lƣu trữ va lƣu trữ ở đâu. Mặt khác,

tập vật lý của sơ đồ luồng dữ liệu cố gắng mô tả chinh xác hệ thống hoạt

động nhƣ thế nao. Tập vật lý nay cho thấy những chƣơng trình, cơ sở dữ

liệu, va những thông tin cần thiết khác cho sự triển khai của một hệ thống

đặc thù.

Designers must obtain a deep appreciation of the system and its

functions because the production of a modular structural chart is not a

mechanical task (Curtis et al., 2000).

Những ngƣời thiết kế phải đạt đƣợc sự đánh giá sâu về hệ thống va

những chức năng của nó vì sự tạo ra những biểu đồ cấu trúc module không

phải la công việc kỹ thuật (Curtis et al.,2000).





12.3 THIẾT KẾ LOGIC VÀ VẬT LÝ

Design consists of two discrete steps: logical design and physical

design. To understand the components of each it is necessary to discuss

logical and physical analysis.

Thiết kế gồm có 2 bƣớc rời rạc: thiết kế logic va thiết kế vật lý. Để

hiểu về thanh phần của mỗi bƣớc cần phải nói về sự phân tich logic va vật

lý.

Phân tich logic va vật lý

12.3.1 Phân tich logic va vật lý

The physical analysis phase requires the systems analyst to

determine the specifics of the existing processes that the system will

automate, whether these processes are currently part of a technology system

or are completely manual. Physical analysis involves the process of

determining, in specific detail, exactly who does what and when he or she

does it in the process or problem being solved (Curtis et al., 2000). This

analysis shows what is really going on in the system, and helps the systems

analyst put some structure around the new system‘s requirements.

Công đoạn phân tich vật lý yêu cầu ngƣời phân tich hệ thống phải

xác định chi tiết những tiến trình hiện có của hệ thống sẽ đƣợc tự động hóa,





cho dù những tiến trình nay la một phần công nghệ hay hoan toan thủ công.

Sự phân tich vật lý liên quan đến việc xác định, trong chi tiết kĩ thuật, một

cách chinh xác rằng ai lam cái gì va khi nao anh (cô) ta lam việc đó trong

tiến trình hoặc vấn đề đang đƣợc giải quyết (Curtis et all.,2000). Sự phân

tich nay cho thấy cái gì đang thực sự diễn ra trong hệ thống va giúp ngƣời

phân tich hệ thống đặt vai cấu trúc xung quanh những yêu cầu của hệ thống

mới.

Physical analysis occurs after the initial round of interviews with

stakeholders and end users. At this point in the process, the systems analyst

is likely to have an unwieldy batch of interview notes, details of

observations, questionnaire responses, and sundry documents (Curtis et al.,

2000). This information provides the basis for building a methodical

description of the existing manual system. Building this description is the

foundation of physical analysis. This work is considered physical analysis

because the ultimate result of this work is a very nuts-and-bolts description

of the actual (manual) steps and processes comprising the system, with little

to no logical abstraction.

Sự phân tich vật lý có ở giai đoạn đầu của việc phỏng vẫn những

stakeholder va ngƣời dùng cuối.Lúc nay, ngƣời phân tich hệ thống giống

nhƣ có một quyển ghi chú phỏng vấn không dễ dang, những quan sát chi

tiết, bản trả ời câu hỏi, va những tai liệu lặt vặt. Những thông tin nay la nền

tảng cho việc xây dựng một mô tả có phƣơng pháp của hệ thống thủ công





hiện tại. Xây dựng mô tả nay la cơ sở cho sự phân tich vật lý. Công việc

nay đƣợc xem nhƣ la phân tich vật lý bởi vì kết quả cuối cùng la một mô tả

rất chặt chẽ của những bƣớc (thủ công) thật sự va các tiến trình bao gồm

trong hệ thống, với một it hoặc không có sự trừu tƣợng logic nao.

A primary vehicle for accomplishing the physical analysis phase is

the manual system flowchart. This chart is very much like the process

flowcharts that many people are familiar with, with some minor changes.

The chart is structured in such a way that it is apparent which department,

organization, or person owns each task, as shown in Exhibit 12-7.

Phƣơng tiện chinh để hoan thanh giai đoạn phân tich vật lý la một

lƣu đồ hệ thống thủ công. Biểu đồ nay rất giống với những lƣu đồ ma nhiều

ngƣời quen thuộc, với một vai thay đổi nhỏ. Sơ đồ nay đƣợc cấu trúc theo

cái cách hiển nhiên ma công việc của những cơ quan, tổ chức, hoặc cá

nhân, đƣợc trình bay(Hình 12 – 7).

As you can see, this is a very detailed and physically oriented

diagram, showing the passage of documents and data through very specific

checkpoints. This provides the data presentation required in order to gain

the required level of understanding of the system as it exists, but you could

not develop a system from this picture; a logical diagram is required for

that.





Nhƣ bạn có thể thấy, đây la một biểu đồ rất hƣớng chi tiết va vật lý,

cho thấy những đoạn của tai liệu va dữ liệu thông qua những checkpoint rất

chi tiết. Cái nay cung cấp sự trình bai dữ liệu để đạt đƣợc mức yêu cầu thấu

hiểu hệ thống nhƣ la nó đang tồn tại, nhƣng bạn không thể phát triển hệ

thống từ tấm hình nay, một sơ đồ logic la cần thiết cho chuyện đó.

The logical analysis phase is focused on abstracting the details

uncovered during physical analysis out to a level of logical representation,

which will allow them to be manipulated. Logical analysis produces the

ultimate result of the systems analysis process: the decomposition of the

functions of the system into their logical constituents and the production of

a logical model of the processes and data flows (Curtis et al., 2000).

Giai đoạn phân tich logic tập trung vao sự trừu tƣợng những chi tiết

không đƣợc bao gồm trong sự phân tich vật lý, cái ma sẽ cho phép chúng

đƣợc thao tác. Phân tich logic cho kết quả cuối cùng của tiến trình phân tich

hệ thống la: sự phân tách những chức năng thanh các thanh phần logic của

chúng va sự sản xuất một mẫu logic của những tiến trình va những luồn dữ

liệu (Curtis et al., 2000).

As the systems analyst and end user work through the flowcharts

produced from the physical analysis and the preliminary logical model

based upon it, the goal should be to jointly produce a detailed written

description of all activities within the end user‘s purview that fall within the





scope of the system (Bloor and Butler, 1989). The systems analyst and the

end user must agree that this list is complete and precise. The entries in the

list should be mutually exclusive and the list must be comprehensively

exhaustive. Combined with the manual system flowcharts and logical

diagrams, this list will serve as basic system requirements. Ultimately a

detailed system requirements specification will be created (see Appendix

G). With these documents in hand, the design phase can begin.

Khi ngƣời phân tich va ngƣời dùng lam việc thông qua các lƣu đồ

đƣợc tạo ra từ phân tich vật lý va các mô hình logic sơ bộ dựa trên nó, mục

tiêu nên đƣợc để cùng nhau tạo ra một mô tả chi tiết bằng văn bản của tất cả

các hoạt động trong tầm hiểu biết của ngƣời dùng cuối ma rơi vao phạm vi

của hệ thống (Bloor and Butler, 1989). Các nha phân tich hệ thống va ngƣời

dùng cuối phải đồng ý rằng đây la danh sách đầy đủ va chinh xác. Các mục

trong danh sách cần riêng biệt va danh sách nay phải đƣợc đầy đủ một cách

toan diện. Kết hợp với hệ thống các lƣu đồ thủ công va sơ đồ logic, danh

sách nay sẽ phục vụ nhƣ la những yêu cầu hệ thống cơ bản. Cuối cùng một

hệ thống các yêu cầu đặc điểm kỹ thuật chi tiết sẽ đƣợc tạo ra. Với các tai

liệu nay trong tay, giai đoạn thiết kế có thể bắt đầu.

The analysis phase was broken down into two components: physical

analysis and logical analysis. The design phase is also broken down into

two components, although in the design phase logical design precedes

physical design.





Giai đoạn phân tich đƣợc chia thanh hai phần: phân tich vật lý va

phân tich logic. Giai đoạn thiết kế cũng đƣợc chia thanh hai thanh phần,

mặc dù trong giai đoạn thiết kế, thiết kế logic đến trƣớc thiết kế vật lý.

12.3.2 Thiết kế logic

The logical analysis and logical design phases are very similar and

overlapping. Martin Butler and Robin Bloor stress that, in the logical phase,

we create a model of the application area that matches the events occurring

within the intended system. As these events are identified, each must be

examined to determine specific criteria for it (Bloor and Butler, 1989):

- What initiates the event?

- What is changed by the event?

- What subsequent events are triggered by the event?

- What error conditions can arise?

Các phân tich logic va giai đoạn thiết kế logic la rất giống nhau va

chồng chéo. Martin Butler va Robin Bloor nhấn mạnh rằng, trong giai đoạn

logic, chúng ta tạo ra một mô hình của các khu vực ứng dụng phù hợp với

những sự kiện xảy ra trong hệ thống định dùng. Khi những sự kiện nay





đƣợc xác định, mỗi cái phải đƣợc kiểm tra để xác định tiêu chi cụ thể cho

nó:

Cái gì khởi đầu sự kiện?

Cái gì được thay đổi bởi sự kiện này?

Những sự kiện tiếp theo được kích hoạt bởi sự kiện này?

Những điều kiện có thể phát sinh lỗi?

These descriptions are crucial inputs for the physical design phase

because they will allow us to derive the required objects and methods. It is

this process that is likely the most important aspect of systems design; all of

the blueprints for future code are based upon this logical model.

Những mô tả nay la yếu tố đầu vao quan trọng trong giai đoạn thiết

kế vật lý, vì chúng sẽ cho phép chúng ta lấy đƣợc các đối tƣợng va phƣơng

pháp đƣợc yêu cầu. Đó la quá trình ma có thể la khia cạnh quan trọng nhất

của thiết kế hệ thống; tất cả các kế hoạch chi tiết cho các qui tắc trong

tƣơng lai dựa trên mô hình logic nay.

The tools of the logical paradigm are somewhat different from those

of physical analysis discussed previously. Physical analysis tools, such as

manual system flowcharts, are very concerned with the specific steps and

decision points inherent in moving through the system. The logical analysis





and design tools are more focused on definition of individual components

of the system and the ways these components interact. The tools of choice

for the logical phase of the systems development process are the data-flow

diagram (DFD) and the entity-relationship diagram when using the

traditional, structured paradigm.

Các công cụ của các mô hình logic có hơi khác với phân tich vật lý

thảo luận trƣớc đó. Công cụ phân tich vật lý, chẳng hạn nhƣ lƣu đồ hệ

thống thủ công, rất có liên quan với các bƣớc cụ thể va điểm quyết định cố

hữu trong việc di chuyển thông qua hệ thống. Các phân tích logic và các

công cụ thiết kế đƣợc tập trung hơn vao xác định các thanh phần riêng lẻ

của hệ thống va những cách các thanh phần tƣơng tác. Các công cụ lựa

chọn cho các giai đoạn logic của quá trình phát triển hệ thống la sơ đồ

luồng dữ liệu (DFD) va lƣợc đồ quan hệ khi sử dụng các mô hình truyền

thống có cấu trúc.

At this stage of the process, with the logical design of the system

complete, all that remains to complete the design is to define the physical

design of the software.

Ở giai đoạn nay của quá trình, với thiết kế logic của hệ thống hoan

chỉnh, tất cả những gì còn lại để hoan tất việc thiết kế la xác định thiết kế

vật lý của phần mềm.





12.3.3 Thiết kế vật lý

The physical design is the blueprint for actual development of the

software and deployment of the system. The physical phase is concerned

with matching the logical model to the hardware and software at our

disposal. Thus, we are transforming a logical model into a workable model

that can be implemented (Bloor and Butler, 1989). Unlike the logical

phases that immediately precede this work, the physical design phase is

focused on specific implementation of the system. The logical design was

built on the requirements defined during the physical and logical analysis

phases. This fact allows the designer to build a physical design that

implements the logical design without worrying about meeting the

functional requirements of the end users; if the logical design is

implemented, these requirements will be fulfilled.

Thiết kế vật lý la bản vẽ chi tiết cho sự phát triển thực tế của các

phần mềm va triển khai hệ thống. Giai đoạn vật lý có liên quan với các mô

hình logic kết hợp với phần cứng va phần mềm lúc chúng ta xử lý. Vì vậy,

chúng ta đang chuyển đổi mô hình logic vao một mô hình hoan toan khả thi

có thể đƣợc triển khai thực hiện (Bloor va Butler, 1989). Không giống nhƣ

giai đoạn logic ma ngay lập tức đứng trƣớc công việc, giai đoạn thiết kế vật

lý la tập trung vao việc thực hiện cụ thể của hệ thống. Phần thiết kế logic

đƣợc xây dựng dựa trên những yêu cầu đƣợc hình thanh trong quá trình

phân tich vật lý va logic. Điều nay cho phép kỹ sƣ thiết kế có thể xây dựng





một thiết kế vật lý có thể vận hanh thiết kế logic ma không phải quan tâm

về những yêu cầu chức năng từ phia ngƣời dùng cuối; một khi thiết kế logic

đƣợc cai đặt, những yêu cầu nay sẽ đƣợc đáp ứng một cách đầy đủ.

The physical design phase is also where some specific

implementation decisions must be made. Many, if not most, automated

systems today use third-party software for pieces of the solution. Database

software, Java application server software, and object messaging software

are some examples of the kinds of third-party components that are often

required. The logical design need not be concerned with the specific vendor

choice, only with a requirement for one, because the logical design is

intended to be abstracted away from the specific details of the

implementation. The physical design, however, must answer these

questions (Curtis et al., 2000). This fact illustrates the true distinction

between the logical and physical design phases: the logical design is

focused on what the system will do and the physical design is focused on

how the system will do it.

Phần thiết kế vật lý ngoai ra còn la nơi để tiến hanh cai đặt một số

việc cụ thể. Có nhiều, nếu không phải la hầu hết, các hệ thống tự động ngay

nay sử dụng phần mềm của công ty thứ ba để chi nhỏ các giải pháp. Phần

mềm cho cơ sở dữ liệu, phần mềm ứng dụng Java chạy trên máy chủ, va

phần mềm gửi tin nhắn cho ngƣời khác, la một số các vi dụ về các loại của

các phần mềm thanh phần của công ty thứ ba thƣờng đƣợc yêu cầu. Phần





thiết kế logic không cần phải bận tâm đến sự lựa chọn một nha cung cấp cụ

thể nao, chỉ cần có các yêu cầu cho nha cung cấp, vì phần thiết kế logic chỉ

nhằm trừu tƣợng hóa những chi tiết cụ thể của việc cai đặt. Mặc dù vậy,

thiết kế vật lý phải trả lời đƣợc cái câu hỏi sau (Curtis et al., 2000). Cái nay

cho thấy sự khác nhau cơ bản giữa thiết kế logic va thiết kế vật lý: thiết kế

logic tập trung cho biết hệ thống sẽ lam gì, trong khi thiết kế vật lý tập

trung cho biết hệ thống sẽ lam chuyện đó nhƣ thế nao.

12.4 SỰ ĐẶC TẢ CỦA CÁC HỆ THỐNG

The detailed design that has been achieved at this point in the

process results in a systems specification. No agreed-on standard format for

this specification exists and some insist that writing a design spec is more

of an art form than a scientific process. Most IT professionals have sought a

―cookie-cutter‖ explanation of how to write a good design spec, but one

simply does not exist. Curtis et al. (2000) give a good basic outline of what

a design specification should include:

An executive summary in order to provide a quick summary of the

major points in the specification

A description of the proposed system and its objectives (may also

include flow block diagrams and data flow diagrams may be used)





A description of all programs to include module specifications and

structure charts, together with test data

A description of all input to include specimen source documents,

screen layouts, menu structures, and control procedures

A description of all output to include specimen output reports and

contents of listings.

A description of all data storage to include specification of file and

database structure

A detailed specification of controls operating over procedures within

the system

A specification of all hardware requirements and performance

characteristics to be satisfied

A specification of clerical procedures and responsibilities

surrounding the system

A detailed schedule for the implementation of the system

Cost estimates and constraints





Bản thiết kế chi tiết đã đạt đƣợc cho tới thời điểm nay la kết quả của

một đặc tả của các hệ thống. Không có một định dạng chuẩn nao đƣợc

thống nhất cho các đặc tả nay va một số ngƣời cho rằng việc viết một bản

đặc tả thiết kế thì giống với một nghệ thuật hơn la một quy trình khoa học.

Hầu hết những chuyên gia IT đều cố gắng tìm kiếm một lời giải chung

chung để lam thế nao viết một bản đặc tả thiết kế tốt, nhƣng hầu nhƣ không

thể tìm đƣợc lời giải đó. Curtis el al. (2000) đƣa ra một bản phác thảo tốt va

cơ bản về những gì cần có trong một bản đặc tả thiết kế:

Bản tóm tắt thực thi nhằm cho biết một cái nhìn chung về điểm mấu

chốt ma bản đặc tả muốn nhắm đến.

Bản mô tả sự vận hanh của hệ thống va các đối tƣợng của nó (có thể

dùng sơ đồ luồng dữ liệu (DFD) hoặc sơ đồ dòng khối (flow block

diagram)).

Liệt kê tất cả các chƣơng trình để bổ sung vao trong mô-đun các đặc

tả va các biểu đồ cấu trúc cùng với dữ liệu kiểm thử.

Chi tiết tất cả những dữ liệu đầu vao để bổ sung vao trong các tai liệu

mẫu, thiết kế man hình, cấu trúc thanh menu, va các phƣơng thức điều

khiển.

Chi tiết tất cả các dữ liệu đầu ra để bổ sung vao các mẫu dữ liệu ra để

báo cáo va lập danh sách.





Chi tiết tất cả các dạng lƣu trữ dữ liệu nhằm bổ sung cho việc đặc tả

về tập tin va cấu trúc cơ sở dữ liệu.

Một bản đặc tả chi tiết của việc điều hanh quá trình chạy thông qua

các thủ tục, ham trong hệ thống.

Một bản đặc tả tất cả những yêu cầu về phần cứng va những yêu cầu

về xử lý phải đƣợc đáp ứng.

Một bản đặc tả các ham, thủ tục biên chép (ghi chép) va các trách

nhiệm liên quan đến hệ thống.

Một thời gian biểu chi tiết cho việc tiến hanh cai đặt của hệ thống.

Các chi phi ƣớc tinh va rang buộc.

Appleton (1997) states that the design specification should meet the

following criteria:

It should adequately serve as training material for new project

members so that they are able to understand what is said in design

meetings.

It should serve as ―objective evidence‖ that the designers are

following through on their commitment to implement the functionality

described in the requirements spec.





It needs to be as detailed as possible, while at the same time not

imposing too much of a burden on the designers.

Appleton (1997) chỉ ra rằng một bản đặc tả thiết kế nên thỏa mãn các

tiêu chuẩn sau đây:

Nó nên đƣợc trang bị một cách đầy đủ nhƣ một công cụ hƣớng dẫn

cho những ngƣời thanh viên mới của dự án, nhƣ vậy họ có thể hiểu đƣợc

những gì đƣợc ghi trong bản thiết kế.

Nó nên đƣợc trang bị nhƣ một ―bằng chứng về mục tiêu‖ cho những

nha thiết kế theo đó tiến hanh cai đặt để tuân thủ theo những yêu cầu chức

năng đã đƣợc đề ra.

Nó cang chi tiết cang tốt, khi cùng một thời điểm không lam cho

ngƣời thiết kế thêm gánh nặng phải cáng đáng.

12.5 MỘT SỐ HƢỚNG DẪN CHO MỘT BẢN ĐẶC TẢ HỆ THỐNG

Appendix J is a complete SDS for a working student-created system:

Section 1 provides an overview of the system, its mission and goals,

and any other supporting documentation deemed necessary by the support

team. Much of this can be copied from the SRS (Appendix G), project plan

(Appendix F), and feasibility study (Appendix C).





Phụ lục J la một bản SDS hoan chỉnh cho một hệ thống do sinh viên

tạo ra có thể chạy đƣợc:

Phần 1 cung cấp một cái nhìn tổng quát về hệ thống, nhiệm vụ va

mục tiêu, va bất cứ tai liệu hỗ trợ có thể sẽ cần thiết đƣợc cung cấp từ các

đội hỗ trợ. Hầu hết những cái nay có thể đƣợc chép từ SRS (Phụ lục G), lên

kế hoạch cho dự án (Phụ lục F), va nghiên cứu tinh khả thi (Phụ lục C).

Section 2 provides a list of design considerations that includes:

assumptions, dependencies, frequency of use, database requirements,

memory, and hardware and software constraints, as well as a description of

the system environment — i.e., user interfaces, software interfaces, and

communications interfaces. Section 2 also discusses policies and

procedures, design methodology, and system risks.

Phần 2 cung cấp danh sách của những sự xem xét thiết kế, bao gồm:

sự giả định, sự phụ thuộc, tần số sử dụng, yêu cầu cơ sở dữ liệu, bộ nhớ, va

phần cứng, cùng rang buộc phần mềm, cùng với bản mô tả về môi trƣờng

hệ thống – vi dụ, giao diện ngƣời dùng, giao diện phần mềm, va giao diện

tƣơng tác. Phần 2 ngoai ra còn đề cập về chinh sách va các thủ tục (ham),

các phƣơng pháp thiết kế, va nguy cơ hệ thống.

Section 3 specifies the architecture of the system. (Appendix I)

Phần 3 đặc tả về cấu trúc của hệ thống(Phụ lục I).





Section 4 provides a high-level design spec of the system. A detailed

set of DFDs can be found in this section.

Phần 4 cung cấp một bản đặc tả thiết kế của hệ thống ở cấp độ cao

hơn. Một tập hợp những sơ đồ luồng dữ liệu chi tiết (DFD) đƣợc cung cấp

trong phần nay.

Section 5, the low-level design, provides a complete set of PSPECs

as well as a data dictionary (Appendix K).

Phần 5, thiết kế ở mức thấp, cung cấp một tập hợp đầy đủ của

PSEPC cũng nhƣ từ điển dữ liệu (Phụ lục K).

Section 6 is reserved for a list of business-use cases as well as a

series of screen shots showing the design of the user interface. (Appendix

E).

Phần 6 dùng dự trữ cho một danh sách của các trƣờng hợp dùng

trong kinh doanh va những đoạn chụp man hình cho việc thiết kế giao diện

ngƣời dùng (Phụ lục E).

12.6 KẾT LUẬN

Davis (2002) makes an important point when he states that without a

complete, unambiguous design specification document, one could be setting





oneself up for ―costly‖ rewrites. Therefore it is important to recognize that

the systems specification is used as (Curtis et al., 2000):

The exit criterion from the stage of detailed design prior to the stage

of implementation.

A source documentation from which programs are written and

hardware ―tenders‖ are brought about.

A historical reference of the system for future users and developers

A comparative document during the assessment phase once the

system is being used

Davis (2002) chỉ ra một điểm quan trọng rằng nếu không có một bản

tai liệu đặc tả thiết kế đầy đủ, rõ rang, một ngƣời có thể tự thiết lập ra

những bản viết khác nhau. Do đó việc nhận ra rằng đặc tả hệ thống nhƣ

(Curtis et al., 2000) la quan trọng:

Những tiêu chuẩn để kết thúc một phần của bản thiết kế chi tiết trƣớc

khi chuyển sang phần cai đặt.

Tai liệu nguồn để chƣơng tình có thể đƣợc cai đặt va phần cứng có

khả năng tƣơng thich.





Những thảo khảo về trƣớc đây của hệ thống nhằm xác định những

ngƣời dùng va nha phát triển tƣơng lai.

Một tai liệu tƣơng đối trong quá trình đánh giá một pha từ khi hệ

thống đã đƣợc sử dụng.

An analyst who refers to the basic outline of design specification that

considers everything from goals and objectives, to subsystems description,

to potential project issues, should be able to develop a spec document that is

understood by developers and at least somewhat by customers. These

specifications should also help in avoiding errors and expensive rewrites.

Một nha phân tich, ngƣời luôn muốn tham khảo bản phác thảo cơ

bản của bản đặc tả thiết kế, luôn nhìn nhận mọi thứ từ mục tiêu, đich, cho

tới mô tả các hệ thống con, những vấn đề tiềm tang của dự án, ngƣời có khả

năng phát triển tai liệu đặc tả - cái đƣợc các nha phát triển hiểu rõ va it nhất

la một số loại khách hang. Những đặc tả nay ngoai ra có thể giúp tránh

đƣợc những lỗi va chi phi viết lại tốn kém.

A functional design specification is like a pyramid. The top reflects a

broad overview that describes the wide spectrum of the system and its

components. At each level below the overview, one has an overview of

each of the primary components and as much detail as one‘s developers

require (Davis, 2002).





Một bản đặc tả thiết kế các yêu cầu giống nhƣ một cái kim tự tháp.

Cái đỉnh tƣơng ứng nhƣ một cái nhìn rộng, chung, mô tả một cách bao trùm

về hệ thống va các thanh phần của nó. Mỗi cấp phia dƣới của cái nhìn

chung đó, có một tầm nhìn khái quát của mỗi thanh phần chinh va can chi

tiết hơn nữa nếu nha phát triển cần đến (Davis, 2002).

12.7 TÀI LIỆU THAM KHẢO:

Bloor, R. and Butler, M. (1989a). Object orientation…let‘s get

physical, DEC User, December, 42.

Curtis, G., Hoffer, J.A., George, J.F., and Valacich, J. (2000).

Introduction to Business Systems Analysis, Pearson Custom Publishing,

Boston.

Davis, J. (2002). Design specifications: how much detail is enough?

Available:

http://builder.com.com/article.jhtml?id = 0120020206jed03.htm&src

= search:.

Harrington, J.L. (1998). Relational Database Design Clearly

Explained, Morgan Kaufmann, San Diego.





Kendall, K.E. and Kendall, J.E. (2002). Systems Analysis and

Design, Prentice Hall, New York.




Chương 13: Thiết kế hướng đối tượng 482

CHƢƠNG 13 THIẾT KẾ HƢỚNG ĐỐI TƢỢNG

Người dịch:

4. Lê Quang Thảo

5. Huỳnh Thảo Hạnh

Duy


Current code is a liability, not an asset. The challenge is to develop

new code that is truly an asset. This challenge was issued by Vaughan

Merlyn, one of the luminaries of our industry. It is one that bottom-line-

conscious software engineering managers are now taking seriously. To

meet this challenge, developers will need to do more than just tweak some

code and liven up user interfaces. They will need to dramatically alter the

way in which they code.

Code hiện tại la một khó khăn va không đƣợc xem nhƣ tai sản.Thách

thức đƣợc đặt ra la phát triển code mới để no thật sự trở thanh tai sản.





Thách thức nay đã đƣợc đƣa ra bởi Vaughan Merlyn, một trong những

doanh nhân của nền công nghiệp chúng ta. Đây quả la một vấn đề quan

trong đối với những ngƣời quản lý phần mềm. Còn các developer cần phải

lam nhiều hơn nữa để phát triển code của mình. Họ cần có sự đột biến so

với con đƣờng lập trình hiện tại.

13.1 WHAT IS OO ?

Object orientation (OO), which views the abstractions manipulated

by computer software as counterparts to real-world objects, has promised

developers a brave new world. Object-oriented development emerged as the

dominant software development methodology of the 1990s. Not

surprisingly, many organizations are jumping on the OO bandwagon.

Hƣớng đối tƣợng la một cách nhìn nhận sự trừu tƣợng những phần

mềm máy tinh nhƣ một phần của thế giới thực,đây cũng la xu hƣớng của

các developers hiện tại.Sự phát triển của hƣớng đối tƣợng nổi lên nhƣ la

một phƣơng pháp phát triển phần mềm nổi trội trong những năm

1990.Không có gì bất ngờ khi nhiều tổ chức đã chuyển sang mô hình hƣớng

đối tƣợng nay.

The concept of an object is the fundamental building block on which

the object-oriented paradigm rests. Four pivotal concepts are behind object

orientation: encapsulation, message passing, dynamic binding, and





inheritance. To the extent that a tool or language incorporates these

concepts,it becomes qualified as an object-oriented tool kit.

Đối tƣợng trong OO(Object-Oriented) chinh la những khối căn bản

nền tảng đã đƣợc xây dựng sẵn trong mô hình OO.Có 4 khái niệm để miêu

tả đối tƣợng nay:có tinh đóng gói, thông tin ngắn gọn, liên kết linh hoạt,

va kế thừa. Trong phạm vi một công cụ hay một ngôn ngữ nao đó có tich

hợp các khái niệm thì nó sẽ trở thanh một bộ công cụ của OO.

We can explain these concepts using a simple letter as an analogy.

Suppose a user wrote an e-mail letter to a colleague in another department.

The letter is an object that has many properties in common with

other letters: it contains information and has associated procedures that

allow the user to manipulate it (read, write, and send). These properties,

when grouped together, constitute the concept of the letter object. This

process of combining data and functions all in one object is encapsulation.

Chúng ta có thể giải thich những khái niệm nay sử dụng 1 lá thƣ đơn

giản nhƣ la một sự tƣơng đồng.Giả sử rằng 1 ngƣời viết 1 lá thƣ cho 1

ngƣời đồng nghiệp ở bộ phần khác.Một lá thƣ la 1 đối tƣợng có nhiều thuộc

tinh thông thƣờng nhƣ những lá thƣ khác, nó bao gồm thông tin va những

cái thủ tục bắt buộc cho phép ngƣời dung thao tác nó (nhƣ đọc, viết,

gửi).Những thuộc tinh nay khi đƣợc gom nhóm lại nó sẽ cấu thanh khái





niệm của đối tƣợng ở đây la lá thƣ. Tiến trình của sự kết hợp dữ liệu va tất

cả các chức năng trong một đối tƣợng đƣợc gọi la tinh đóng gói

Now suppose the e-mail system only allows users to write letters in

English, but the company just hired an employee who speaks only

Japanese. The company now needs the facility to create and manipulate

Japanese letters. This is done by putting letter objects in discrete

categories,referred to as classes.

Bây giờ giả sử lá thƣ hệ thống chỉ cho phép ngƣời dùng viết những

ki tự bằng tiếng Anh nhƣng công ty vừa mới thuê những nhân viên chỉ biết

nói tiếng Nhật.Vì thể công ty đang cần những khả năng đọc va thao tác

trên những lá thƣ tiếng Nhật.Điều nay sẽ đƣợc giải quyết bằng cách đƣa ra

những đối tƣợng lá thƣ trong những phạm trù khác nhau có liên quan đến

các lớp.

A class is a collection of objects that share the same functionality

and characteristics (procedures and data). In this example, two classes are

created: an English letter class and a Japanese letter class. Both classes have

many functions and characteristics in common. By identifying those things

held in common we can create a super or parent class. Thus, the English

letter and the Japanese letter become subclasses with each pinpointing how

it differs from its parent and siblings.





Một lớp la một tập hợp các đối tƣợng chia sẻ những chức năng va

đặc điểm giống nhau (các thủ tục va dữ liệu của lá thƣ).Trong lớp nay có 2

lớp đƣợc tạo ra: lớp lá thƣ ghi bằng tiếng Anh va lớp lá thƣ ghi bằng tiếng

Nhật.Cả 2 lớp đều có nhiều chức năng va thuộc tinh thông thƣờng.Để nhận

biết ra những thuộc tinh thông thƣờng nay chúng ta cần tạo ra lớp cha. Vì

vậy những lớp lá thƣ tiếng Anh, lá thƣ Nhật Bản đã trở thanh những

subclasses.

The English and Japanese letter subclasses inherit the functionality

of ―reading, writing, and sending‖ from the parent object. However, the

Japanese subclass is different in that it has the extra characteristic of

translating text into the Japanese language, and the English subclass is

different in that it translates into English. This is the meat behind the OO

concept of inheritance.

Nhũng lớp nay sẽ kế thừa các chức năng của lớp cha nhƣ đọc,viết,

gửi từ lớp cha.Tuy nhiên lớp lá thƣ tiếng Anh cũng có những phƣơng thức

khác nhƣ dịch sang tiếng Anh, tƣơng tƣ lớp lá thƣ Nhật Bản cũng

vậy.Chúng ta sẽ gặp lại khái niệm kế thừa ở phần sau.

The letter object permits the user to request certain tasks or services,

such as ―read a letter‖, ―write a letter‖, or ―send a letter‖. This is commonly

called ―sending a message to an object‖— or to use OO parlance, message

passing.





Đối tƣợng lá thƣ cho phép ngƣời dùng yêu cầu những thao tác va

dịch vụ nao đó nhƣ đọc thu, viết thƣ, gửi thƣ.Điều nay thông thƣờng gọi la

―sending a message to an object‖ hay sử dụng thông điệp ngắn gọn

(message passing)

Sending a message is not quite the same as issuing a function call, a

process familiar to most developers. Different objects can respond to the

same message in different ways. For example, as just discussed, the ―read‖

message is handled one way by the English object and another way by the

Japanese object. In fact, the OO term ―polymorphism‖ is used to describe

the ability to send general-purpose messages to objects that will then handle

them appropriately. The objects handle the specific details.

Gửi 1 thông điệp không nhƣ la cung cấp 1 chức năng đƣợc gọi,1 tiến

trình quen thuộc với các developers.Sự khác biệt của những đối tƣợng có

thể đƣợc đáp ứng bằng những thông điệp giống nhau thông qua nhiều cách

khác nhau. Vi dụ nhƣ thảo luận‖, đọc ‖message bằng tiếng Anh hoặc tiếng

Nhật.Sự thật mẫu hƣớng đối tƣợng đƣợc miêu tả những khả năng để gửi

những thông điệp tổng quát mong muốn đến đối tƣợng ma sau đó ngƣời ta

có thể vận dụng nó một cách chinh xác.Những đối tƣợng sử dụng những

đặc tả chi tiết

In sending these messages, the user never needs to specify the type

of object with which he or she is dealing. OO systems utilize what is known





as dynamic binding to determine the object type at run time when the code

is executed.

Trong việc gửi những thông điệp nay,ngƣời dùng không bao giờ cần

đến đặc tả loại đối tƣợng.Hệ thống hƣớng đối tƣợng tận dụng những gì biết

đƣợc nhƣ la sự nối kết chặt chẽ để xác định loại đối tƣợng đang chạy khi

ma mã lệnh đƣợc thực thi.

The benefits of OO can be summed up as: quality, productivity,

predict ability, and control of complexity.

Tóm lại những lợi ich của hƣớng đối tƣợng (OO):chất lƣợng, hiệu

quả,dự đoán trƣớc đƣợc va có thể quản lý đƣợc sự phức tạp.

13.2 OO FROM THE BOTTOM UP

If we build object-oriented systems, we need tools that support the

building of these applications. Developers building today‘s applications are

essentially using the traditional, structured process methodologies

developed by experts like Ed Yourdon, Tom DeMarco, and Chris Gane and

TrishSarson, as well as the data modeling methodology pioneered by Peter

Chen.

Nếu chúng ta xây dựng hệ thống hƣớng đối tƣợng, chúng ta cần

những công cụ ma nó có thể hỗ trợ để xây dựng các ứng dụng nay. Các

developer xây dựng ứng dụng ngay nay đều cần thiết sử dụng những





phƣơng pháp cấu trúc truyền thống đƣợc phát triển bởi các chuyên gia nhƣ

là Ed Yourdon, Tom DeMarco, and Chris Gane and Trish Sarson tốt nhƣ la

mô hình dữ liệu mẫu đƣợc khám phá bởi Peter Chen

Currently, information engineering techniques pivot around data and

itsrelationships as documented in data-flow diagrams (Exhibit 13-1) and

entity-relationship diagrams (Exhibit 13-2). Structured analysis is not based

on objects, however.

Hiện tại thì những thông tin kĩ thuật công nghệ đều xoay quanh 1

trục dữ liệu va mối quan hệ đó đƣợc biểu diễn trong sơ đồ luồng dữ liệu

hình 13-1 va mô hình quan hệ thực thể kết hợp đƣợc thê hiện đƣợc biểu

hiện ở sơ đồ 13-2. Cấu trúc phân tich không dựa trên những đối tƣợng,tuy

nhiên





Interestingly, not everything using objects is object oriented.

Professor Paul Wegner of Brown University has defined three levels of

object orientation for this purpose. The first level is object based. Object-

based languages, tools, and methodologies support the concept of the object

and use of messages to communicate between objects. The second level is

what is known as class based, which supports the concepts of

objects,messaging, and classes. The third level is object oriented, which

supports the definition that this chapter has already supplied.





Thật la thú vị la mọi việc đều không muốn sử dụng đối tƣợng trong

hƣớng đối tƣợng.Giảng viện Paul Wegner của trƣờng đại học Brown đã

định nghĩa 3 mức cho thiết kế hƣớng đối tƣợng vì mục đich nay.Mức thứ

nhất đó la đối tƣợng căn bản. Đối tƣợng căn bản ở đây đó chinh la những

ngôn ngữ,công cụ va những phƣơng pháp hỗ trơ cho những đối tƣợng va sử

dụng những thông điệp để liên lạc giữa những đối tƣợng. Mức thứ 2 đƣợc

biết đến nhƣ la những lớp căn bản ma nó hỗ trợ các khái niệm về đối

tƣợng,thông điệp, lớp. Mức thứ 3 la hƣớng đối tƣợng,nó sẽ hỗ trợ cho

những định nghĩa ma chƣơng nay sẽ cung cấp đầy đủ

There are three levels of object orientation utilized in systems

development. Object-oriented analysis (OOA) coincides with traditional

analysis but utilizes OO techniques. Object-oriented design (OOD) is th

design phase of the OO methodology and OOP (object-oriented

programming) is the programming phase. The reader is urged to review the

definitions at the end of this chapter for a better feel for the vocabulary of

this methodology.

Có 3 lớp của sự hƣớng đối tƣợng đƣợc dùng trong sự phát triển hệ

thống.Phân tich hƣớng đối tƣợng trùng với cách phân tich truyền thống

nhƣng có dùng công nghệ hƣớng đối tƣợng.Thiết kế hƣớng đối tƣợng la

một giai đoạn của phƣơng pháp hƣớng đối tƣợng va lập trình hƣớng đối

tƣợng (OOP) la giai đoạn lập trình. Ngƣời đọc có thể xem lại những định

nghĩa nay ở cuối chƣơng để có thể cảm thấy hiểu rõ hơn về những từ vựng

trong phƣơng pháp nay.





OO seems to have penetrated the organization in a bottom–up

manner.Though the benefits of OO have been touted for at least a decade, it

was only when OO languages became widely available that these methods

began to be widely adopted. A big part of this can be attributed to the

introduction of the Internet and Java programming language, which is OO.

The introduction of ―visual‖ program development environments for C++

(Exhibit 13-3) and Visual Basic.Net was also a contributing factor.

Hƣớng đối tƣợng dƣờng nhƣ đi vao tổ chức theo cách từ dƣới lên.

Mặc dù lợi ich của HĐT đã đƣợc giới thiệu đến cả 1 thập kỉ nay, nhƣng chỉ

khi ngôn ngữ HĐT phổ biến rộng rãi thì phƣơng pháp HĐT mới bắt đầu

đƣợc sử dụng nhiều. Công lớn la nhờ việc giới thiệu Internet va ngôn ngữ

lập trình Java – ngôn ngữ HĐT. Kế đến la môi trƣờng phát triển Visual

Studio C++ (hình 13-3) va Visual Basic của Microsoft. Mạng Internet cũng

la 1 nhân tố quan trọng..Hình 13-2, Hình 13-3

Classes are actually the building block of OO systems. Classes are

built to be reusable and are often thought of as ―black boxes‖. The

programmer should have only the details he or she needs to get the class to

work. Classes can be stored in a class library. If enough classes are

available to the programmer, the task of programming becomes less

burdensome and the code is of a much higher quality because classes and

objects available in a class library have been thoroughly tested.





Lớp (class) la nền tảng của hệ thống HĐT. Lớp đƣợc xây dựng va tái

sử dụng va thƣờng đƣợc coi la ―hộp đen‖ (black box). Lập trình viên nên

biết các chi tiết cần thiết để lam cho một Lớp hoạt động. Lớp có thể đƣợc

lƣu trong thƣ viện lớp. Nếu có đủ lớp trong thƣ viện thì việc lập trình sẽ bớt

đi gánh nặng va code viết ra cũng sẽ chất lƣợng hơn vì các lớp va các đối

tƣợng trong thƣ viện đều đã đƣợc kiểm tra kĩ cang.

The best way to explain the inner workings of classes is to show you

a very simple program. In the C++ program displayed in Exhibit 13-4, we

create a class named DayOfYear. Class DayOfYear encapsulates data (the

integers month and day) and function (the function called output). If you

read through the program (//denotes comments), you will immediately see

the flexibility and power of classes and objects. As you can see, classes are

the heart of an OO system. It makes sense, then, that OOA and OOD

revolve around identification and specification of classes.

Cách tốt nhất để giải thich những công việc bên trong của một lớp la

viết ra một chƣơng trình đơn giản. Trong chƣơng trình C++ ở hình 13-4,

chúng ta tạo ra một lớp có tên DayOfYear. Lớp DayOfYear đóng gói dữ

liệu (các số nguyên tháng va ngay) va ham (ham output). Nếu bạn đọc qua

chƣơng trình, bạn sẽ nhanh chóng thấy đƣợc tinh chất linh hoạt va sức

mạnh của lớp va đối tƣợng. Nhƣ bạn có thể thấy, lớp la trái tim của hệ

thống HĐT. Ta thấy rằng OOA (phân tich HĐT) va OOD (thiết kế HĐT)

xoay quanh các vần đề về sự nhận dạng va sự đặc tả của lớp.





13.3 METHODOLOGIES

13.3.1 OOAD Methodologies

Object-oriented analysis and design (OOAD) benefits from a variety

of competing but similar methodologies. The major OO methodologies are

described by Gora (1996):

Phân tich va thiết kế HĐT đem lại lợi ich từ nhiều phƣơng pháp cạnh

tranh nhƣng giống nhau. Phƣơng pháp HĐT chủ yếu đƣợc mô tả bởi Gora

(1996)

13.3.2 Booch

Grady Booch‘s approach to OOAD (Object-Oriented Design with

Applications, Benjamin/Cummings, 1994) is one of the most popular and is

supported by a variety of reasonably priced tools ranging from Visio to

Rational Rose.

Hƣớng tiếp cận của Grady Booch đối với OOAD la một trong những

hƣớng phổ biến nhất va đƣợc hỗ trợ bởi rất nhiều công cụ với giá cả hợp lý

từ Visio đến Rational Rose





13.3.3 Coad and Yourdon

Coad and Yourdon published two of the first books on OOAD

(Object-Oriented Analysis and Object-Oriented Design, Prentice-Hall, New

York, 1990 and 1991, respectively). Their methodology focuses on analysis

of business problems. Analysis proceeds in five stages, called SOSAS:

Subjects: these are similar to the levels or layers in data-flow diagrams.

Objects: object classes are specified in this stage.

Structures: there are two types: classification structures and

composition structures. Classification structures correspond to the

inheritance relationship between classes. Composition structures define

the other types of relationships between classes. Methodologies deal

with these structures.

Attributes: these are handled similarly to attributes in relational

analysis.

Services: what other methodologies call methods or operations is

identified.

In design, these activities are refined into four components:

Problem domain component: classes that deal with the problem

domain; for example, customer classes and order classes





Human interaction component: user-interface classes such as window

classes

Task management component: system-management classes such as

error classes and security classes

Data management component: database access method classes and the

like

Coad va Yourdon đã xuất bản 2 trong những cuốn sách đầu tiên viết

về OOAD (2 cuốn Object-Ori-ented Analysis và Object-Oriented Design,

Prentice-Hall, New York, xuất bản năm 1990 va 1991). Phƣơng pháp của

họ tập trung vao phân tich các vần đề nghiệp vụ

Quá trình phân tich gồm 5 giai đoạn, gọi la SOSAS:

Subjects: xác định những chủ đề tƣơng ứng với cấp độ (level) hay tầng

(layer) trong biểu đồ dòng dữ liệu (data-flow diagram).

Objects: các lớp đối tƣợng đƣợc xác định trong giai đoạn nay.

Structures: có 2 loại: cấu trúc phân lớp (classification) va cấu trúc phức

hợp (composition). Cấu trúc phân lớp tƣơng ứng với quan hệ kế thừa

giữa các lớp. Cấu trúc phức hợp định nghĩa các quan hệ khác giữa các

lớp.





Attributes: các thuộc tinh sẽ đƣợc quản lý giống nhƣ trong phân tich

qua hệ.

Services: xác định cái ma các phƣơng pháp khác gọi la phƣơng thức

(method).

Thiết kế gồm 4 phần:

Problem domain component: thiết kế các lớp giải quyết các phạm vi

vấn đề (problem domain), vì dụ, lớp customer (khách hang) va lớp

order (đặt hang).

Human interaction component: thiết kế lớp giao diện ngƣời dùng nhƣ la

lớp window.

Task management component: thiết kế lớp quản lý hệ thống nhƣ lớp

quản lý lỗi hay bảo mật.

Data management component: thiết kế lớp truy xuất cơ sở dữ liệu.

13.3.4 Jacobson: Objectory and OOSE

Jacobson‘s full OOAD methodology, Objectory, is proprietary. His

object-oriented software engineering (OOSE) is a simplified version of

Objectory (Object-Oriented Systems Engineering, Addison-Wesley,

Reading, MA, 1992).





Trong phƣơng pháp của Jacobson, tinh đối tƣợng (Objectory) la độc

quyền. Kĩ thuật phần mềm HĐT của ông cũng la một phiên bản đơn giản

hóa của Objectory.

The major distinguishing feature in Jacobson is the use case. A use-

case definition consists of a diagram and a description of the interaction

between the actor and a system. An actor may be an end user or some other

object in the system.

Đặc trƣng phân biệt của phƣơng pháp của Jacobson la use case. Một

định nghĩa use case bao gồm 1 biểu đồ va một sự mô tả quá trình tƣơng tác

của tác nhân (actor) va hệ thống. Một tác nhân có thế la ngƣời dùng cuối

hay đối tƣợng nao đó trong hệ thống.

According to Jacobson, a use case is any description of a single way

to use a system or application, or any class of top-level usage scenarios, that

captures how actors use their black-box applications. A use case is any

behaviorally related sequence of transactions that a single actor performs in

a dialog with a system in order to provide some measurable value to the

actor.

Theo Jacobson, một use cae la một sự mô tả bất kỳ về một cách sử

dụng hệ thống hoặc ứng dụng, hoặc lớp bất kỳ nằm ở kịch bản sử dụng

thuộc tầng cao trong hệ thống, cho biết cách ma tác nhân sử dụng ứng dụng.

Một use cae la một chuỗi các giao tác ma mỗi tác nhân sẽ thực hiện.





Use cases are used to document user requirements in terms of user

dialogs with a system. They appear first in the requirements model and are

then used to generate a domain object model with objects drawn from the

entities of the business, as mentioned in the use cases. This is then

converted into an analysis model by classifying the domain objects into

three types: interface objects, entity objects, and control objects.

Use case đƣợc dùng để tai liệu hóa yêu cầu của ngƣời dùng. Chúng

xuất hiện đầu tiền trong mô hình các yêu cầu va sau đó đƣợc dùng để tạo ra

các mô hình đối tƣợng đƣợc vẽ từ tập thực thể của nghiệp vụ, nhƣ đã đƣợc

đề cập trong các use case. Mô hình nay sau đó lại đƣợc chuyển thanh mô

hình phân tich bằng cách phân loại các đối tƣợng thanh 3 loại: đối tƣợng

giao diện, đối tƣợng thực thể, va đối tƣởng điều khiển.

13.3.5 LBMS SEOO

Systems engineering OO (SEOO) is a proprietary methodology and

tool kit from the U.K.-based company LBMS. The four major components

of the SEOO methodology are:

• Work-breakdown structures and techniques

• An object modeling methodology

• GUI design techniques





• Relational database linkages to provide ER modeling and 4GL-specific

features

Systems engineering Object-Oriented (SEOO) la một phƣơng pháp

độc quyền va bộ công cụ của công ty LBMS. Bốn phần chinh của phƣơng

pháp SEOO là:

• Work-breakdown structures and techniques

• An object modeling methodology: Phƣơng pháp mô hình đối tƣợng.

• GUI design techniques: Kĩ thuật thiết kế giao diện đồ họa.

• Relational database linkages to provide ER modeling and 4GL-specific

features: sự kết hợp với cơ sở dữ liệu quan hệ để cung cấp mô hình ER

va các đặc trƣng 4GL-specific.

13.3.6 Phƣơng Pháp Rumbaugh OMT

James Rumbaugh‘s methodology is described in his book Object-

Oriented Modeling and Design (Prentice-Hall, New York, 1991).

Rumbaugh starts by assuming that a requirements specification exists.

Analysis consists of building three separate models:

• The object model (OM): definition of classes, together with attributes

and methods; the notation is similar to that of ER modeling with

methods (operations) added





• The dynamic model (DM): state transition diagrams (STDs) for each

class, as well as global event-flow diagrams

• The functional model (FM): diagrams very similar to data-flow

diagrams

Phƣơng pháp luận của James Rumbaugh đƣợc mô tả trong cuốn sách

Object-Ori-ented Modeling and Design (Prentice-Hall, New York, 1991).

James Rumbaugh mở đầu bằng cách cho rằng các chi tiết yêu cầu la phải

có. Phân tich bao gồm xây dựng 3 hình thức riêng biệt:

Mô hình đối tƣợng (Object Model – OM): những định nghĩa của lớp,

thuộc tinh va phƣơng thức; các ki hiệu cũng giống nhƣ của mô hình ER với

những phƣơng thức thêm vao

Mô hình động (Dynamic Model – DM): đồ thị chuyển đổi trạng thái

(State Transition Diagrams – STDs) cho từng lớp cũng nhƣ các đồ thị dòng

sự kiện toan cục

Mô hình chức năng (Function Model – FM): đồ thị rất giống với dồ

thị dòng dữ liệu

13.3.7 Shlaer và Mellor:

Shlaer and Mellor‘s work is one of the earliest examples of OO

methodology. (See Shlaer and Mellor‘s books, Object-Oriented Systems





Analysis: Modeling the World in Data and Object Lifecycles: Modeling the

World in States, Prentice-Hall, New York, 1988 and 1992, respectively.)

The Shlaer and Mellor methodology starts with an information

model that describes objects, attributes, and relationships. Next, a state

model documents the states of objects and the transitions between them.

Finally, a data-flow diagram shows the process model.

Những tìm hiểu của Shlaer and Mellor la một trong những vi dụ

nguyên thủy của phƣơng pháp hƣớng đối tƣợng. Phƣơng pháp luận của

Shlaer and Mellor bắt đầu với những mô hình thông tin mô tả đối tƣợng,

thuộc tinh, các mối quan hệ. sau đó, mô hình trạng thái ghi nhận những

trạng thái của đối tƣợng va sự chuyển đổi giữa chúng. Cuối cùng biểu đồ

dòng dữ liệu cho thấy mô hình tiến trình

13.3.8 OOAD Simplied

Organizations that have purchased an OO software tool generally

adhere to the OOAD methodology that the tool encompasses (i.e.,

Objectory, LBMS, etc.). Other organizations, however, are free to mix and

match the ―best of breed‖ components of a wide variety of OOAD

methodologies.This section explains one such simplified approach.

1. Create the system boundary diagram. The first step in the analysis and

design is the creation of a system boundary diagram. This diagrams the

domain model and its relationship with external systems or users, as





shown in Exhibit 13-5. The model structure diagram depicts the

relationship of the domain objects.

2. Develop an actor list of external systems and users (Exhibit 13-6).The

actor list shows each actor and his or her role in the domain model.

Gather information about these actors.

3. Create use cases and scenarios. Use cases are a user-centered analysis

technique to capture requirements from a user‘s point of view;they

describe the possible sequences of interactions among the systems with

one or more actors. Use cases illustrate high-level abstract functions

without writing code. Scenarios capture the exceptions, nonstandard

responses, and problems from the normal use case flow. Exhibit 13-7

shows a sample use case diagram and Appendix E shows a set of use

case diagrams with associated scenarios.

4. Generate CRC cards, which are note cards that contain the domain

model‘s classes, their responsibilities, and collaborators (Exhibit 13-8).

The nouns used in the uses cases become the potential classes in the

CRC cards. The verbs are the class‘s responsibilities; the collaborators

help the classes do their jobs.

5. Draw a collaboration graph depicting the collaborations (i.e.,

relationships between objects) uncovered during the CRC process





(Exhibit 13-9) and event traces to represent how events cause flow

from one object to another (Exhibit 13-10).

6. Create a system class diagram from the information derived in the

preceding exercises. Exhibit 13-11 shows a class diagram depicted in

terms of a system‘s subsystems. In the case of an OO system we use

the term package, which is a collection of classes. Subsequent diagrams

will depict each class as shown in this highest level class diagram

(Exhibit 13-12).

Những tổ chức mua các công cụ phần mềm hƣớng đối tƣợng thƣờng

bám vao phƣơng pháp OOAD đƣợc bao gồm trong công cụ đó. Phần nay sẽ

diễn tả cách đơn giản hóa cách tiếp cận đó.

Tạo ra biểu đồ đƣờng biên hệ thống (System Boundary Diagram).

Bƣớc đầu tiên trong phân tich va thiết kế la việc tạo nên biểu đồ biên hệ

thống. Biểu đồ nay mô tả mô hình miền va mối quan hệ với các hệ thống

bên ngoai hay ngƣời dùng. Biểu đồ cấu trúc mô hình mô tả quan hệ giữa

các đối tƣợng trong miền.

Phát triển danh sách actor của các hệ thống bên ngoai va ngƣời dùng.

Danh sách nay cho biết vai trò của từng actor trong mô hình miền. Thu thập

thông tin về những actor nay.

Tạo ra các use cases va các kịch bản (scenarios). Use cases la kĩ

thuật phân tich lấy ngƣời dùng lam trung tâm để đƣa ra các yêu cầu từ góc





nhìn của ngƣời dùng; chúng mô tả những chuỗi tƣơng tác giữa các hệ thống

với một hay nhiều actors. Use cases minh họa chức năng trừu tƣợng ở mức

cao ma không lập trình. Kịch bản nắm bắt những phản hồi ngoại lệ, không

đúng chuẩn va những vấn đề trong dòng sự kiện thông thƣờng

Tạo ra các thẻ CRC (CRC cards), la những thẻ bao gồm các lớp mô

hình miền, trách nhiệm va các cộng tác viên (collaborators). Các danh từ sử

dụng trong use cases tiềm tang khả năng trở thanh những lớp trong thẻ

CRC. Động từ la những trách nhiệm của các lớp; còn collaborators giúp cho

các lớp lam công việc của mình.

Vẽ biểu đồ cộng tác mô tả những sự liên kết (vi du: các mối quan hệ

giữa các đối tƣợng) đƣợc sinh ra trong quá trình CRC hoạt động va dòng sự

kiện để đại diện cho các sự kiện tạo thanh dòng từ đối tƣợng nay sang đối

tƣợng khác.

Tạo ra biểu đồ lớp hệ thống từ những thông tin lấy đƣợc từ các hoạt

động trƣớc. Với trƣờng hợp hệ thống hƣớng đối tƣợng, ta sử dụng thuật ngữ

package, một bộ các lớp (classes). Những đồ thị con sẽ mô tả những lớp

đƣợc vẽ trong đồ thị gốc

Từ điển dữ liệu la một bộ các chi tiết tiến trình có thể tạo ra toan bộ

dữ liệu va các tiến trinh đƣợc định danh trong tất cả thiết kế man hình.





Sử dụng phƣơng pháp hƣớng đối tƣợng la một quá trình lặp đi lặp

lại; các bƣớc đƣợc miêu tả va minh họa ở trên có thể đƣợc thay đổi va tiến

hóa.




Chương 14:Thiết kế giao diện người dùng 507

CHƢƠNG 14 THIÊT KÊ GIAO DIÊN NGƢƠI

DÙNG

Người dịch:



3. Lê Văn Chân

4. Lê Anh Khoa






Like many aspects of software engineering, in order to be effective,

user interface design needs to be analyzed, planned, and implemented in a

detailed and organized manner. With the demand for enhanced functionality

and implementation of increasingly complex systems, the pressure to

produce user interfaces that satisfy all user requirements becomes a great

challenge. Without guiding principles and a fundamental plan of attack,

developers are doomed to failure. Fortunately, as computer systems have

grown more complex, facilities for creating user interfaces quickly and

more efficiently have also come on stream. However, tools alone do not

make for a good user interface design.

Cũng nhƣ những khia cạnh khác trong công nghệ phần mềm, để hiệu

quả, thiêt kê giao diên ngƣơi dung cân đƣơc phân tich , lên kê hoach , va

đƣơc cai đặt một cách chi tiêt va co tô chƣc . Vơi nhu câu vê tinh năng nâng

cao va sƣ phát triển cac hê thông nga y cang phƣc tap , áp lực tạo ra những

giao diên ngƣơi dung thoa man tât ca nhƣng đoi hoi cua ngƣơi sƣ dung la

môt thƣ thach lơn . Môt khi thiêu hƣơng dân vê nhƣng nguyên tăc cơ ban

hay kê hoach nên tang , ngƣơi phat tri ển sẽ thất bại . Nhƣng may măn thay ,

khi cac hê thông may tinh phat triên phƣc tap hơn thi sƣ tiên nghi trong viêc

thiêt kê giao diên ngƣơi dung cung đƣơc trở nên nhanh va hiêu qua hơn .

Tuy nhiên chỉ dùng công cu thì thể không t ạo ra một thiết kế giao diện

ngƣơi dung tôt.

User interfaces have matured rapidly over the last decade. The

increasing speed and power of the PC and the growth of the Internet have





fueled the development of larger and more complex applications requiring

easier and more intuitive user interfaces. As application developers deliver

more sophisticated and robust applications, users expect and demand better

and more intuitive user interfaces to accompany those applications.

Competition among application developers is fierce and a product‘s user

interface plays a key role in adoption and acceptance by its user

community.

Giao diên ngƣơi dung phat triên nhanh chong trong thâp ky qua .

Viêc may tinh ngay cang tăng tôc tôc đô va sƣ phat triê n manh cua Internet

la dẫn tới sự phát triển những ứng dụng lớn va phực tạp hơn , nhƣng lại đoi

hỏi giao diện ngƣời dùng dễ dang va trực quan hơn . Môt khi nha phat triên

ứng dụng đƣa ra những sản phẩm tinh vi va công phu thì ngƣơi sƣ dung ho

cang mong chờ sản phẩm đó tốt hơn va giao diện trực quan hơn . Sự canh

tranh giƣa cac nha phat triên ƣng dung rât khắc nghiệt va giao diên ngƣơi

dùng của sản phẩm đóng vai trò chinh trong việc cộng đồng ng ƣời sử dụng

có lựa chọn va chấp nhận sản phẩm hay không.

14.1 NHỮNG NGUYÊN TẮC CƠ BẢN CỦA THIẾT KẾ GIAO DIỆN

No discussion of user interface design would be complete without

reference to the underlying principles that guide good user interface design.

Volumes have been written on the subject. The following are pointers to a

few of the lists of user interface design principles from various sources:





Design Basics, from the Internet, http://www-

3.ibm.com/ibm/easy/eou_ext.nsf/Publish/6 (IBM).

Practical Real World Design, First Principles, from the Internet,

http://www.asktog.com/basics/firstPrinciples.html (Tognazzini,).

Principles of Good GUI Design, from the Internet,

http://axp16.ii.e.,org.mx/Monitor/v01n03/ar_ihc2.htm (Hobart,).

Muôn thiêt kê giao diên ngƣơi dung tôt chăc chăn phai co tai liêu

tham khao hƣơng dân tôt vê cac nguyên tăc thiêt kê cơ ban . Đã có rất nhiều

tai liệu nói về điều nay. Dƣới đây la môt sô nguôn tham khao:

Design Basics, from the Internet, http://www-

3.ibm.com/ibm/easy/eou_ext.nsf/Publish/6 (IBM).

Practical Real World Design, First Principles, from the

Internet,http://www.asktog.com/basics/firstPrinciples.html

(Tognazzini,).

Principles of Good GUI Design, from the

Internet,http://axp16.ii.e.org.mx/Monitor/v01n03/ar_ihc2.htm (Hobart).

The perspectives are somewhat different, but all espouse the same

basic principles, reiterated here for emphasis:





Quan điêm thi co chut gi đo hơi khac nhau , nhƣng tât ca đêu tuân

theo cac nguyên tăc cơ ban dƣới đây:

Put the user in control. The user is obviously the most important

player in this game and should be able to customize the interface to suit his

or her preferences or needs. Whenever possible, account for the user‘s skill

level; categories such as novice, occasional user, and frequent user make a

good starting point. One example of this is a Macintosh word processing

product. A set of five options enables the user to set the desired level of

experience ranging from ―novice‖ to ―power user‖. Choosing a level results

in filtering menus for only those options required by a user of the selected

experience. A user gaining more experience at a specific level can move to

the next level when ready.

Chú trọng đến ngƣơi sƣ dung: Rõ rang ngƣời sử dụng đóng vai trò

quan trong nhât va nên đƣợc lựa chon giao diên phu hơp vơi sơ thich , nhu

câu cua ho . Bât cƣ khi nao co thê , hãy chú ý đến kha năng cua ngƣơi dung :

ngƣơi mơi hoc , ngƣơi sƣ dung không thƣơng xuyên va ngƣơi sƣ dung

nhiêu. Môt vi du vê san phâm xƣ ly văn bản cua Macintosh : môt tâp hợp

gồm năm tuy chon cho phep ngƣơi sƣ dung chọn mƣc mong muôn để lam

việc, tƣ ―ngƣơi mơi băt đâu ‖ cho đên ―ngƣơi thanh thao‖ . Lựa chọn một

mức dẫn tới việc ứng dụng chỉ hiện thị những danh mục phù hợp với mức

đó. Ngƣơi dung khi đã đạt đƣợc nhiêu kinh nghiêm hơn ơ môt mƣc cu thê

môt co thê chuyên sang mƣc tiêp theo.





Be direct. The user should be allowed to work with the information

presented by the application directly. When a user performs an action, the

result of the action should be immediately apparent.

Trƣc tiêp: Nên cho phep ngƣơi dung trƣc tiêp lam viêc vơi thông tin

hiên thi trên ƣng dung . Khi ngƣơi dung thƣc hiên môt hanh đông , kêt qua

của nó phải rõ rang.

Use appropriate metaphors. Whenever possible use metaphors that

are familiar to the user. Metaphors help to make the user more comfortable

when using the software and provides for a more intuitive interface. For

example, a checkbook is a suitable metaphor for an application that

manages a user‘s bank account.

Sƣ dung tinh đôi sanh thich hơp: Sƣ dung tinh đôi sanh quen thuôc

vơi ngƣơi sƣ dung bât cƣ khi nao co thê . Tinh đối sánh giúp cho con ngƣời

ta thoai mai hơn khi sƣ dung phân mêm va no cung câp giao diên trƣc quan

hơn. Vi dụ nhƣ hình dáng một cuốn sổ ghi séc la một hì nh anh đôi sanh

thich hợp cho ứng dụng quản lý tai khoản ngân hang của ngƣời dùng.

Make the interface consistent. Consistency in design makes it

easier for the user to apply skills learned on one task to another task. Users

should not need to spend time trying to remember differences in behavior

among objects. Many Windows applications, for example, have the same

basic pattern for menus; File and Edit are always the first two menus on the





left and Help is typically the last menu on the right, as indicated in Exhibit

14-1.

Tạo giao diện nhất quán : Tinh nhất quán trong thiết kế lam cho

ngƣơi dung áp dung nhƣng ky năng đa hoc tƣ công viêc nay sang công viêc

khác dễ dang hơn. Ngƣơi dung không cân danh thơi gian đê nhơ nhƣng cac

thao tác khac nhau trên cac đôi tƣơng khác nhau . Nhiêu ƣng dung windows

có cùng một kiểu menu cơ bản : File va Edit la 2 menu đâu tiên bên trai va

Help la cai cuôi bên phai. Xem hinh minh hoa 14-1.

Regular users of Windows applications expect these menus in this

order; therefore, it does not make sense to break this paradigm.

Nhƣng ngƣơi dung thông thƣơng đêu mong đơi cac trât tƣ menus

nay thanh ra đừng nên phá vơ nó.





Provide shortcuts. For novice users, shortcuts may not be all that

important, but as the user gains experience with the interface, inevitably he

will look for faster and more efficient ways of getting the job done.

Cung câp phim tăt : Vơi nhƣng ngƣơi mơi băt đâu , phim tắt không

phải la tât ca nhƣng gi quan trong , nhƣng với ngƣơi dung co kinh nghiêm ,

họ sẽ cần nhƣng cach nhanh hơn va hiêu qua hơn đê hoan thanh công viêc.

Shortcuts play a key role here and are greatly appreciated by power

users. I know one technical writer who works in Microsoft Word with the

toolbar and menu bar hidden, doing all formatting work with only shortcuts.

Quite amazing!

Phim tắt đóng vai trò quan trọng va đƣợc những ngƣời dùng chuyên

nghiệp đanh gia cao . Tôi biết một nha văn lam việc bằng Microsoft Word

với thanh công cụ va thanh trình đơn ẩn, tất cả các thao tác chỉ thông qua

các phim tắt. Khá tuyệt vời!

Be forgiving. The user should be allowed to change his mind and

reverse a previously performed action. If circumstances make it impossible

to reverse the result of an action, provide an indication to the user up front,

indicating that the action about to take place cannot be reversed. It is also

important to make error recovery as easy as possible.

Khoan dung: Nên cho phep ngƣơi dung thay đôi suy nghi cua ho va

quay lai hanh đông trƣơc cua ho . Trong trƣơng hơp không thê khắc phục





đƣợc kêt qua một khi đã hanh đông thi hiên thi thông bao cho ho răng hanh

đông ho sắp lam sẽ không đảo ngƣợc đƣợc . Khôi phục sau lỗi cần cang dễ

cang tốt.

Provide feedback. It is important that the user know what task is

being performed. We all know how frustrating it can be when a program

freezes the system while it is performing a task with no visual indication

that the task is being performed or completed. Visual queues should be used

to provide user interaction and feedback appropriate to the task performed.

Cung câp thông tin phan hôi : Điêu quan trong la ngƣơi sƣ dung

biêt viêc gi đang đƣơc thƣc hiên. Tât ca chung ta biêt thê nao la bƣc bôi khi

môt chƣơng trinh lam đứng hệ thông trong khi ban thân no đang thƣc hiên

công viêc , không co 1 chỉ thị trực quan nao cho biết công việc đang đƣợc

thƣc hiên hay hoan thanh . Nên sƣ du ng nhƣng hang đơi trƣc quan đê cung

câp sƣ tƣơng tac ngƣơi dung va phan hôi thich hơp vơi nhiêm vu thƣc hiên.

Make the interface aesthetically pleasing. An important aspect of

the user interface is its visual appearance. Visual elements on the screen

compete for the user‘s attention. It is not a simple task to get the right

balance so that the user‘s attention is focused on the right elements at the

right time. Often it is necessary to acquire the services of a graphics

designer to get the right result. A professionally designed, aesthetically

pleasing application is more likely to gain acceptance among users than one

that lacks this characteristic.





Giao diên phai co tinh thâm my : Môt khia canh quan trong cua

giao diên ngƣơi dung la hinh thƣc cua no . Nhƣng yêu tô trƣc quan trên man

hình thu hút sự chú ý cho ngƣời dùng. Không phai đơn gian đê co đƣơc môt

sƣ cân băng chinh xac đê sƣ chu y cua ngƣơi dung tâp trung vao nhƣng yêu

tô chinh vao đung thơi điêm . Thƣơng thi cân phải thuê môt nha thiêt kê đô

họa để có đƣợc một kết quả chinh xác . Môt ƣng dung đƣợc thiêt kê chuyên

nghiêp, mang tinh thâm my thi co nhiêu kha năng danh đƣơc sƣ châp thuân

tƣ phia ngƣơi dung hơn nhƣng ƣng dung thiêu đi đăc tinh nay.

Be as simple as possible. This may sound simple, but from the

developer‘s perspective simplifying the user interface typically involves

quite a bit of work. In a complex application or product, try to develop a

user interface that exposes only information necessary for the user to get the

task done.

Đơn gian nhât co thê: Điêu nay nghe co ve đơn gian, nhƣng tƣ quan

điêm cua nha phat triên đê đơn gian hoa giao diên ngƣơi dung thi no thông

thƣơng bao gôm kha nhiêu công viêc . Trong môt ƣng dung hay san phâm

phƣc tap, hãy cố gắng phát triển giao diện chỉ thể hiện những thô ng tin ma

ngƣơi dung cân đê hoan thanh công viêc.

Provide help. A help system is vital. Many different types of help

systems are available. Embedded help is totally integrated within the

application; it provides help instructions for every screen that is part of the

user interface. Online help, typically accessible by choosing an item from





the help menu, is a set of topics about the product; a table of contents,

index, and search mechanism are typically provided so that the user can

browse or search for a topic of interest. Context-sensitive help provides

information about the current context; for example, when a specific dialog

is displayed, the user can press F1 to get information about that dialog.

Tooltip help displays hints; for example, when the cursor hovers over a

toolbar button, help text is displayed as shown in Exhibit 14-2.

Cung câp trơ giup : Môt hê thông trơ giup la rât quan trong . Có

nhiêu loai trơ giup khac nhau . Trơ giup nhung hoan toan đƣơc tinh hơp bên

trong ƣng dung, nó cung cấp những chỉ dẫn giúp đơ cho mỗi phần của giao

diên ngƣơi dung. Hô trơ trƣc tuyên, thông thƣơng co thê truy câp băng cach

chọn mục ở menu trợ giúp , la tập chủ đề về sản phẩm , bảng các nội dung ,

chỉ mục, va cơ chế tìm kiếm thƣờng đƣợc cung cấp để ngƣời dùng có thể

duyêt hay tim kiêm chu đê quan tâm. Hô trơ ngƣ canh cung câp thông tin vê

tình huống hiện tại ; vi dụ khi một hộp thoại hiển thị lên , ngƣơi dung co thê

bâm F1 để xem thông tin về hộp thoại đó. Tooltip giúp hiển thị gợi ý, chăng

hạn khi đƣa con trỏ chuột hiển thị trên một nút thanh công cụ thì văn bản

trơ giup hiên thi nhƣ hinh 14–2.





Two industry standards that provide excellent information on user

nterface design principles are The Windows Interface Guidelines for

Software Design and Macintosh Human Interface Guidelines. Two websites

that provide some excellent examples of good and bad user interface design

are the Interface Hall of Fame, http://www.iarchitect.com/mfame.htm and

the Interface Hall of Shame, http://www.iarchitect.com/mshame.htm. See

the reference list at the end of this chapter for more details about these

sources.





Hai tiêu chuân công nghiêp cung câp thông t in chuân vê nhƣng

nguyên tăc trong thiêt kê giao diên ngƣơi dung la The Windows Interface

Guidelines for Software Design va Macintosh Human Interface Guidelines.

Hai trang web cung câp nhƣng vi du chuân vê thiêt kê giao diên ngƣơi dung

hay va dở la Interface Hall of Fame, va Interface Hall of Shame. Xem danh

sách tai liệu tham khảo ở cuối chƣơng để biết thêm chi tiết.

14.2 QUÁ TRÌNH THIẾT KẾ GIAO DIỆN

Principles are good, but how and when do we apply them? One of

the most popular user interface design methodologies is one that mimics the

overall software development process. This process consists of four phases;

each phase is repeated during each iteration of the cycle. A summary of the

design process is shown graphically in Exhibit 14-3 and each of its phases

is described briefly below:

Nguyên tăc la tôt nhƣng khi nao chung ta ap dung chung va ap dung

chúng nhƣ ra sao ? Môt trong nhƣng phƣơng phap thiêt kê giao diên ngƣơi

dùng phổ biến nhất la bắt chƣớc qu á trình phát triển phần mềm tổng thể .

Quá trình nay bao gồm bốn giai đoạn , môi giai đoan đƣơc lăp lại qua môi

chu ky. Môt ban tom tăt cua qua trinh thiêt kê đƣơc thê hiên đô hoa ơ hinh

14 – 3 va mỗi giai đoạn của nó đƣơc diên giai văn tăt nhƣ sau:

Analysis. This phase involves collection of information about the

user and the tasks that he or she will want to perform using the application.





An excellent, highly rated book on this subject is User and Task Analysis

for Interface Design (Hackos and Redish, 1998). This book clearly

separates analysis from design and provides guidelines and techniques for

eliciting task information from prospective users.

Phân tích: Giai đoạn nay bao gồm việc thu thập thông tin về ngƣời

sử dụng va các công viêc ma ngƣời đó sẽ muốn thực hiện bằng các ứng

dụng. Cuôn sach đƣơc đanh gia cao vê chu đê nay la User and Task

Analysis for Interface Design (Hackos and Redish , 1998). Nó tách biệt rõ

rang việc phân tich từ thiết kê va cung câp cac phƣơng châm va kỹ thuât thu

thâp thông tin công viêc tƣ ngƣơi dung tiêm năng.

Design. Once the analysis has been completed and all tasks have

been identified, the process of identifying the required objects and the

actions to be performed can begin. User scenarios play a key role in this

phase. From the scenario narrative, the designer can extract the objects

(typically nouns) and the actions (typically verbs) to build a list of required

elements. One book that addresses many of the issues that the developer

faces during the design phase is User Interface Design for Programmers

(Spolsky, 2000).

Thiêt kê: Môt khi hoan thanh bƣơc phân tich va tât ca cac công viêc

đa đƣơc xac đinh , quá trình xác định đối tƣợn g va nhƣng hanh đông cần

đƣơc thƣc hiên co thê băt đâu. Kịch bản ngƣời dùng đóng vai trò quan trọng

trong giai đoan nay. Tƣ kich ban, ngƣơi thiêt kê co thê lây nhƣng đôi tƣơng





(thƣơng la danh tƣ ) va hanh động (thƣơng la động từ ) để xây dựng danh

sách các yếu tố đƣợc yêu cầu . Môt cuôn sach đê câp đên nhiêu vân đê ma

môt ngƣơi thiêt kê đôi măt trong suôt giai đoan thiêt kê la : User Interface

Design for programmers (Spolsky, 2000).

Implementation. In the implementation phase, a prototype is

produced. This is typically achieved using one of the many fourth-

generation languages or programming development environments (Visual

Basic, Visual C++, Visual J++, Java, etc.) that allow the rapid development

of user interfaces using predefined libraries of components such as

Windows, Menus, Buttons, Drop-Down list controls, Tree controls, etc.

Thưc thi: Môt mâu thƣ nghiêm đƣơc tao ra trong giai đoan thƣc thi .

Mâu nay thƣờng đƣợc tạo băng ca ch sƣ dung môt trong cac ngôn ngƣ thê

hê thƣ tƣ hoăc nhƣng môi trƣơng phat triên lâp trinh nhƣ (Visual Basic ,

Visual C, Visual J, Java, v.v.), chúng cho phép phát triển nhanh chóng của

giao diên ngƣơi dung băng cach sƣ dung thƣ viên đa đƣơc đinh nghia trƣơc

nhƣ cửa sổ, thực đơn, nút bấm, Drop-Down, danh sách, cây,…

Test. When the prototype is complete, the developer can take the

software to the customer for user interface evaluation. Users can test drive

the software and make suggestions for improvements, which become part

of the analysis phase. Then the cycle can begin again to refine the process

further. Pamela Savage compares three different evaluation techniques: 1)





expert reviews, 2) user reviews, and 3) interactive usability testing, with the

conclusion that all three play a role in the evaluation process.

Kiêm tra : Khi cac mâu thƣ nghiêm hoan tât , nha phát triển có thể

đƣa phân mêm cho khach hang đê đanh gia giao diên ngƣơi dung. Ngƣơi sƣ

dụng có thể chạy thử phần mềm va đề xuất một số vấn đề cải thiện – môt

phân cua giai đoan phân tich. Sau đo, chu ky co thê băt đâu lai đê tinh chinh

nhƣng qua trinh xa hơn . Pamela Savage so sanh ba ky thuât đanh gia khac

nhau: 1. Chuyên gia đanh gia, 2. Ngƣơi dung đanh gia, 3. Kiêm tra tinh tiện

dụng trong tƣơng tac , vơi kêt luân tât ca ba ky thuât đong môt vai tro trong

quá trình đánh giá.

One aspect of good user interface design not immediately apparent

from the four phases of the design cycle described here is that the design

involves input from many different disciplines in addition to software

development. These disciplines include visual designers, writers, human

factors experts, and, of course, the user. A well-balanced team of people

providing input from different perspectives is critical to the success of the

user interface.

Môt khia canh cua thiêt kê giao diên ngƣơi dung tôt không đƣợc nêu

rõ trong bôn giai đoan cua chu ky thiêt kê diên ta ơ trên la thiêt kê bao gôm

đâu tƣ vao nhiêu nganh kiên thƣc khac nhau bên canh phat triên phân mêm .

Các nganh nay gồm ngƣời thiết kế trực quan , nhƣng ngƣơi viêt , nhƣng

chuyên gia vê con ngƣơi va tât nhiên nƣa l a ngƣời sử dụng . Môt đôi ngu





đung mƣc cung câp đâu vao vơi nhƣng quan điêm khac nhau la rât quan

trọng cho sự thanh công giao diện ngƣời dùng.

14.3 THIẾT KẾ NHẬP XUẤT HIỆU QUẢ

Some systems analysts believe that designing input and output is the

most important task in designing a system because it is the part the end user

actually sees. Even though some people might disagree with this point of

view, poorly designed input and output may cause an otherwise well

designed and solidly implemented system to fail. When systems analysts

design input and output, there are three aspects of concern: (1) the input and

output data (data flow) between software components, (2) the design of

input and output between the software and other nonhuman producers and

consumers of information, (3) the interaction between the user and the

computer.

Môt sô nha phân tich tin răng thiêt kê nhập xuất la nhiêm vu quan

trọng nhất trong thiết kế hệ thống vì nó la phần ngƣời sử dụng cuối thực sự

thấy. Măc du môt sô ngƣơi không đông y vơi quan điêm nay , thiêt kê nhập

xuất kem co thê khiến cả một hệ thống đƣợc thiết kế va cai đặt cẩn thận bị

thất bại. Khi nha phân tich hê thông thiêt kê nhập xuất, có ba điểm cần quan

tâm: 1. Dữ liệu nhập xuất (luông dƣ liêu) giƣa cac thanh phân phân mêm. 2.

Thiết kế nhập xuất giữa phần mềm va các đối tƣợng nhập xuất thông tin

không phải la con ngƣời 3. Tƣơng tac giƣa ngƣơi dung va may tinh.





14.3.1 Thiết kế nhập

A key factor for developing the design input is the customer‘s

requirements. This includes, but is not limited to: end-user expectations,

patterns of end-user usage, security, and performance. The customer should

not be the only consideration, however. All factors relevant to the design of

the system should be considered, including management requirements,

interface requirements, and other related processing requirements.

Yêu tô chinh đê phat triên đâu vao thiêt kê la yêu câu cua khach

hang, bao gôm (nhƣng không giơi han trong): sƣ mong chơ cua ngƣơi dung

cuôi, các cách sử dụng của ngƣời dùng cuối , bảo mật , va hiệu suất . Tuy

nhiên, không nên chi xem xet tƣ phia măt khach hang . Tât ca nhƣng yêu tô

liên quan đên viêc thiêt kê đ ầu vao của hệ thống đều phải đƣợc xem xét ,

gôm co cac yêu câu quan ly , yêu câu giao diên, va những yêu cầu xử lý liên

quan khac.

A variety of media and methods is used to capture and input data so

that it can be used properly, including: (1) paper forms combined with data

entry screens, (2) electronic forms, and (3) direct entry devices.

Sƣ phong phu cua đa phƣơng tiên va cac phƣơng phap đƣơc sƣ dung

để thu thập va nhập dữ liệu để nó có thể đƣợc sử dụng hợp lý , gôm co: 1.

Các dạng dữ liệu giấy kết hợp với các man hình nhập liệu . 2. Dạng điện tử.

3. Thiêt bi nhập trƣc tiêp.





14.3.1.1 Giấy

Even though the usage of computers is very common, it would be

surprising to find a system that did not have at least one input or output

paper form. Paper forms carry data physically. In every business or

organization there are manual transactions that might require the use of

manual forms, such as order forms, sales transactions, and surveys. The

data captured on these forms, therefore, must be entered into the system for

processing. Guidelines for designing a paper form include:

Măc dâu viêc sƣ dung may tinh la rât phô biên, nhƣng nêu tim ra môt

hê thông ma không co it nhât môt mâu giây tơ đâ u vao hay đâu ra nao thi la

điêu đang ngac nhiên . Biểu mẫu lƣu trữ dữ liệu một cách vật chất . Trong

nhƣng doanh nghiêp hay tô chƣc , có những giao dịch thủ công đòi hỏi sử

dụng những hình thức thủ công chẳng hạn nhƣ mẫu đơn đặt hang, giao dich

bán hang va các bản khảo sát . Dƣ liêu đƣơc lây thông qua cac dang nay vi

vây phai đƣơc nhâp vao hê thông đê xƣ ly . Nguyên tăc thiêt kê biểu mâu

giây bao gôm:

Select proper paper. Papers of different colors, grades, and weight

might be used to print a form. When we select a paper for our form, we

need to consider some factors, for example: how long the company will

keep it, how to fill in the form (handwritten or printed), how it will be

handled (gently, roughly), and if the paper is easy and convenient to use.





Chọn đúng giấy : Giây có mau khac nhau , loại giấy, va trọng lƣợng

có thể đƣợc sử dụng để in ra mẫu . Khi chung ta chon dang giây đê lam

mâu, chúng ta cần xem xét một số yếu t ố. Vi dụ: Thơi gian công ty giƣ no ,

điên vao mâu băng cach nao (viêt tay hay in ), sử dụng nó thế nao (nhẹ

nhàng, mạnh bạo), va giấy có dễ va tiện để dùng hay không.

The size of paper should be appropriate. The most popular size is 8.5

by 11 inches. If you require a smaller form, try to use half of this standard

size: 8.5 by 5.5. For card forms, the standards start with 8 by 10 inches. It is

best not to use nonstandard sizes because those sizes often have problems in

handling and filing and usually increase the cost of devices and papers.

Kich thƣớc giấy phải thich hợp: Cơ phô biên nhât la 8.5x11inch. Nêu

bạn muốn mẫu nhỏ hơn , cô găng sƣ dung môt nửa cua cơ chuân nay

(8.5x5.5). Đối với hình thức thẻ , cơ chuân la 8x10. Tôt nhât la đƣng sƣ

dụng kich cơ không chuẩn vì chúng thƣờng đụng các vấn đề về xử lý , điên

thông tin va thƣơng lam tăng chi phi cua thiêt bi va giây tơ.

Forms should be easy to fill out. To make forms easy to fill out, the

following techniques are used: (1) Put simple instructions or examples on

the form to assist users. (2) Form flow should be designed to follow a

logical sequence (left to right, top to bottom) (See Exhibit 14-4). (3) Group-

related data should be in the same section. (4) Each section and field should

have a caption that tells the user what to put there. (5) Use proper space to





make the form clearer. (6) Using lines and boxes can also help. (7) Have

alternative selections capability (i.e., use of a check box).

Mâu nên dê điên : Đê tao nhƣng mâu dê điên , sƣ dung ky thuât : 1.

Đặt chỉ dẫn thông tin hoặc những vi dụ đơn giản trên mẫu để hỗ trợ ngƣời

sƣ dung . 2. Nên thiêt kê dong mâu theo logic (trái sang phải , trên xuông

dƣơi) (xem hinh 14–4). 3. Nhƣng nhom dƣ liêu liên quan nên thuôc cung

môt muc. 4. Môi muc va linh vƣc phai co chu thich chi cho ngƣơi dung nên

viêt gi vao đo . 5. Bô tri không gian thich hơp đê lam cho mâu ro rang hơn .

6. Cũng co thê sƣ dung dong va cac hôp vuông . 7. Cho phép có những lƣa

chọn khác nhau (vi dụ nhƣ sử dụng check box).

Design to meet the purpose of a form. A systems analyst should

design different forms to better reflect different process requirements even

if several forms are similar to each other.

Thiêt kê đê đap ƣng cac muc đich cua mâu : Môt nha phân tich hê

thông nên thiêt kê nhƣng mâu khac nhau đê phan anh tôt hơn nhƣng yêu

câu xƣ ly khac ngay cả khi môt vai dang la tƣơng tƣ nhau.

Make the form attractive. An attractive form can encourage the user

to complete it. A form should be designed to look neat and the input fields

should be logically ordered. Aesthetic forms or usage of different fonts

within the same form can help make it attractive.





Tạo mẫu lôi cuốn : Mâu lôi cuôn co thê tao cơ hôi cho ngƣơi ngƣơi

sƣ dung hoan thanh no . Nên thiêt kê mâu nhin gon va cac trƣơng đâu vao

cân co thƣ tƣ logic . Các hình thức thẫm mỹ hay cá c phông chƣ khac nhau

trên cung môt mâu cung gop phân lam cho no thu hut, lôi cuôn hơn.





Design evaluation. After a form prototype has been created, we must

give it to the user and check to see if it meets the user‘s requirements. The

user can provide some suggestions and the designer can make modifications

according to the suggestions. The evaluation cycle (see Exhibit 14-5)

repeats until users are satisfied with the form.

Đanh gia thiêt kê : Sau khi tao ra môt mâu thƣ nghiêm mâu , ta phai

đƣa no cho ngƣơi dung đê kiêm tra liêu no co đap ƣng yêu câu cua ngƣơi sƣ

dụng hay không. Ngƣơi dung co thê đƣa ra môt sô đê xuât va ngƣơi thiêt kê

có thể hiệu chỉnh theo hƣớng của đề xuất đó . Chu trinh đanh giá (xem hinh

14 – 5) lăp đi lăp lai cho đên khi ngƣơi sƣ dung thoa man mâu đo.





14.3.1.2 Mâu điên tư

When we talk about electronic forms systems (see Exhibit 14-6), we

turn our attention from paper to screens. Designers must design electronic

forms to reflect the organization of the data source. When it is used by

people (customer, clerk, etc.), it must be designed with all the captions, data

entry fields, and instructions arranged in a logical manner that can help

users completing the forms. The designing guideline for the paper form can

also apply to screen form because both have the same components.

Khi chung ta noi vê hê thông mâu điên tƣ (xem hinh 14-6). Ta

chuyên sƣ chu y tƣ giây sang man hinh . Nhƣng nha thiêt kê phai thiê t kê

nhƣng mâu điên tƣ đê phan anh viêc tô chƣc cua nguôn dƣ liêu . Khi ngƣơi





ta sƣ dung no (khách hang, thƣ ky, …), nó phải đƣợc thiết kế với tất cả các

chú thich , nhƣng trƣơng nhâp liêu , va những chỉ dẫn đƣợc sắ p xêp hơp ly

để có thể giúp ngƣời sử dụng hoan thanh mẫu . Các phƣơng châm thiết kế

mâu giây co thê cung đƣơc ap dung vao dang điên tƣ bơi vi ca hai cung co

nhƣng thanh phân tƣơng tƣ nhau.

Electronic forms have many advantages over paper that make use of

this automated capability much more efficient: (1) the ability to process

calculations; (2) the ability to retrieve data and populate the electronic form

to reduce the number of fields that the user must fill in; (3) ability to

validate each field automatically; (4) the ability to coordinate processes

between tasks; (5) the ability to provide immediate help.

Nhiêu lơi thê cua mâu điên tƣ so vơi giây ma lam cho cach sƣ dung

khả năng tự động nay có nhiều hiệ n qua hơn đo la : 1. Khả năng xử lý các

tinh toán. 2. Khả năng truy xuất dữ liệu va bổ sung dữ liệu để hạn chế thông

tin ngƣời dùng phải nhập . 3. Khả năng kiểm tra tinh hợp của dữ liệu nhập .

4. Khả năng tự động phối hợp giữa những quy trình công việc. 5. Khả năng

cung câp trơ giup ngay lâp tƣc.

In most situations, electronic forms can replace all paper forms and

substantially reduce the cost of a system. Factors that affect the cost

include: (1) printers might run out of paper, causing the system to pause; (2)

electronic forms can prevent many data entry errors and the end user from

using the wrong form; (3) electronic forms can be easily modified to meet





new business requirements; (4) electronic form databases efficiently

manage the many forms in use in an organization.

Trong hâu hêt trƣơng hơp , các mẫu điện tử có thể thay thế tất cả các

mâu giây va giam đang kê chi phi cua môt hê thông . Nhƣng nhân tô anh

hƣơng đên chi phi bao gôm: 1. Máy in hết giây - nguyên nhân hê thông tam

dƣng, 2. Các mẫu điện tử có thể ngăn ngừa một số lỗi nhập liệu do ngƣời

dùng cuối điền sai. 3. Hình thức điện tử có thể đƣợc sửa đổi dễ dang để đáp

ứng những yêu cầu kinh doanh mới . 4. Cơ sơ dƣ liêu các mẫu điên tƣ quan

lý hiệu quả nhiều dạng đƣợc sƣ dung trong cac tô chƣc.

14.3.1.3 Nhưng thiêt bi nhâp trưc tiêp

When using electronic forms, the keyboard is the most common

input device. However, there are some instances where data is not input by

a user or a keyboard is not practical. Other data entry devices include:

• Scanner or optical character reader (OCR)

• Point-of-sale (POS) device

• Automatic teller machines (ATMs)

• Mouse

• Voice recognition





Khi sƣ dung hinh thƣc điên tƣ , ban phim la thiết bị nhập phổ biến

nhât. Tuy nhiên co môt sô trƣơng hơp thƣc tê dƣ liêu không đƣơc nhâp

băng ban phim. Môt sô thiêt bi nhâp liêu trƣc tiêp khac bao gôm:

• Máy quét hoặc máy đọc ki tự quang học

• Thiêt bi POS (Point-of-sale (POS) device)

• Máy ATM (Automatic teller machines (ATMs))

• Chuôt (Mouse)

• Nhân dang tiêng noi (Voice recognition)

14.3.2 Thiêt kê xuất

Output can be produced in a variety of ways: printing, screen, audio,

microform, CD ROM, or electronic output. Each technology has different

speed and cost, and affects the end user differently. When we choose an

output technology, the following should be considered: (1) the purpose of

the output; (2) the person who needs the information; (3) the reason the

output is needed; (4) the way the output will be used; (5) what specific

information will be included; (6) how the output will be viewed, i.e.,

printed on paper, stored on secondary storage such as tape, CD, tape, etc.,

or viewed on the screen; (7) how often the output is to be updated; (8) any

security issues.





Dữ liệu xuất co thê đƣơc tao băng nhiêu cach cach khac nhau : máy

in, man hình, âm thanh, dạng thu nhỏ (microform), CD hoăc la cac đâu ra

điên tƣ . Môi công nghê co tôc đô va ch i phi khac nhau va co anh hƣơng

khác nhau đến ngƣời dùng cuối . Khi chung ta lƣa chon công nghê đâu ra ,

xem xet nhƣng điêu sau : 1. Mục đich của dữ liệu xuất , 2. Ngƣơi cân thông

tin. 3. Lý do cần thiết của dữ liệu xuất . 4. Cách dữ liệu xuất đƣơc sƣ dung .

5. Bao gôm nhƣng thông tin cu thê gi . 6. Dữ liệu xuất đƣơc xem nhƣ thê

nao, vi dụ nhƣ đƣợc in ra giấy , đƣơc lƣu trong bô nhơ ngoai nhƣ băng tƣ ,

CD… hay đƣơc xem trên man hinh . 7. Độ cập nhật thƣờng xuyên của dữ

liệu xuất. 8. Bât cƣ nhƣng vân đê bao mât nao.

14.4 KIỂM THỬ TÍNH TIỆN DỤNG

A user interface design can benefit greatly from usability testing.

Although this testing involves quite a lot of up-front investment, the results

are worth the investment, especially for commercial applications that have

potentially a wide audience. Usability testing involves observing users as

they use the application to perform their required tasks. The tests are

generally administered by human factors specialists and are usually

performed in a special work area where the specialists are separated from

the users by a one-way mirror that enables the specialists to observer users

as the tasks are performed. Users typically describe what they want to do

and how they are going about it using the software. The specialists study

these patterns and use the data to improve the user interface. This technique





is a very effective means of detecting misunderstood or misinterpreted areas

of the user interface. These areas can be redesigned and the tests can be

performed again to check for improvement.

Thiêt kê giao diên ngƣơi dung co thê thu lơi rât nhiêu tƣ viêc kiêm

tra tinh tiện dung . Măc du viêc kiêm tra nay bao gôm kha nhiêu đầu tƣ ban

đầu nhƣng kêt qua lại xứng đáng với gia tri đâu tƣ , đăc biêt la với cac ƣng

dụng thƣơng mại có khách hang tiền năng lớn . Kiêm thử tinh tiện dụng liên

quan đên viêc quan sat ngƣơi sƣ dung khi ho sƣ dung ƣng dung đê thƣc

hiên cac nhiêm vu đƣơ c yêu câu . Quá trình kiểm tra thƣờng đƣợc theo dõi

bơi nhƣng chuyên gia về con ngƣời va đƣợc thực hiện trong một khu vực

lam việc đặc biệt . Ở đó những chuyên gia đƣơc tach biêt tƣ nhƣng ngƣơi

dùng bằng một tấm gƣơng 1 chiều, cho phep ho quan sat ngƣơi dung khi

công viêc đƣơc thƣc hiên . Ngƣơi dung thƣơng diên giai nhƣng gi ho muôn

lam va định lam nhƣ thế nao khi sử dụng phần mềm. Các chuyên gia nghiên

cƣu nhƣng mô hinh nay va sƣ dung dƣ liêu đê cải thiện giao diện ngƣời

dùng. Kỹ thuật nay la một phƣơng tiện rất hiện quả để phát hiện những chỗ

chƣa hiêu hay bi hiêu lâm cua giao diên ngƣời dung . Nhƣng chô nay co thê

đƣơc thiêt kê lai va viêc kiêm tra co thê thƣc hiên lai đê thây sƣ cai thiên.

14.5 KẾT LUẬN

Providing a good user interface is a critical skill for application

developers today. Good user interface design does not happen automatically

despite the myriad of tools available to help developers create them.





Ngay nay cung cấp một giao diện ngƣời dùng tốt la một kỹ năng

quan trong cua ngƣơi phat triên ƣng dung . Thiêt kê giao diên ngƣơi dung

tôt không tự nhiên ma có, dẫu cho có rât nhiêu cac công cu co săn co thê hô

trơ ngƣơi phat triển.

A good portion of this chapter has been devoted to stressing the

design principles; this is not an accident. The developer must learn and

apply basic principles and follow the tried and true process that leads to

quality user interface designs. The formula already exists; it merely needs

to be applied. The developer must always keep the users‘ interests in mind,

especially in cases of conflict between satisfying a user requirement and

taking an easier implementation route. The user interface should strive to

delight and help the user get the job done faster and more efficiently.

Developers must gain as much experience as possible when working with

and being exposed to good user interface designs.

Môt phân lớn cua chƣơng nay đƣơc d anh để nhấn mạnh các nguyên

tăc trong thiêt kê. Điêu nay không phai la tinh cơ. Ngƣơi phat triên phai hoc

va áp dụng các nguyên tắc cơ bản va các quy trình theo đúng nguyên tắc để

tạo ra những thiết kế giao diện ngƣời d ùng có chất lƣợng . Công thƣc thi đa

có, chỉ đơn thuần áp dụng thôi . Ngƣơi phat triên luôn phai giƣ nhƣng môi

quan tâm cua ngƣơi dung trong tâm tri , đăc biêt la trong trƣơng hơp xung

đôt giƣa thoa man yêu câu ngƣơi sƣ dung va việc dễ dang hơn trong quy

trình thực hiện. Giao diên ngƣơi dung nên cô găng thoa man va giup ngƣơi

sƣ dung thƣc hiên công viêc nhanh va hiêu qua hơn . Ngƣơi phat triên phai





cố thu thập cang nhiêu kinh nghiêm cang tôt khi tiêp xuc va lam viêc vơi

các thiết kế giao diện ngƣời dùng tốt.

The user interface is a key component when it comes to the

acceptance of an application or product. It can mean the difference between

adoption and obscurity.

Giao diên ngƣơ i dung la thanh phân chinh để sản phẩm đƣợc chấp

nhận. Nó tạo nên sự khác biệt giữa việc chấp nhận va không chấp nhận.


Hackos, J. and Redish, J. (1998) User and Task Analysis for

Interface Design, John Wiley & Sons, New York.

Hobart, J. Principles of good GUI design, from the Internet,

http://axp16.ii.e.,org.mx/Monitor/v01n03/ar_ihc2.htm.

IBM. Design basics, from the Internet,

http://www3.ibm.com/ibm/easy/eou_ext.nsf/

Publish/6.Isys Information Architects. Interface hall of fame, from

the Internet http://www.iarchitect.com/mfame.htm.





Isys Information Architects. Interface hall of shame, from the

Internet http://www.iarchitect.com/mshame.htm.

Macintosh Human Interface Guidelines. (1993) Addison-Wesley,

Reading, MA.

Savage, Pamela. AT&T Bell Laboratories, User interface evaluation

in an iterative design process: a comparison of three techniques, from the

internet,

http://www.acm.org/sigchi/chi96/proceedings/shortpap/Savage/sp_txt.html.

Spolsky, J. (2000) User interface design for programmers, from the

Internet,

http://www.joelonsoftware.com/uibook/chapters/fog0000000065.html.

The Windows Interface Guidelines for Software Design. (1995)

Microsoft Press, Redmond, WA.

Tognazzini, B. Practical real world design, first principles, from the

Internet, http://www.asktog.com/basics/firstPrinciples.html.

Two additional general sources of information that are worth a

mention even though they are not explicitly referenced in this chapter are:

Sumit, GUI design links, from the Internet, http://www.sum-

it.nl/enguilin.html.





Wilson, C. User interface design bibliography, from the Internet,

http://world.std.com/~uieweb/biblio.htm.

Other Sources:

Blum, B.I. (1992) Software Engineering: a Holistic View, Oxford

University Press, Inc., New York.

Burch, J.G. (1992) System Analysis, Design, and Implementation,

Boyd & Fraser Publishing Company, Boston.

Kendall, K.E. and Kendall, J.E. (2001) System Analysis and Design,

5th ed., Prentice Hall, Inc.,

Upper Saddle River, NJ.Pressman, R.S. (2001) Software

Engineering: a Practitioner‘s Approach, 5th ed., McGraw-Hill Companies,

Inc., New York.

Shaw, M. and Garlan, D. (1996) Software Architecture: Perspectives

on an Emerging Discipline, Prentice Hall, Inc., Upper Saddle River, NJ.

www.sxu.edu/~rogers/bu433/index.html: System design: input,

output, user interface.

www.webster.edu/~crawfodj/2810/pdf/2810ch07.pdf, User interface,

input, and output design.




Chương 15: Software Re-Engineering 540

CHƢƠNG 15 SOFTWARE RE-ENGINEERING

Người dịch:





5. Nguyễn Bá Huy





Organizations spend much money building software applications

customized according to their business rules. In other words, software is the

realization of business rules. When business rules change, software must

also change. Software change is very important because organizations are

now completely dependent upon their software and have invested millions

of dollars in these systems. Therefore, organizations must invest in system

change to maintain the value of these systems. Software re-engineering is a

strategy for software change. It rebuilds existing legacy systems that have

become expensive to maintain or architecturally obsolete.

Các tổ chức tốn nhiều tiền để xây dựng phần mềm ứng dụng theo các

yêu cầu nghiệp vụ. Hay nói cách khác, phần mềm la sự hiện thực hóa các

quy định nghiệp vụ. Khi các quy định nghiệp vụ thay đổi, phần mềm cũng

phải thay đổi. Sự thay đổi phần mềm la rất quan trọng bởi vì các tổ chức

ngay nay hoan toan phụ thuộc vao phần mềm va họ đã đầu tƣ hang triệu đô

la vao những hệ thống đó. Vì thế ma, các tổ chức phải đầu tƣ vao sự thay

đổi hệ thống để bảo trì chất lƣợng hệ thống. Tái cơ cấu lại phần mềm la

chiến lƣợc cho sự thay đổi phần mềm. Nó xây dựng lại kế thừa hệ thống có

sẵn, cái ma trở nên đắt để bảo trì kiến trúc lỗi thời





15.1 WHAT IS SOFTWARE RE-ENGINEERING?

Software re-engineering is (usually) concerned with reimplementing

legacy systems to make them more maintainable. Re-engineering may

involve redocumenting the system, organizing and restructuring the system,

translating the system to a more modern programming language, or

modifying and updating the structure and values of the system‘s data. The

functionality of the software is not changed and, normally, the system

architecture also remains the same. Re-engineering improves the system

structure, creates new system documentation, and makes it easier to

understand.

Tái cơ cấu phần mềm thƣờng đề cập đến sự thực hiện lại hệ thống có

sẵn để lam cho nó có thể duy trì lâu hơn.Sự cơ cấu lại có lẽ gắn liền với sự

lấy lại các tai liệu của hệ thống, tổ chức va cấu trúc lại hệ thống, chuyển đổi

hệ thống đến 1 ngôn ngữ hiện đại hơn, hay thay đổi va cập nhật lại hệ thống

va giá trị dữ liệu hệ thống. Các chức năng của phần mềm không bị thay đổi

va thƣờng thì kiến trúc của phần mềm vẫn đƣợc giữ nguyên. Sự tái cơ cấu

cải tiến cấu trúc hệ thống, tạo ra tập văn bản hệ thống mới (tập văn bản nay

ghi các công việc đã hoan thanh), va lam nó dễ hiểu

15.2 WHY WE NEED SOFTWARE RE-ENGINEERING

Computer software is the product that software engineers design and

build. Once software is put into use, new requirements emerge and existing





requirements change as the business rules change. Parts of software may

need to be modified to correct errors or improve its performance.

Phần mềm máy tinh la sản phầm dc kĩ sƣ phần mềm thiết kế va xây

dựng. Khi phần mềm dc đƣa vao sử dụng, những yêu cầu mới nổi lên va

yêu cầu phần mềm tồn tại dc thay đổi để phù hợp với ngữ cảnh. 1 phần của

phần mềm có lẽ cần đƣợc thay đổi để chữa các lỗi hay cải tiến sự thực thi.

As time goes on, software gets old and frequently breaks down. As

the software is modified, it becomes more and more complicated and

difficult to maintain. The level of difficulty of maintainability is directly

proportionate to the cost of maintaining the system.

Theo dòng thời gian, phần mềm trở nên lỗi thời va thƣờng bỏ đi. Khi

phần mềm đƣợc thay đổi, nó trở thanh ngay cang phức tạp hơn va khó bảo

trì. Mức độ khó bảo trì cân xứng với chi phi bảo trì hệ thống.

We are consequently faced with a dilemma. If we continue to use the

system and make changes as required, our costs will inevitably increase. If

we decide to replace the system with a new system, costs will be incurred

and the new system might not be as good as the old system.

Vì vậy, chúng ta đối mặt với tình trạng khó xử. Nếu chúng ta tiếp tục

sử dụng hệ thống va tạo sự thay đổi nhƣ yêu cầu, chi phi của chúng ta

không thể tránh khỏi tăng lên. Nếu chúng ta quyết định thay thế hệ thống





với 1 hệ thống mới, giá thanh sẽ phải gánh chịu va hệ thống mới có lẽ sẽ

không tốt bằng hệ thống cũ.

Software engineering techniques extend the lifetime of legacy

systems and reduce the costs of keeping these systems in use. We can create

a product with added functionality, better performance and reliability, and

improved maintainability by means of rebuilding the legacy system. Re-

engineering may involve some structural modifications but does not usually

involve major architectural change.

Kĩ thuật phần mềm mở rộng thời gian tồn tại của tai sản hệ thống va

giảm chi phi đƣa hệ thống vao hoạt động. Chúng ta có thể tạo ra sản phầm

va thêm các chức năng, thực thi tốt hơn va tin cậy hơn, cải tiến sự có thể

duy trì bằng cách xây dựng lại hệ thống kế thừa. Sự tái cơ cấu có lẽ kéo

theo vao sự thay đổi cấu trúc, nhƣng thƣờng thì không lam thay đổi kiến

trúc chính

15.3 SOFTWARE RE-ENGINEERING STRATEGIES

A major problem for organizations is implementing and managing

change to their legacy systems so that these systems continue to support the

organization‘s business operations. There are a number of different

strategies for software change:

• Software maintenance





• Architectural transformation — e.g., migration to servers or to Intranets

• Software re-engineering

Vấn đề chinh cho các tổ chức la sự thay đổi việc thực thi va quản lý

đến hệ thống kế thừa để ma những hệ thống nay tiếp tục giúp cho tổ chức

kinh doanh hoạt động. Có 1 số chiến lƣợc khác nhau của sự thay đổi hệ

thống:

• Bảo trì hệ thống.

• Sự chuyển đối kiến trúc. Vd: chuyển server hay mạng nội bộ.

• Tái cơ cấu phần mềm.

Software maintenance is the general process of changing a system

after it has been delivered; this strategy does not normally involve major

architectural changes to the system. The following are three types of

software maintenance:

Maintenance to repair software faults:

• Coding errors are very cheap to correct.

• Design errors are more expensive because this may involve rewriting

several program components.





• Requirement errors are most expensive to repair due to the extensive

system redesign that may be necessary.

• Maintenance to adapt the software to a different operating environment

• Maintenance to add to or modify the system‘s functionality External

and internal factors, such as changing markets, changing laws,

management changes, and structural reorganization, mean that

businesses undergo continual change. These changes generate new or

modified software requirements, so all useful software systems

inevitably change as the business changes.

Sự bảo trì phần mềm la 1 quá trình chung của sự thay đổi hệ thống

sau khi nó dc phân phối ; chiến lƣợc nay không liên quan đến sự thay đổi

kiến trúc hệ thống. Sau đây la 3 loại bảo trì hệ thống:

• Bảo trì va sửa chữa lỗi phần mềm:

• Sữa lỗi coding rất it tốn chi phi.

• Lỗi thiết kế tốn chi phi hơn vì nó dẫn đến đến việc viết lại vai thanh

phần hệ thống.

• Lỗi yêu cầu tốn nhiều chi phi sửa chữa nhất, bởi vì thiết kế lại hệ thống

mở rộng la việc cần thiết.

• Bảo trì để thich nghi hệ thống với môi trƣờng khác.





• Bảo trì để thêm hay sữa đổi các chức năng hệ thống. Các yêu tối bên

ngoai va bên trong, nhƣ la sự thay đổi thị trƣờng, thay đổi luật, thay đổi

việc quản lý va tổ chức lại cấu trúc, nghĩa la việc kinh doanh phải trỉa

qua sự thay đổi liên tục, vì thế tất cả các phần mềm hệ thống không thể

tránh đƣợc thay đổi khi việc kinh doanh thay đổi.

Approximately 20 percent of all maintenance efforts are spent fixing

mistakes. The remaining 80 percent is spent adapting existing systems to

changes in their external environment, making enhancements requested by

users, and re-engineering an application for future use (Pressman, 2001).

After software has been corrected, adapted, and enhanced many

times, it usually becomes unstable. The more maintainence on the software,

the more frequently unexpected and serious side effects may occur.

Although the system still works, its maintenance costs increase and its

value decreases

Gần 20% của tất cả các nổ lực bảo trì la dùng để sữa lỗi. 80% còn lại

dùng để thich nghi hệ thống với sự thay đổi môi trƣờng bên ngoai, lam tốt

các yêu cầu bởi ngƣời sử dụng va tái cơ cấu ứng dụng cho việc sử dụng

trong tƣơng lai.

Sau khi phần mềm đƣợc sữa lỗi, thich ứng, va cải tiến nhiều lần, nó

thƣờng trở nên không ổn định. Cang bảo trì hệ thống, những tác động

không lƣờng trƣớc va các khia cạnh nghiêm trọng có lẽ xảy ra. Mặc dù hệ





thống vẫn hoạt động, bảo trì nó lam tăng chi phi va giá trì của nó giảm

xuống.

15.4 THE PROCESS OF RE-ENGINEERING

The main activities in a typical re-engineering process are:

Hoạt động chinh của quá trình cơ cấu la:

15.4.1 Source Code Translation

The simplest form of software re-engineering is program translation

where source code in one programming language is automatically

trans¬lated to source code in another language (i.e., COBOL to Java). The

struc¬ture and organization of the program are unchanged but have higher

qual¬ity than the original program. One reason for this is that the target

language may be an updated version of the original language or may be a

translation to a completely different language. Source-level translation may

be neces¬sary for the following reasons:

• Hardware platform update: the organization may wish to change its

standard hardware platform, but compilers for the original language

may not be available on the new hardware.

• Organizational policy changes: an organization may want to

standard¬ize on a particular language to minimize its support software





costs. Maintaining many versions of old compilers can be very

expensive.

• Lack of software support: the suppliers of the language compiler may

have gone out of business or may discontinue support for their product.

• Developers want to make the system easier to understand, test, and

maintain: Some legacy systems have solid program architecture;

how¬ever, individual modules were coded in a way that makes them

diffi¬cult to understand, test, and maintain. In this situation, the code

can be restructured (Pressman, 2001).

Hình thức đơn giản nhất của việc tái cơ cấu phần mềm la việc thông

dịch chƣơng trình, tự động chuyển mã nguồn từ 1 ngôn ngữ lập trình sang 1

ngôn ngữ lập trình khác. Cấu trúc va tổ chức của chƣơng trình không bị

thay đổi nhƣng có chất lƣợng cao hơn chƣơng trình ban đầu. 1 li do la ngôn

ngữ đich có lẽ đƣợc cập nhật phiên bản của ngôn ngữ ban đầu hay có lẽ

đƣợc chuyển đổi hoan toan sang ngôn ngữ khác. Mức độ chuyển đổi mã

nguồn có lẽ cần thiết vì những lý do sau:

• Cập nhật nền phần cứng: tổ chức có lẽ muốn thay đổi chuẩn phần cứng,

nhƣng trình biên dịch cho ngôn ngữ ban đầu có lẽ không thich hợp trên

phần cứng mới.





• Thay đổi chinh sách tổ chức: 1 tổ chức muốn tiêu chuẩn hóa trên 1

ngôn ngữ cụ thể để giảm chi phi hổ trợ của phần mềm. Việc bảo trì

nhiều phiên bản của trình biên dịch cũ có thể rất đắt.

• Thiếu sự hỗ trợ của phần mềm: sự hổ trợ của ngôn ngữ biên dịch có lẽ

từ bỏ hay có lẽ không tiếp tục hổ trợ cho sản phẩm của họ.

• Ngƣời phát triển ứng dụng muốn lam cho hệ thống dễ hiểu, dễ kiểm tra

va dễ bảo trì. Vai hệ thống thừa kế có kiến trúc vững chắc, tuy nhiên,

cá nhân các mô đun đƣợc cai đặt theo cách để lam nó khó hiểu, khó

kiểm tra va bảo trì. Trong tình huống nay, việc cai đặt có thể đƣợc cấu

trúc lại.

15.4.2 Reverse Engineering

Reverse engineering is the process of analyzing software with the

objec¬tive of recovering its design and specification. The software source

code is usually available as input to the reverse engineering process.

Reverse engi¬neering is different from re-engineering. Its purpose is to

derive the design or specification of a system from its source code, while

the objective of re-engineering is to produce a new, more maintainable

system. Of course, reverse engineering to develop a better understanding of

a system is often part of the re-engineering process.

Thiết kế đối chiếu la quá trình phân tich phần mềm với mục đich

khám phá thiết kế va chi tiết kĩ thuật của nó. Mã nguồn phần mềm thƣờng





sẵn có để lam dữ liệu đầu vao cho quá trình thiết kế đối chiếu. Thiết kế đối

chiếu khác với sự tái cơ cấu. Mục đich của nó la đạt đƣợc thiết kế hay chi

tiết kĩ thuật của hệ thống từ mã nguồn của nó, trong khi mục đich của việc

tái cơ cấu la để sản xuất ra hệ thống mới, có thể duy trì dc lâu hơn. Dĩ

nhiên, thiết kế đối chiếu lam hiểu về hế thống tốt hơn va nó la 1 phần của

quá trình tái cơ cấu.

Reverse engineering can be used during software re-engineering to

recover the original program design to help developers understand a

pro¬gram before reorganizing its structure. However, re-engineering need

not always follow reverse engineering:

• The design and specification of an existing system may be reverse

en¬gineered so that they can serve as input to the requirements

specifica¬tion for that program‘s replacement.

• Alternatively, the design and specification may be reverse engineered

so that they are available to help program maintenance. With this

ad¬ditional information, it may not be necessary to re-engineer the

sys¬tem source code.

Thiết kế đối chiếu có thể sử dụng suốt quá trình tái cơ cấu phần mềm

để phục hồi lại thiết kế chƣơng trình ban đầu, giúp ngƣời phát triển phần

mềm hiểu chƣơng trình trƣớc khi tổ chức lại cấu trúc của nó. Tuy nhiên,

việc tái cơ cấu thƣờng thì không cần theo thiết kế đối chiếu:





• Thiết kế va chi tiết kĩ thuật của hệ thống đang tồn tại có lẽ đƣợc thiết kế

đối chiếu để ma nó có thể phục vụ nhƣ la dữ liệu đầu vao của yêu cầu

chi tiết kĩ thuật cho sự thay thế chƣơng trình.

• Nhƣ 1 sự lựa chọn, bản thiết kế va chi tiết kĩ thuật có lẽ đƣợc thiết kế

đối chiếu để ma nó sẵn sang giúp bảo trì chƣơng trình. Với những

thông tin thêm vao, nó có lẽ không cần thiết để tái cơ cấu lại mã nguồn

hệ thống.

The reverse engineering process is illustrated in Exhibit 15-1. The

pro¬cess starts with an analysis phase, during which the system is analyzed

using automated tools to discover its structure. In itself, this is not enough

to recreate the system design. Engineers then work with the system source

code and its structural model, adding information that they have collected

by understanding the system. This information is maintained as a directed

graph linked to the program source code.

Quá trình thiết kế đối chiếu đƣợc minh họa trong hình trên 15.1.

Quá trình bắt đầu với giai đoạn phân tich, suốt quá trình nya, hệ thống đƣợc

phân tich sử dụng công cụ tự động để khám phá cấu trúc của nó.Tự nó la

chƣa đủ để tạo lại thiết kế hệ thống. Ngƣời kĩ sƣ sau đó lam viết với mã

nguồn hệ thống va mô hình cấu trúc, thông tin bổ sung dc chọn lựa với sự

hiểu về hệ thống. Thông tin nay đƣợc bảo trì nhƣ la 1 biểu đồ có hƣớng đến

mã nguồn chƣơng trình.





Information store browsers are used to compare the graph structure

and the code and to annotate the graph with extra information. Documents

of various types, such as program and data structure diagrams and

trace¬ability matrices, can be generated from the directed graph.

Traceability matrices show where entities in the system are defined and

referenced.

Trình duyệt chƣơng trình lƣu trữ đƣợc dùng để so sánh cấu trúc đồ

thị va mã rồi chú thich với những thông tin thêm. Đa dạng các loại tai liệu,

nhƣ biểu đồ cấu trúc chƣơng trình va dữ liệu va khả năng tìm vết của nhiều

ma trận, có thể đƣợc tạo ra từ đồ thị có hƣớng. Ma trận tìm vết đƣa ra nơi

thực thể trong hệ thống đƣợc định nghĩa va tham khảo.

Tools for program understanding may be used to support the reverse

engineering process. These usually present different system views and

allow easy navigation through the source code. For example, they allow

users to select a data definition, and then move through the code to where

that data item is used. Examples of such program browsers are discussed by

Cleveland (1989), Oman and Cook (1990), and Ning et al. (1994).

Công cụ cho việc tìm hiểu chƣơng trình có lẽ đƣợc sử dụng để hỗ trợ

quá trình thiết kế đối chiếu. Nó thƣờng thể hiện cách nhìn hệ thống khác

nhau va cho phép dễ dang định vị vị tri của mã nguồn. Vi dụ, nó cho phép

ngƣời sử dụng chọn định nghĩa dữ liệu va sau đó chuyển đến mã nơi ma





mục dữ liệu đƣợc dùng. Vi dụ của những trình duyệt đƣợc thảo luận bởi

Cleveland (1989), Oman & Cook (1990) và Ning et al (1994).

After the system design documentation has been generated, further

information may be added to the information store to help recreate the

sys¬tem specification. This usually involves further manual annotation of

the system structure. The specification cannot be deduced automatically

from the system model.

Sau khi tai liệu thiết kế hệ thống đƣợc tạo ra, những thông tin mở

rộng có thể dc thêm vao thông tin lƣu trữ để giúp tạo lại chi tiết kĩ thuật hệ

thống. Nó thƣờng liên quan đến những chú thich hƣớng dẫn của cấu trúc hệ

thống. Chi tiết kĩ thuật không thể đƣợc suy luận tự động từ mô hình hệ

thống.

15.4.3 Program Structure Improvement

The need to optimize memory use and the lack of understanding of

soft¬ware engineering by many programmers have meant that many legacy

sys¬tems are not well structured. Their control structure is tangled with

many unconditional branches and unintuitive control logic. This structure

may also have been degraded by regular maintenance. Changes to the

program may have made some code unreachable, but this can only be

discovered after extensive analysis. Maintenance programmers often dare

not remove code in case it may be accessed indirectly.





Sự cần thiết của việc tối ƣu hóa bộ nhớ va sự thiếu hiểu biết về kỹ

thuật lập trình cũng có thể lam cho cấu trúc của chƣơng trình không rõ

rang. Các lệnh điều kiện có thể vô nghĩa hay có các đoạn code không bao

giờ dùng tới. Cấu trúc nay có thể cũng có thể bị xuống cấp va cần bảo

dƣơng thƣờng xuyên. Thay đổi để chƣơng trình có thể đã đƣợc thực hiện

một số mã không thể truy cập, nhƣng điều nay chỉ có thể đƣợc phát hiện

sau khi phân tich. Các lập trình viên thƣờng không dám bỏ mã trong trƣờng

hợp nó có thể đƣợc truy cập gián tiếp.

Typically, programs develop complex logic structure as they are

modi¬fied during maintenance. New conditions and associated actions are

added without changing the existing control structure. In the short term, this

is a quicker and less risky solution because it reduces the chances of

introduc¬ing faults into the system. In the long term, however, it leads to

incompre¬hensible code. Complex code structures can also arise when

programmers try to avoid duplicating code. Along with unstructured

control, complex conditions can also be simplified as part of the program

restructuring pro¬cess. For instance,

Thông thƣờng, các chƣơng trình phát triển kết cấu logic phức tạp vì

chúng đã đƣợc sửa đổi trong quá trình bảo dƣơng. Trong ngắn hạn, đây la

một giải pháp nhanh va it rủi vì nó lam giảm lỗi của hệ thống . Tuy vậy, về

lâu dài, nó dẫn đến không thê hiêu đƣợc code . Cấu trúc mã phức cũng có

thể phát sinh khi lập trình cố gắng tránh nhân đôi mã. Cùng với điều khiển





có cấu trúc, phức tạp điều kiện cũng có thể đơn giản nhƣ la một phần của

quá trình chuyển dịch cơ cấu chƣơng trình. Vi dụ:

Complex condition:

If not (a > b and (c < d or not (e > f)))…

Simplified condition:

If a < = b and (c > = d or e > f)… This is how a conditional statement

including ―not‖ logic may be made more understandable.

1 câu lệnh phức tạp:

if (a> b và (c <d hay không (e> f)))...

Đƣợc đơn giản hóa thanh:

if a <= b va (c> = d hoặc e> f)...

Đây la cách bao gồm một câu lệnh có điều kiện "không‖ logic để câu

lệnh dễ hiểu hơn.

If the program is data driven, with components tightly coupled

through shared data structures, restructuring the code may not lead to a

significant improvement in understandability. Program modularization may

also be necessary. If the program is written in a nonstandard language





dialect, standard restructuring tools may not work properly and significant

manual intervention may be required.

In some cases, it may not be cost-effective to restructure all of the

pro¬grams in a system. Some may be of better quality than others and some

may not be subject to frequent change. Arthur (1988) suggests that data

should be collected to help identify those programs that could benefit most

from restructuring: The metrics, such as failure rate, percentage of source

code changed per year, component complexity, and the degree to which

programs or components meet current standards, can be used to identify the

candidates for restructuring.

Nếu chƣơng trình sử dụng nhiều dữ liệu hƣớng đich, kết chặt chẽ với

các thanh phần thông qua cấu trúc dữ liệu đƣợc chia sẻ, tái cấu trúc mã

không có thể dẫn đến một ý nghĩa cải thiện tinh dễ hiểu. Mô-đun hóa

chƣơng trình cũng có thể cần thiết. Nếu chƣơng trình đƣợc viết bằng một

ngôn ngữ khác chuẩn, công cụ chuyển dịch cơ cấu tiêu chuẩn có thể không

hoạt động đúng.

15.4.4 Program Modularization

Program modularization is the process of reorganizing a program so

that related program parts are collected together and considered as a sin¬gle

module. Once this has been done, it becomes easier to remove

redun¬dancies in these related components, to optimize their interactions,





and to simplify their interface with the rest of the program. A number of

types of module may be created during the program modularization

process.

Mô-đun hóa chƣơng trình la một quá trình sắp xếp lại chƣơng trình 1

cách hợp lý. Một khi điều nay đã đƣợc thực hiện, chƣơng trình trở nên dễ

dang hơn trong việc loại bỏ dƣ thừa trong các thanh phần liên quan, để tối

ƣu hóa các tƣơng tác, va để đơn giản hóa giao diện của họ với phần còn lại

của chƣơng trình. Một số loại module có thể đƣợc tạo ra trong quá trình

mô-đun chƣơng trình

• Data abstractions. In order to save memory space, many legacy

sys¬tems depend on use of shared tables and common data areas. The

in-formation stored in these areas is globally accessible and may be

used by different parts of the system in different ways. It is expensive

mak¬ing changes to these global data areas due to the costs of

analyzing change impacts across all uses of the data. To reduce the

costs of changes to these shared data areas, the program modularization

pro¬cess may focus on the identification of data abstractions. Data

ab¬stractions or abstract data types collect data and associated

processing and are resilient to change.

• Hardware modules. These are related to data abstractions and gather all

of the functions used to control a particular hardware device.





• Functional modules. For instance, all of the functions concerned with

input and input validation may be incorporated in a single module. This

type of modularization should be considered where it is imprac¬tical to

recover program data abstractions.

• Process support modules. All of the functions and specific data items

re¬quired to support a particular business process are grouped here.

• Module dữ liệu. Để tiết kiệm không gian bộ nhớ, hệ thống có nhiều dữ

liệu phụ thuộc vao việc sử dụng các bảng dữ liệu đƣợc chia sẻ va phổ

biến các khu vực. Các thông tin đƣợc lƣu giữ trong các khu vực nay la

trên toan cầu có thể truy cập va có thể đƣợc sử dụng bởi các phần khác

nhau của hệ thống theo những cách khác nhau. Nó la đắt tiền lam thay

đổi đối với các khu vực nay dữ liệu toan cầu do chi phi phân tich thay

đổi tác động trên tất cả sử dụng các dữ liệu.

• Module phần cứng: Đây la những liên quan đến phần cứng va thu thập

dữ liệu. Tất cả các chức năng đƣợc sử dụng để điều khiển một thiết bị

phần cứng cụ thể.

• Module chức năng: Tất cả các chức năng có liên quan đƣợc tich hợp

vao trong một module đơn lẻ





15.4.5 Data Re-Engineering

Until now, most of our discussion on software evolution has focused

on the problems of program modification. However, in many cases,

associated problems of storage, organization, and format of the data

processed by leg¬acy programs may need to evolve to reflect changes to the

software. The process of analyzing and reorganizing the data structures and,

sometimes, the data values in a system to make it more understandable is

called data re-engineering.

Cho đến nay, hầu hết các việc thảo luận tập trung vao phần mềm sửa

đổi các vấn đề của chƣơng trình. Tuy nhiên, trong nhiều trƣờng hợp, liên

kết vấn đề dung lƣợng lƣu trữ, tổ chức, va định dạng của dữ liệu trong

chƣơng trình cũng cần đƣợc chú ý.

In principle, data re-engineering should not be necessary if the

function¬ality of a system is unchanged. In practice, however, there are a

number of reasons why you may need to modify the data as well as the

programs in a legacy system:

Về nguyên tắc, tái tổ chức dữ liệu không cần thiết nếu các chức năng

của một hệ thống không thay đổi. Trong thực tế, tuy nhiên, có một số lý do

tại sao bạn có thể cần phải sửa đổi dữ liệu cũng nhƣ các chƣơng trình trong

một hệ thống:





• Data degradation. Over time, the quality of data tends to decline.

Change to the data incurs errors, redundant values may have been

created, and changes to the external environment may not be reflect¬ed

in the data. This is unavoidable because the lifetime of data is often

very long.

• Inherent limits built into the program. Programs are now often

re¬quired to process much more data than was originally envisioned by

their developers. Data re-engineering may be required to remove these

limitations.

• Architectural evolution. If a centralized system is migrated to a

distrib¬uted architecture, it is essential that the core of that architecture

be a data management system that can be accessed from remote clients.

This may require a large data re-engineering effort to move data from a

mainframe to a server-based database management system. The move

to a distributed program architecture may also be initiated when an

organization decides to move from file-based data manage¬ment to a

database management system.

• Dữ liệu bị suy thoái. Theo thời gian, chất lƣợng của dữ liệu có xu

hƣớng suy giảm.





• Dữ liệu có tinh tiến hóa. Nếu có hệ thống tập trung đến một phân bố

kiến trúc nao đó thì dữ liệu trong kiến trúc đó có thể tiến hóa khiến cho

chƣơng trình cũ không đáp ứng đƣợc

• …

Because data architecture has a strong influence on program

architec¬ture and the algorithms that populate it, changes to the data will

invariably result in architectural or code-level changes. Rickets (1993)

mentions some of the problems with data that can arise in legacy systems

made up of several cooperating programs:

Các vấn đề cần giải quyết trong việc tổ chức lại dữ liệu la:

• Data naming problems. Name may be cryptic and difficult to

under¬stand. Different names may be given to the same logical entity

in dif¬ferent programs in the system. The same name may be used in

different programs to mean different things.

• Đặt tên cho biến: Tên có thể rất khó hiểu. Các tên khác nhau có thể

đƣợc trao cho các tổ chức hợp lý khác nhau trong cùng một các chƣơng

trình trong hệ thống. Cùng tên có thể đƣợc sử dụng trong các chƣơng

trình khác nhau để có nghĩa la những nghĩa khác nhau.

• Field length problems. When field lengths in records are explicitly

as¬signed in the program, the same item may be assigned different





lengths in different programs or the field length may be too short to

represent current data.

• Record organization problems. Records representing the same entity

may be organized differently in different programs.

• Hard-coded literals. Absolute values, such as tax rates, are included

di¬rectly in the program rather than referenced using some symbolic

name.

• Lack of a data dictionary.

• Inconsistent data definitions. Data values may also be stored in an

in¬consistent way. After the data definitions have been re-engineered,

the data values must also be converted to conform to the new structure.

• Chiều dai của các biến. Khi độ dai các biến trong chƣơng trình không

đáp ứng đƣợc thực tế thì cũng cần thay đổi.

• Hard-coded literals. Giá trị tuyệt đối, chẳng hạn nhƣ mức thuế, đƣợc

bao gồm trực tiếp trong chƣơng trình thay vì sử dụng một số tham

chiếu tƣợng trƣng tên.

• Thiếu một dữ liệu từ điển.

• Không phù hợp dữ liệu đƣợc định nghĩa. Giá trị liệu cũng có thể đƣợc

lƣu trữ trong một không phù hợp cách. Sau khi định nghĩa dữ liệu đã





đƣợc tái thiết kế, các dữ liệu giá trị cũng phải đƣợc chuyển đổi để phù

hợp với cấu trúc mới.

Exhibit 15-2 illustrates the process of data re-engineering, assuming

that data values converted. The change summary tables hold details of all

the changes to be made. They are therefore used at all stages of the data re-

engineering process.

In Stage 1 of this process, the data definitions in the program are

modi¬fied to improve understandability; the data is not affected by these

modifi¬cations. It is possible to automate this process to some extent using

pat¬tern matching systems such as Awk (Aho et al., 1988) to find and

replace definitions or to develop XML descriptions of the data (St Laurent

and Cerami, 1999) and use these to drive data conversion tools. However,

some manual work is almost always necessary to complete the process. The

data re-engineering process may stop at this stage if the goal is simply to

improve the understandability of the data structure definitions in a

pro¬gram. If, however, there are data value problems as discussed earlier,

Stage 2 of the process may then be entered.

If an organization decides to continue to Stage 2 of the process, it is

then committed to Stage 3, data conversion, which is usually a very

expensive process. Programs must be written that embed knowledge of the





old and the new organization. These process the old data and output the

converted information.

15.5 FORWARD ENGINEERING

The major distinction between re-engineering and new software

development is the starting point for the development. For system re-

engineering, the old system acts as a specification for the new system.

Chikofsky and Cross (1990) call conventional development forward

engineering (Exhibit 15-3) to distinguish it from software re-engineering

(Exhibit 15-4). Forward engineering starts with a system specification and

involves the design and implementation of a new system; re-engineering

starts with an existing system and transformation of the old system.

Sự khác biệt lớn giữa re-engineering 1 phần mềm va phát triển phần

mềm mới la điểm khởi đầu của quá trình phát triển. Đối với hệ thống tái kỹ

thuật, hệ thống hanh vi cũ nhƣ la một đặc điểm kỹ thuật cho hệ thống mới.

Chikofsky và Cross (1990) gọi sự phát triển quy ƣớc mong kỹ thuật để phân

biệt với software re-engineering. Forward engineering bắt đầu với một hệ

thống va đặc điểm kỹ thuật liên quan đến các thiết kế va thực hiện một hệ

thống mới; software re-engineering bắt đầu với một hệ thống hiện có va

chuyển đổi của hệ thống cũ.




Chương 16: Kiểm thử phần mềm 567

CHƢƠNG 16 KIỂM THỬ PHẦN MỀM

Testing is a critical component of software development. Its goal is

to uncover and correct errors found in software. Because software is

complex, it is reasonable to presume that software testing is a labor- and

resource-intensive process. Automated software testing helps to improve

testers‘ productivity and reduce resources that may be required. By its very

nature, automated software testing increases test coverage levels, speeds up

test turnaround time, and cuts costs of testing. Unfortunately, due to a





variety of reasons, not all test automation projects will achieve these returns

on investment. In this chapter, a practical approach to automated software

testing is discussed.

Software Testing la một thanh phần quan trọng của sự phát triển

phần mềm. Mục tiêu của nó la để phát hiện va sửa chữa các lỗi tìm thấy

trong phần mềm. Bởi vì phần mềm rất phức tạp thật hợp lý để ch rằng

Software Testing la một quá trình cần nhiều nguồn lực la động và tài

nguyên. Phần mềm tự động thử nghiệm sẽ giúp cải thiện năng suất testing

va giảm nguồn tai nguyên có thể sẽ đƣợc yêu cầu. Bởi bản chất của nó,

phần mềm tự động kiểm tra thử nghiệm lam tăng độ phủ của bộ test, tăng

tốc thời gian quay vòng thử nghiệm, va cắt giảm chi phi của thử nghiệm.

Thật không may, vì nhiều lý do, không phải tất cả các dự án thử nghiệm tự

động hóa na cũng đƣợc đầu tƣ. Trong chƣơng nay, một cách tiếp cận thực

tế để kiểm tra phần mềm tự động đƣợc thảo luận

16.1 KIỂM THỬ PHẦN MỀM LÀ GÌ ?

A critical component in the process of software development is

software testing. The classic software life cycle model suggests a

systematic, sequential approach to software development that progresses

through software requirements analysis, design, code generation, and

testing. That is, once source code has been generated, program testing

begins with the goal of finding differences between the expected behavior

specified by system models and the observed behavior of the system.





Một thanh phần quan trọng trong quá trình phát triển phần mềm la

Software Testing. Các chu trình sống của các mô hình phần mềm cổ điển

gợi ý 1 phƣơng pháp phát triển phần mềm một cách có hệ thống va có trình

tự la phân tich các yêu cầu phần mềm, thiết kế, viết code, va test. Đó la, khi

mã nguồn đã viết xong, chƣơng trình bắt đầu đƣợc thử nghiệm với mục tiêu

la tìm ra sự khác biệt giữa các kết quả mong muốn va kết quả ma chƣơng

trình trả về.

The process of creating error-free software applications requires

technical sophistication in the analysis, design, and implementation of that

software and proper test planning, as well as robust automated testing tools.

When planning and executing tests, software testers must consider the

software and the function it performs, the inputs and how they can be

combined, and the environment in which the software will eventually

operate.

Quá trình tạo ra ứng dụng phát sinh lỗi phần mềm đòi hỏi kỹ thuật

phức tạp trong phân tich, thiết kế, thực hiện phần mềm va lập kế hoạch

kiểm tra thich hợp, cũng nhƣ kiểm nghiệm với các công cụ kiểm lỗi tự động

mạnh. Khi lập kế hoạch va thực hiện các thử nghiệm, ngƣời Test lỗi

Software phải xem xét các chƣơng trình va các ham ma nó thực thi, các yếu

tố đầu vao va lam thế nao chúng liên kết với nhau thế nao, đồng thời môi

trƣờng ma phần mềm cuối cùng sẽ hoạt động.





During early stages of the testing process, the programmer usually

performs all tests. This stage of testing is referred to as unit testing. Here

the programmer usually works with the debugger that accompanies his or

her compiler. For example Visual Basic, as shown in Exhibit 16-1, enables

the programmer to ―step through‖ a program‘s (or object‘s) logic, one line

of code at a time, viewing the value of any and all variables as the program

proceeds.

Trong giai đoạn đầu của quá trình Software Testing, lập trình viên

thƣờng thực hiện tất cả các bộ test. Giai đoạn thử nghiệm nay đƣợc gọi la

kiểm tra đơn vị (unit testing). Ở đây các lập trình viên test bằng cách debug.

Vi dụ nhƣ Visual Basic, nhƣ thể hiện trong hình 16-1, cho phép lập trình

viên "đi qua‖ logic của chƣơng trình, một dòng mã tại một thời điểm, xem

bất kỳ va tất cả các biến nhƣ la kết quả của chƣơng trình.

A particular program is usually made up of many modules. An OO

system is composed of many objects. Programmers usually architect their

programs in a top–down modular fashion. Integration testing proves that

the module interfaces are working properly. For example, in Exhibit 16-2, a

programmer conducting integration testing would ensure that Module2

(process module) correctly interfaces with its subordinate, Module2.1

(calculate process).

Một chƣơng trình đặc biệt thƣờng đƣợc tạo thanh từ nhiều module.

Một hệ thống Hƣớng Đối Tƣợng la hỗn hợp của nhiều đối tƣợng. Thƣờng la





lập trình viên thiết kế chƣơng trình của họ theo mô hình từ trên xuống dƣới

(top-down). Test Tich hợp (integration testing) chứng minh rằng các giao

diện module đang lam việc đúng cách. Vi dụ, tại hình 16-2, một lập trình

viên tiến hanh thử nghiệm kết hợp giửa các module để đảm bảo rằng

module2 có cách giao tiếp đúng với cấp dƣới của mình

Hình 16-1





If module2.1 had not yet been written, it would have been referred to

as a stub. Integration testing could still be performed if the programmer

inserted two or three lines of code in the stub, which would act to prove that

it is well integrated to module2.

Nếu module2.1 vẫn chƣa đƣợc viết, nó có thể đã đƣợc gọi la một

đoạn không hoan chỉnh. Test kết hợp vẫn có thể đƣợc thực hiện nếu các lập

trình viên đƣa vao hai hoặc ba dòng mã trong đoạn nay, ma sẽ hanh động

để chứng minh rằng nó cũng tich hợp tốt vao module2.

On occasion, a programmer will code all the subordinate modules

first and leave the higher-order modules for last. This is known as bottom–

up programming. In this case module2 would be empty except for a few

lines of code to prove that it is integrating correctly with module2.1, etc. In

this case, module 2 would be referred to as a driver.

Một lập trình sẽ code tất cả các mô-đun cấp thấp trƣớc va sau đó tới

các module có trật tự cao hơn. Điều nay đƣợc gọi la lập trình từ dƣới lên

(bottom-up). Trong trƣờng hợp nay module2 sẽ la trống rỗng, ngoại trừ một

vai dòng mã để chứng minh rằng nó đƣợc tich hợp một cách chinh xác với

module2.1, Trong trƣờng hợp nay, module 2 sẽ đƣợc gọi la một trình điều

khiển.





Hình 16-2

Where integration testing is performed on the discrete programs or

objects with a master program, system testing refers to testing the interfaces

between programs within a system. Because a system can be composed of

hundreds of programs, this is a vast undertaking.

Trong trƣờng hợp Test Tich hợp (integration testing) đƣợc thực hiện

trên các chƣơng trình riêng biệt hoặc các đối tƣợng với một chƣơng trình

tổng thể, hệ thống thử nghiệm chỉ dùng để kiểm tra các giao diện giữa các





chƣơng trình trong vòng một hệ thống. Bởi vì một hệ thống có thể đƣợc tạo

thanh từ hang trăm chƣơng trình, đây la một cam kết rộng lớn.

It is quite possible that the system being developed is a replacement

for an existing system. In this case, parallel testing is performed. The goal

here is to compare outputs generated by each of the systems (old versus

new) and determine why there are differences, if any.

Có thể cho rằng hệ thống đang đƣợc phát triển để thay thế cho một

hệ thống hiện có. Trong trƣờng hợp nay, thử nghiệm song song(parallel

testing) đƣợc thực hiện. Mục tiêu ở đây la để so sánh kết quả đầu ra đƣợc

tạo ra bởi mỗi hệ thống (cũ so với mới) va xác định lý do tại sao có sự khác

biệt, nếu có.

Parallel testing requires end users to be part of the testing team. If the

end user determines that the system is working correctly, we can see that

the customer has ―accepted‖ the system. This, then, is a form of customer

acceptance testing.

Song song kiểm tra(parallel testing) yêu cầu ngƣời dùng cuối cũng la

một phần của đội thử nghiệm. Nếu ngƣời dùng xác nhận rằng hệ thống

đang hoạt động tốt, chúng ta có thể thấy rằng các khách hang đã "chấp

nhận‖ hệ thống. Điều nay la một hình thức kiểm tra sự chấp nhận của khách

hàng.





As the testing progresses, testing specialists may become involved

(see Appendix P for a sample QA handover document). Within the

vernacular of IT, staff dedicated to performing testing are referred to as

quality assurance engineers and reside within the quality assurance

department. QA testers must have a good understanding of the program

being tested as well as the programming language that the program was

coded in. In addition, the QA engineer must be methodical and be able to

grasp complex logic. Generally speaking, technical people with these

attributes are hard to come by and even harder to keep because most of

them aspire to become programmers.

Khi tiến trình thử nghiệm, các chuyên gia testing có thể tham gia.

Trong nganh CNTT, đội ngũ nhân viên chuyên dụng thực hiện các thử

nghiệm đƣợc gọi la kỹ sƣ đảm bảo chất lƣợng va nằm trong bộ phận bảo

đảm chất lƣợng. Ngƣời test QA(quality assurance) thử phải có một sự hiểu

biết tốt về chƣơng trình đang đƣợc thử nghiệm cũng nhƣ các ngôn ngữ lập

trình ma chƣơng trình đã đƣợc code. Ngoai ra, các kỹ sƣ QA phải có

phƣơng pháp va có thể nắm bắt logic phức tạp.

Even simple software can present testers with obstacles. Couple this

complexity with the difficulty in attracting and keeping QA staff and you

have the main reason that many organizations now automate parts of the

testing process.





Ngay cả phần mềm đơn giản có thể đem lại cho tester những trở

ngại. Những phức tạp nay với những khó khăn trong việc thu hút va giữ

nhân viên bảo đảm chất lƣợng la lý do chinh để nhiều tổ chức bây giờ tự

động hoá quá trình thử nghiệm.

16.2 CHIẾN LƢỢC KIỂM THỬ PHẦN MỀM

Software testing is one critical element of software quality assurance

(SQA) that aims at determining the quality of the system and its related

models. In such a process, a software system will be executed to determine

whether it matches its specification and executes in its intended

environment. To be more precise, the testing process focuses on the logical

internals of the software, ensuring that all statements have been tested, and

on the functional externals by conducting tests to uncover errors and ensure

that defined input will produce actual results that agree with required

results.

Software Testing la một trong những yếu tố quan trọng bả đảm chất

lƣợng phần mềm (SQA) nhằm mục tiêu xác định chất lƣợng của hệ thống

và các mô hình liên quan của nó. Trong quy trình nhƣ vậy, một hệ thống

phần mềm sẽ đƣợc thực thi để xác định xem nó phù hợp với đặc điểm kỹ

thuật va thực hiện trong môi trƣờng dự định của nó. Để đƣợc chinh xác

hơn, quá trình kiểm tra tập trung va đặc tinh logic của phần mềm (đảm bả

rằng tất cả các trƣờng hợp đã đƣợc thử), va trên chức năng bên ngoai

(functinal external) bằng cách tiến hanh các xét nghiệm để phát hiện sai sót





va đảm bả rằng các đầu va đƣợc xác định sẽ ch ra kết quả thực tế va đúng

với kết quả yêu cầu.

To ensure that the testing process is complete and thorough it is

necessary to create a test plan (Appendix O). A thorough test plan consists

of the following:

1. Revision history

2. System introduction

2.1. Goals and objectives

2.2. Statement of scope

2.3. Major constraints

3. Test plan

3.1. System description

3.2. Testing strategy

3.3. Testing resources

3.4. Testing metrics

3.5. Testing artifacts





3.6. Testing schedule

4. Test procedures

4.1. Class testing

4.2. Integration testing

5. Appendix 1: class testing test cases

5.1. Application controller subsystem

5.2. User management subsystem

5.3. Resource management subsystem

5.4. Order subsystem

5.5. Accounting subsystem

5.6. Customer relationship management subsystem

5.7. Persistence subsystem

6. Appendix 2: integration testing test cases

6.1. Customer registration

6.2. Reallocate resources





6.3. Search for service provider and initiate order

6.4. Place order

6.5. Pay for service

7. Appendix: project schedule

Để đảm bảô rằng quá trình thử nghiệm la hoan chỉnh va triệt để, cần

phải tạo ra một kế hoạch thử nghiệm (Phụ lục). Một kế hoạch kiểm tra toan

diện ba gồm sau đây:

1.Revision history

2.System intrduction

2.1.Goals and objectives

2.2.Statement f scope

2.3.Major constraints

3.Test plan

3.1.System description

3.2.Testing strategy





3.3.Testing resources

3.4.Testing metrics

3.5.Testing artifacts

3.6.Testing schedule

4.Test procedures

4.1.Class testing

4.2.Integration testing

5.Appendix 1: class testing test cases

5.1.Applicatin cntroller subsystem

5.2.User management subsystem

5.3.Resource management subsystem

5.4.Order subsystem

5.5.Accunting subsystem

5.6.Customer relationship management subsystem

5.7.Persistence subsystem





6.Appendix 2: integration testing test cases

6.1.Customer registration

6.2.Reallcate resources

6.3.Search for service provider and initiate order

6.4.Place order

6.5.Pay for service

7.Appendix: project schedule

A sample test plan, created by my students for an OO dog grooming

system, can be found in Appendix O. Although all components of this test

plan are important, you will note that the plan is really focused around three

things:

1. The test cases

2. Metrics that will determine whether there has been testing success

or failure

3. The schedule

Kế hoạch test vi dụ trong Appendix tập trung va 4 điểm chinh sau:





1. Test case

2. Ma trận xác định test na đúng, test na sai.

3. Lịch trình.

16.3 TEST AUTOMATION

The usual practice in software development is that the software is

written as quickly as possible and, once the application is done, it is tested

and debugged. However, this is a costly and ineffective way because the

software testing process is difficult, time consuming, and resource

intensive. With manual test strategies, this can be even more complicated

and cumbersome. A better alternative is to perform unit testing independent

of the rest of the code. During unit testing, developers compare the object

design model with each object and subsystem. Errors detected at the unit

level are much easier to fix; we only need to debug the code in that small

unit. Unit testing is widely recognized as one of the most effective ways to

ensure application quality; however, it is a laborious and tedious task. The

workload for unit testing is tremendous, so to perform unit testing manually

is practically impossible and hence the need for automatic unit testing.

Another good reason to automate unit testing is that, when performing

manual unit testing, we run the risk of making mistakes (Aivazis, 2000).





Trong việc phát triển phần mềm thông thƣờng thì code đƣợc viết

nhanh nhất có thể trong một lần va khi ứng dụng đƣợc thực hiện, nó đƣợc

kiểm nghiệm va debugged. Tuy nhiên, đây la một cách tốn kém va không

hiệu quả vì kiểm nghiệm trong quá trình thử nghiệm phần mềm la khó

khăn, tốn thời gian va cần nhiều nguồn lực. Test tay trong trƣờng hợp nay

rất phức tạp. Phƣơng pháp thay thế la: thể hiện các unit test đôc lập với

code còn lại. Trong quá trình kiểm tra đơn vị(testing unit), các nha phát

triển so sánh các mô hình thiết kế đối tƣợng với từng đối tƣợng va hệ thống

phụ. Lỗi tại cấp đơn vị đƣợc phát hiện va sửa chữa dễ dang hơn vì chỉ cần

sửa lỗi mã trong những đơn vị nhỏ. Testing unit đƣợc công nhận la một

trong những cách hiệu quả nhất để đảm bả chất lƣợng ứng dụng, tuy nhiên,

nó la một công việc tẻ nhạt va đòi hỏi siêng năng. Các đơn vị khối lƣợng

công việc để thử nghiệm rất lớn, do đó Testing unit không thể đƣợc thực

hiện bằng tay ma phải có một chƣơng trình kiểm tra tự động. Chƣơng trình

nay trả ra các lỗi có thể có trong code(Aivazis, 2000).

Besides saving time and preventing human errors, automatic unit

testing helps facilitate integration testing. After unit testing has removed

errors in each subsystem, combinations of subsystems are integrated into

larger subsystems and tested. When tests do not reveal new errors,

additional subsystems are added to the group, and another iteration of

integration testing is performed. The re-execution of a subset of tests that

have already been conducted is regression testing. It ensures that no errors





are introduced as a result of adding new modules or modification in the

software (Kolawa, 2001).

Bên cạnh việc tiết kiệm thời gian va ngăn ngừa lỗi con ngƣời mắc

phải, Testing unit autmation tạo thuận lợi cho test Tich hợp (integration

testing). Sau khi kiểm tra đơn vị(Testing unit) lại bỏ các lỗi ở từng module,

các module đƣợc tich hợp lại thanh hệ thống lớn hơn va đƣợc test. Khi thử

nghiệm không phát sinh lỗi mới, modul đƣợc kết hợp thanh nhóm, va lặp

lại với các module khác tạo thanh các bai kiểm tra hồi quy. Cuối cùng sau

khi kết hợp tất cả các module thì tái thực hiện một lần nửa. Nó đảm bả rằng

không có lỗi đƣợc phát sinh khi thêm mô-đun mới hặc sửa đổi trong các

phần mềm (Klawa, 2001).

As integration testing proceeds, the number of regression tests can

grow very large. Therefore, it is inefficient and impractical to re-execute

every test manually once a change has occurred. The use of automated

capture and playback tools may prove useful in this case. They enable the

software engineer to capture test cases and results for subsequent playback

and comparison.

Khi tiến hanh integration testing, số lƣợng các bai kiểm tra hồi qui có

thể phát triển rất lớn. D đó, nó sẽ không hiệu quả va không thực tế để tái

thực hiện kiểm tra bằng tay mỗi khi một sự thay đổi đã xảy ra. Việc sử

dụng công cụ bắt tự động va phát lại(capture and playback) rất hữu ich





trong trƣờng hợp nay. Chúng ch phép các kỹ sƣ phần mềm nắm bắt các

trƣờng hợp kiểm tra va kết quả cho phát lại sau đó va so sánh.

Test automation can improve testers‘ productivity; they can apply

one of several types of testing tools and techniques at various points of code

integration. Some examples of automatic testing tools in the market

include:

• C++Test for automatic C/C++ unit testing by ParaSoft

• Cantata++ for dynamic testing of C++ by IPL

• WinRunner for unit and system tests by Mercury Interactive

Kiểm tra tự động hóa(Test autmation) có thể cải thiện năng suất bằng

cách áp dụng một trong một số lại hình của công cụ kiểm tra va kỹ thuật tại

các điểm khác nhau của hội nhập mã. Một số vi dụ về các công cụ kiểm tra

tự động trên thị trƣờng ba gồm:

• C + + Kiểm tra ch tự động C / C + +, đơn vị kiểm nghiệm của ParaSoft

• Cantata + + để thử nghiệm của C + + bằng IPL

• WinRunner ch các đơn vị va thử nghiệm hệ thống của Mercury

Interactive





WinRunner is probably one of the more popular tools in use today

because it automates much of the painful process of testing. Used in

conjunction with a series of test cases (see Appendix O, Section 5), a big

chunk of the manual processes that constitute the bulk of testing can be

automated. The WinRunner product actually records a particular business

process by recording the keystrokes a user makes (e.g., emulates user

actions of placing an order). The QA person can then directly edit the test

script that WinRunner generates and add checkpoints and other validation

criteria.

WinRunner có lẽ la một trong những công cụ phổ biến đƣợc sử dụng

ngay nay vì nó tự động hóa nhiều quá trình thử nghiệm. Sử dụng kết hợp

với một lạt các trƣờng hợp thử nghiệm (xem Phụ lục, mục 5), Các sản phẩm

WinRunner thực sự ghi lại thanh một quá trình cụ thể bằng cách ghi âm các

tổ hợp phim của ngƣời sử dụng (vi dụ, mô phỏng những hanh động của

ngƣời dùng đặt hang). Ngƣời QA có thể trực tiếp sửa kịch bản thử nghiệm

ma WinRunner tạo ra va thêm trạm kiểm sát va tiêu chi xác nhận khác.

When done correctly with appropriate testing tools and strategies,

automating software testing provides worthwhile benefits such as

repeatability and significant time saving. This is true especially when the

system moves into system test. Higher quality is also a result because less

time is spent in tracking down test environmental variables and in rewriting

poorly written test cases (Raynor, 1999).





Khi lam đúng với công cụ kiểm tra va các chiến lƣợc thich hợp, phần

mềm tự động há thử nghiệm (Test autmation) cung cấp những lợi ich đáng

giá nhƣ tiết kiệm thời gian đáng kể. Điều nay đặc biệt đúng khi hệ thống di

chuyển va thử nghiệm hệ thống. Chất lƣợng cao cũng la một kết quả, vì

không thời gian kiểm tra các kết quả va viết lại các test case nhàm

chán(Raynr, 1999).

16.4 NGUYÊN LÝ TEST AUTOMATION

Test automation can be applied at unit testing, one or more layers of

integration testing, and system testing (which is another form of

integration). Tests should be executed soon after the code is written, before

too much code integration has occurred, so that bugs will not be carried

forward. When strategizing for test automation, consider automating these

tests as early as possible, as well as later in the testing cycle (Zallar, 2002).

Kiểm tra tự động (Test autmatin) có thể đƣợc ứng dụng va unit

Testing, integration testing, va thử nghiệm hệ thống (la một hình thức hội

nhập). Các thử nghiệm nên đƣợc thực hiện ngay sau khi mã đƣợc viết,

trƣớc khi việc kết hợp mã xảy ra, d đó, lỗi sẽ không đƣợc lan truyền. Khi

lập chiến lƣợc cho việc tự động kiểm tra, cần xem xét việc tự động há các

xét nghiệm nay cang sớm cang tốt, cũng nhƣ sau nay trong chu trình thử

nghiệm (Zallar, 2002).





Pettichord (2001) describes several principles that testers should

adhere to in order to succeed with test automation. These principles include:

• Taking testing seriously

• Being careful who you choose to perform these tests

• Choosing what parts of the testing process to automate

• Being able to build maintainable and reliable test scripts

• Using error recovery

Pettichrd (2001) mô tả một số nguyên tắc ma ngƣời tester nên tuân

theo để thanh công với bai kiểm tra tự động hóa. Những nguyên tắc nay ba

gồm

• Kiểm tra nghiêm túc

• Cẩn thận khi Chọn ngƣời thực hiện những thử nghiệm nay

• Chọn những phần nao của quá trình thử nghiệm để tự động hóa

• Có thể xây dựng các kịch bản thử nghiệm duy trì va đáng tin cậy

• Sử dụng phục hồi lỗi.





Testers need to realize that test automation is a software

development activity and so needs to adhere to standard software

development practices. That is, test automation systems need to be tested

and subjected to frequent review and improvement to make sure that they

are indeed addressing the testing needs of the organization.

Cần phải nhận ra rằng kiểm định tự động la một trong những hạt

động phát triển phần mềm va vì vậy cần phải tuân theo tiêu chuẩn thực tiễn

phát triển phần mềm. Đó la, kiểm tra hệ thống tự động hóa cần phải đƣợc

kiểm tra va xem xét thƣờng xuyên va cải thiện để chắc chắn rằng chúng

đang thực sự chỉ ra đƣợc những nhu cầu testing của tổ chức.

Because automating test scripts is part of the testing effort, good

judgment is required in selecting appropriate tests to automate. Not

everything can or should be automated. For example, overly complex tests

are not worth automating; manual testing is still necessary in this case.

Bởi vì các kịch bản thử nghiệm tự động háo la một phần của nỗ lực

thử nghiệm, sự điều chỉnh tốt la cần thiết trong việc lựa chọn các test thich

hợp để tự động há. Không phải tất cả mọi thứ có thể hoặc nên đƣợc tự

động. Vi dụ, các test quá phức tạp không đáng tự động hoá; test tay vẫn

còn cần thiết trong trƣờng hợp nay.

Zambelich (2002) provides a guideline to make automated testing

cost effective. He says that automated testing is expensive and does not





replace the need for manual testing or enable you to ―down-size‖ your

testing department. Automated testing is an addition to your testing process.

Some pundits claim that it can take between three to ten times as long (or

longer) to develop, verify, and document an automated test case than to

create and execute a manual test case. Zambelich indicates that this is

especially true if you elect to use the ―record/playback‖ feature (contained

in most test tools) as your primary automated testing methodology. In fact,

Zambelich says that record/playback is the least cost-effective method of

automating test cases. Automated testing can be made to be cost-effective,

according to Zambelich, if some common sense is applied to the process:

• Choose a test tool that best fits the testing requirements of your

organization or company. An automated testing handbook is available

from the Software Testing Institute

(http://www.softwaretestinginstitute.com).

• Understand that it does not make sense to automate everything. Overly

complex tests are often more trouble to automate than they are worth.

Concentrate on automating the majority of your tests, which are

probably fairly straightforward. Leave the overly complex tests for

manual testing.

• Only automate tests that will be repeated; one-time tests are not worth

automating.


http://www.softwaretestinginstitute/




Zambelich (2002) cung cấp một phƣơng châm để thực hiện tự động

thử nghiệm hiệu quả chi phi. Ông nói rằng thử nghiệm tự động la tốn kém

va không lại bỏ đƣợc sự cần thiết phải kiểm tra tay hặc ch phép bạn "dwn-

size‖ bộ phận testing của bạn. Tự động thử nghiệm la một bổ sung ch quá

trình thử nghiệm của bạn. Một số học giả cho rằng thời gian để phát triển,

xác minh, va tai liệu một trƣờng hợp kiểm tra tự động có thể tốn gấp 3-10

lần thời gian kiểm tra bằng tay. Zambelich chỉ ra rằng điều nay đặc biệt

đúng nếu bạn chọn để phƣơng pháp ―ghi / phát lại‖ la phƣơng pháp tự động

kiểm tra chinh của bạn. Trong thực tế, nói rằng Zambelich ghi / phát lại la

phƣơng pháp it -hiệu quả nhất của phƣơng pháp tự động hoá kiểm tra. Kiểm

tra tự động có thể đem lại hiệu quả, the Zambelich, nếu theo các điều sau:

• Chọn một công cụ thử nghiệm phù hợp nhất các yêu cầu thử nghiệm

của tổ chức hặc công ty của bạn. Một cuốn cẩm nang kiểm tra tự động

có sẵn từ các Viện Kiểm thử phần mềm

(http://www.sftwaretestinginstitute.cm).

• Hiểu rằng nó không thể tự động hoá mọi thứ. Xét nghiệm quá phức tạp

thƣờng gặp nhiều rắc rối để tự động hoá hơn la đem lại hiệu quả. Tập

trung va tự động hoá phần lớn các thử nghiệm đơn giản của bạn. Để lại

các bai kiểm tra quá phức tạp để kiểm tra bằng tay.

• Chỉ tự động hoá các xét nghiệm sẽ đƣợc lặp đi lặp lại; thử nghiệm

không lặp la không đáng tự động hoá.





16.5 THỰC TẾ TIẾP CẬN TỰ ĐỘNG TESTING SFTWARE

Isenberg (1994) explains requirements for success in automated

software testing. In order to succeed, the following four interrelated

components must work together and support one another.

• Automated testing system — it must be flexible and easy to update.

• Testing infrastructure — this includes a good bug tracking system,

standard test case format, baseline test data, and comprehensive test

plans.

• Software testing life cycle — it defines a set of phases outlining what

test activities to perform and when to conduct them. These phases are

planning, analysis, design, construction, testing (initial test cycles, bug

fixes, and retesting), final testing and implementation, and

postimplementation.

• Corporate support — automation cannot succeed without the

corporation‘s commitment to adopting and supporting repeatable

processes.

Isenberg (1994) giải thich các yêu cầu ch sự thanh công trong việc

kiểm tra phần mềm tự động. Để thanh công, bốn thanh phần sau phải lam

việc cùng nhau va hỗ trợ lẫn nhau.





• Hệ thống kiểm tra tự động – ba gồm hệ thống tìm lỗi tốt, định dạng test

case tốt, dự liệu test, kế hạch kiểm lỗi tốt.

• Kiểm tra chu kỳ Phần mềm – xác định một tập hợp các bƣớc việc kiểm

lỗi thực hiện va khi na thực hiện, ba gồm lập kế hạch, phân tich, thiết

kế, tiến hanh, sửa lỗi, cai đặt lần cuối.

• Cơ sở hạ tầng testing -cuộc sống nó định nghĩa một tập hợp các giai

đoạn phác thoả những gì để thực hiện các hạt động kiểm tra va khi tiến

hanh chúng. Những giai đoạn đang có kế hoạch, phân tich, thiết kế, xây

dựng, thử nghiệm (các chu trình thử nghiệm ban đầu, sửa lỗi, va

retesting), thử nghiệm cuối cùng va thực hiện, va postimplementation.

• Hỗ trợ của danh nghiệp – việc kiểm lỗi tựu động không thể thanh công

ma không có cam kết của Tổng công ty để áp dụng va hỗ trợ quá trình

lặp lại.

Automated testing systems should have the ability to adjust and

respond to unexpected changes to the software under test, which means that

the testing systems will stay useful over time. Some of the practical features

of automated software testing systems suggested by Isenberg are:

• Run all day and night in unattended mode

• Continue running even if a test case fails





• Write out meaningful logs

• Keep test environment up to date

• Track tests that pass, as well as tests that fail

Hệ thống tự động thử nghiệm nên có khả năng điều chỉnh va phản

ứng với những thay đổi bất ngờ của phần mềm đƣợc thử nghiệm, có nghĩa

la các hệ thống kiểm nghiệm hữu ich sẽ ở lại qua thời gian. Một số tinh

năng thiết thực của các hệ thống kiểm tra tự động phần mềm đƣợc đề xuất

bởi Isenberg là:

• Khởi động cả ngay va đêm trong chế độ không giám sát

• Tiếp tục chạy ngay cả khi một trƣờng hợp thử nghiệm không thanh

công

• Viết ra các bản ghi có ý nghĩa

• Môi trƣờng test giống môi trƣờng thực tế.

• The dõi các xét nghiệm đúng, cũng nhƣ các bai kiểm tra ma sai

16.6 SỬ DỤNG CÔNG CỤ THỬ NGHIỆM TỰ ĐỘNG

When automated testing tools are introduced, test engineers may

need to face some difficulties. Project management should be used to plan





the implementation of testing tools. Without proper management and

selection of the right tool for the job, automated test implementation will

fail (Hendrickson, 1998). Dustin (1999) has accumulated a list of

―automated testing lessons learned‖ from his experiences with real projects

and test engineer feedback. Some are presented here:

• The various tools used throughout the development life cycle do not

• integrate easily if they are from different vendors.

• Automated testing tools can speed up the testing effort; however, it

• should be introduced early in the testing life cycle in order to gain

benefits.

• Duplicate information that is kept in multiple repositories is difficult to

maintain. As a matter of fact, in many instances the implementation of

more tools can result in less productivity.

• The automated testing tool drives the testing effort. Often when a new

tool is used for the first time, more time is spent on installation,

training, initial test case development, and automating test scripts than

on actual testing.

• It is not necessary for everyone on the testing staff to spend his or her

time automating scripts.





• Sometimes elaborate test scripts are developed through overuse of the

testing tool‘s programming language, which duplicates the

development effort. That is, too much time is spent on automating

scripts without much additional value gained. Therefore, it is important

to conduct an automation analysis and to determine the best approach

to automation by estimating the highest return.

• Automated test script creation is cumbersome. It does not happen

automatically.

• Tool training needs to be initiated early in the project so that test

engineers have the knowledge to use the tool.

• Testers often resist new tools. When introducing a new tool to the

testing program, mentors and advocates of the tool are very important.

• There are expectations of early payback. When a new tool is introduced

to a project, project members anticipate that the tool will narrow the

testing scope right away. In reality, it is the opposite — i.e.,

• initially the tool will increase the testing scope.

Khi công cụ kiểm tra tự động đƣợc giới thiệu, kỹ sƣ kiểm tra có thể

phải đối mặt với một số khó khăn. Quản lý dự án nên lam quen với việc lên

kế hạch thực hiện các công cụ kiểm tra. Nếu không có quản lý phù hợp va

lựa chọn công cụ thich hợp ch công việc, việc kiểm tra tự động sẽ không





thanh (Hendricksn, 1998). Dustin (1999) đã tich lũy đƣợc một danh sách

các "kinh nghiệm testing‖ từ kinh nghiệm của mình với các dự án thực tế va

phản hồi của kỹ sƣ kiểm tra. Một số đƣợc trình bay ở đây:

• Các công cụ khác nhau đƣợc sử dụng trong suốt chu kỳ phát triển phần

mềm không tich hợp một cách dễ dang nếu chúng đƣợc từ nha cung

cấp khác nhau.

• Tự động công cụ kiểm tra có thể tăng tốc độ kiểm tra, tuy nhiên, cần

sớm đƣợc giới thiệu trong chu trình sống thử nghiệm để đạt đƣợc lợi

ích.

• Bản sa các thông tin ma đƣợc giữ trong kh nhiều la khó khăn để duy trì.

Nhƣ một vấn đề của thực tế, trong nhiều trƣờng hợp thực hiện nhiều

công cụ có thể dẫn đến năng suất thấp hơn.

• Các công cụ kiểm tra tự động điều khiển nỗ lực thử nghiệm. Thông

thƣờng khi một công cụ mới đƣợc sử dụng ch lần đầu tiên, cần danh

nhiều thời gian cho việc cai đặt, đao tạo, trƣờng hợp thử nghiệm ban

đầu phát triển, va tự động hoá các kịch bản thử nghiệm hơn về việc

kiểm tra thực tế.

• Không cần thiết cho tất cả mọi ngƣời trên các nhân viên kiểm nghiệm

để danh thời gian của mình tự động hoá các script





• Đôi khi xây dựng kịch bản thử nghiệm đƣợc phát triển vƣợt quá khả

năng của công cụ thử nghiệm, dẫn đến tốn chi phi hơn gấp nhiều lần.

Vì vậy, điều quan trọng để tiến hanh phân tich tự động hóa va xác định

phƣơng pháp tốt nhất để tự động hóa theo ƣớc tinh lợi nhuận cao nhất.

• Tự động tạo ra kịch bản thử nghiệm la rƣờm ra. Nó không xảy ra tự

động.

• Đa tạ sử dụng Công cụ cần phải đƣợc bắt đầu sớm trong dự án để kỹ sƣ

thử nghiệm có kiến thức để sử dụng công cụ.

• Testers thƣờng chống lại các công cụ mới. Khi giới thiệu một công cụ

mới để các chƣơng trình thử nghiệm, cố vấn va ủng hộ của công cụ nay

la rất quan trọng.

• Có những mong đợi của hoan vốn sớm. Khi một công cụ mới đƣợc giới

thiệu đến một dự án, các thanh viên dự án dự đán rằng công cụ sẽ thu

hẹp phạm vi kiểm tra ngay lập tức. Trong thực tế, nó la ngƣợc lại – tức

la, bƣớc đầu công cụ sẽ tăng phạm vi kiểm tra.

16.7 KẾT LUẬN

Test engineers can enjoy productivity increases as a testing task

becomes automated and a thorough test plan is implemented. Creating a

good and comprehensive automated test system requires an additional

investment of time and consideration, but it is cost effective in the long run.





More tests can be executed while the amount of tedious work on

construction and validation of test cases is reduced.

Kỹ sƣ kiểm tra có thể thich việc tăng năng suất khi test tự. Tạo ra

một hệ thống kiểm tra tự động tốt va toan diện đòi hỏi phải đầu tƣ thêm thời

gian va xem xét, nhƣng nó la chi phi có hiệu quả về lâu dai. Nhiều xét

nghiệm đƣợc chạy trong khi số lƣợng công việc tẻ nhạt trong việc kiểm lỗi

đƣợc giảm xuống.

Automated software testing is by no means a complete substitute for

manual testing. In other words, manual testing cannot be totally eliminated;

it should always precede automated testing. In this way, the time and effort

saved by using of automated testing can now be focused on more important

testing areas.

Phần mềm tự động thử nghiệm la do không có nghĩa la thay thế

hoan tan để thử nghiệm các hƣớng dẫn sử dụng. Nói cách khác, kiểm tra tay

không thể đƣợc lại bỏ hoan tan, nó luôn luôn phải đứng trƣớc thử nghiệm tự

động. Bằng cách nay, ta có thể danh thời gian nhiều hơn cho các mảng

testing quan trọng hơn.


Aivazis, M., (2000). Automatic unit testing, Computer, 33, back

cover.





Dustin, E. (1999) Lessons in test automation, STQE Mag., and from

the World Wide Web: http://www.stickyminds.com/pop_print.asp?ObjectId

= 1802&ObjectType = ARTCO, October, 41.

Hendrickson, E. (1998). The difference between test automation

failure and success, Quality Tree Software, retrieved from

http://www.qualitytree.com/feature/dbtasaf.pdf.

Isenberg, H.M. (1994) The practical organization of automated

software testing, Multi-Level Verification Conference 95, December 1994,

retrieved from http://www.automated-testing.com/PATfinal.htm.

Kolawa, A., (2001). Regression testing at the unit level? Computer,

34, back cover.

Pettichord, B. (2001). Success with test automation, retrieved from

http://www.io.com/~wazmo/succpap.htm.

Raynor, D.A. (1999). Automated software testing, retrieved from

http://www.trainersdirect.com/resources/articles/ProjectManagement/Auto

matedSoftwareTestingRaynor.html.

Zallar, K. (2002). Automated software testing — a perspective,

retrieved from http://www.testingstuff.com/autotest.html.


http://www.qualitytree.com/feature/dbtasaf.pdf

http://www.automated-testing.com/PATfinal.htm

http://www.io.com/~wazmo/succpap.htm

http://www.trainersdirect.com/resources/articles/ProjectManagement/AutomatedSoftwareTestingRaynor.html

http://www.trainersdirect.com/resources/articles/ProjectManagement/AutomatedSoftwareTestingRaynor.html

http://www.testingstuff.com/autotest.html




Zambelich, K. (2002). Totally data-driven automated testing,

retrieved from http://www.sqatest.com/w_paper1.html.


http://www.sqatest.com/w_paper1.html



Chương 17: Quá trình thực hiện kiểm định EDP 602

CHƢƠNG 17 QUÁ TRÌNH THỰC HIỆN KIỂM

ĐỊNH EDP

Người dịch:



13. Nguyễn Tấn


15. Lê Hoang Vũ





17.1 QUÁ TRÌNH THỰC HIỆN KIỂM ĐỊNH EDP

For as long as there have been computer departments there have been

EDP (electronic data processing) auditors. These were and are the people

who make sure a system does what it is supposed to do. In this chapter we

discuss a methodology for EDP auditing using a Web-based system as an

example.

Chuyên viên kiểm định xử lý dữ liệu điện tử(EDP auditors):la những

ngƣời bảo đảm hệ thống chạy đúng nhƣ những gì nó đƣợc yêu cầu. Nội

dung chƣơng: Phƣơng pháp kiểm định EDP sử dụng hệ thống chạy trên nền

web(Web-based system) lam vi dụ

In the ―Wild West‖ days of the Internet, companies were ―plopping‖

systems online faster than you could say ―dot-com crash and burn‖. Now

that those heady days appear to be over, smart organizations are beginning

to think of their Web-based systems in the same terms as they do their more

conventional systems.

Trong những ngay sơ khai của internet,những công ty hay bị ―rơi

khỏi‖ mạng còn nhanh hơn la bạn có thể nói ―.Com‖ cháy va sụp đổ. Tuy

nhiên,những ngay đó đã qua đi,va ngay nay,các công ty luôn chú trọng vao

hệ thống chạy trên nền web(Web-based systems) của họ ngang tầm với

những gì ma họ xây dựng cho các tiện ich khác





In their quest toward increasing market share while lowering costs,

these organizations are finally delving into the intricacies of the Web-based

system to scrutinize such things as response time/availability, accessibility,

ergonomics, logistics, customer service, and security and privacy.

Các công ty nay ngay cang chú trọng vao việc tăng thị phần va giảm

đi chi phi.Với mục đich đó họ chú trọng vao Web-based system để ra soát

những thứ nhƣ thời gian phản ứng, thời gian sẵn có, khả năng kết nối, hậu

cần, dịch vụ khách hang, an ninh va sự riêng tƣ.

This chapter provides the IT manager with a series of checklists that

can be used to audit the Web-based system and easily modified to audit

conventional systems. Audits should be done regularly, with the results

used to fine-tune the system. Ultimately, think of these checklists as a set

ofissues that can be considered ―food for thought‖.

Chƣơng nay cung cấp cho những ngƣời quản lý hệ thống(IT

manager) một loạt các bảng kiểm mục có thể đƣợc sử dụng để kiểm toán

các hệ thống dựa trên web (Web-based system)va dễ dang sửa đổi để kiểm

toán các hệ thống theo quy ƣớc.Việc kiểm định phải diễn ra thƣờng xuyên

để đƣa ra các kết quả dùng để tinh chỉnh hệ thống va các bảng kiểm định

đƣợc xem nhƣ la 1 loạt các vấn đề đƣợc đƣa ra để giải quyết, va nó đƣợc

gọi la ―food for thought‖





17.2 TỔ CHỨC CỦA SỰ KIỂM ĐỊNH

It is recommended that you hire an external consulting firm to

perform this critical effort; however, your EDP audit department, with

adequate training, would be a sufficient alternative. The reason why I much

prefer an external auditor is that ―neutral third parties‖ are usually more

objective because they are not stakeholders and are not friendly with

stakeholders. There is nothing like an unbiased opinion.

Chúng tôi đề nghị bạn thuê một công ty tƣ vấn bên ngoai để thực

hiện các công việc quan trọng. Tuy nhiên, EDP bộ phận, kiểm toán của bạn

với đao tạo phù hợp, sẽ la một thay thế đầy đủ. Lý do tại sao tôi rất thich

kiểm toán viên bên ngoai vì họ la "bên thứ ba trung lập‖ thƣờng đáp ứng

đƣợc nhiều mục tiêu bởi vì họ không phải la các bên liên quan va không

quen biết với các bên liên quan. Họ sẽ không có ý kiến thiên vị bên nào.

At a minimum, the auditor should obtain the following

documentation:

1 ngƣời kiểm toán viên phải xây dựng đƣợc 3 tai liệu sau:





A diagram of the application system.A Web-based system is not

unlike any other computer system. It has processes (e.g., process credit

card) and entities (e.g., airline ticket) and shows the flow of data between





the entities via the processes. Exhibit 17-1 shows an excerpt from a typical

data-flow diagram.

Sơ đồ của hệ thống ứng dụng (A diagram of the application system).

Một Web-based system không phải la không giống nhƣ bất kỳ hệ thống

máy tinh khác.Nó có các quy trình (vi dụ, quá trình thẻ tin dụng) va các tổ

chức (vi dụ, hãng hang không vé) va cho ta thấy dòng chảy của dữ liệu giữa

các thực thể thông qua các quá trình.Hỉnh 17-1 cho thấy một đoạn trich từ

một luồng dữ liệu sơ đồ điển hình.





• A network diagram. Most modern computer systems are developed

using one of several traditional network architectures (i.e., two-tier, three-

tier, etc.). Add EDI or Internet connectivity and you have quite a





sophisticated environment. The auditor will need a roadmap to this

environment to be able to determine any connectivity issues. Exhibit 17-2

demonstrates what a simple network diagram should look like.

Sơ đồ mạng(A network diagram): nó la lộ trình để các kiểm định

viên có thể xác định bất cứ vấn đề nao trên môi trƣờng mạng

• Staff hierarchy diagram. A complete list, preferably a diagram that

shows direct reports, along with phone numbers and e-mail addresses is

required. A good starting point is shown in Exhibit 17-3.

Sơ đồ phân cấp đội ngũ nhân sự(Staff hierarchy diagram): Một danh

sách đầy đủ các nhân viên, báo cáo, đi cùng với yêu cầu về số điện thoại va

địa chỉ e-mail





One would think that a modern organization would have these three

items readily available. Think again. In my own experience, few of the

organizations that I audit possess all three of these required items. Few

possess even two.

Chúng ta nghĩ rằng một tổ chức hiện đại sẽ có cả ba tai liệu. Hãy

nghĩ lại. Theo kinh nghiệm của riêng tôi, các công ty ma tôi kiểm toán. Ít có

tổ chức nao có hết cho dù la 2 tai liệu.

If these are not available to the auditor, my recommendation is to

start the audit effort with a series of brainstorming sessions in which at least

the two diagrams are created. Even if diagrams are available, one or more

brainstorming sessions are still advisable. This provides the auditors a

―walk through‖ where system and network architects can be questioned

directly and invariably speeds up the audit process.

Nếu những không có sẵn để kiểm toán viên, đề nghị của tôi la để bắt

đầu kiểm toán với một loạt các buổi ―BrainStorm‖, trong đó it nhất la hai

biểu đồ đƣợc tạo ra. Thậm chi nếu sơ đồ có sẵn, vẫn nên tổ chức một hoặc

nhiều phiên họp ―BrainStorm‖. Việc nay cung cấp cho các kiểm toán viên

―walk through‖ hệ thống va mạng lƣới các kiến trúc va tăng tốc quá trình

kiểm toán.

Once the preliminary step has been completed (i.e., understanding

the system), the auditor can proceed through his or her paces in a logical





and methodical manner. The following sections, presented as a series of

checklists, represent areas of the audit that can be performed in any order.

Một khi bƣớc sơ bộ đã đƣợc hoan thanh, các kiểm toán viên có thể

tiến hanh thông qua một cách hợp lý. Những phần sau, biết tới nhƣ la một

loạt các kiểm tra, danh sách, đại diện cho các lĩnh vực của kiểm toán có thể

đƣợc thực hiện theo thứ tự bất kỳ.

The checklist is actually a series of questions or areas to be studied.

The responses to these questions form the data collected for input to the

final audit report. This report will contain problems found and issues

overlooked, as well as recommendations for improvement. For example, the

auditor might find that the company has done inadequate security testing.

The recommendation here might be to bring in a ―white hat‖ to perform

penetration as well as intrusion testing. Alternatively, the audit might

uncover a deficiency in fulfillment processes the company follows to ship

products to the customer. Again, the audit report will make

recommendations for improvement.

Danh sách kiểm tra(checklist) thật ra la một loạt các câu hỏi hoặc các

khu vực đƣợc nghiên cứu. Những câu hỏi dạng dữ liệu thu thập cho vao báo

cáo kiểm toán cuối cùng. Báo cáo nay sẽ chứa những vấn đề, xem xét, cũng

nhƣ các khuyến nghị để cải thiện. Vi dụ, các kiểm toán viên có thể thấy

rằng công ty đã thực hiện kiểm tra an ninh không đủ. Các khuyến nghị ở

đây có thể la để mang lại một ―white hat‖ để thâm nhập cũng nhƣ kiểm tra





sự xâm nhập. Ngoai ra, các kiểm toán có thể phát hiện ra sự thiếu hụt trong

quá trình thực hiện để giao sản phẩm cho khách hang. Một lần nữa, báo cáo

kiểm toán sẽ đƣa ra các đề nghị để cải thiện.

17.3 SYSTEMIC AUDIT:

17.3.1 Hệ thống kiểm toán

It is surprising that many companies spend millions of dollars on

advertising budgets to draw more ―eyeballs‖ to their sites but never factor

in whether or not the projected additional load can be supported by the

current system configuration. A systemic audit looks at such things as

response time, network architecture, and linkages.

Thật ngạc nhiên khi nhiều công ty chi tiêu hang triệu đô la vao ngân

sách quảng cáo để thu hút thêm mọi ngƣời đến các trang web của họ lại it

khi quan tâm đến yếu tố về các thanh phần có thể gắn thêm hỗ trợ bởi cấu

hình hệ thống hiệntại.Một hệ thống kiểm toán sẽ nhìn vao những yếu tố trên

nhƣ thời gian đáp ứng, kiến trúc mạng va mối liên kết.





17.3.2 Thời gian đáp ứng

Measurables in this section include actual response time versus

projected response time. In spite of advances in supplying high-bandwidth

connections to consumers, the vast majority of PCs are connected to the

Web with little more than a 56-Kb modem and good intentions. This means

that sites that are highly graphical or use add-ons such as Macromedia Flash

will appear slow to download

Một Measurables trong phần nay bao gồm thời gian phản ứng thực tế

so với dự kiếnthời gian đáp ứng. Mặc dù có tiến bộ trong việc cung cấp

băng thôngkết nối cao đến ngƣời tiêu dùng, đại đa số các máy tinh đƣợc kết

nối vớiWeb với it hơn 56-modem Kb. Điều nay có nghĩamà các trang web

đƣợc đánh giá cao đồ họahoặc sử dụng tiện ich nhƣ MacromediaFlash sẽ tải

về rất chậm.





Given the wide variety of modem types, auditors should test the

response time of the site using different scenarios such as:

• Using a DSL or cable modem connection

• Using a 56-Kb connection

• Using a 28-Kb connection

• At random times during the day, particularly 9 a.m (start of work day)

and 4 p.m. (kids home from school

Web sites such as netmechanic.com, a subscription service, can

assist in this endeavor by checking for slow response time directly from

their Web sites.)

Do sự đa dạng các loại modem, kiểm toán viên nên kiểm trathời gian

đáp ứng của trang web bằng cách sử dụng các cách khác nhau nhƣ:

• Sử dụng một DSL hoặc kết nối modem cáp

• Dùng 56-Kb kết nối

• Dùng 28-Kb kết nối

• Tại lần ngẫu nhiên trong ngay, đặc biệt la 09:00 (bắt đầu ngay lam

việc) va 04:00 (giờ ra về)





Những trang web nhƣ netmechanic.com, một dịch vụ thuê bao, có

thể hỗ trợtrong nỗ lực nay bằng cách kiểm tra cho thời gian phản ứng chậm

trực tiếp từ website của họ.

17.3.3 Liên kết hỏng

One of the top five irritants that Web surfers report is clicking on a

linkand getting a ―nonexistent page‖ error message. This often results

fromsystem maintenance where Web programmers move the actual page

butneglect to modify the link to that page. Unfortunately, this is a

frequentoccurrence. One of a number of tools, including netmechanic.com,

canassist in tracking down these broken links.

Một trong những năm đầu, các trang web thƣờng báo la liên kết đã

hỏng hoặc ―không tồn tại trang". Điều nay thƣờng la kết quả từ hệ thống

bảo trì, nơi các trang web di chuyển nhƣng ngƣời ta lại bỏ bê sửa đổi các

liên kết tới trang đó. Thật không may, đây la một việc thƣờng xuyên xảy

ra. Một trong một số công cụ, bao gồm cả netmechanic.com, có thểhỗ trợ

cho việc theo dõi xuống những liên kết nay bị hỏng.

17.3.4 Cơ sở dữ liệu kiểm toán

Originally the Web was a simple place consisting mostly of text;

nary adatabase was in sight. Today, the Web is filled to the brim with

databases.The addition of databases makes the audit process even more





complex.Because programming code is used to query, and perhaps even

calculate,against thatdatabase, it is imperative that random checks be

performed inan effort to pinpoint database query and calculation

errors.Essentially, auditing database access is similar to traditional IT

(information technology)QA (quality assurance) process. One or more

scriptsmust be written that will take that database through its paces. For

example,if a database program calculates insurance rates based on a zip

code, thenthat calculation should be duplicated manually or in a different

parallelautomated fashion to ensure that the result is correct. The same can

besaid for information that visitors to the site enter via a form. Is the

informationentered the same as that sent to the database?

Ban đầu trang Web la một nơi đơn giản, chủ yếu la văn bản; load

mộtcơ sở dữ liệu đã đƣợc chọn. Hôm nay, trên Web la đến kết nối trực tiếp

với cơ sở dữ liệu cang nhanh hơn.Việc bổ sung cơ sở dữ liệu lam cho quá

trình kiểm toán phức tạp hơn.

Bởi vì mã lập trình đƣợc sử dụng để truy vấn, va thậm chi tinh

toán,đối với cơ sở dữ liệu đó, Vì vậy bắt buộc ta phải kiểm tra ngẫu nhiên

đƣợc thực hiện tạimột thời điểm để xác định các lỗi truy vấn cơ sở dữ liệu

va tinh toán.Về cơbản, kiểm toán, truy cập cơ sở dữ liệu tƣơng tự nhƣ thông

tintruyền thốngnhằm bảo đảm chấtlƣợng của quá trình. Một hoặc nhiều

kịch bảnphải đƣợc viết ra để cơ sở dữ liệu đƣợc test thông qua nó. Ví

dụ,nếu một chƣơng trình cơ sở dữ liệu tinh toán mức giá bảo hiểm dựa trên





một mã vùng, sau đóma tinh toán nên đƣợc lặp lại bằng tay hoặc một cách

khác a phải lam song song nhau.Thông tin thu đƣợcđể đảm bảo rằng kết

quả hoạt động la có tốt hay hông. Cũng có thể đƣợcnói cho các thông tin

ma khách truy cập vao trang web nhập thông qua một biểu mẫu để chúng ta

test lỗi.

17.3.5 Mạng kiểm toán

The network, including node servers, should be tested to see if it is

effectively configured to provide optimum response. It is not uncommon to

find the Web development group separated from the traditional IT develop-

ment group. This means that one frequently finds network configurations

designed inappropriately for the task at hand. For example, a site attracting

tens of thousands of hits a day would do well to run a multitude of Web

servers rather than just one.

Most organizations use one or more ISPs (Internet service providers)

to host their sites. The auditor should carefully gauge the level of service

provided by these ISPs as well.

Mạng nay sẽ kiểm tra cả máy chủ để xem nócó cấu hình hiệu quả tối

ƣu để cung cấp đáp ứng những nhu cầu đặt ra hay không. Điều không phải

la không phổ biến, đặc biệt trong các nhóm phát triển web tách ra từ

cácCNTT truyền thống phát triển. Vi dụ, một trang web thu húthang chục

ngan hits một ngay thƣờng sẽ có vô số webmáy chủ thay vì chỉ một.Hầu hết





các tổ chức sử dụng một hoặc nhiều ISP (nha cung cấp dịch vụ Internet)

đểlƣu trữ các trang web của họ. Các kiểm toán viên nên cẩn thận đo mức độ

dịch vụ cung cấp bởi các ISP nao la tốt nhất.

17.3.6 An ninh va chất lƣợng

No one topic is discussed more in the press than Internet security.

From ―love bug‖ viruses to wily hackers breaking into Western Union,

security is an important component of the audit.

It is worthwhile to keep in mind that the auditor is not a security

auditor, nor should he be. His role is to conduct a top level assessment of

the security of the Internet- or Intranet-based system and, if warranted,

recommend the services of a security firm well versed in penetration and

intrusion testing. The entire issue of security is wrapped up within the more

comprehensive issue of quality. This section will address both issues.

Không có một chủ đề đƣợc thảo luận trên báo chi nhiều hơn so với

bảo mật Internet. Từ sự kiện virus "I LOVE YOU‖ để tin tặc đột nhập vao

gian trá Western Union, an ninh la một thanh phần quan trọng của kiểm

toán này.

Chú ý rằng rằng các kiểm toán viên không phải la một kiểm toán

viên an ninh. Vai trò của kiểm toán viên chỉ la để tiến hanh đánh giá xác

định đƣợc cấp cao nhất của bảo mật của Internet hoặc Intranet dựa trên hệ

thống, va nếu cần thiết sẽ đề nghị các dịch vụ của một công ty bảo mật để





kiểm tra.Toan bộ các vấn đề an ninh la sẽ nói lên phạm vi toan diện hơnvấn

đề chất lƣợng.

17.4 BẢO MẬT VÀ CHẤT LƢỢNG BẢO MẬT

It is worthwhile to keep in mind that the auditor is not a security

auditor, nor should he be. His role is to conduct a top level assessment of

the security of the Internet- or Intranet-based system and, if warranted,

recommend the services of a security firm well versed in penetration and

intrusion testing. The entire issue of security is wrapped up within the more

comprehensive issue of quality. This section will address both issues.

Không có chủ đề nao thảo luận nhấn mạnh nhiều bảo mật mạng

(Internet security). Từ virus ―love bug‖ đến những hackers bẻ khóa Wester

Union, bảo mật (security) la thanh phần quan trọng của việc kiểm tra

(important component of the audit.)

Thật tốt khi biết rằng ngƣời kiểm tra (auditor) không phải la ngƣời

kiểmtra bảo mật (security auditor). Nếu đƣơc quyền thì vai trò của anh ta

chỉ la quản lý 1 mức độ đánh giá nhất định về bảo mật (security) của

internet hoặc Intranet-based system va phó thác vao những dịch vụ bảo mật

tốt trong việc ngăn chặn va xâm nhập(security firm well). Toan bộ kết quả

của bảo mật thì đƣợc bao ham trong kết quả của chất lƣợng. Phần nay sẽ

mang vị tri của 2 kết quả





17.4.1 Xem xét lại những kế hoạch bảo mật

All organizations must possess a security plan in writing. If they do

not have this then they are severely deficient. The plan, at a minimum,

should address:

Mọi tổ chức phải có một kế hoạch bảo mật bằng văn bản(in writing).

Nếu chúng không có điều nay thì. Kế hoạch, ở một mức tối thiểu, nên có:

• Authentication. Is the person who he says he is.

• Chứng thực: La ngƣời ma có thể chứng minh đc ngƣời đó la ai ?

• Authorization. What users have what privileges; in other words, ―who

can do what?‖

• Sự ủy quyền.Ngƣời dùng có thể lam gì, nói cách khác la Ai có thể lam

gì?

• Information integrity. Can the end user maliciously modify the

information?

• Toan vẹn thông tin, Ngƣời dùng cuối có thể chỉnh sửa nguy hại đến

thông tin ?

• Detection. Once a problem is identified, how is it handled?





• Nhận ra đc vấn đề. 1 vấn đề đƣợc tìm thấy, nhƣng lam thế nao để điều

khiển nó

17.4.2 Passwords

Passwords are the first shield of protection against malicious attacks

upon your eBusiness. Questions to ask in this section include:

Mật khẩu la lá chắn bảo vệ đầu tiên chống lại sự tấn công các ý vao

doanh nghiệp điện tử của bạn (eBusiness). Những câu hỏi đặt ra trong phần

nay bao gồm:

• Is anonymous login permitted? Under what conditions?

• Có cho phép 1 anonymous login vao không? Dƣới điều kiện la gì ?

• Is a password scanner periodically used to determine if passwords can

be hacked? Examples of this sort of utility include L0phtcrack.com for

NT and www.users.dircon.co.uk/~crypto for UNIX.

• máy quét password đƣợc dùng định kì để xác định sẽ thế nao nếu

những password bị hack

• How often are passwords changed?

• Passwords thƣờng xuyên thế nao?





• How often are administrative accounts used to log on to systems?

Passwords are hard to remember. This means that, in order to gain

entrance to systems quickly, administrative and programming systems

people often create easy-to-remember passwords such as ―admin‖.

These are the first passwords that hackers try to gain entrance into a

system.

• Tai khoảng admin thƣờng log on vao hệ thống bao nhiu lần? Passwords

thì khó nhớ.Điều nay có nghĩa la, để vao đc hệ thống nhanh chống,

admin va ngƣời hệ thống chƣơng trình thƣờng tạo password dễ nhớ nhƣ

―admin‖. Đây cũng la password đầu tiên ma hacker thƣờng thử để vao

hệ thống

17.4.3 Staff Background

Administrative network staff must have a security background as

well as a technical background. Those wishing to train their staffs would do

well to look into the security skills certification program provided by

www.sans.org.

Đội ngũ admin mạng phải có nền tản bảo mật va kĩ thuật tốt. Đội ngũ

admin mạng phải có nền tản bảo mật va kĩ thuật tốt. Việc đó muốn đao tạo

đội của họ sẽ lam tốt để tìm đc bằng chƣơng trình kĩ năng bảo mật đc

provided by www.sans.org.


http://www.sans.org/




17.4.4 Connectivity

Today‘s organization may have many external connections (i.e.,

partners, EDI, etc.), each of which the auditor should examine:

Việc tổ chức ngay nay có lẽ phải có nhiều kết nối từ bên ngoai (vd,

partners, EDI..), mỗi cái kết nối, Auditor nên xem xét:

• The data passed between organizations: is what the company sent

received correctly?

• Dữ liệu truyền giữa những tổ chức: cái ma công ty truyền va nhận có

đúng hay ko ?

• The security of the connection: how is the data transmitted? Is it

required to be secure? Is encryption used?

• Bảo mật của kết nối: bằng cách nay dữ liệu đc truyền đi, nó có đòi đỏi

đc bảo đảm ko ? Việc mã hóa có thƣờng dùng ko ?

• If encryption is indeed used, it must be determined whether an

appropriate algorithm is deployed.

• •Nếu sự mã hóa thật sự đc dùng, nó phải dùng thuật toán thich hợp nao

cho hiệu quả?





17.4.5 Cơ sở cần có của phần mềm

All organizations invest in and then use a great deal of third-party

software. As publicized by the press, much of this software — particularly

browsers and e-mail packages, but word processing packages as well —

contain security holes that, left unpatched, put the organization at risk.

Therefore, for each software package used (for Net purposes):

Tất cả những tổ chức đầu tƣ vao xây dựng phần mềm va sau đó dùng

phần mềm của bên thứ 3. Khi đƣa ra công khai điểm nay, thì có nhiều phần

mềm nhƣ vậy – đặc biệt la những gói của trình duyệt va email, cũng nhƣ la

những gói word processing – chứa lỗ hổng bảo mật, chƣa đc vá, ƣớc chừng

la sẽ đc đƣa va sử dụng. Vì thế, mỗi gói phần mềm đc dùng cần (cho mục

đich mạng (Net)):

• Check for publicized security holes.

• Kiểm tra va công khai lỗ hổng bảo mật

• Check for availability of software patches. Always upgrade to the latest

version of software and apply the latest patches.

• Kiểm tra những phần mềm vá còn hiệu lực, luôn nâng cấp phần mềm

mới nhất va sử dụng bản vá mới nhất.

• Check to see if patches have been successfully applied.





• Kiểm tra để thấy rằng việc vá có thanh công ko ?

• Check security software for security holes. Security software, such as a

firewall, can contain security holes just like any other type of software.

Check for updates.

• Kiểm tra phần mềm bảo bạo để tìm lỗi bảo mật. Phần mềm bảo mật

nhƣ la firewall có thể chứa lỗ hỏng bảo mật giống nhƣ những loại phần

mềm khác.Kiểm tra va update.

17.4.6 Phát triển trong nha

The vast majority of Web-based software is written by in-house

programming staff. When writing for the Web it is important to ensure that

your own staff does not leave gaping holes through which malicious

outsiders can gain entrance. There are a variety of programming

―loopholes‖ that open the door wide to hackers:

Phần lớn phần mềm dựa trên nền web (Web-based) đc biết bởi đội

ngũ chƣơng trình trong nha(viết tại nha ?) (in-house programming staff).

Khi viết cho Web, quan trọng la phải đảm bảo rằng đội ngũ của bạn ko để

lại những lổ hỏng (ma nhửng mối nguy hiểm bên ngoai có thể vao). Có 1 số

chƣơng trình loopholes khác nhau, có thể mở rộng cửa cho hackers:

• In programming parlance, a ―GET‖ sends data from the browser

(client) to the server. For example, look at the query string below:





• Trong cách nói của lập trình, 1 ―GET‖ la gởi dữ liệu từ browser(client)

tới server. Vi dụ nhƣ, nhìn câu truy vấn dƣới đây:

http://www.site.com/process_card.asp?cardnumber = 123456789

All HTTP (hypertext transport protocol) requests get logged as

straight text into the server log as shown below:

Tất cả giao thức HTTP đòi hỏi phải ghi lại đoạn text thẳng vào

server, ghi nhƣ dƣới đây

2000–09–15 00:12:30 — W3SVC1 GET/process_card.asp

cardnumber = 123456789 200 0 623 360 570

80 HTTP/1.1 Mozilla/4.0+(compatible;+5.01;+Windows+NT)

Not only is the credit card number clearly visible in the log, but it

might also be stored in the browser‘s history file, thus exposing this

sensitive information to someone else using the same machine later.

Security organizations recommend utilization of the POST method rather

than the GET method for this reason.

Không chỉ la có số của thẻ tin dụng đc ghi rõ rang, ma nó còn chứa

tên file history của browser, vì vậy sẽ đƣa ra những thông tin nhạy cảm cho

1 số ngƣời khác dùng chung máy sau đó. Những tổ chức bảo mật khuyên la

nên dùng phƣơng pháp POST hơn la phƣơng pháp GET vì lý do này





Are the programmers using ―hidden‖ fields to pass sensitive

information? An example of this is relying on hidden form fields used with

shopping carts. The hidden fields are sometimes used to send the item price

when the customer submits the form. It is rather easy for a malicious user to

save the Web page to his own PC, change the hidden field to reflect any

price he wants, and then submit it.

Những lập trình viên thƣờng dùng thuộc tinh hidden để che dấu

những thông tin nhạy cảm nay. 1 vi dụ về việc tin cậy va thuộc tinh hidden

khi dùng với shopping carts.Thuộc tinh hidden thỉnh thoảng đc dùng để gởi

1 item price khi khách hang đồng ý form.Điều nay rát dễ cho những ngƣời

dùng có ý xuấ khi lƣu Web page vao PC của anh ta, thay đổi thuộc tinh ẩn

va chỉnh những giá ma anh ta muốn, sau đó đồng ý nó.

One way to combat the problem discussed in the previous item is to

use a hash methodology. A hash is a function that processes a variable-

length input and produces a fixed-length output. Because it is difficult to

reverse the process, the sensitive data transmitted in this matter is secured.

The auditor is required to assess the utilization of this methodology given

any problems he might find in assessing the previous item.

Phƣơng pháp chống lại vấn đề nay đã đc thảo luận trong nhiều điểm

trƣớc, la dùng phƣơng pháp hash. 1 hash la 1 chức năng thực thi chiều dai

giá trị biến input va đƣa ra 1 output có chiều dai cố định. Bởi vì khó có thể

đảo ngƣợc tiến trình, nên dữ liệu nhạy cảm đc chuyển đổi bằng cách nay sẽ





đc an toan. Auditor đc đòi hỏi phải đánh giá việc ứng dụng phƣơng pháp

nay cho những vấn đề anh ta tìm đc trong việc đánh giá những item trƣớc

Is sensitive data stored in ASP or JSP pages? Microsoft‘s Internet

information server (IIS) contains a number of security flaws that, under

certain circumstances, allows the source of an ASP or JSP page to be

displayed rather than executed. In other words, the source code is visible to

anyone browsing that particular Web site. If sensitive data, such as

passwords, is stored in the code then they will be displayed as well. The

rule here is not to hardcode any security credentials into the page.

Dữ liệu nhạy cảm đc chứa trong trang ASP hay JSP phải ko?

Microsoft‘s Internet information server (IIS) chứa 1 số bảo mật sai sót về

điều đó, dƣới những tình huống nao, cũng cho phép source của 1 trang ASP

hay JSP đc hiển thị hơn la thực thi.Nói cách khác, source code thì có thể

trông thấy bởi những ngƣời dùng duyệt 1 phần của Web site. Nếu dữ liệu

nhay cảm, nhƣ la password, thì đc lƣu trong code sau đó chúng cũng sẽ đc

hiển thị. Quy luật ở đây la không nên code cứng cho mọi khả năng bảo mật

vào trong trang web (page)

Are application-specific accounts with rights identified early in the

development cycle? There are two types of security. One is referred to as

―declarative‖ and takes place when access control is set from outside the

application program. ―Programmatic‖ security occurs when the program

checks the rights of the person accessing the system. When developing code





for the Web, it is imperative that the rights issue be addressed early in the

development cycle. Questions to ask include:

Sự ứng dụng các tai khoản riêng biệt với các quyền đƣợc xác định

trƣớc trong chu kỳ phát triển phải ko? Có hai loại hình bảo mật. Một la

đƣợc gọi la "declarative‖ va xảy ra khi kiểm soát truy cập đƣợc thiết lập từ

bên ngoai các chƣơng trình ứng dụng.(―Programmatic‖) Bảo mật "Có hệ

thống‖ xảy ra khi các chƣơng trình kiểm tra các quyền của ngƣời truy cập

vao hệ thống. Khi phát triển code cho Web, nó la bắt buộc rằng các vấn đề

quyền đƣợc giải quyết trƣớc trong chu kỳ phát triển. Các câu hỏi yêu cầu

bao gồm:

- How many groups will be accessing the data?

- Có bao nhiu nhóm sẽ đc truy cập vao dữ liệu ?

- Will each group have the same rights?

- Mỗi nhóm sẽ có quyền giống nhau ko ?

- Will you need to distinguish between different users within a group?

- Bạn có cần phải phân biệt giữa ngƣời dùng va nhóm ko ?

- Will some pages permit anonymous access while others enforce

authentication?





- Một số trang cho phép truy cập dƣới dạng nặc danh(anonymous) trong

khi một số trang thì đòi hỏi phải chứng thực ?

How are you dealing with cross-site scripting? When sites accept

userprovided data (e.g., registration information, bulletin boards), which is

then used to build dynamic pages (i.e., pages created on the spur of the

moment), the potential for security problems is increased 100- fold. No

longer is the Web content created entirely by the Web designers; some of it

now comes from other users. The risk comes from the existence of a

number of ways in which text can be entered to simulate code. This code

can then be executed as any other code written by the Web designers —

except that it was written by a malicious user instead. Javascript and html

can be manipulated to contain malicious code, which can perform a number

of activities such as redirecting users to other sites, modifying cookies, etc.

More information on this topic can be obtained from CERT‘s Website at

http://www.cert.org/advisories/CA-2000–02.html and

http://www.cert.org/tech_tips/ malicious_code_mitigation.html.

Lam thế nao bạn giao dịch với cross-site scripting? Khi các trang

web chấp nhận ngƣời sử dụng cung cấp dữ liệu (vi dụ, thông tin đăng ký,

các bản tin), ma sau đó sẽ đƣợc sử dụng để xây dựng các trang động (vi dụ,

các trang tạo ra chỉ trên thời điểm nay), tiềm năng cho các vấn đề an ninh

đƣợc tăng 100 lần. Không chỉ còn la nội dung của trang web đƣợc tạo ra do

các nhà thiết kế web, một phần của nó bây giờ đến từ những ngƣời dùng

khác. Nguy cơ đến từ việc tồn tại của một số cách ma trong đó các đoạn


http://www.cert.org/advisories/

http://www.cert.org/tech_tips/




text có thể đƣợc nhập để mô phỏng mã.Mã nay sau đó có thể đƣợc thực thi

nhƣ các mã khác giống các đoạn text của các nha thiết kế web – chỉ khác la

nó đƣợc viết bởi một ngƣời sử dụng độc hại để thay thế. Javascript va html

có thể đƣợc chế tác để chứa mã độc, có thể thực hiện một số hoạt động nhƣ

chuyển hƣớng ngƣời dùng đến trang web khác, sửa đổi các cookie, vv

thông tin thêm về chủ đề nay có thể đƣợc lấy từ Website CERT tại

http://www.cert.org/advisories/CA-2000–02.html and

http://www.cert.org/tech_tips/malicious_code_mitigation.html.

Have you checked Wizard-generated or sample code? Often

programmers ―reuse‖ sample code they find on the Web or make use of

generated code from Web development tools. Often the sample or

generated code contains hardcoded credentials to access databases,

directories, etc. The auditor will want to make sure that this is not the case

in the code being audited.

Bạn đã kiểm tra việc phát sinhWizard code hoặc code mẫu? Thƣờng

thì các lập trình viên "tái sử dụng‖ code mẫu ma họ tìm thấy trên Web hoặc

dùng công cụ tạo code ra từ công cụ phát triển Web. Thƣờng thì các code

mẫu hoặc tạo ra chứa hard coded để truy cập vao cơ sở dữ liệu, thƣ mục, vv

Các auditor (kiểm toán viên) muốn đảm bảo rằng đây không phải la trƣờng

hợp trong các mã đƣợc đc kiểm tra (đã đc ghi rồi).


http://www.cert.org/advisories/CA-2000–02.html

http://www.cert.org/tech_tips/malicious_code_mitigation.html




Are code reviews performed? Nothing is worse than the lone

programmer. Many of the problems discussed in the previous sections can

be negated if the code that all programmers write is subject to a peer

review. Code reviews, a mainstay of traditional quality-oriented

programming methodology, are rarely done in today‘s fast-paced Internet

environment. This is one of the reasons why so many security breakins

occur.

Code Review có đƣợc lam không ?Không gì tệ hơn một ngƣời lập

trình đơn độc. Nhiều vấn đề ở phần trƣớc có thể đƣợc giải quyết nếu tất cả

các ngƣời lập trình cùng ngồi lại va viết vao cái một cái peer review. Code

reviews la cơ sở để định hƣớng chất lƣợng của một programming

methodology, hiếm khi đƣợc hoan thanh ở thời buổi internet nhanh chóng

ngay nay. Đây la lý do tại sao nhiều breakins bảo mật sãy ra.

It is necessary to conduct a Web server review. In order to run

programs on the Web, many organizations use the CGI (common gateway

interface) to enable programs (i.e., scripts) to run on their servers. CGI is

not only a gateway for your programming code (i.e., via data collections

forms) but also a gateway for hackers to gain access to your systems.

Vulnerable CGI programs present an attractive target to intruders because

they are easy to locate and usually operate with the privileges and power of

the Web server software. The replacement of Janet Reno‘s picture with that

of Hitler on the Department of Justice Web site is an example of this sort of

CGI hole. The following questions must be asked of developers using CGI:





Kiểm soát một Web Server Review(bản báo cáo của webserver) la

cần thiết. Để chạy những chƣơng trình ở giao diện web, nhiều tổ chức sử

dụng CGI (Cổng kết nối giao diện) để cho phép những chƣơng trình nhƣ la

Script … có thể chạy trên server của họ. CGI không chỉ la một cổng giao

tiếp để lập trình (VD: via data collections forms) nó còn la môt cổng vao

cho hacker tiếp cận hệ thống của bạn. Yếu điểm của CGI la nó la một mục

tiêu hấp dẫn cho những ngƣời khách không mời bởi vì nó dễ dang để tiếp

cận va thƣờng hoạt động với quyền ƣu tiên cao ở các phần mêm trên máy

chủ (server). Các câu hỏi sau thƣờng đƣợc hỏi bởi những nha phát triển sử

dụng CGI:

- Are CGI interpreters located in bin directories? This should not be the

case because you are providing the hacker with all the capabilities he

needs to insert malicious code and then run it directly from your server.

- Thông dịch CGI có đƣợc đặt ở thƣ mục bin hay không?: Nó không nên

vì bạn sẽ cung cấp cho các hacker khả năng chèn các mã nguồn độc hại

vao va sau đó chạy trực tiếp từ máy bạn.

- Is CGI support configured when not needed?

- CGI có cung cấp những cấu hình khi không cần hay không ?

- Are you using remote procedure calls (RPC)? These calls allow

programs on one computer to execute programs on a second computer.

Much evidence indicates that the majority of distributed denial of





service attacks launched during 1999 and early 2000 were executed by

systems that had RPC vulnerabilities. It is recommended, wherever

possible, to turn off or remove these services on machines directly

accessible from the Internet. If this is not possible, then at least ensure

that the latest patches to the software are installed; these mitigate some

of the known security holes.

- Bạn có sử dụng các remote procedure call (RPC) Lời gọi proceduce từ

xa không? Những lời gọi proceduce từ xa cho phép một chƣơng trình

từ môt máy chạy nhữ chƣơng trình ở máy tinh thứ 2. Nhiều bằng cớ chỉ

ra rằng đa số các cuộc tấn công DDoS vao khoảng 1999 đến đầu 2000

đƣợc thực hiện trên các hệ thống có RPC yếu. Ngƣời ta khuyến cáo

rằng nên tắt hoặc xoá những tiện ich có thể truy cập trực tiếp từ internet

trên máy tinh ở bất cứ nơi nao có thể. Nếu không thể, thì hãy chắc rang

luôn cập nhật bản vá patches mới nhất cho chƣơng trình để giảm nhẹ lỗ

hổng bảo mật.

- Is IIS used? This is the software used on most Web sites deployed on

Windows NT and Windows 2000 servers. Programming flaws in IIS

remote data services (RDS) are used by hackers to run remote

commands with administrator privileges. Microsoft‘s Web site

discusses methodologies to use to combat these flaws.

- Có sử dụng IIS không ?phần mềm nay đƣợc triển khai ở nhiều trang

Web ở Windows NT va Windows 2000 servers. Điểm yếu của IIS la





RDS (Remote data Services) Dịch vụ dữ liệu từ xa có thể đƣợc sử dụng

bởi các hacker để thực thi các câu lệnh với quyền Administrator. Web

của Microsoft đang thảo luận về cách thức chống lại các thiếu sót nay.

17.4.7 Testing

Pre-PC testing was a slow and meticulous process. Today‘s faster

pace means that inadequate testing is performed by most organizations. In

addition, many organizations forego security testing entirely. In this section

of the audit, we determine whether adequate security is performed.

Pre-PC testing luôn la một tiến trình chậm chạp va kĩ cang. Với

nhịp sống ngay nay, những testing nhanh (không đủ) thƣờng đƣợc thực hiện

bởi các công ti. Thêm vao đó, nhiều công ti bỏ qua việc kiểm tra các việc

testing bảo mật. Trong phần nay, chúng tôi định nghĩa một bảo mật (test

bảo mật) đầy đủ đƣợc thực hiên.

Has penetration testing been done? This testing is used to assess the

type and extent of security-related vulnerabilities in systems and networks,

test network security perimeters, and empirically verify the resistance of

applications to misuse and exploitation. It is possible that system

administrators are sophisticated enough to be able to utilize the tool sets

available to scan the systems for vulnerabilities; however, a whole host of

―white hat‖ hacker security consulting firms have sprung up over the past

several years and these people are recommended.





Việc penetration testing đã hoan thanh ? Việc testing đƣợc sử dụng

để đánh giá loại va phạm vi của việc bảo mật liên quan đến hệ thống, kiểm

tra bảo mật mạng vòng ngoai va xác định đƣợc sức đề kháng của các ứng

dụng với những sự khai thác sai (hacker khai thác). Các ngƣời quản trị có

thể đủ tinh tế để sử dụng các phần mềm quét các lỗ hổng hệ thống.

Has intrusion testing been done? Many software tools are available

on the market today that ―monitor‖ systems and report on possible

intrusions. These are referred to as intrusion detection systems (IDS). In

this section of the audit, we determine whether an IDS is used and, if so,

how effectively.

Việc đã intrusion testing (kiểm tra sự xâm nhập) hoan thanh ?

Nhiều software đƣợc bán ngay nay nhƣ nhữ hệ thống giám sát va báo cáo

thì có thể bị xâm nhập. Có xem bởi intrusion detection systems (IDS) Hệ

thống giám sát sự xâm nhập. ở chƣơng về sự kiểm tra chúng ta sẽ xem xét

khi nao một IDS đƣơc sử dụng hiệu quả.

Is there a QA (quality assurance) function? Although QA

departments have been a traditional part of the IT function for decades,

many newer pure-play Internet companies seem to ignore this function. In

this section, the auditor will determine if the QA function is present; if it is,

then it will be reviewed.





Có Tồn tại QA (quality assurance) function chức năng ổn định hay

không ?Mặc dù sự ổn định la một lĩnh vƣc truyền thống trong chức năng

của CNTT trong nhiều thập niên, Nhiều công ti Internet mới có vẻ nhƣ bỏ

qua chức năng nay. Trong chƣơng nay, ngƣời kiểm tra sẽ định nghĩa chức

năng ổn định có tồn tại không ?va sẽ đƣợc thể hiện nhƣ thế nao ?

17.4.8 Lập báo cáo

Logging of all logins, attempted intrusions, etc. must be maintained

for a reasonable period of time. In this section, the auditor will determine if

these logs are maintained and, if so, for how long.

Việc ghi lại tất cả sự đăng nhập, thử xâm phạm phải đƣợc duy trì

trong một thời gian hợp lý.ở chƣơng nay, auditor ngƣời kiểm toán sẽ xác

định có ghi lại điều đó không ? nếu có thì sẽ duy trì trong bao lâu ?

17.4.9 Sao lƣu

In the event of failure it is usual that the last backup be used to

restore the system. In this section, the auditor will determine the frequency

of backups and whether this schedule is reasonable.

Nếu xuất hiện lỗi, dễ thấy la bản sao lƣu gần nhất của hệ thống sẽ

đƣợc sử dụng. Ở chƣơng nay auditor Ngƣời kiểm toán sẽ xác định cái chu

kì của viêc sau lƣu một cách hợp lý.





17.5 KHOA HỌC NGHIÊN CỨU TÍNH TIỆN DỤNG

At this stage the auditor becomes involved in more abstract issues. In

the last section on security, we could be very specific about what a system

requires. In the section on ergonomics we need to be more subjective.

Ở tầng nay auditor Ngƣời kiểm toán sẽ bị vƣớng vao nhiều những

khái niệm trừu tƣợng. Ở chƣơng cuối, phan security ta sẽ đƣợc chỉ ra về

những điều ma một hê thống cần. Ở chƣơng nay, chúng ta cần suy nghĩ môt

cách chủ quan.

To achieve this end will require the auditor to meet with the system

developers and with the end users. At times, these end users will be current

or potential customers of the system; therefore, it might be necessary to

develop surveys and perform focus groups. The goal here is nothing less

than determining a ―thumbs up‖ or ―thumbs down‖ on the Web-based

system vis-à-vis other Web-based systems.

Để hoan tất cần phải có sự trao đổi giữa ngƣời kiểm tra, ngƣời lam

phần mêm va ngƣời dùng cuối. Những ngƣời dung cuối la khách hang tiềm

năng của hệ thống vì thế cần có một Sự khảo sát va trình diễn cho từng

nhóm ngƣời dung, mục đinh la để chỉ ra ―thumbs up‖ or ―thumbs down‖

của giao diện Web.





17.5.1 Điều hƣớng

Navigation means determination of whether or not the site makes

sense in terms of browsing it.

Điều hƣớng nghĩa la xác định có hay không trong một trang web để

lam dễ hiểu khi xem nó.

• How easy is it to find something on this site? If looking for a specific

product, how many pages does one need to surf through to find it?

• Lam cách nao để tìm đƣợc một thứ ở trang web ? Bao nhiêu trang cần

phải lƣớt qua để tìm đƣợc nó ?

• Is there a search engine? If so, review for correctness and

completeness. Many sites do not have search engines (in this instance

we are talking about a search engine to search the site only, rather than

the Internet). If the Web site exhibits depth (i.e., many pages), it

becomes rather difficult to navigate around it. If a search engine is

available, the auditor must check to see if what is being searched for

can be correctly found.

• Có một công cụ tìm kiếm nao không ?nếu có hãy xem xét về tinh đúng

đắn va đầy đủ. Rất nhiều trang web không có công cụ tìm kiếm (của

bản thân chinh trang web đó) Nếu cấu trúc một web side sâu (nhiều

pages) nó trở nên rất khó khăn để tìm ra một thứ. Nếu tồn tại công cụ





tìm kiếm, Ngƣời kiểm tra cần phải kiểm tra xem cái đƣợc tìm có thể

đƣợc tìm thấy không ?

• Is there a site map? If so, review for correctness and completeness.

While not required and not often found, site maps are one of the most

useful of site navigation tools. If available, the auditor will determine

correctness of this tool.

• Có tồn tại môt bản đồ trang web ? Nếu có thì nhƣ thế nao la đúng đắn

va hoan thiên ?Thƣờng thi luôn cần nhƣng it đƣợc tìm thấy ở các trang

web.Nó la một công cụ điều hƣớng hữu hiệu.

• Are back and forward (or other) buttons provided? What tools are

provided to the end user for moving backward and forward within the

site? Are the browser‘s back and forward buttons the only navigation

tools — or did the Web designers provide fully functional toolbars? If

so, do these toolbars work on all pages? We have found that, of those

firms audited, 10 percent of the pages pointed to by the toolbars cannot

be found.

• Có Tồn tại các công cụ để quay lui hay tiến tới ?công cụ đó cung cấp

cho user tiến va lui ở trong môt trang web. Chỉ thiết kế các nút back và

forward hay cả một thanh công cụ với đầy đủ chức năng ? nếu có,

thanh công cụ đó có lam việc trên tất cả các page ? Chúng ta nhân ra





răng chỉ khoảng 10 % các trang trỏ bởi các thanh công cụ không thể

đƣợc tìm thấy.

• Are frames used? If so, do toolbars and other navigation tools still

work?

• Có sử dụng Frames không ?nếu có thanh công cụ va các sự chuyển

hƣơng khác còn lam việc ?

17.5.2 Tiện lợi

In the end it comes down to one question really: ―How usable is the

Web site?‖ In this section we ask:

• How easy is it to use this site? Although the auditor might have an

opinion that might well be valid, here we resort to surveys and focus

groups to determine the answer.

• How useful is this site?

• Trang web đó sử dụng dễ dang ra sao ?mặc dù ngƣời kiểm toán có các

ý kiến có giá trị, nhƣng cái cách thức ở đây la lam một khảo sát từng

nhóm ngƣời dùng để tìm ra câu tra lời.

• Trang web cung cấp cho ngƣời dung những ich lợi gì ?

Nội dung:





In this section we assess the value of the information contained

within the site compared to competitive sites.

Ở phần nay chúng ta tiếp cận những thông tin có giá trị trong một

website va so sánh sự cạnh tranh giữa các trang web.

• Is content updated regularly?

• Có phải cập nhật các nội dung một cách thƣờng xuyên ?

• Is content relevant?

• Các nội dung có thich đáng ?

• Do visitors consider content worthwhile?

• Các khách hang có cảm thấy thú vị ?

• How does content compare with competitors‘?

• Lam cách nao để Nội dung cạnh tranh đƣợc với đối thủ ?

The auditor will use survey techniques to determine the answer to

this question.

Ngƣời kiểm tra sẽ sử dụng các khảo sát để tìm ra câu trả lời.





17.6 DỊCH VỤ KHÁCH HÀNG

The Web is a doorway to the company‘s business; however, it is just

one part of the business. Tangential services must be audited as well.

Customer service is one of the biggest problem areas for Net firms. There

have been many well-publicized instances of shoddy customer service. It is

in the company‘s best interests, therefore, to assess customer service within

the firm vis-a-vis its Web presence.

The Web is a doorway(con đƣờng) to the company‘s business;

however, it is just onepart of the business. Tangential services must be

audited as well. Customerservice is one of the biggest problem areas for

Net firms. There have beenmany well-publicized instances(trƣờng hợp) of

shoddy (chất lƣợng kém) customer service. It is in thecompany‘s best

interests, therefore, to assess(đanh giá) customer service within thefirm vis-

a-vis its Web presence.

Web la một cách kinh doanh của các công ty. Tuy nhiên, nó chỉ la

một phần của kinh doanh. Những dịch vụ lộn xộn cũng cũng cần đƣợc kiểm

soát. Dịch vụ khách hang la một trong những vấn đề lớn nhất của các hãng

Internet. Có nhiều trƣờng hợp công khai vễ những dịch vụ khách hang kém

chất lƣợng. Vì vậy, nó la sự thich thú nhất của các công ty để đánh giá đƣợc

dịch vụ khách hang trong các hãng Web có quan hệ với nhau





17.6.1 Acvessibility

How easy is it for your customers to reach you?

• Review e-mail response. How long does it take you to respond to a

customer e-mail?

• Review telephone response. How long does a customer wait on hold

before a person answers his or her query?

Những khách hang của bạn đến với bạn dễ thế nao ?

• Xem xét lại những câu trả lời từ email. Mất bao lâu để bạn trả lời email

cho khách hàng

• Xem xét lại những cuộc trả lời từ điện thoại. Khách hang phải chờ bao

lâu trƣớc khi một ngƣời trả lời những thắc mắc của khách hang

17.6.2 E-Commerce

If your site doubles as an e-commerce site (i.e., you sell goods or

services from your site), you need to assess the quality of this customer

experience.

• Check shopping experience. Using a ―mystery shopper‖ approach, the

auditor will endeavor to make routine purchases using the Web site.

Determine:





- Is the shopping cart correct (i.e., are the goods you purchased in the

shopping cart?

- Does the e-commerce software calculate taxes properly?

- Does the e-commerce software calculate shipping charges

properly?

Nếu site của bạn gấp đôi site thƣơng mại (bạn bán hang hoá hay dịch

vụ từ site của bạn), bạn cần đánh giá chất lƣợng của khách hang

• Kiểm tra kinh nghiệm mua sắm,. Sử dụng gần nhƣ la một ―Khách hang

tiềm năng‖ . Kiểm toán viên sẽ cố gắng mua bán hang ngay trên site

này

• Check the fulfillment experience:

- Is a confirmation e-mail sent to the purchaser?

- Is the return policy carefully explained?

- How quickly does the company refund money on returns?

• Kiểm tra kinh nghiệm thực hiện

- Xác nhận email gửi cho ngƣời bán

- Trả lại nhửng chinh sách giải thich một cách cẩn thận





- Công ty hoan trả tiền nhanh nhƣ thế nao

17.6.3 Sự riêng tƣ

At a minimum, the auditor must review the company‘s privacy

policy statement. He or she should then review the data flow to determine if

the privacy policy is adhered to.

Ở mức tối thiểu,, kiểm toán viên cần xem xét lại những chinh sách

riêng của công ty. Họ nên xét duyệt lại luồng dữ liệu để quyết định nếu

chinh sách riêng đƣợc gia nhập vao

17.6.4 Tinh hợp pháp

The digital age makes it easy to perform illegal and potentially

litigious acts. From a corporate perspective, this can be anything from a

Web designer illegally copying a copyrighted piece of art to employees

downloading pornography.

Thời đại kỷ thuật số kiến ta dễ dang trái luật va có khả năng dẫn đến

hanh vi kiện tụng. Từ viễn cảnh tập thể, điều nay có thể la một thứ gì đó từ

ngƣời thiết kế Web một cách bất hợp lý sao chép mẫu bản quyền nghệ thuật

để các nhân viên tải những hình ảnh khiểu dâm





17.6.5 Bản quyền

Check the content ownership of text on your site. It is quite easy to

copy text from one site to another. Ensure that your copy is completely

original or that you have the correct permissions to reprint the data. In the

same way, check image ownership.

Kiểm tra nội quyên quyền sở hữu văn bản trên site của bạn. Nó hoan

toan dễ dang để copy một đoạn text từ một web khác. Đảm bảo rằng bản

copy của bạn hoan toan có nguồn gốc hoặc bạn phải xin phép để in lại dữ

liệu. Tƣơng tự, cần kiểm tra quyền sở hữu những hình ảnh

17.6.6 Cách sử dụng Web của nhân viên

In a number of court cases employees have claimed harassment

when other employees within the organization downloaded and e-mailed

pornography. The company is responsible for the actions of its employees;

therefore, it is highly recommended that the company:

Nhiều trƣờng hợp ra toa đòi quấy rầy khi những nhân viên khác

trong tổ chức tải hoặc gửi thƣ điện tử khiêu dâm công ty có trách nhiệm cho

những hanh động của những nhân viên của họ

• Create a policy memo detailing what can and cannot be done on the

Internet (include e-mail). Make sure all employees sign and return this





memo. Use tools such as those on surfcontrol.com to monitor employee

Net usage.

• Tạo những chinh sách bảng ghi nhớ chi tiết những gì có thể hoạc không

thể lam trên Internet (bao gồm email).Phải chắc chắn rằng những nhân

viên ki va trả về bang ghi nhớ nay. Sử dụng những công cụ nhƣ

surfcontrol.com để giám sát nhân viên sử dụng Net

• Determine whether any e-mail monitoring software is used and

determine its effectiveness.

• Quyết định vai phần mềm giám sát việc gửi mail va quyết định tinh

hiệu quả của nó

17.7 KẾT LUẬN

Auditing IT systems is an important activity. It is surprising, then,

that so few companies take the time and effort to perform this necessary

activity. EDP auditing not only pinpoints potentially troublesome technical

areas but it can also serve as reinforcement for stakeholder support by

identifying human factor issues as well.

Kiểm toán những hệ thống công nghệ thông tin la một hoạt động

quan trọng. Một vai công ty đã mất thời gian va sức lực để thực hiện hoạt

động cần thiết nay. kiểm toán EDP không chỉ xác định một vai vấn đề tiềm





tang trong phạm vi kỹ thuật nhƣng nó cũng có thể phục vụ tăng cƣờng cho

stakeholder chống đở bằng cách chỉ ra những tác nhân phát hanh




Chương 18: Quản lý bảo trì phần mềm 650

CHƢƠNG 18 QUẢN LÝ BẢO TRÌ PHẦN MỀM

Người dịch:


2. Lê Anh Dũng


4. Lê Văn Huy


Maintenance is often called the enigma of software. Enormous

amounts of dollars are spent on it but little management attention is given to





it. Software maintenance presents a real conundrum — hardware

deteriorates because of lack of maintenance, whereas software often

deteriorates because of the presence of maintenance.

Bảo trì thƣờng đƣợc gọi la bi mật của phần mềm. Một lƣợng lớn đô

la bỏ ra cho nó, nhƣng sự quan tâm đến quản lý bảo trì thì rất it. Bảo trì

phần mềm đƣa ra một câu hỏi khó thực sự – Phần cứng bị hƣ hỏng do thiếu

bảo trì, ngƣợc lại phần mềm thƣờng bị hƣ hỏng vì sự hiện diện của bảo trì.

Maintenance is also the most expensive component of the software

life cycle, as shown in Exhibit 18-1. IT departments spend from 75 to 80

percent of their budget (Guimaraes, 1983) and time on the maintenance

process of system development. In addition, the cost of fixing an error rises

dramatically as the software progresses through the life cycle. This amply

demonstrates that maintenance costs more than any other phase and also

that maintenance costs (per fixing the error) are enormous.

Bảo trì la giai đoạn tốn chi phi nhất trong chu trình phát triển hệ

thống phần mềm (SDLC). (xem hình 18 -1). Bộ phận IT tốn 75 – 80 %

ngân sách (theo Guimaraes,1983) va thời gian cho qui trình bảo trì trong sự

phát triển hệ thống. Ngoai ra, chi phi sửa còn lỗi tăng nhanh trong khi phần

mềm phát triển xuyên suốt của chu kỳ sống. Chứng minh đầy đủ cho điều

nay la chi phi bảo trì cao hơn bất kỳ chi phi của các giai đoạn khác(trong

SDLC). Chi phi bảo trì nay (trên mỗi lỗi sai) còn rất lớn.





Hình 18.1: Chi phí của việc bảo trì

Once a new system is implemented, the real work begins for most IT

departments. As users utilize the system, errors are discovered, and changes

are requested. As systems have become more widely used within critical

departments of the organization, the maintenance process has taken on a

more important role. The management of systems maintenance has become

perhaps the most critical phase of systems development.

Khi một hệ thống mới đƣợc thực thi, các công việc thực sự bắt đầu

cho hầu hết các phòng ban IT. Ngƣời dùng sử dụng các hệ thống, lỗi sai

đƣợc phát hiện, va sự thay đổi đƣợc yêu cầu. Khi hệ thống đã trở nên rộng





rãi hơn, đƣợc sử dụng trong các bộ phân quan trọng của tồ chức, thì tiến

trình bảo trì có vai trò quan trọng hơn nữa. Sự quản lý bảo trì phần mềm có

lẽ trở thanh giai đoạn quan trọng nhất của sự phát triển hệ thống phần mềm.

18.1 QUÁ TRÌNH BẢO TRÌ:

As the new system is implemented and users begin to work with it,

errors occur or changes are needed. Just as in the development of a new

system, maintenance requires that steps be taken carefully in making

changes or fixing errors. In the event of an error, this can be even more

critical. Each step of the maintenance process is similar to steps in the

systems development life cycle (Curtis et al., 2000) as seen in Exhibit 18-2.

This is a logical extension of the development process because changes

made to the system can affect the whole system and need to be controlled

carefully.

Khi hệ thống đƣợc hiện thực va ngƣời dùng bắt đầu lam việc với nó,

những lỗi xảy ra hoặc sự thay đổi la cần thiết. Cũng nhƣ trong việc phát

triển mới hệ thống, bảo trì đòi hỏi các bƣớc tiến hanh một cách cẩn thận

trong thay đổi hoặc sửa lỗi. Trong trƣờng hợp bị lỗi, điều nay có thể quan

trọng hơn. Mỗi bƣớc trong quá trình bảo trì cũng giống nhƣ những bƣớc

trong trong chu trình phát triền của hệ thống(SDLC). Đây la một sự mở

rộng logic của qui trình phát triển bởi vì sự thay đổi lam cho hệ thống có

thể ảnh hƣởng toan bộ hệ thống va cần phải điều chỉnh một cách thật cẩn

thận.





The first step in the process is to obtain a maintenance request from a

user. Many organizations use a system service request form (see

Appendices A and B) that spells out the problem or need. Once the request

has been received, the requests can be transformed into changes that can

then be used to make design changes. After the changes are designed and

tested, the changes can be implemented.

Bƣớc đầu tiên trong quá trình nay la có một yêu cầu bảo trì từ ngƣời

dùng. Nhiều tổ chức sử dụng hình thức hệ thống yêu cầu dịch vụ (xem Phụ

lục A va B) ma cho phép tìm ra các vấn đề hoặc yêu cầu cần. Một lời yêu

cầu đƣợc nhận, sau đó nó có thể đƣợc sử dụng để thiết kế cho sự thay đổi

của hệ thống. Sự thay đổi nay đƣợc thiết kế va kiểm thử, sự thay đổi có thể

đƣợc hiện thực vao trong hệ thống.

Hình 18.2: So sánh vòng đời bảo trì với vòng đời phát triển hệ thống.

Exhibit 18-3 is an overview of system maintenance. Both the

customer and maintainer are interacting with his or her own documentation,





i.e., user manual and maintainer manual. The customer poses questions,

problems, and suggestions to the maintainer who, in turn, gives the

answers, which are filtered through a change control process and back into

the system.

Hình 18-3 la sơ đồ tổng quan về sự bảo trì hệ thống. Cả khách hang

va ngƣời bảo trì thì tác động lẫn nhau với tai liệu riêng của họ….tai liệu

hƣớng dẫn sử dụng va tai liệu hƣớng dẫn bảo trì. Khách hang đƣa ra những

câu hỏi, vấn đề va những đề xuất cho ngƣời bảo trì. Lần lƣợt, ngƣời bảo trì

đƣa ra các câu trả lời. Nó sẽ đƣợc lọc ra bởi quá trình kiểm soát sự thay đổi

va quay trở lại hệ thống.

Hình 18.2: Tổng quan về bảo trì hệ thống





18.2 CÁC LOẠI BẢO TRÌ:

Categorizing the types of maintenance required is helpful in

organizing and prioritizing the requests of users. Software maintenance is

more than fixing mistakes. Maintenance activities can be broken down into

four subactivities.

• Corrective maintenance

• Adaptive maintenance

• Perfective maintenance or enhancement

• Preventive maintenance or reengineering

Phân loại các loại hình bảo trì theo yêu cầu la hữu ich trong việc tổ

chức va ƣu tiên các yêu cầu của ngƣời sử dụng. Công việc bảo trì phần

mềm đòi hỏi nhiều yêu cầu hơn việc sửa chữa những sai sót. Hoạt động bảo

trì có thể đƣợc chia thanh bốn loại sau:

• Bảo trì hiệu chỉnh.

• Bbảo trì tƣơng thich.

• Bảo trì hoàn thành hoặc nâng cao.

• Bảo trì dự phòng hoặc tái cấu trúc.





18.2.1 Bảo trì hiệu chỉnh:

Corrective maintenance involves fixing bugs or errors in the system

as they are discovered. This maintenance is the type most users are familiar

with because these problems are the most irritating to users. These usually

receive top priority because they can paralyze the organization if not

identified and fixed. Corrective maintenance consumes approximately 17

percent of the maintainer‘s time (Lientz and Swanson, 1978). Major skills

required for corrective maintenance are:

• Good diagnostic skills

• Good testing skills

• Good documentation skills

Hiệu chỉnh liên quan đến việc bảo trì sửa chữa lỗi hay lỗi trong hệ

thống khi chúng đƣợc phát hiện. Loại bảo trì nay la loại hầu hết ngƣời đều

dùng quen thuộc vì những vấn đề nay hầu hết la những vấn đề gây khó chịu

cho ngƣời dùng. Những vấn đề thƣờng nhận đƣợc ƣu tiên hang đầu bởi vì

nó có thể gây tê liệt các hệ thống, nếu nó không xác định va sửa lỗi. Hiệu

chỉnh bảo trì chiếm khoảng 17% thời gian của các nha bảo trì (theo Lientz

va Swanson, 1978). Kỹ năng chuyên nganh cần thiết để bảo trì hiệu chỉnh

là:

• Kỹ năng chẩn đoán.





• Kỹ năng kiểm tra.

• Kỹ năng dẫn chứng bằng tƣ liệu.

18.2.2 Bảo trì tƣơng thich:

Adaptive software maintenance is performed to make a computer

program usable in a changed environment. For example, if the computer on

which the software runs is going to use a new operating system, the system

requires some adaptive tweaking. Adaptive maintenance is typically part of

a new release of the code or part of a larger development effort.

Approximately 18 percent of software maintenance is adaptive (Lientz and

Swanson, 1978).

Bảo trì tƣơng thich phần mềm đƣợc thực hiện để lam cho một

chƣơng trình máy tinh có thể sử dụng trong một môi trƣờng thay đổi. Vi dụ,

phần mêm chạy trên một máy tinh vừa thay đổi một hệ điều hanh mới, hệ

thống đòi hỏi một số điều chỉnh thich ứng. Bảo trì tƣơng thich thƣờng la

một phần phát hanh mới của mã nguồn hoặc một phần của nỗ lực phát triển

lớn hơn. Bảo trì tƣơng thich chiếm khoảng 18% thời gian của các nha bảo

trì (theo Lientz và Swanson, 1978).

18.2.3 Hoan thiện bảo dƣỡng:

This is the act of improving the software‘s functionality as a result of

end-user requests to improve product effectiveness. This includes





• Adding additional functionality

• Making the product run faster

• Improving maintainability

This is the biggest maintenance time consumer. Approximately 60

percent of software maintenance is spent on perfective maintenance (Lientz

and Swanson, 1978).

Đây la hanh động của việc cải thiện chức năng của phần mềm nhƣ la

kết quả của yêu cầu của ngƣời dùng cuối để cải thiện hiệu quả sản phẩm.

Điều nay bao gồm:

• Thêm bổ sung chức năng.

• Làm cho sản phẩm chạy nhanh hơn.

• Nâng cao khả năng bảo trì.

Đây la loại bảo trì chiểm thời gian lớn nhất. Khoảng 60% bảo trì

phần mềm la chi cho bảo trì hoan thanh (Lientz va Swanson, 1978).

18.2.4 Bảo trì dự phòng

This refers to performing ―premaintenance‖ in order to prevent

system problems; it is different from corrective maintenance, which is





performed to correct an existing problem. This is like maintaining a car in

which you change the oil and air filter, not in response to some problem but

to prevent a problem from occurring in the first place.

Điều nay nói đến thực hiện ―tiền bảo trì‖ để ngăn chặn hệ thống gặp

vấn đề; việc nay khác với việc bảo trì sửa sai - đƣợc thực hiện để sửa một

vấn đề đang tồn tại. Điều nay cũng giống nhƣ việc duy trì một chiếc xe

trong đó bạn thay đổi dầu va lọc không khi, không để giải quyết một số vấn

đề ma để ngăn chặn một vấn đề có thể xảy ra.

18.3 CHI PHÍ BẢO TRÌ

As computers and their systems become more widely used, the need

for maintenance grows. As these same systems age, maintenance becomes

more critical and time consuming. Since the early 1980s, it is estimated that

maintenance costs have skyrocketed from 40 percent of the IT budget to 75

to 80 percent (Exhibit 18-1). The reason for these increases stems from

once newly designed systems aging. This shift from development to

maintenance is a natural occurrence as organizations avoid the high cost of

new systems and struggle to maintain their current systems.

Khi máy tinh va hệ thống của họ cang trở nên đƣợc sử dụng rộng rãi,

sự cần thiết của việc bảo trì ra đời. bảo trì trở thanh một công việc tối quan

trọng va tốn thời gian. Kể từ đầu những năm 1980, ƣớc tinh chi phi bảo trì

đã tăng vọt từ 40 phần trăm của ngân sách cho CNTT lên 75 đến 80%





(Hình 18-1). Sự thay đổi từ sự phát triển để bảo trì la một sự xuất hiện tự

nhiên bởi vì các tổ chức muốn tránh chi phi cao cho một hệ thống mới va sự

gắn sức để duy trì các hệ thống hiện tại của họ.

Many factors affect the cost in time and money expended on system

maintenance. One of the most costly is design defects. The more defects in

a system, the more time is spent identifying and fixing them. If a system has

been designed and tested properly, most defects should have been

eliminated, but in the case of poor design or limited testing, defects can

cause system downtimes that cost the organization in lost efficiency and

perhaps sales.

Nhiều yếu tố ảnh hƣởng đến sự tiêu tốn thời gian va tiền bạc tiêu

dùng bảo trì vao việc bảo trì. Một trong những yếu tố gây tốn kém nhất la

những khiếm khuyết trong thiết kế. Cang nhiều khiếm khuyết trong một hệ

thống,cang nhiều thời gian danh để xác định va sửa chữa chúng. Nếu có hệ

thống đã đƣợc thiết kế va thử nghiệm chinh xác, hầu hết các khuyết tật cần

phải đƣợc loại bỏ, nhƣng trong trƣờng hợp thiết kế nghèo nan hoặc thử

nghiệm hạn chế, khuyết tật có thể gây chết hệ thống va lam hệ thống giảm

hiệu quả va có thể ảnh hƣởng việc buôn bán.

The number of users can also affect the cost of system maintenance.

The more users, the more time will be spent on changes to the system. More

importantly, the more platforms the system is installed on, the higher the

cost of maintenance. If a single system needs a change, then the time it





takes to change the system is limited, but if that system resides on platforms

across the country, e.g., in many branch offices of corporations, then the

cost is increased significantly.

Số lƣợng ngƣời sử dụng cũng có thể ảnh hƣởng đến chi phi bảo trì hệ

thống. Nhiều ngƣời sử dụng hơn, nhiều thời gian hơn sẽ đƣợc chi tiêu vao

những thay đổi cho hệ thống. Quan trọng hơn, hệ thống đƣợc cai đặt trên

cang nhiều nền,chi phi bảo trì cang cao. Nếu một hệ thống đơn cần có một

sự thay đổi, thì thời gian cần phải thay đổi hệ thống thì đƣợc giới hạn,

nhƣng nếu hệ thống nằm trên nền tảng trên khắp đất nƣớc, vi dụ nhƣ, trong

nhiều văn phòng chi nhánh của các tập đoan, thì chi phi đƣợc tăng lên đáng

kể.

The quality of the documentation can also affect the overall cost of

maintenance. Poor documentation can result in many lost hours searching

for an answer that should have been explained in the documentation (Lientz

and Swanson, 1981). The documentation is a type of road map to the

system; when the map is well defined, finding your way through the system

and understanding it become much easier.

Chất lƣợng của các tai liệu hƣớng dẫn cũng có thể ảnh hƣởng đến chi

phi tổng thể của bảo trì. Tai liệu nghèo nan có thể dẫn đến mất nhiều giờ

tìm kiếm cho một câu trả lời, những điều nay cần phải đƣợc giải thich trong

tai liệu hƣớng dẫn (Lientz va Swanson, 1981). Tai liệu nay la một loại bản





đồ đƣờng hệ thống; khi bản đồ nay cũng xác định tốt, việc tìm cách xuyên

qua va hiểu đƣợc hệ thống sẽ dễ dang hơn.

The quality of the people and their skill level can also cost an IT

department many wasted hours. An inexperienced or overloaded

programmer can increase the cost of maintenance in two ways. First he or

she can waste hours learning on the job at the IT department‘s expense.

Second, a programmer overwhelmed with projects, may skip steps in the

maintenance process and, in turn, make mistakes that cost time and money

to fix.

Trình độ va kỹ năng của nhân viên bảo trì cũng có thể lam cho một

bộ phận CNTT lãng phi nhiều giờ. Một lập trình viên thiếu kinh nghiệm

hoặc quá tải có thể lam tăng chi phi bảo trì theo hai cách. Đầu tiên ngƣời đó

có thể lãng phi giờ vao việc học công việc tại bộ phận phi tổn. Thứ hai, một

lập trình viên choáng ngợp với các dự án, có thể bỏ qua bƣớc trong bảo trì

xử lý va, đến lƣợt nó, tạo ra những sai lầm lam tiểu tốn thời gian va tiền bạc

để sửa chữa.

The tools available to maintenance personnel can save many hours of

work. Using automation tools such as CASE tools, debuggers, and others

can help the programmer pinpoint problems faster or make changes more

easily.





Việc có sẵn công cụ cho nhân viên bảo trì có thể tiết kiệm giờ công

việc. Sử dụng công cụ tự động hóa nhƣ TOOL - CASE, Debugger, và

những công cụ khác có thể giúp các lập trình viên xác định các vấn đề

nhanh hơn hoặc thay đổi dễ dang hơn.

The structure of the software can also contribute to maintenance

costs (Gibson, 1989). If software is built in a rational and easy-to-follow

manner, making changes will be much easier and thus much faster, saving

time and resources. Software maintenance costs can be reduced

significantly if the software architecture is well defined and clearly

documented, and creates an environment that promotes design consistency

through the use of guidelines and design patterns (Hulse et al., 1989).

Cấu trúc của phần mềm cũng có thể đóng góp vao chi phi bảo trì

(Gibson, 1989). Nếu phần mềm đƣợc xây dựng hợp lý va theo cách thức,

thực hiện thay đổi sẽ dễ dang hơn nhiều va do đó nhanh hơn, tiết kiệm thời

gian va tai nguyên. Chi phi bảo trì phần mềm có thể đƣợc giảm đáng kể nếu

kiến trúc phần mềm cũng đƣợc định nghĩa rõ rang va tai liệu hoá, va tạo ra

một môi trƣờng khuyến khich thiết kế thống nhất thông qua việc sử dụng

hƣớng dẫn va các mẫu thiết kế (Hulse et al., 1989).

18.4 MẪU BẢO TRÌ

Harrison and Cook have developed a new model of software

maintenance based upon an objective decision rule, which determines





whether a given software module can be effectively modified or if it should

be rewritten. Their take is that completely rewriting a module can be

expensive. However, it can be even more expensive if the module‘s

structure has been severely degraded over successive maintenance

activities. A module that is likely to experience significant maintenance

activity is called ―change prone‖. Their paper suggests that early

identification of change-prone modules through the use of change measures

across release cycles can be an effective technique in efficiently allocating

maintenance resources.

Harrison va Cook đã phát triển một mô hình mới của bảo trì phần

mềm dựa trên một nguyên tắc, quyết định khách quan, ma xác định liệu một

mô-đun phần mềm có thể đƣợc sửa đổi có còn hiệu quả hoặc nếu nó cần

đƣợc viết lại. viết lại hoan toan một mô-đun rất tốn chi phi.Tuy nhiên,có thể

tốn chi phi hơn nữa nếu nhƣ cấu trúc của modun bị xuống cấp trầm trọng

đối với hoạt động bảo trì liên tục. Một module có có khả năng trải qua đƣợc

hoạt động bảo trì mang tinh quan trọng thì đƣợc gọi la modun ―hƣớng thay

đổi‖ (change prone).

In maintenance requests for nonchange-prone modules, the process

flow is as follows:

Analyze code and identify change →

Implement change and update documentatio →





Apply metric analysis →

Compare with baseline →

Check to see if it exceeds the threshold →

If yes, then declare module to be ―change prone;‖ otherwise, declare

module to be non-change prone.

Trong các yêu cầu bảo trì cho mô-đun‖ không hƣớng thay đổi‖

(non_change prone) tiến trình dòng chảy nhƣ sau:

Phân tích mã và nhận dạng thay đổi →

Thực hiện thay đổi và cập nhật các tài liệu hƣớng dẫn→

Áp dụng số liệu phân tích →

So sánh với baseline →

Kiểm tra xem nếu nó vƣợt quá ngƣơng →

Nếu có, tuyên bố mô-đun đã la modun "hƣớng thay đổi‖ nếu không,

module la modun ―không hƣớng thay đổi‖

The process for maintenance requests for a change-prone module is

as follows:





Identify the highest level artifact affected by the request→

Regenerate artifact →

Identify artifacts that can be reused →

Iterate through ―development‖ →

Declare module to be non-change prone.

Quá trình bảo trì cho modun ―hƣớng thay đổi‖ nhƣ sau:

Xác định các artifact(những thứ) cấp cao nhất bị ảnh hƣởng bởi các

yêu cầu →

Tái sinh artifact →

Xác định các artifact có thể đƣợc tái sử dụng →

Lam thông qua quá trình "phát triển" →

Tuyên bố mô-đun la modun ―không hƣớng thay đổi‖.

18.5 QUẢN LÝ BỘ PHẬN BẢO TRÌ

As systems age and demand increases for maintenance personnel,

there has been a loud debate over just who should be doing the maintaining.

Should it be the original developers? Or should it be a separate maintenance





department? Many have argued that the people who developed the system

should maintain it because they will best understand the system and be

better able to change it (Swanson, 1990). This logic is correct but difficult

to fulfill because developers want to keep building new systems and

consider maintenance a less desirable function. IT professionals view

maintenance as fixing someone else‘s mistakes. One solution to this

problem that has been tried recently involves rotating the IT personnel from

development to maintenance and back to allow everyone to share in the

desirable as well as undesirable functions of the department.

Khi hệ thống có thời kì va tăng nhu cầu về tổ chức bảo trì, đã từng có

một cuộc tranh luận lớn hơn giữa những ngƣời cần đƣợc lam việc duy trì.

Nó có nên đƣợc la các nha phát triển đầu tiên? Hoặc nó phải la một bộ phận

bảo trì riêng biệt? Nhiều ngƣời đã lập luận rằng những ngƣời phát triển hệ

thống nên duy trì nó, vì họ sẽ hiểu tốt nhất hệ thống va có thể thay đổi nó

tốt hơn (Swanson, 1990). Lập luận nay la đúng, nhƣng khó khăn để thực

hiện bởi vì các nha phát triển muốn tiếp tục xây dựng các hệ thống mới va

xem xét việc duy trì một chức năng it mong muốn hơn. Chuyên gia CNTT

xem việc bảo trì la sửa chữa những sai lầm của ngƣời khác. Một trong

những giải pháp cho vấn đề nay đã đƣợc thử gần đây liên quan đến việc

quay bộ phận CNTT từ phát triển sang bảo trì va quay trở lại để cho phép

mọi ngƣời chia sẻ những chức năng mong muốn cũng nhƣ không mong

muốn của bộ phận nay.





18.6 ĐÁNH GIÁ HIỆU QUẢ

An important part of managing maintenance is to understand and

measure the effectiveness of the maintenance process. As a system is

implemented, service requests may be quite high as bugs are worked out

and needs for change are discovered. If the maintenance process is

operating properly an immediate decrease in failures should be seen

(Exhibit 18-4). Good management of maintenance should include recording

failures over time and analyzing these for effectiveness. If a decrease is not

noticed, the problem should be identified and resolved.

Một phần quan trọng của việc quản lý bảo trì la để hiểu va đánh giá

hiệu quả của quá trình bảo dƣơng. Nhƣ một hệ thống đƣợc triển khai thực

hiện, các yêu cầu dịch vụ có thể có khá nhiều lỗi phát sinh va có các nhu

cầu cho sự thay đổi. Nếu quá trình bảo dƣơng vận hanh đúng la một sự

giảm sai sót phải đƣợc thể hiện ngay (Hình 18-4). Quản lý bảo trì tốt nên

bao gồm ghi nhận lại các sai sót theo thời gian va phân tich chúng vì tinh

hiệu quả. Nếu sự giảm sai sót không đƣợc nhận thấy, vấn đề cần đƣợc xác

định va giải quyết lại.





Sai sót

Sự triển khaiHì

nh 18-4 Phân phối chuẩn các sai sót theo sự triên khai

Another measure of success of the maintenance process is the time

between failures. The longer the time between failures, the more time can

be spent on improving the system and not just fixing the existing system

(Lientz, 1983). Failures will happen, but more costly is the time fixing even

the simplest failure.

Thƣớc đo sự thanh công của quá trình bảo dƣơng la thời gian giữa

các sai sót. Thời gian giữa sai sót cang dai, cang có nhiều thời gian hơn cho

việc cải thiện hệ thống va không chỉ sửa chữa hệ thống hiện có (Lientz,





1983). Sai sót sẽ xảy ra, nhƣng tốn kém hơn la thời gian sửa chữa, ngay cả

sai sót đơn giản nhất.

Recording the type of failure is important to understanding how the

failure happened and can assist in avoiding failures in the future. As this

information is recorded and maintained as a permanent record of the

system, solutions can be developed that fix the root cause for a variety of

failures.

Ghi nhận lại các kiểu sai sót rất quan trọng để hiểu nguyên nhân sai

sót xảy ra va có thể trợ giúp trong việc tránh sai sót trong tƣơng lai. Theo

thông tin nay đƣợc ghi chép va lƣu giữ nhƣ một ghi nhận thƣờng trực của

hệ thống, các giải pháp có thể đƣợc phát triển ma sửa chữa đƣợc nguyên

nhân chủ chốt cho một loạt các sai sót.

18.7 QUẢN LÝ YÊU CẦU BẢO TRÌ

As problems arise or the need for change is discovered, the flow of

these requests must be handled in a methodical way. Because all requests

are not equal and they arrive at the project manager‘s desk at various times,

a system has been developed by most IT departments. This system provides

a logical path for the approval of requests and prioritizes and organizes

those approved. The project manager has the job of categorizing the

requests and passing them on to the ―priority board‖ that decides if the

request is within the business model and what, if any, priority to give the





change. As decisions are made by the board, they are passed back to the

project manager for action. The project manager then reports the decision to

the user and acts on the change based on the priority given.

Vì những vấn đề phát sinh hoặc sự cần thiết phải thay đổi đƣợc phát

hiện, dòng chảy của những yêu cầu nay phải đƣợc xử lý một cách có

phƣơng pháp. Bởi vì tất cả yêu cầu không giống nhau va chúng tìm đến ban

lam ngƣời quản lý dự án vao các thời điểm khác nhau, một hệ thống đã

đƣợc phát triển bởi hầu hết các bộ phận CNTT. Hệ thống nay cung cấp một

con đƣờng hợp lý cho việc phê duyệt yêu cầu va các ƣu tiên va các tổ chức

phê duyệt. Ngƣời quản lý dự án có công việc phân loại yêu cầu va đƣa

chúng vào các ―bảng ƣu tiên‖ ma quyết định nếu yêu cầu có trong mô hình

kinh doanh va những gì, nếu có, ƣu tiên cho việc thay đổi. Theo quyết định

đƣợc thực hiện bởi dƣa trên bảng nay, chúng đƣợc truyền lại cho ngƣời

quản lý dự án để hanh động. Ngƣời quản lý dự án sau đó báo cáo quyết

định đến ngƣời dùng va hanh động trên sự thay đổi dựa trên những ƣu tiên.

The type and severity of change help decide what priority it is given.

If the change is important enough, it may be placed at the top of the queue

for immediate action. If several changes occur in a single module a batch

change may be requested. A batch change involves making changes to a

whole module at once to avoid working on the same module several times.

This also allows users to view the changes as a single update that may

change the use of a module through screen changes or functionality.





Các loại hình va mức độ nghiêm trọng của sự thay đổi giúp quyết

định mức độ ƣu tiên. Nếu sự thay đổi đủ quan trọng, nó có thể đƣợc đặt ở

đầu hang đợi để hanh động ngay lập tức. Nếu một vai thay đổi xảy ra trong

một mô-đun đơn, sự thay đổi hang loạt có thể đƣợc yêu cầu. Một loạt thay

đổi bao gồm việc lam thay đổi đối với toan bộ mô-đun một lúc để tránh lam

việc trên cùng một vai mô-đun lần. Điều nay cũng cho phép ngƣời dùng

xem những thay đổi nhƣ la một cập nhật duy nhất ma có thể thay đổi việc

sử dụng một mô-đun thông qua man hình thay đổi hoặc chức năng.





Bảng Ưu tiên

Quyết định

Nộp yêu cầu

Yêu cầu thay đổi

Người

dùng

Thứ tự thay đổiSắp ưu tiên và

phân loại

Người quản lý Dự án

Lập trình viên

Hình 18-5 Sơ đồ thay đổi yêu cầu

The queue of changes is a valuable tool in controlling work that

needs to be done. Items high in the queue receive the immediate attention

they deserve; those of lesser importance may never be acted on due to a

change in needs or a new system that solves the problem.

Hang đợi thay đổi la một công cụ có giá trị trong việc kiểm soát công

việc cần phải lam. Những mục đầu hang đợi nhận đƣợc sự chú ý chúng

xứng đáng ngay lập tức, những mục có tầm quan trọng thấp hơn có thể

không bao giờ đƣợc hoạt động do một sự thay đổi trong nhu cầu hoặc một

hệ thống mới giải quyết đƣợc vấn đề.

18.8 KẾT LUẬN

Managing system maintenance requires that steps be taken similar to

the development of new systems. System maintenance is in many ways an





extension of the system development life cycle and involves similar steps to

ensure that the system is properly maintained. As a new system is

implemented, system maintenance is required to fix the inevitable errors

and track them for future use. As a system ages and changes are requested,

system maintenance has the job of categorizing, prioritizing, and

implementing changes to the system. As these changes are made, the

system librarian has the very important job of controlling the integrity of

the system. The proper management of system maintenance is vital to the

continued success of the system. A well managed systems maintenance

department can save time and money by providing an error-free system that

meets the needs of the users it serves.

Quản lý việc bảo trì hệ thống yêu cầu các bƣớc tƣơng tự nhƣ sự phát

triển của hệ thống mới. Hệ thống bảo trì trong nhiều cách la một phần mở

rộng của vòng đời phát triển hệ thống va liên quan đến các bƣớc tƣơng tự

để bảo đảm rằng hệ thống đƣợc duy trì đúng cách. Khi một hệ thống mới

đƣợc thực hiện, bảo trì hệ thống la cần thiết để sửa chữa sai sót không thể

tránh khỏi va theo dõi chúng trong những sử dụng ở tƣơng lai. Khi một hệ

thống có thời kì va những thay đổi đƣợc yêu cầu, bảo trì hệ thống có nhiệm

vụ phân loại, ƣu tiên, va thực hiện các thay đổi cho hệ thống. Khi những

thay đổi nay đƣợc thực hiện, thủ thƣ hệ thống có công việc rất quan trọng

của việc kiểm soát sự toan vẹn của hệ thống. Sự quản lý thich hợp bảo trì hệ

thống la rất quan trọng cho sự thanh công liên tục của hệ thống. Một hệ

thống bảo trì đƣợc quản lý tốt có thể tiết kiệm thời gian va tiền bạc bằng





cách cung cấp một hệ thống không có lỗi, đáp ứng nhu cầu của ngƣời sử

dụng nó phục vụ.


Curtis, G., Hoffer, J., George, J., and Valacich, S. (2000).

Introduction to Business Systems Analysis, Pearson Custom Publishing,

Boston.

Gibson, V. and Senn, J. (1989). System Structure and Software

Maintenance Performance, ACM Press, New York.

Guimaraes, T. (1983). Managing Application Program Maintenance

Expenditures, ACM Press, New York.

Harrison, W. and Cook, C. Insights on improving the maintenance

process through software measurement.

http://www.cs.pdx.edu/~warren/Papers/CSM.htm.

Hulse, C., Edgerton, S., Ubnoske, M., and Vazquez, L. (1999).

Reducing Maintenance Costs through the Application of Modern Software

Architecture Principles, ACM Press, New York.

Lientz, B. (1983). Issues in Software Maintenance, ACM Press, New

York.





Lientz, B.P. and Swanson, E.B. (1978). Characteristics of application

software maintenance, Commn. ACM, 21, 466–481.

Lientz, B.P. and Swanson, B. (1981). Problems in Application

Software Maintenance, ACM Press, New York.

Swanson, E. (1990). Departmentalization in Software Development

and Maintenance, ACM Press, New York.




Chương 19: Khoa học về tài liệu hóa 673

CHƢƠNG 19 KHOA HỌC VỀ TÀI LIỆU HÓA

Người dịch:



3. Lê Văn Chân

4. Lê Anh Khoa






The one thing that software developers hate to do is to document

their programs and their systems. Therefore, it is understandable that

software documentation is the one of the most neglected areas in

information technology. However, documentation is one of the most

important components of systems development. Without adequate

documentation, the system can be neither utilized efficiently nor maintained

properly.

Tai liệu hóa các chƣơng trình va hệ thống la điều ma các nha phát

triển phần mềm không thich lam.Vì vậy, tai liệu hóa phần mềm la một trong

những phần bị xao lãng nhất trong công nghệ thông tin. Tuy nhiên, tai liệu

hóa la một trong những thanh phần quan trọng nhất cho việc phát triển các

hệ thống. Nếu không có tai liệu hƣớng dẫn đầy đủ, hệ thống có thể không

đƣợc tối ƣu hiệu quả hay duy trì đúng cách.

19.1 TÀI LIỆU HÓA LÀ GÌ?

According to Ambler (2002), a document is any artifact external to

source code whose purpose is to convey information in a persistent manner;

documentation includes documents and comments in source code. A model

is an abstraction that describes one or more aspects of a problem or a

potential solution.

Theo Ambler (2002), tai liệu (document) la những thứ khác với mã

nguồn đƣợc dùng để diễn đạt thông tin theo một cách thống nhất; hệ thống





tai liệu (documentation) bao gồm các tai liệu va chú thich trong mã nguồn.

Mô hình la cách biểu diễn trừu tƣợng một hoặc nhiều khia cạnh của một

vấn đề hoặc giải pháp tiềm năng.

All professionals in the field agree that documentation promotes

software quality. There are numerous, well-documented reasons for this.

David Tufflye, a consultant who specializes in producing high-quality

documentation to a predefined standard, says that consistent, accurate

project documentation is known to be a major factor contributing to

information systems quality. He goes on to say that document production,

version control, and filing are often not performed, contributing to a higher

number of software defects that impact the real and perceived quality of the

software, as well as leading to time and expense spent on rework and higher

maintenance costs (Tufflye, 2002).

Tất cả chuyên gia đều đồng ý rằng tai liệu hóa lam tăng chất lƣợng

phần mềm. Có nhiều lý do để giải thich việc nay. David Tufflye, một nha tƣ

vấn chuyên về sản xuất hệ thống tai liệu chất lƣợng cao theo một tiêu chuẩn

đƣợc xác định sẵn, nói rằng, tai liệu dự án chinh xác va phù hợp đƣợc xem

la một nhân tố chinh đóng góp cho chất lƣợng hệ thống thông tin. Ông cũng

nói rằng tai liệu hóa, kiểm soát phiên bản, va lập các hồ sơ thông tin thƣờng

không đƣợc thực hiện. Điều nay gây ra một lƣợng lớn các khuyết tật phần

mềm va dẫn đến thời gian va chi phi cho việc lam lại va bảo dƣơng cao lên

(Tufflye, 2002).





Marcello Alfredo Visconti proposes a software system

documentation process maturity model that is consistent with — and runs in

conjunction with — the Software Engineering Institute‘s (SEI) software

process and capability maturity model. He argues that one of the major

goals of software engineering is to produce the best possible working

software along with the best possible supporting documentation.

Marcello Alfredo Visconti đề xuất một mô hình quy trình phát triển

tai liệu của hệ thống phần mềm phù hợp va đi cùng với mô hình quy trình

phát triển phần mềm của Viện Kỹ thuật ứng dụng (SEI). Ông lập luận rằng

một trong những mục tiêu chinh của công nghệ phần mềm la sản xuất các

phần mềm tốt nhất cùng với các tai liệu hỗ trợ tốt nhất có thể.

Decades‘ worth of empirical data shows that software documentation

processes and products are key components of software quality. These

studies show that poor-quality, out-of-date, or missing documentation is a

major cause of errors in future software development and maintenance

(Visconti, 1993). For example, the majority of defects discovered during

integration testing are design and requirements defects, e.g., defects in

documentation that were introduced before any code was written.

Qua nhiều thập niên, thực nghiệm cho thấy các sản phẩm va các quy

trình lam tai liệu hƣớng dẫn phần mềm la chìa khóa cho chất lƣợng phần

mềm. Những nghiên cứu cho thấy rằng tai liệu chất lƣợng kém, lạc hậu,

hoặc thiếu sót la một nguyên nhân chinh gây ra sai sót trong phát triển va





bảo dƣơng phần mềm trong tƣơng lai (Visconti, 1993). Vi dụ, phần lớn

khuyết tật đƣợc phát hiện trong thời gian thử nghiệm tich hợp la những sai

sót về thiết kế va yêu cầu, chẳng hạn nhƣ những khiếm khuyết trong hệ

thống tai liệu đƣa ra trƣớc khi mã nguồn đƣợc viết.

Visconti‘s four-level documentation maturity model provides the

basis for an assessment of an organization‘s current documentation process

and identifies key practices and challenges to improve the process. The

fourlevel enhanced model appears in Exhibit 19-1.

Mô hình 4 cấp về quy trình phát triển tai liệu của Visconti cung cấp

cơ sở cho việc đánh giá quá trình lam tai liệu hiện thời của một tổ chức

cũng nhƣ xác định công việc va thách thức chinh để cải thiện quá trình. Mô

hình 4 cấp đã cải tiến đƣợc trình bay ở Hình 19-1.





Key practices as defined by Cook and Visconti (2000) are:

Công việc chinh đƣợc định nghĩa bởi Cook va Visconti (2000) la:

19.1.1 Tạo ra các văn bản phần mềm cơ bản

- Consistent creation of basic software development documents





- Consistent creation of basic software quality documents

- Tạo ra các tai liệu cơ bản về phát triển phần mềm phù hợp

- Tạo ra các tai liệu cơ bản về chất lƣợng phần mềm phù hợp

19.1.2 Sự công nhận tầm quan trọng của tai liệu ở mức ngƣời quản lý

- Documentation generally recognized as important

- Tai liệu nói chung đƣợc xem la quan trọng

19.1.3 Sự tồn tại của chinh sách hay tiêu chuẩn về tai liệu

- Written statement or policy about importance of documentation

- Written statement or policy indicating what documents must be created

for each development phase

- Written statement or policy describing the contents of documents that

must be created for each development phase

- Văn bản hoặc chinh sách về tầm quan trọng của tai liệu

- Văn bản hoặc chinh sách chỉ ra rằng tai liệu phải đƣợc tạo ra cho mỗi

giai đoạn phát triển





- Văn bản hoặc chinh sách mô tả nội dung của các tai liệu phải đƣợc tạo

ra cho mỗi giai đoạn phát triển

19.1.4 Giám sát thực hiện chinh sách hoặc tiêu chuẩn

- Use of a mechanism, such as a check-off list, to verify that required

documentation is done

- Monitor adherence to documentation policy or standards

- Sử dụng một cơ chế, chẳng hạn nhƣ một danh sách đánh dấu, để kiểm

tra tai liệu đƣợc yêu cầu đã đƣợc thực hiện hay chƣa

- Giám sát sự tuân thủ các chinh sách về tai liệu hƣớng dẫn hoặc tiêu

chuẩn

19.1.5 Sự tồn tại của một quá trình định sẵn để tạo các tai liệu

- Written statement to prescribe process for creation of documents

- Mechanism to monitor adherence to prescribed process

- Adequate time to carry out the prescribed process

- Training material or classes about the prescribed process

- Văn bản quy định quá trình tạo ra các tai liệu





- Cơ chế để giám sát sự tuân thủ các quy trình theo quy định

- Thời gian thoả đáng để thực hiện quá trình theo quy định

- Tai liệu hƣớng dẫn hoặc các lớp học về quá trình theo quy định

19.1.6 Phƣơng pháp để đảm bảo chất lƣợng của các tai liệu

- Mechanism to monitor quality of documentation

- Mechanism to update documentation

- Documentation is traceable to previous documents

- Cơ chế giám sát chất lƣợng của các tai liệu

- Cơ chế để cập nhật tai liệu

- Tai liệu có thể truy ngƣợc về những tai liệu trƣớc đó

19.1.7 Đánh giá về tinh tiện dụng của các tai liệu

- Person or group perception of usability of documents created

- Mechanism to obtain user feedback about usability of created

documentation

- Quan điểm của cá nhân hoặc tập thể về các tai liệu đƣợc tạo ra





- Cơ chế để có đƣợc thông tin phản hồi từ ngƣời dùng về tinh tiện dụng

của tai liệu

19.1.8 Định nghĩa về các thƣớc đo chất lƣợng va tinh tiện dụng của tai

liệu phần mềm

- Definition of measures of documentation quality

- Definition of measures of documentation usability

- Định nghĩa về cách đo chất lƣợng tai liệu

- Định nghĩa về cách đo tinh tiện dụng của tai liệu

19.1.9 Tập hợp va phân tich các thƣớc đo chất lƣợng của tai liệu

- Collection of measures about quality of documentation

- Analysis of documentation quality measures

- Recording of documentation error data

- Tracking of documentation errors and problem reports to solutions

- Analysis of documentation error data and root causes

- Generation of recommendations based on analysis of quality

measurements and error data





- Tập hợp các cách đo về chất lƣợng của các tai liệu

- Phân tích các cách đo chất lƣợng tai liệu

- Ghi nhận dữ liệu lỗi trong tai liệu

- Theo dõi các lỗi va báo cáo vấn đề để tìm giải pháp

- Phân tich các lỗi va nguyên nhân

- Đƣa ra các khuyến nghị dựa trên phân tich chất lƣợng thƣớc đo va dữ

liệu lỗi

19.1.10 Tập hợp va phân tich các thƣớc đo tinh tiện dụng của tai liệu

- Collection of measures about usability of documentation

- Analysis of documentation usability measurement

- Generation of recommendations based on analysis of usability

measurements

- Generation of documentation usage profile

- Tập hợp của các cách đo về tinh tiện dụng của các tai liệu

- Phân tich cách đo tinh tiện dụng của tai liệu





- Đƣa ra các khuyến nghị dựa trên phân tich sự đánh giá tinh tiện dụng

- Đƣa ra các hồ sơ hƣớng dẫn sử dụng tai liệu

19.1.11 Quy trình phản hồi - cải tiến

- Mechanism to feedback improvements to documentation process

- Mechanism to incorporate feedback on quality of documentation

- Mechanism to incorporate feedback on usability of documentation

- Cơ chế cải tiến quá trình lam tai liệu dựa vao phản hồi

- Cơ chế để kết hợp phản hồi về chất lƣợng của các tai liệu

- Cơ chế để kết hợp phản hồi về tinh tiện dụng của các tai liệu

An assessment procedure was developed to determine where an

organization‘s documentation process stands relative to the model. This

enables mapping from an organization‘s past performance to a

documentation maturity level and ultimately generates a documentation

process profile. The profile indicates key practices for that level and

identifies areas of improvement and challenges to move to the next higher

level.





Một quy trình đánh giá đã đƣợc phát triển để xác định xem quá trình

lam tai liệu của một tổ chức liên hệ đến mô hình ở điểm nao. Điều nay cho

xác định mức độ phát triển va sử dụng tai liệu của một tổ chức dựa vao

năng suất của tổ chức đó, va cuối cùng la tạo ra một hồ sơ về quy trình xử

lý tai liệu. Các hồ sơ chỉ ra công việc chinh ở mức độ đó va xác định các

lĩnh vực cần cải tiến va thách thức để đạt tới mức độ cao hơn.

Application of the model has a definite financial benefit. The

software documentation maturity model and assessment procedure have

been used to assess a number of software organizations and projects; a

cost/benefit analysis of achieving documentation maturity levels has been

performed using COCOMO that yielded an estimated return on investment

of about 6:1 when moving from the least mature level to the next.

According to Visconti, these results support the main claim of this research:

software organizations that are at a higher documentation process maturity

level also produce higher-quality software, resulting in reduced software

testing and maintenance effort (Visconti, 1993).

Áp dụng mô hình đem lại lợi ich nhất định về tai chinh. Mô hình quy

trình phát triển tai liệu phần mềm va thủ tục đánh giá đã đƣợc sử dụng để

đánh giá một số tổ chức va các dự án phần mềm; một phân tich chi phi/lợi

ich để đạt đƣợc 1 cấp độ đã đƣợc thực hiện, sử dụng COCOMO, cho thấy

tỉ lệ lợi nhuận thu về trên vốn đầu tƣ ƣớc tinh khoảng 06:01 khi di chuyển

từ cấp độ thấp nhất đến cấp độ kế tiếp. Theo Visconti, những kết quả nay

chứng tỏ các khẳng định của nghiên cứu nay: các tổ chức phần mềm đang ở





cấp độ cao hơn trong quy trình lam tai liệu cũng sản xuất phần mềm chất

lƣợng cao, dẫn đến giảm công việc thử nghiệm phần mềm va bảo trì

(Visconti, 1993).

19.2 CÁC PHƢƠNG PHÁP VÀ TIÊU CHUẨN

The many approaches to producing documentation are practically

unique to each organization. Although the majority of software

documentation is produced manually — i.e., done with word processing

programs or with tools such as Microsoft Visio, some systems are designed

to ease the process and will produce ―automatic‖ documentation. Some of

the automatic documentation capabilities are a subset of systems of a wider

range of capabilities; this is the case with many computer-assisted software

engineering (CASE) tools. These products are designed to support

development efforts throughout the software development life cycle

(SDLC), with documentation just one small part.

Các phƣơng pháp tiếp cận để tạo ra tai liệu la duy nhất cho mỗi tổ

chức. Mặc dù phần lớn các tai liệu phần mềm đƣợc sản xuất thủ công - tức

la, thực hiện với các chƣơng trình xử lý văn bản hoặc với các công cụ nhƣ

Microsoft Visio, một số hệ thống đƣợc thiết kế để lam dễ dang quá trình

sản xuất va "tự động‖ tạo ra tai liệu. Một số trong những tinh năng lam tai

liệu tự động chỉ la một phần trong một hệ thống các tinh năng rộng hơn,

đây la trƣờng hợp các công cụ phần mềm hỗ trợ máy tinh (CASE). Những





sản phẩm nay đƣợc thiết kế để hỗ trợ quy trình phát triển phần mềm

(SDLC), va tai liệu hƣớng dẫn chỉ một phần nhỏ.

An example of one such tool is Hamilton Technologies 001 which is

discussed at length in this handbook. 001 is a CASE tool (now usually

called application development tool in lieu of the term CASE) that

surrounds itself with an intriguing methodology called ―development before

the fact‖ (DBTF). The premise behind 001 and DBTF is that developing

systems in a quality manner begets quality and error-reduced systems. One

of the intriguing features of the 001 tool set is that it not only generates

programming source code from maps (i.e., models) of a business problem,

but also generates the documentation for the system.

Một vi dụ của một trong những công cụ nhƣ vậy la Hamilton

Technologies 001 (đƣợc đề cập rất nhiều trong cuốn sổ tay nay). 001 la một

công cụ CASE (bây giờ thƣờng đƣợc gọi la công cụ phát triển ứng dụng

thay cho thuật ngữ CASE) sử dụng một phƣơng pháp hấp dẫn đƣợc gọi la

"phát triển trƣớc thực tế‖ (DBTF). Những tiền đề phia sau 001 va DBTF la

phát triển hệ thống một cách chất lƣợng sinh ra những sản phẩm chất lƣợng

va it lỗi hơn. Một trong những tinh năng hấp dẫn của các công cụ thiết lập

001 la nó không chỉ tạo ra mã nguồn từ bản đồ (tức la các mô hình) của một

vấn đề kinh doanh, ma còn tạo ra những tai liệu cho hệ thống.

On one end of the documentation spectrum, many companies utilize

no tools other than a word processor and a drawing tool to extract





documentation from their reluctant programmers. On the other end,

forward-thinking companies make significant investments in their software

development departments by outfitting them with tool suites such as 001.

The vast majority of organizations lie somewhere between these two

extremes.

Ở một thái cực, nhiều công ty chỉ sử dụng một bộ soạn thảo văn bản

va một công cụ vẽ để lấy tai liệu từ các lập trình viên miễn cƣơng của họ.

Ngƣợc lại ở một thái cực khác, nhiều công ty biết tinh xa đã đầu tƣ đáng kể

cho các bộ phận phát triển phần mềm của họ bằng cách trang bị cho họ với

bộ công cụ nhƣ 001. Đa số các tổ chức nằm đâu đó giữa hai thái cực nay.

The world of client/server has afforded the developer with new

opportunities and decisions to make in terms of which tool set to use. When

Microsoft Office was first introduced, it was utilized mostly for word

processing. Today, Microsoft Access, the database component of the MS

Office product set, has become a significant player in corporations with a

requirement for a robust but less complex database than that of the

powerhouse computers that run their back offices (i.e., Sybase, Oracle,

Microsoft SQL Server).

Thế giới của máy con/máy chủ (client/server) đã cho các nha phát

triển những cơ hội va quyết định mới để xác định những công cụ để sử

dụng. Khi Microsoft Office lần đầu tiên đƣợc giới thiệu, nó đã đƣợc sử

dụng chủ yếu cho xử lý văn bản. Ngay nay, Microsoft Access, thanh phần





cơ sở dữ liệu của MS Office, đã trở thanh một thứ quan trọng trong các

công ty với yêu cầu của một cơ sở dữ liệu mạnh mẽ nhƣng đơn giản hơn

Sybase, Oracle, Microsoft SQL Server.

Microsoft Access enables the automated production of several kinds

of documents related to the datasets implemented with the program. The

documents describe schemas, queries, and entity relationship diagrams

(ERDs) as shown in Exhibit 19-2.

Microsoft Access cho phép sản xuất tự động của nhiều loại tai liệu

liên quan đến các tập dữ liệu đƣợc triển khai thực hiện với chƣơng trình.

Các tai liệu mô tả lƣợc đồ, truy vấn, va sơ đồ quan hệ thực thể (ERDs) nhƣ

thể hiện trong Hình 19-2.

Some products are dedicated to producing documentation. One such

product is Doc-o-Matic by toolsfactory.com. It is designed to work with the

Borland Delphi software development environment. The product works

with Delphi‘s internal structures, which may consist of: Author, Bugs,

Conditions, Examples, Exceptions, History, Ignore, Internal, Notes,

Parameters, Remarks, Return Value, See Also, Todo, and Version (Leahey,

2002). Doc-o-Matic has been compared to a gigantic parsing routine. As

software systems grow in size and sophistication, it becomes harder for

humans to understand them and anticipate their behavior, says Charles

Robert Wallace in his dissertation, ―Formal Specification of Software Using

Abstract State Machines‖. This method essentially enables walk-through





before code is written. Wallace argues that normal specification techniques

aim to foster understanding and increase reliability by providing a

mathematical foundation to software documentation (Wallace, 2000). His

technique calls for layering information onto a model through a series of

refinements.

Một số sản phẩm chuyên về sản xuất tai liệu. Một trong số đó la

Doc-o-Matic của toolsfactory.com. Nó đƣợc thiết kế để lam việc với môi

trƣờng phát triển phần mềm Borland Delphi. Sản phẩm nay tƣơng thich với

cấu trúc bên trong của Delphi, có thể bao gồm: Author, Bugs, Conditions,

Examples, Exceptions, History, Ignore, Internal, Notes, Parameters,

Remarks, Return Value, See Also, Todo, và Version (Leahey, 2002). Doc-o

-Matic đã đƣợc so sánh với một quy trình phân tich khổng lồ. Khi hệ thống

phần mềm ngay cang lớn va phức tạp, con ngƣời cang khó nắm bắt va dự

đoán các hanh vi của hệ thống, nhƣ Charles Robert Wallace đã nói trong

luận án của mình, "Formal Specification of Software Using Abstract State

Machines". Phƣơng pháp nay về cơ bản cho phép diễn tập trƣớc khi mã

đƣợc viết. Wallace cho rằng kỹ thuật đặc tả bình thƣờng nhắm tới mục đich

tăng cƣờng sự hiểu biết va độ tin cậy bằng cách cung cấp một nền tảng toán

học cho tai liệu phần mềm (Wallace, 2000). Các kỹ thuật của ông yêu cầu

phân lớp thông tin vao một mô hình thông qua một loạt các sang lọc.





19.3 TẠO TÀI LIỆU MỘT CÁCH ĐÖNG ĐẮN

At present, many organizations are practicing a ―hit or miss― form of

software documentation. These are usually the companies that follow no or

few policies and procedures and loosely follow standards. Good software

development is standards based; thus, documentations must also be





standards based. At minimum, software documentation should consist of

the following:

Hiện nay, nhiều tổ chức đang thi hanh một cách tai liệu hóa phần

mềm trúng hoặc trật. Đây thƣờng la những công ty ma không lam theo hoặc

chỉ theo vai chinh sách va thủ tục va hầu nhƣ không theo tiêu chuẩn. Phát

triển tốt phần mềm phải dựa trên các tiêu chuẩn; do đó, tai liệu cũng phải

đƣợc dựa trên các tiêu chuẩn. Tai liệu phần mềm tối thiểu phải bao gồm

những điều sau đây:

19.3.1 Tất cả các tai liệu hƣớng dẫn đƣợc sản xuất trƣớc khi bắt đầu

phát triển mã nguồn

Most projects go through a systems development life cycle, which

often starts with a feasibility study, goes on to create a project plan, and

then enters into the requirements analysis and system design phases. Each

of these phases produces one or more deliverables, schedules, and artifacts

(examples of these can be found in the appendices to this handbook). In

sum, the beginnings of your system documentation effort should include the

feasibility study, project plan, requirements specification, and design

specification, where available.

Hầu hết các dự án đi qua một chu kỳ phát triển hệ thống, ma thƣờng

bắt đầu với một nghiên cứu tinh khả thi, tiếp tục la tạo ra một kế hoạch cho

dự án, va sau đó phân tich yêu cầu va các giai đoạn phân tich thiết kế hệ





thống. Mỗi giai đoạn sản xuất một hay nhiều sự chuyển giao, lịch trình, va

hiện vật (vi dụ trong số nay có thể đƣợc tìm thấy trong phụ lục). Tóm lại,

việc tai liệu hóa nên bắt đầu ngay từ trong các nghiên cứu tinh khả thi, kế

hoạch dự án, xác định yêu cầu va thiết kế.

19.3.2 Lƣu đồ chƣơng trình

Programmers usually, although not always, initiate their

programming assignment by drawing one or more flowcharts that diagram

the nuts and bolts of the actual program. Systems analysts can utilize

diagrammatic tools such as data flow diagrams (DFD) or UML-based

(unified modeling language) class diagrams (Exhibits 19-3 and 19-4) to

depict the entire system from a physical design level; however, the

programmer is often required to utilize flowcharts (Exhibit 19-5) to depict

the flow of a particular component of the DFD or UML class diagram.

Ngƣời lập trình thông thƣờng, mặc dù không phải luôn luôn, bắt đầu

công việc lập trình bằng cách vẽ một hoặc nhiều lƣu đồ có sơ đồ các nút va

chốt của chƣơng trình thực tế. Các nha phân tich hệ thống có thể sử dụng

các công cụ nhƣ sơ đồ luồng dữ liệu (DFD) hoặc dựa trên sơ đồ lớp theo

UML (ngôn ngữ mô hình hóa chuẩn) (Hình 19-3 và 19-4) để miêu tả toan

bộ hệ thống từ một mức độ thiết kế vật lý. Tuy nhiên, các lập trình viên

thƣờng đƣợc yêu cầu để sử dụng lƣu đồ (Hình 19-5) để miêu tả dòng chảy

của một thanh phần đặc biệt của các sơ đồ lớp UML va DFD.





19.3.3 Mô hình sử dụng hay mô hình nghiệp vụ

The first bullet point recommends including in your documentation

all documentation created during the analysis and design component of the

systems development effort. Use cases may or may not be a part of these

documents — although they should be. Use cases, an example of which is

shown in Exhibit 19-6, provide a series of end-user procedures that make

use of the system in question. For example, in a system that handles student

registration, typical use cases might include student log in, student

registering for the first time, and a student request for financial aid. Use

cases are valuable in all phases of systems development: 1) during systems

analysis, use cases enable the analyst to understand what the end user wants

out of the new system; 2) during programming, use cases assist the

programmer to understand the logic flow of the system; and 3) during

testing, use cases can form the basis of the preliminary test scripts.

Điểm đầu tiên trong phần nay đã đề nghị đƣa vao hệ thống tai liệu

của bạn tất cả các tai liệu đƣợc tạo ra trong quá trình phân tich va thiết kế

thanh phần hệ thống. Các mô hình sử dụng có thể hoặc không cần la một

phần của các tai liệu nay - mặc dù nên có. Vi dụ, trong một hệ thống xử lý

việc đăng ký sinh viên, mô hình sử dụng tiêu biểu có thể bao gồm đăng

nhập, sinh viên đăng ký lần đầu, va sinh viên yêu cầu hỗ trợ tai chinh. Các

mô hình sử dụng có giá trị trong tất cả các giai đoạn phát triển hệ thống: 1)

trong phân tich hệ thống, mô hình sử dụng cho phép các nha phân tich hiểu

những gì ma ngƣời dùng muốn từ hệ thống mới; 2) trong quá trình lập trình,





các trƣờng mô hình sử dụng giúp các lập trình viên hiểu những luồng logic

của hệ thống; va 3) trong thử nghiệm, trƣờng hợp sử dụng có thể hình thanh

cơ sở của các script kiểm tra sơ bộ.

19.3.4 Thuật ngữ tham khảo

Every organization is unique in that it has its own vocabulary.

Systems people are also unique in that they often use a lingo

incomprehensible to most end users. A ―dictionary‖ of terms used is

beneficial in clearing up any misunderstandings.

Mọi tổ chức đều sử dụng những thuật ngữ của riêng mình . Những

ngƣời lam hệ thống thƣờng sử dụng một ngôn ngữ ngƣời dùng cuối không

thê hiêu. Một từ điển những từ ngữ nhƣ thế đƣợc sử dụng sẽ có lợi trong

việc sẽ có tác dụng loại bỏ các hiểu lầm.

19.3.5 Từ điển dữ liệu

Although a data dictionary (DD) is usually included in system design

specification (SDS), if it is not, it should be included here. An excerpt of a

DD can be seen in Exhibit 19-7 and in Appendix K. A data dictionary is

―terms of reference‖ for the data used in the system. It describes database,

tables, records, fields, and all attributes such as length and type (i.e.,

alphabetic, numeric). The DD also should describe all edit criteria such as





the fact that social security numbers must be numeric and must contain nine

characters.

Một từ điển dữ liệu (DD) thƣờng đƣợc bao gồm trong đặc điểm kỹ

thuật trong thiết kế hệ thống (SDS), nếu nó không có thì cần đƣợc đƣa vao

đây. Một trich đoạn của một DD có thể đƣợc nhìn thấy trong Hình 19-7 tại

Phụ lục K. Một từ điển dữ liệu la tập những thuật ngữ cho các dữ liệu đƣợc

sử dụng trong hệ thống. Nó mô tả cơ sở dữ liệu, bảng biểu, bản ghi, trƣờng

dữ liệu, va tất cả các thuộc tinh nhƣ chiều dai va kiểu (tức la chữ, số). Các

DD cũng nên miêu tả tất cả các sửa các tiêu chi dữ liệu hợp lệ, vi dụ nhƣ số

CMND phải gồm 9 chữ số.





19.3.6 Tai liệu về chƣơng trình / Thanh phần / Đối tƣợng

Aside from flowcharts, unless the programmer is using an automated

CASE tool that generates documentation, the programmer should provide

the following documentation: 1) control sheet (see Appendix N); 2)

comments within the program (Exhibit 19-8); 3) textual description of what

the program is doing, including pseudocode, as shown in Exhibit 19-8.





Ngoài lƣu đồ, trừ khi lập trình viên đang sử dụng một công cụ tự

động tạo ra tai liệu, lập trình viên nên cung cấp các tai liệu sau đây: 1) bảng

điều khiển (xem Phụ lục N); 2) chú thich trong chƣơng trình (19-8); 3) văn

bản mô tả chƣơng trình lam gì, bao gồm cả mã giả, nhƣ thể hiện trong

Exhibit 19-8.

19.3.7 Các tai liệu trình bay

It is likely that, at some point, the system team will be asked to make

a presentation about the system. All presentation paraphernalia such as

slides, notes, etc. should be included in the system documentation.

Có lẽ rằng, tại một số điểm, đội ngũ hệ thống sẽ đƣợc yêu cầu thực

hiện một bai trình bay về hệ thống. Tất cả các tai liệu trình bay nhƣ slide,

ghi chú, vv nên đƣợc bao gồm trong tai liệu hệ thống.





19.3.8 Các trƣờng hợp kiểm tra (Phụ lục O) va kế hoạch kiểm tra

Although use cases form the basis of the initial set of test cases, they

are a small subset of test cases. An entire chapter has been dedicated to

software testing, so we will not prolog the discussion here. Suffice it to say

that any and all test cases used in conjunction with the system — along with

the results of those test cases — should be included in the system

documentation.

Mặc dù các mô hình sử dụng tạo ra cơ sở của các thiết lập ban đầu

của các trƣờng hợp kiểm tra, chúng chỉ la một tập hợp nhỏ các trƣờng hợp

thử nghiệm. Toan bộ 1 chƣơng đã danh cho việc thử nghiệm phần mềm, vì

vậy chúng tôi sẽ không thảo luận tại đây. Nhƣ thế đủ để thấy rằng bất kỳ va

tất cả các trƣờng hợp kiểm tra - cùng với các kết quả - nên đƣợc bao gồm

trong các tai liệu của hệ thống.

19.3.9 Tiêu chuẩn đo lƣờng

It is sad to say that most organizations do not measure the

effectiveness of their programmers. Those that do should add this

information to the system documentation. This includes a listing of all

metrics (formula) used and the results of those measurements. (This

handbook contains many chapters on metrics.) At a minimum, the weekly

status reports and management reports generated from toolsets such as

Microsoft Project should be included in the system documentation.





Rất tiếc khi phải nói rằng, hầu hết các tổ chức không đánh giá hiệu

quả của các lập trình viên của họ. Những ngƣời lam việc nay nên thêm

thông tin nay tai liệu hệ thống, bao gồm một danh sách của tất cả số liệu

(công thức) đƣợc sử dụng va kết quả của những phép đo. (Cuốn cẩm nang

nay có chứa nhiều chƣơng về số liệu). Ở mức tối thiểu, các báo cáo tình

trạng hang tuần va báo cáo quản lý phát sinh từ các công cụ nhƣ Microsoft

Project nên đƣợc bao gồm trong tai liệu hệ thống.

19.3.10 Các hƣớng dẫn hoạt động

Once the system is implemented, aside from the end users that the

system was developed for, some computer support operations personnel

may be required to support this system in some way. Precise instructions

for these support personnel are mandatory and must be included in the

documentation for the system.

Một khi hệ thống đƣợc thực hiện, ngoai ngƣời dùng cuối của hệ

thống, một số nhân viên hỗ trợ hoạt động có thể đƣợc yêu cầu để hỗ trợ hệ

thống nay theo một số cách. Hƣớng dẫn chinh xác cho các nhân viên hỗ trợ

la bắt buộc va phải đƣợc bao gồm trong các tai liệu cho hệ thống.

19.3.11 Tập tin trợ giúp ngƣời dùng cuối

Most systems are built using a client/server metaphor that is quite

interactive. Most systems, therefore, provide end users with online help. A





copy of each help file should be saved as documentation. Most corporate

systems are Windows-based; hence, a Windows-style format in creating

help files (Exhibit 19-9) has become the de facto standard. Microsoft Help

Workshop is often used to assist in developing these.hlp files, which are

compiled from RTF (rich text format) files.

Hầu hết các hệ thống đƣợc xây dựng bằng cách sử dụng mô hình

máy con/máy chủ khá tƣơng tác. Hầu hết các hệ thống, do đó, cung cấp cho

ngƣời dùng cuối với sự giúp đơ trực tuyến. Một bản sao của từng tập tin

giúp đơ nên đƣợc lƣu dƣới dạng tai liệu. Hầu hết các hệ thống doanh nghiệp

dựa trên Windows, vì vậy, một định dạng kiểu Windows trong việc tạo ra

các tập tin trợ giúp (Hình 19-9) đã trở thanh tiêu chuẩn ngầm. Microsoft

Help Workshop thƣờng đƣợc sử dụng để hỗ trợ trong việc phát triển tập

tin.hlp, đƣợc biên dịch từ tập tin RTF.

19.3.12 Tai liệu hƣớng dẫn ngƣời dùng

Aside from the built-in help file, a user manual should be included in

what is provided to the end user. Increasingly, this user manual is supplied

right on the CD rather than on paper. There are two different types of end-

user manuals. One is more of an encyclopedia that explains the terms and

workings of the system when the end user has a specific question. The

second type is more of a tutorial.





Ngoai việc tập tin giúp đơ, một hƣớng dẫn sử dụng nên đƣợc bao

gồm trong những gì đƣợc cung cấp cho ngƣời dùng cuối. Ngay cang nhiều

hƣớng dẫn sử dụng nay đƣợc cung cấp ngay trên đĩa CD hơn la trên giấy.

Có hai loại khác nhau của hƣớng dẫn sử dụng. Một la bách khoa toan thƣ

giải thich các thuật ngữ va hoạt của hệ thống khi ngƣời dùng cuối có một

câu hỏi cụ thể. Loại thứ hai thì la hƣớng dẫn từng bƣớc.

User tutorials are easy to develop; it is important to approach the task

step by step, going through all the motions of using the software exactly as

a user would. Simply record every button you push and key you press. As

seen in Exhibit 19-10, a table format works well documenting the use of the

SecureCRT program, which is a product of New Mexico-based Van Dyke

Software. Another advantage is that the user documentation development

process serves double duty as a functional test. As the analyst or tech writer

is developing the tutorial, he or she might just uncover some bugs.

Hƣớng dẫn ngƣời sử dụng rất dễ phát triển. Điều quan trọng la tiếp

cận nhiệm vụ từng bƣớc, duyệt qua tất cả các thao tác sử dụng phần mềm

chinh xác nhƣ cách ngƣời dùng cuối lam. Chỉ cần ghi lại mỗi nút hay phim

ma bạn nhấn. Nhƣ thấy trong Hình 19-10, một định dạng bảng tạo ra tai

liệu rất tốt sử dụng SecureCRT, một sản phẩm của New Mexico-based Van

Dyke Software. Lợi thế nữa la quá trình phát triển tai liệu hƣớng dẫn ngƣời

sử dụng phục vụ cả nhiệm vụ thử nghiệm chức năng. Khi các nha phân tich

xây dựng tai liệu hƣớng dẫn sử dụng, họ có thể phát hiện ra một số lỗi.





19.4 BẢO TRÌ TÀI LIỆU

In his discussion of system documentation for the article ―Tools and

Evidence‖, Scott Ambler (2002) suggests that modeling and documentation

are effective, when employed with sense and restraint, and enhance system

functionality. He makes a case that there is a need for restraint and that

models should be discarded once they have fulfilled their purpose. As a

project progresses, models are superseded by other artifacts such as other

models, source code, or test cases that represent the information more

effectively. Ambler takes a fresh approach — it is important to know what

to keep, but it is also important to know what to throw away.

Trong cuộc thảo luận của mình về hệ thống tai liệu cho bai viết

"Công cụ va chứng cứ‖, Scott Ambler (2002) cho thấy rằng mô hình hóa va

tai liệu hóa có hiệu quả khi lam việc với sự hợp lý va các rang buộc, va tăng

cƣờng chức năng hệ thống. Ông thực hiện một trƣờng hợp cần phải có rang

buộc va các mô hình cần đƣợc loại bỏ một khi đã hoan thanh nhiệm vụ. Khi

một dự án tiến hanh, các mô hình đƣợc thay thế bằng hiện vật khác nhƣ các

mô hình khác, mã nguồn, hoặc các trƣờng hợp kiểm tra ma biểu diễn thông

tin hiệu quả hơn. Ambler dùng một cách tiếp cận mới - điều quan trọng la

biết giữ những gì, nhƣng cũng rất quan trọng để biết những gì cần vứt đi.

Documentation is particularly critical for maintenance work. Code

can be mysterious to maintenance programmers who must maintain the





system for years after the original system was written and the original

programmers have moved on to other jobs (Graham et al., 2000).

Tai liệu đặc biệt quan trọng cho công tác bảo trì. Các dòng code có

thể rất khó hiểu đối với các lập trình viên bảo trì, những ngƣời phải duy trì

hệ thống nhiều năm sau khi hệ thống gốc đã đƣợc viết va các lập trình viên

ban đầu đã chuyển sang công việc khác (Graham et al, 2000.).

Documentation is becoming more important. Ravi Shankar Kalakota

(1996) wrote about organizing practices in his 1996 dissertation,

―Organizing for Electronic Commerce‖. Organizing is crucial, he says, and

the problem of organizing has three distinct dimensions:

Tai liệu ngay cang trở nên quan trọng. Ravi Shankar Kalakota (1996)

đã viết về quản lý công việc trong luận án 1996 của mình, "Quản lý cho

thƣơng mại điện tử". Quản lý la rất quan trọng, ông nói, va vấn đề quản lý

có ba chiều khác nhau:

• Organizing large amounts of data and digital documents

• Organizing business processes and workflows

• Organizing computing and processing

• Quản lý một lƣợng lớn dữ liệu va tai liệu kỹ thuật số

• Quản lý các quy trình va dòng chảy nghiệp vụ





• Quản lý tinh toán va xử lý

Kalakota offers resolution for each of these challenges, but for our

purposes, I will limit discussion to the specific issues.

Distributed documents must be organized such that users and

programs are able to locate, track, and use online documents. The growth of

networking brings with it a corresponding increase in the number of

documents to be organized. Current document organization techniques are

derived from techniques used in file systems and are not sufficient for

organizing the large number of heterogeneous documents that are becoming

available for various purposes.

Kalakota cung cấp giải pháp cho mỗi thách thức, nhƣng vì mục đich

của chúng ta, tôi sẽ hạn chế thảo luận các chi tiết cụ thể.

Tai liệu đƣợc phân phối phải đƣợc tổ chức sao cho ngƣời sử dụng

va các chƣơng trình có thể xác định vị tri, theo dõi, va sử dụng tai liệu trực

tuyến. Sự phát triển của mạng mang đến một sự gia tăng tƣơng ứng số tai

liệu cần quản lý. Kỹ thuật quản lý tai liệu hiện nay xuất phát từ các kỹ thuật

đƣợc sử dụng trong các hệ thống tập tin va không đủ để tổ chức số lƣợng

lớn các tai liệu không đồng nhất đang trở nên ngay cang nhiều va cho các

mục đich khác nhau.

Second, Kalakota believes that new computing forms must be

developed to process, filter, and customize online documents. He asserts





that the traditional notion of client/server computing is not sufficient to deal

with the complexity and needs of electronic commerce. Third, workflows

need to be structured to take advantage of online documents. Workflows

often dictate organization structure but are difficult to study because they

are essentially complex patterns of interaction between agents (Kalakota,

1996). We can easily characterize the variable properties of sequential

actions, but not real-time patterns for tasks occurring in parallel.

Thứ hai, Kalakota tin rằng các hình thức tinh toán mới phải đƣợc

phát triển để xử lý, lọc, va tuỳ chỉnh các văn bản trực tuyến. Ông khẳng

định rằng mô hình truyền thống client/server la không đủ để đối phó với sự

phức tạp va nhu cầu của thƣơng mại điện tử. Thứ ba, luồng công việc cần

phải đƣợc cấu trúc để tận dụng các tai liệu trực tuyến. Luồng công việc

thƣờng áp đặt cấu trúc tổ chức nhƣng lại khó nghiên cứu vì chúng la mô

hình phức tạp của sự tƣơng tác giữa các tác nhân (Kalakota, 1996). Chúng

ta có thể dễ dang xác định các thuộc tinh của các hanh động tuần tự, nhƣng

không thể lam trên các mẫu thời gian thực cho công việc diễn ra song song.

19.5 KẾT LUẬN

Documentation is an often neglected but very necessary component

of the software development life cycle (SDLC). Numerous approaches and

methods are available to software development teams to assist with the task.





Most important are a commitment to documenting software, setting

standards for the organization, and making them stick, that is, adhering to

the standards.

Tai liệu la một thanh phần thƣờng bị quên lãng nhƣng rất cần thiết

cho quy trình phát triến của phần mềm (SDLC). Có nhiều phƣơng pháp va

cách tiếp cận khác nhau để hỗ trợ các đội phát triển phần mềm thực hiện

nhiệm vụ nay. Quan trọng nhất la lựa chọn phần mềm lam tai liệu, thiết lập

tiêu chuẩn cho tổ chức, va gắn kết chúng lại, nghĩa la, tôn trọng các tiêu

chuẩn.


Ambler, S.W. (2002). Tools and evidence. Software development.

Online.Available:

http://www.sdmagazine.com/documents/s=7134/sdm0205i/0205i.htm.

Applied Information Science International. (1996). Entity

relationship diagram. [Online]. Available:

http://www.aisintl.com/case/olais/pb96/er_model.htm.

Cook, C.R. and Visconti, M. (2000). Software system documentation

process maturity model. http://www.cs.orst.edu/~cook/doc/Model.htm.





Graham, C., Hoffer, J.A., George, J.F., and Valacich, J.S. (2000).

Introduction to Business Systems Analysis. Pearson Custom Publishing,

Boston.

Kalakota, R.S. (1996). Organizing for electronic commerce. DAI-A.

57/02. (From University of Phoenix Online Collection. [ProQuest Digital

Dissertations]. Publication number: AAT 9617262. Available:

http://www.apollolibrary.com:2118/dissertations/fullcit/9617262.)

Leahey, R. (2002). Doc-O-Matic 1.0: generates docs in WinHelp,

RTF, HTML or HTML Help. Delphi Informant. Online. Available:

http://www.delphizine.com/productreviews/2001/07/di200107rl_p/di20010

7rl_p.asp.

Tufflye, D. (2002). How to write, version and file software

development documentation. Online. Available:

http://tuffley.hispeed.com/tcs20006.htm.

Visconti, M.A. (1993). Software system documentation process

maturity model. DAI-B. 55/03. (From University of Phoenix Online

Collection. [ProQuest Digital Dissertations]. Publication number: AAT

9422184. Available:


Wallace, C.R. (2000). Formal specification of software using

abstract state machines. DAI-B. 61/02. (From University of Phoenix Online





Collection. [ProQuest Digital Dissertations]. IBSN: 0–599–63514–2.

Available:





Chương 20: Khảo sát về Năng suất và Chất lượng 713

CHƢƠNG 20 KHẢO SÁT VỀ NĂNG SUẤT VÀ

CHẤT LƢỢNG

Người dịch:





5. Nguyễn Bá Huy





Who among us does not remember the soulful tale of Alice? In her

journey through Wonderland she comes upon the Queen of Hearts who, at

one point in the fantasy, makes sport of the game of chess with live chess

pieces, including our very own Alice. The Queen makes Alice run fast, but

Alice finds that she is merely running in place…running so very fast just

tocatch up.

Không ai trong chúng ta không nhớ đến câu chuyện về Alice? Trong

chuyến đi về Xứ Sở Thần Tiên, cô ấy đã gặp Nữ Hoang Tim, at one point in

fantasy, tạo ra trò chơi với các quân cờ sống, trong đó có cả Alice. Nữ

Hoang bắt Alice chạy thật nhanh nhƣng Alice nhận ra rằng cô ấy chỉ đơn

thuần đang chạy … chạy rất nhanh để đuổi kịp.

Have productivity and quality risen? Or, like Alice, are more and

more firms merely running in place — too tired from continual day to day

operational battles or too shell-shocked from retrenching to support the new

paradigms of client/server architectures, object orientation, and Intranetsto

pay heed to TQM (total quality management)?

Có phải chất lƣợng va năng suất đang tăng nhanh? Hay chỉ nhƣ

Alice, ngay cang nhiều các hãng đang chạy đua – quá mệt mỏi với những





tranh đua ngay nối tiếp ngay hoặc la quá shell-shocked from cắt bớt để hỗ

trợ cho một kiến trúc client/server tiến hóa, hƣớng đối tƣợng,..

Many years ago, sometime in the 1920s, some social scientists were

studying the productivity of workers at a Western Electric plant in

Hawthorne, Illinois. They discovered that when they turned up the lighting,

productivity went up. They also found that when they turned down the

lighting, productivity went up again. What these social scientists found was

that when the Hawthorne workers realized that people were paying

attention to them, they started to do better work. This became known as the

―Hawthorne effect‖.

Nhiều năm về trƣớc, vao khoãng những năm 1920, một số những

nha khoa học xã hội nghiên cứu về năng suất của ong thợ ở Western

Electric Plant ở Illinois. Họ nhận thấy rằng khi tăng tia chớp thì năng suất

tăng. Họ cũng nhận thấy rằng khi giảm tia chớp, năng suất lại tăng lần

nữa.Những nha khoa học nay nhận ra rằng những con ong Hawthrone khi

chúng nhận thấy có nhiều ngƣời quan sát thì năng suất lam việc của chúng

tăng lên. Đây trở thanh hiện tƣợng Hawthorne.

Even though the jury is still out on the effects of quality programs on

the process of information technology, there is no doubt that the industry is

extremely interested in its potential. According to some industry statistics,

less than 5 percent of IT organizations are doing this sort of thing.

Eventhough TQM is strongly rooted in many industries as a whole, for





example, the 60 to 70 percent of those in manufacturing who have some

sort of quality program in place, IT tends to be a black hole.

Mặc dù vẫn chƣa có những nhận xét về chất lƣợng chƣơng trình

trong quá trình công nghệ thông tin nhƣng không có nghi ngờ nao nữa về

việc nền công nghiệp đang rất hứng thú với khả năng của nó.Dựa theo một

số những thống kê của nganh công nghiệp, không quá 5% các tổ chức tin

học đang lam việc nay.Mặc dù TQM đang bắt rễ trong nhiều nganh công

nghiệp, vi dụ nhƣ 60-70% những nganh công nghiệp chế tạo, nơi có những

chƣơng trình chất lƣợng tại chỗ, IT có xu hƣớng la ―lỗ đen‖.

However, interest in the concept is increasing. One should start off

the process by understanding a single principle — that change is painful

and lengthy. In fact, to effectuate any kind of change you need something

like a ten-year plan. Ten years is a long time, however, and management‘s

patience is short. So how can you motivate change over that time period?

Tuy nhiên sự hứng thú trong suy nghĩ đang gia tăng.Chúng ta nên bắt

đẩu quá trình bằng cách hiểu những vấn đề cơ bản nhất –sự thay đổi này

rất cực khổ va mất nhiều thời gian.Trong thực tế, nếu muốn tạo nên sự thay

đổi bạn nên có những thứ nhƣ ―kế hoạch 10 năm‖. 10 năm la khoảng thời

gian dai, tuy nhiên sự kiên nhẫn lại rất it. Vậy bạn tìm nguồn động lực nhƣ

thế nao suốt khoảng thởi gian đó?





20.1 KẾ HOẠCH CHO CHẤT LƢỢNG

The secret is to make management extremely dissatisfied with the

status quo; to do that, you need to look at the cost of the status quo. One

way of accomplishing this is to examine the cost of poor quality.

Bi mật của việc nay la lam cho việc quản lý không thể chấp nhận

tình trạng hiện có. Để lam đƣợc điều nay bạn phải xem xét chi phi của tình

trạng hiện tại.Một cách để lam đƣợc việc nay đó la kiểm tra chi phi của chất

lƣợng thấp.

By answering questions such as ―what are we spending on detecting

defects?‖ and ―what are we spending on repairing defects?‖ the IT

organization can begin to accumulate the statistics it needs to make the push

for change. The data need not be hard to track; in most cases it is already

available through project management systems that track walkthroughs,

reviews, defect rates, etc. About 40 to 50 percent of the IT budget is

spenton fixing defects due to poor quality. With statistics like this, it should

be rather easy to motivate massive change.

Bằng cách trả lời các câu hỏi ―Chúng ta chi trả cái gì để tìm ra thiếu

sót?‖ và ―Chúng ta chi trả cái gì để sữa chữa thiếu sót?‖, các tổ chức tin học

co thể bắt đầu tich lũy các thống kê cần thiết để tạo động lực cho sự thay

đổi.Dữ liệu phải khó để lần dấu vết.Trong nhiều trƣờng hợp, nó phải có sẵn

trong hệ thống quản lý dự án: mức thiếu sót, bản review,…40-50% chi phí





đƣợc chi trả cho việc sữa chữa các thiếu sót bởi vỉ chất lƣợng kém.Với

thống kê nhƣ thế nay, nó sẽ dễ dang hơn cho việc tạo động lực để thay đổi.

Techniques to introduce TQM programs to the ―black hole‖ of IT

vary from company to company, but some commonalities are shown below:

• Conduct a customer satisfaction survey.

• Get management sponsorship to fix what the surveys found wrong.

• Top management needs to make a visible and personal commitment to

any quality program.

• Customers as well as suppliers need to be involved.

• Define the processes.

• Come up with ways to improve the process.

• Determine metrics to measure the improvement of the process.

Các kỹ thuật để giới thiệu TQM với ―lỗ đen‖ của IT đa dạng với các

công ty, những cách phổ biến:

• Khảo sát ý kiến ngƣời dùng

• Sữa chữa những vần đề tìm thấy từ khảo sát





• Khách Hang va Nha Cung Cấp phải cùng tham gia

• Định nghĩa rõ các quá trình.

• Đƣa ra đƣợc cách thức để cải thiện quá trình

• Đƣa ra các luật để đánh giá

In the 1990s Coopers & Lybrand, now PriceWaterhouseCoopers

after a merger, had a substantial TQM federal practice. This group focused

on taking appropriate elements of TQM and applying them to software

delivery organizations. The end result was the development of a specific

methodology for doing that. This methodology provided a framework for

managing continuous improvement for software delivery.

Năm 1990, Cooper va Lybrand tập trung lấy những yếu tố quan

trọng của TQM va áp dụng nó vao các tổ chức sản xuất phần mềm.Kết quả

cuối cùng la sự phát triển một phƣơng pháp mới. Phƣơng pháp nay cung

cấp khung quản lý sự cải thiện liên tục cho sản xuất phần mềm.

This group had first-hand experience of the endemic behaviors in

most of us attracted to this business that are contrary to the quality tenets of

TQM. One of these is the ―code or die‖ syndrome. The greater the deadline

pressures, the more we focus on ―I got to code right now‖. This is a quality

problem because it speaks to the fact that we are generally product oriented

and when the pressure is on we fundamentally have no faith in the process.





However, TQM says if you want to improve the quality of the product, you

focus on improving the process. So this is a behavior that gets us into

trouble every time. In order to combat behaviors that seem to sabotage the

drive toward quality, Coopers & Lybrand modified their four-phase TQM

methodology to suit the tenets of software engineering.

Nhóm nay có kinh nghiệm về cách cƣ xử đặc trƣng của chúng ta khi

kết dinh với công việc cái ma liên quan đến xu hƣớng chấ lƣợng của

TQM.Một trong số đó la ―code or die‖.Áp lực deadline cang lớn, chúng ta

cang tập trung vao việc ―Chúng ta phải code ngay bây giờ‖.Đó la về vấn đề

chất lƣợng bởi vì nó nói đến việc một cách tổng quát, chúng ta la những sản

phẩm hƣớng đối tƣợng. Khi áp lực đến gần, một cách không chủ ý chúng ta

không có niềm tin vao quá trình thực hiện.Tuy nhiên, TQM nói rằng nếu

muốn cải thiện chất lƣợng sản phẩm thì phải tập trung vao cải thiện quá

trình lam.Vì vậy cách ứng xử nay thƣờng xuyên đƣa chúng ta vao những

tình huống rắc rối. Cooper với Lybrand đã đƣa ra phƣơng pháp 4-câu TQM

phù hợp với công nghệ phần mềm

The centerpiece of the assessment phase of the Coopers & Lybrand

methodology is development of metrics by which the quality baseline is

assessed and by which improvements over time can be measured. There is

no specific list of metrics; the choice of metrics depends upon the client

because quality is different things for different people. What you think are

key quality issues should drive what you are trying to measure. In order to

determine the appropriate metrics for any particular client, Coopers





consultants utilized a method first developed by NASA and then put into

the public domain. Called goal–question–metric (GQM), it is a disciplined

technique used to refine from key quality issues their individual

components and, ultimately, the metrics that might be derived from them.

Assesment la sự phát triển các luật ma bằng các luật nay những chất

lƣợng căn bản đƣợc tiếp cận va sự cải tiến về thời gian đƣợc đo đạc.Không

có những luật cụ thể, sự lựa chọn luật tùy thuộc vao client bởi vì chất lƣợng

tùy thuộc vao quan điểm của mỗi ngƣời.Những cái gì ma bạn nghĩ la yêu

cầu chất lƣợng chinh có thể định hƣớng cách bạn đánh giá.Để đƣa ra đƣợc

cách đánh giá cho bất kỳ client nao, Cooper va Lybrand đã lấy phƣơng

pháp đƣợc phát triển bởi NASA đƣa vao sữ dụng gọi la GQM(Goal

Question Metric). Phƣơng pháp nay đƣa ra các yêu cầu chất lƣợng khóa và

những yêu cầu chất lƣợng dẫn xuất từ đó.

The second phase of the Coopers methodology, planning, is based

on what we see today, our vision, or where we want to take ourselves. Here

we look at the highest priority quality issues and think about what we want

to do to build ourselves in that direction. The ―plan‖ developed is actually a

short list of things to do over the next six months. This is actually a list of

―low-hanging fruit‖— the list must contain the greatest near-term opportu

nities to increase quality.

Planning dựa trên những thứ chúng ta thấy ngay nay hoặc la nơi

chúng ta muốn đến.Ở đây chúng ta xem xét vấn đề chất lƣợng có độ ƣu tiên





cao nhất va nghĩ xem chúng ta sẽ thực hiện theo hƣớng đó thế nao. ‖Kế

hoạch‖sẽ la danh sách những công việc sẽ lam trong vòng 6 tháng tới.Danh

sách phải có cơ hội gần có thể cải thiện chất lƣợng.

The third phase, process improvement, is actually a phase of

experimentation. It is here that the low-hanging fruit can be picked, and if

determined not to have any nutritive value to the process, tossed quickly

aside. Finally, in the fourth phase of the Coopers TQM methodology,

integration, the best things from these experiments are built into the

organization.

Progress improvement thực chất nói về kinh nghiệm. Ở đây những

―low-hanging fruit‖ đƣợc chọn va nếu đã quyết định không chọn những

thực phẩm dinh dƣơng thi hãy nhanh chóng đế nó sang một bên.

Intergration chọn lựa những thứ tốt nhất từ kinh nghiệm để xây dựng

vao tổ chức

20.2 QUÁ TRÌNH ĐÁNH GIÁ

Organizations that apply measure productivity and quality do so for

the same reasons. Software is becoming more complex and user demands

and expectations are increasing. The need to develop better software, faster,

translates to a need to quantify the project‘s progress and the system‘s

attributes.





Những tổ chức áp dụng sự đánh giá về chất lƣợng va năng suất đều

có cùng mục đich.Phần mềm ngay cang trở nên phức tạp, yêu cầu ngƣời

dùng ngày càng cao. Nhu cầu phát triển phần mềm nhanh chóng hơn, tốt

hơn chuyển thanh nhu cầu định lƣợng lại thời gian thực hiện phần mềm va

các thuộc tinh hệ thống.

A variety of productivity and quality metrics are available; choosing

the most appropriate one can be as tricky as picking winning lottery

numbers:

• Lines of code

• Pages of documentation

• Number and size of texts

• Function count

• Variable count

• Number of modules

• Depth of nesting

• Count of changes required

• Count of discovered defects





• Count of changed lines of code

• Time to design, code, test

• Defect discovery rate by phase of development

• Cost to develop

• Number of external interfaces

• Number of tools used and why

• Reusability percentage

• Variance of schedule

• Staff years of experience with team

• Staff years of experience with language

• Staff years of experience with software tools

• MIPs per person

• Support to development personnel ratio

• Nonproject to project time ratio





Có nhiều tiêu chi đánh giá, chọn ra tiêu chi thich hợp nhất cũng

giống nhƣ chọn ra ngƣời thắng cuộc trong cuộc thi bốc thăm:

• Những dòng code

• Những trang tai liệu

• Kich thƣớc dữ liệu text

• Số Function

• Số Biến

• Số lƣợng Modules

• Độ sâu của Nesting

• Số lƣợng thay đổi yêu cầu

• Số lƣợng sai sót tìm thấy

• Số lƣợng dòng code thay đổi

• Thời gian thiết kế, code, kiểm tra

• Mức độ sai sót tìm thấy

• Chi phi phát triển





• Số lƣợng giao diện

• Số lƣợng tool sử dụng va tại sao

• Khả năng tái sử dụng

• Kinh nghiệm về nhóm củ nhân viên

• Kinh nghiệm về ngôn ngữ của nhân viên

• Kinh nghiệm về sử dụng các công cụ phần mềm

• MIPs per person

Measuring does have its detractors. Many ―artists‖ still refuse to be

measured. Ironically, measuring often produces the unusual effect of

increasing productivity only in the areas that are measured.

Sự đánh giá có thể có những bất lợi. Có rất nhiều ‖nghệ sĩ‖ tránh bị

phê bình. Sự đánh giá thƣờng tạo ra năng suất chỉ trong phạm vi đƣợc đánh

giá.

In most situations, the term ―metric‖ is used in conjunction with the

pro gramming process only. However, programming is the smallest part of

the systems development life cycle. For an effective measurement program,

each component of the cycle must include its own measures — or a mea

sure must be used that encompasses the entire spectrum of development.





Trong nhiều trƣờng hợp, thuật ngữ‖tiêu chi‖ chỉ đƣợc sữ dụng nhƣ

sự kết nối quá trình lập trình..Tuy nhiên lập trình chì la một phần nhỏ trong

vòng đời phát triển hệ thống.Để có chƣơng trình đánh giá chinh xác,mỗi

thanh phần phải có những đánh giá của riêng nó.

The software development process is one of the most complex

processes a human can perform; it includes numerous formidable tasks.

Although variations abound in the number of executable steps in a life

cycle, most IT organizations perform the same functionality.

Quá trình phát triển phần mềm la một trong những quá trình phức tạp

nhất ma con ngƣời có thể thực hiện đƣợc.Nó bao gồm nhiều công việc ghê

gớm.Mặc dù có rất nhiều cách để phát triển trong vòng lặp phát triển, đa số

các tổ chức đều thực hiện nhƣ nhau.

Metrics must consider several esoteric items, such as user

involvement, which is positively correlated with productivity increases.

Human factors must also be taken into account, such as the square footage

allocated per programmer. Capers Jones, a prominent researcher in this

field, has shown that a full 78 square feet of floor space increases

programmer productivity more than any application development tool.

Design, programming, and quality factors must also be weighed.

Các tiêu chi có rất nhiều thanh phần riêng tƣ, vi dụ nhƣ sự tham gia

của ngƣời dùng cái ma liên kết chặt chẽ đến việc lam tăng năng suất.Yếu tố





con ngƣời cũng đƣợc xem xét đến. Thiết kế, lập trình va nhân tố chất lƣợng

cũng đƣợc xem xét đến.

Quality measurements are frequently overlooked in the race to imple

ment on or before deadline. However, no matter what the time pressure,

certain measures undertaken seriously can enhance the quality of output of

any software investment. The following matrix has proven useful when

filled out by end users:

Đánh giá về chất lƣợng luôn để mắt đến đến quá trình trƣớc khi gặp

deadline.Tuy nhiên, dù áp lực có nhiều nhƣ thế nao, sự đánh giá đúng đắn luôn

ảnh hƣởng đến chất lƣợng đầu ra của bất kỳ sự đầu tƣ phần mềm nao.. Những

câu hỏi sau tỏ ra hiệu quả khi đƣợc ngƣời dùng đánh giá:





Measurement of quality is often thought of as a manufacturing

process. Computer companies that manufacture hardware and software

usually apply metrics to the manufacture of both. Digital Equipment,

acquired by Compaq, which itself was acquired by HP in 2002, was famous

for its software quality controls. DEC ran upward of 22,000 quality checks

on the VAX Cobol compiler (Compaq recently retired the VAX computer

in favor of its Alpha server (http://www.compaq.com/alphaserver/vax/).

With 22,000 tests, it was impossible to test the compiler thoroughly, so

DEC wrote VaxScan, which looked at many micro-oriented measures such

as rate of change and how much the program was tested. It also measured

the introduction of new errors.

Sự đánh giá về chất lƣợng thƣờng đƣợc cho la quá trình công nghiệp.

Những công ty máy tinh sản xuất phần mềm va phần cứng thƣờng áp dụng

tiêu chi để đánh giá cả hai.

20.3 ĐỘ ĐO GỐC

Those who measure most often use a simple source-lines-of-code

(SLOC) metric. With this metric, however, there is room for variation. In

their 1986 book, Software Engineering Metrics and Models, published by

the Benjamin/Cummings Publishing Company, Conte, Dunsmore, and Shen

proposed this definition of SLOC:


http://www.compaq.com/alphaserver/vax/




A line of code is any line of program text that is not a comment or

blank line, regardless of the number of statements or fragments of

statements on that line. This specifically includes all lines containing

program headers, declarations and executable and nonexecutable

statements. The SLOC metric is often further redefined into distinguishing

the number of noncomment source lines of code (NCSLOC) from the lines

of code containing comment statements (CSLOC).

Những ngƣời đánh giá thƣờng sử dụng nhiều nhất la SLOC(source-

line-of-code).Với hệ thống nay, tuy nhiên, có chỗ cho sự đa dạng.Trong

cuốn sách năm 1986, ―Software Engineering Metrics and Models” xuất bản

bởi Benjamin/Cummings Publishing Company, Conte, Dunsmore, and

Shen đã định nghĩa SLOC: ―Line of code la những dòng chƣơng trình

không phải la dòng ghi chú hoặc để trống. Bao gồm tất cả các dòng header,

giải thich, những câu biên dịch va không biên dịch đƣợc‖. Đƣợc định nghĩa

va chia lam 2 loại NCSLOC(noncomment source line of code) va CSLOC

(comment source line of code).

Along with SLOC measurements, the weekly time sheet provides

other gross statistics often used for productivity measurement. The total

number of labor hours expended, divided by the total number of NCSLOC,

provides an overall statistic that can be used to compare productivity

fromproject to project.





Bên cạnh SLOC, những bảng thời gian tuần cung cấp những thống

kê cần thiết cho sự đánh giá.Tổng thời lƣợng lam việc chia cho tồng số

NCSLOC, cung cấp thống kê có thể sử dụng để so sánh năng suất dự án nay

vớ dự án khác.

One problem with the SLOC measurement is that it does not take

into account the complexity of the code being developed or maintained.

Lines of code and man-months hide some very important things. For

example, the SLOC measurement for a name and address file update

program mightbe 600 lines of code per day. On the other hand, the output

for software that tracks satellites might be in the range of 40 to 50 lines of

code per day. To look at this output on a purely gross statistical level, one

would con clude that the name and address project was more productive

and efficient than the satellite project. This conclusion would be wrong.

Starting from this base, two researchers at the Massachusetts

Institute of Technology‘s Center for Information Systems Research in

Cambridge, Massachusetts, examined this complexity issue. Chris F.

Kemerer and Geoffrey K. Gill studied the software development projects

undertaken by an aerospace defense contracting firm from 1984 to 1989.

The Kemerer and Gill team began their research by reviewing the

original measure for complexity as developed by Thomas McCabe, now

president of McCabe & Associates, a Columbia, Maryland, consulting

group, inhis article, ―A Complexity Measure‖. McCabe proposed that a





valid measurement of complexity would be the number of possible paths in

a software module. In 1978, W.J. Hansen in his article, ―Measurement of

Program Complexity by the Pair‖, interpreted McCabe‘s mathematical

formula into four simple rules that would produce a numerical measure of

complexity (i.e., the higher the number, the more complex):

• Add 1 for every IF, case, or other alternate execution construct.

• Add 1 for every iterative DO, DOWHILE, or other repetitive construct.

• Add 2 less than the number of logical alternatives in a case.

• Add 1 for each AND or OR in an IF statement.

Một vấn đề với cách đánh giá SLOC la nó không đƣa vao tai khoản

sự phức tạp của những dòng code đƣợc phát triển hay duy trì. Những dòng

code và man-months che giấu những điều rất quan trọng. Vi dụ, cách đo

đạc SLOC cho chƣơng trình cập nhật tên va địa chỉ có thể có 600 dòng

code 1 ngay. Mặt khác, đầu ra của phần mềm lƣu vết vệ tinh có thể trong

khoảng 40-50 dòng code 1 ngay. Xem xét đầu ra nay ở mức độ thống kế

chéo thuần túy, 1 ngƣời có thể kết luận rằng đối tƣợng tên va địa chỉ hiệu

quả hơn dự án về vệ tinh.Nhận định nay có thể sai. Bắt đầu từ điều nay, 2

nha nghiên cứu ở học viện the Massachusetts Institute of Technology‘s

Center for Information Systems Research in Cambridge,Massachusetts đã

nghiên cứu về vấn đề phức tạp nay.. Chris F. Kemerer and Geoffrey nghiên

cứu về dự an phát triển phẩn mềm từ năm 1984 đến 1989. Nhóm bắt đầu





nghiên cứu bằng cách xem xét lại những đánh giá nguyên mẫu cho sự phức

tạp đƣợc phát triển bởi ThoMas McCabe, hiện nay la chủ tịch của McCabe

& Associates, a Columbia, Maryland trong bài báo ―A Complexity

Measure‖. McCabe nhận định rằng một sự đánh giá chinh xác về độ phức

tạp la số lƣợng những con đƣờng có thể dùng trong module phần mềm.

Năm 1978 W.J. Hansen trong bai báo, ―Measurement of Program

Complexity by the Pair‖, đã diễn tả lại công thức phức tạp của ông

bằng 4 quy luật.

• Cộng 1 cho mỗi IF,CASE,hoặc những cấu trúc thực thi thây thế khác.

• Cộng 1 cho mỗi lần lập DO, DOWHILE, hoạc những cấu trúc lập khác

• Cộng 2 it số lƣợng thây thế logic trông mỗi case.

• Cộng 1 cho mỗi AND hoặc OR trong 1 câu lệnh IF.





Hewlett Packard TQC Metrics

Chuẩn đo Đich đến

Thời gian hoan vốn Thời gian cho tới khi chi phi

phát triển đƣợc bù đắp bởi lợi nhuận

Thời gian đến thị trƣờng Các biện pháp đáp ứng va khả

năng cạnh tranh thời gian dự án phát

triển cho tới khi bán ra thị trƣờng

Tiến độ tye lệ Các biện pháp chinh xác của

lịch trình,lên kế hoạch cho thời gian

phát triển thực tế





Post-release defect density Các biện pháp hiệu quả của

quá trình thử nghiệm,tổng số khiếm

khuyết trong báo cáo 12 tháng đầu

tiên sau khi sản phẩm phát hanh

Tỷ lệ doanh thu Các biện pháp tinh thần,tỷ lệ

phần trăm nhân viên còn lại

Đao tạo Các biện pháp đầu tƣ,phát

triển sự nghiệp,số giờ trong một năm

The results of the Kemerer and Gill study showed that increased

software complexity leads to reduced productivity. They recommended

using more experienced staff and reducing complexity of the individual

software module. To reduce complexity, they suggest establishing a

complexity measure that could be in use as the code is written and then

adhering to this preset standard.

Kết quả của Kemerer and Gill nghiên cứu cho thấy sự tăng lên của

sự phƣớc tạp phần mềm dẫn tới khả năng sản xuất giảm,Họ đề nghị sử dụng

đội ngũ nhân viên giau kinh nghiệm hơn,giảm tinh phƣớc tạp của các đơn

vị đo phần mềm riêng.Để giảm phƣớc tạp,họ đề nghị thiết lập một biện

pháp phƣớc tạp có thể sử dụng nhƣ la mã va sau đó tuân thủ cái chuẩn đã

đƣợc đặt trƣớc.





20.4 CÁCH CỦA HP

Quality and productivity have been an explicit part of Cupertino,

Califor nia-based, Hewlett Packard‘s (HP) corporate objectives. To help

develop and utilize company-wide metrics, HP created the software metrics

council. Today, dozens of productivity and quality managers within HP

perform a variety of functions, from training to communicating the best

software engineering practices to establishing productivity and quality

metrics.

HP đã tiếp nhận phƣơng pháp gọi la ―kiểm soát toan bộ chất lƣợng‖

(TQC – total quality control), một nguyên tắc cơ bản của phƣơng pháp nay

la tất cả các hoạt động của công ty có thể đƣợc nghiên cứu kĩ lƣơng trong

những lĩnh vực liên quan. Các chuẩn có thể đƣợc gán cho mỗi quá trình để

đánh giá tinh hiệu quả.

HP has adopted a methodology called total quality control (TQC). A

fun damental principle of TQC is that all company activities can be

scrutinized in terms of the processes involved; metrics can be assigned to

each process to evaluate effectiveness. HP has developed numerous

measurements, as shown in Exhibit 20-1.

The TQC approach places software quality and productivity

assessment high on the list of software development tasks. When projects





are first defined, along with understanding and evaluating the process to be

automated, the team defines the metrics to be used to measure the process.

Cách tiếp cận TQC đặt chất lƣợng phần mềm va đánh giá năng suất

cao nhất trong những tác vụ của việc phát triển phần mềm. Khi những dự

án lần đầu tiên đƣợc phát triển, cùng với việc hiểu va đánh giá quá trình

một cách tự động, toan đội phát triển phải đề ra những tiêu chuẩn để đánh

giá cả quá trình.

When HP decided to revolve the future of the company around

Riscbased architecture in the 1990s, software reliability was deemed

critical. The development of the systems software was the largest

development effort in HP‘s history, and the first that required multiple

divisions to produce software that would be combined into a single

software system.

Khi HP quyết định xác định tƣơng lai của công ty vao kiến trúc Risc

vao những năm 1990, độ tin cậy của phần mềm đƣợc cho la điều kiện tiên

quyết. Sự phát triển của những hệ thống phần mềm la những nỗ lức lớn

nhất trong lịch sử HP, va điều đầu tiên yêu cầu sự phân chia phức tạp để

sản xuất phần mềm đó la sự kết hợp vao trong một hệ thống phần mềm

(???)

Charles A. Krueger, a professor at the University of Wisconsin in

Madison, has pointed out the productivity paradox of budget versus getting





to market: is it more important to stay within the targeted confines of

money allocated, or to get the product out on time? He quotes a McKinsey

& Co. study indicating that going over budget by 50 percent and getting a

product out on time reduces profits by only 4 percent. Staying on budget

and getting to market five months late reduces profits to a third. Krueger

insists that productivity is really a measure of how successfully you achieve

your results.

Charles A. Krueger, giáo sƣ đại học Wisconsin ở Madison đã chỉ ra

sự nghịch lý: việc phân phối ngân quỹ có quan trọng hơn việc phát hanh sản

phẩm ra đúng thời gian hay không? Nghiên cứu đã chỉ ra rằng chi tiêu vƣợt

ngân quỹ 50% va phát hanh sản phẩm trễ chỉ giảm lợi nhuận 4%. Giữ đúng

ngân quỹ va phát hanh sản phẩm trễ 5 tháng thì lợi nhuận giảm đi 1/3.

Krueger quả quyết rằng năng suất thực sự la 1 thƣớc đo độ thanh công đối

với sản phẩm của bạn.

Hewlett-Packard came to the same conclusion as Krueger, so the

com pany insisted on reliable software and delivery on time. HP established

the systems software certification program to ensure measurable, consistent,

high-quality software through defining metrics, setting goals, collecting and

analyzing data, and certifying products for release. This program developed

four metrics for the Risc project:

Hewlett-Packard có cùng kết luận với Krueger, vì vậy công ty khẳng

định trên việc phần mềm đáng tin cậy va phát hanh đúng thời điểm. HP





thực thi chƣơng trình chứng nhận hệ thống phần mềm để đảm bảo cho một

hệ thống phù hợp va có chất lƣợng cao thông qua việc định nghĩa các

chuẩn, đặt ra mục tiêu, thu thập va phân tich dữ liệu, chứng nhận sản phẩm

để phát hanh. Chƣơng trình nay phát triển 4 chuẩn cho dự án Risc:

• Breadth Ñ measures the testing coverage of user-accessible and internal

functionality of the product.

• Depth Ñ measures the proportion of instructions or blocks of

instructions executed during testing.

• Reliability Ñ measures the stability and robustness of a product and its

ability to recover gracefully from error conditions.

• Defect density Ñ measures the quantity and severity of reported defects

and a product‘s readiness.

• Rộng: dự tinh việc kiểm tra mức độ bao phủ của những ngƣời dùng có

thể sử dụng đƣợc va các chức năng bên trong của sản phẩm.

• Sâu: dự tinh những phần chỉ dẫn hoặc những khối chỉ dẫn đƣợc thực thi

trong suốt quá trình kiểm tra.

• Độ tin cậy: đo lƣờng tinh ổn định của phần mềm cũng nhƣn khả năng

phục hồi trong điều kiện lỗi.





• Mật độ khuyết điểm: dự tinh số lƣợng va tinh nghiêm trọng của những

báo cáo khuyết điểm va sự sẵn sang của sản phẩm.

HP‘s results were impressive. Defects were caught and corrected

early, when costs to find and fix are lower. Less time was spent in the costly

system test and integration phases, and on maintenance. This resulted in

lower overall support costs and higher productivity. It also increased quality

for HP‘s customers.

HP‘s success demonstrates what a corporate-wide commitment to

productivity and quality measures can achieve. The commitment to these

gains was so strong that HP invested in full-time productivity and quality

managers, which is indeed unique.

Kết quả của HP la rất ấn tƣợng. Những lỗi đƣợc phát hiện va sửa

chữa kịp thời, trong khi chi phi để tìm va sửa lỗi la thấp. Tốn it thời gian

hơn cho hệ thống kiểm thử va duy trì. Kết quả nay đã nâng cao năng suất va

giảm chi phi cho việc phát triển sản phầm, cũng đồng thời nâng cao chất

lƣợng cho những khách hang của HP.

20.5 THE FUNCTION POINT ADVANTAGE

In 1983, A.J. Albrecht, with IBM at that time, first proposed the

function point concept in a paper called ―Software Function, Source Lines

of Code and Development Effort Prediction: a Software Science





Validation‖. This metric is a combination of metrics that assesses the

functionality of the development process (see Appendix S for a more

detailed description).

Vao năm 1983, A.J.Albrecht, lam việc cho IBM trong thời gian đó,

lần đầu tiên đề xuất khái niệm ―function point‖ trong một bai báo có tựa đề

―Phần mềm chức năng, những dòng mã nguồn va việc dự đoán quá trình

phát triển: một phần mềm đánh giá khoa học‖ (Software Function, Source

Lines of Code and Development Effort Prediction: a Software Science

Validation.). Chuẩn nay la một sự kết hợp giữa những tiêu chuẩn đánh giá

chức năng của quá trình phát triển (xem phụ lục S).

The function-point metric assesses the functionality of the software

development process by first counting the number of external inputs

(transaction types), external outputs (report types), logical internal files

(nonphysical), external interface files (files accessed by the application but

not maintained or updated by it), and external inquiries.

Những tiêu chuẩn Function Point đánh giá chức năng của quá trình

phát triển phần mềm trƣớc tiên bằng việc tinh toán số lƣợng những dữ liệu

nhập từ ngoai (giao tác) va kết quả xuất ra ngoai (báo cáo), tập tin logic bên

trong, tập tin giao diện bên ngoai (những tập tin đƣợc truy xuất bởi ứng

dụng nhƣng không đƣợc duy trì hoặc cập nhật bởi nó), va những yêu cầu ở

ngoài.





Using a set of standards for assessing complexity, these components

are then classified as relatively low, average, or high. Once the total number

of function counts is computed according to a statistical formula, the second

step assesses the impact of 14 general system characteristics:

• Data communications

• Distributed functions

• Performance

• Heavily used configuration

• Transaction rate

• Online data entry

• End-user efficiency

• Online update

• Complex processing

• Reusability

• Installation ease

• Operational ease





• Multiple sites

• Facilitates change

Sử dụng một tập những tiêu chuẩn để đánh giá độ phức tạp, những

nhân tố nay sau đó đƣợc phân loại nhƣ tƣơng đối thấp, trung bình hay cao

(ảnh hƣởng của nhân tố đánh giá độ phức tạp). Sau khi tinh toán tổng số

chức năng dựa trên các công thức thống kê, bƣớc thứ 2 la đánh giá tác động

của 14 đặc trƣng chung của hệ thống:

• Giao tiếp dữ liệu.

• Các chức năng phân phối.

• Biểu diễn.

• Sử dụng nhiều cấu hình.

• Tỷ lệ giao tác.

• Trƣờng dữ liệu trực tuyến.

• Hiệu quả ngƣời dùng cuối.

• Cập nhật trực tuyến.

• Độ phức tạp của xử lý.





• Khả năng tái sử dụng.

• Dễ cai đặt.

• Dễ hoạt động.

• Nhiều trang.

• Thay đổi dễ dang.

These values are then summed to compute what is known as the

value adjustment factor (VAF). The VAF is then multiplied with the total

function count to create the number of function points.

Những giá trị nay sau đó đƣợc cộng lại để tinh toán những gì đƣợc

biết những la những giá trị điều chỉnh yếu tố. Giá trị điều chỉnh yếu tố sau

đó đƣợc nhân với tổng số chức năng để cho ra tổng số function point.

The one aspect of function-point measurement programs that makes

them so valuable is the presence of large databases of information that

companies can use for comparison. SPR (www.spr.com), for example,

maintains a database of over 9000 completed projects. It is used to compare

an organization to industry norms — i.e., a benchmark.

Một phƣơng diện khác của chƣơng trình đánh giá function point ma

lam cho chúng có giá trị hơn la sự hiện diện của những cơ sở dữ liệu thông

tin lớn ma những công ty có thể sử dụng để so sánh. Vi dụ SPR duy trì một





CSDL của hơn 9000 dự án đã hoan tất. Những cái nay đƣợc sử dụng để so

sánh một tổ chức của những chỉ tiêu công nghiệp.

Aside from these external comparative databases, many in-house

databases have been painstakingly accumulated. As Kemerer states in his

thesis, ―from a control perspective, organizations using a variant method

would have difficulty in comparing their function-point productivity rates to

those of other organizations that switched methods; the new data might be

sufficiently inconsistent as to render trend analysis meaningless‖.

Bên cạnh những CSDL so sánh ngoai đó, nhiều dữ liệu nội bộ đã

đƣợc cẩn thận tich lũy. Nhƣ Kemerer đã trình bay trong luận cƣơng của ông

ta: ―từ một phƣơng diện điều khiển, những tổ chức sử dụng một phƣơng

pháp không ổn định thƣờng gặp phải những khó khăn trong việc so sánh tỷ

lệ năng suất function point với những tổ chức dùng những phƣơng pháp

chuyển đổi, dữ liệu mới có vẻ đầy đủ nhƣng không phù hợp cũng nhƣ

những biểu đồ phân tich vô nghĩa‖.

Most people are using the function point metric because it offers the

only metric that comes close to matching the economic definition of

productivity — costs or services produced per unit of labor and expense. In

the 1990s, using Capers Jones‘ SPR research base of 400 studied

companies, the national average was calculated to be five function points

per person-month; IT groups averaged eight function points per person

month. These numbers can dramatically increase with tool usage to the





degree that it is possible to achieve 65 function points per person-month

with a full application tool environment and reusable code. This metric will

decrease when the development environment is new, but will regain

momentum when familiarity with the tool set increases.

Hầu hết những ngƣời sử dụng chuẩn function point bởi vì nó nó đƣa

ra chỉ những tiêu chuẩn ma gần với định nghĩa năng suất trong kinh tế - giá

cả va dịch vụ sản xuất đƣợc trên mỗi đơn vị lao động va chi phi. Vao thập

niên 90, việc sử dụng nghiên cứu SPR của Capers Jones đã đƣợc xem xét

trong 400 công ty, trung bình quốc gia tinh đƣợc la 5 function point trên

một ngƣời – tháng. Lam việc theo nhóm la 8 function point trên một ngƣời

– tháng. Những con số nay có thể tăng một cách nhanh chóng với việc áp

dụng những công cụ môi trƣờng ứng dụng va mã sử dụng lại. Tiêu chuẩn

nay sẽ giảm nếu môi trƣờng ứng dụng la mới, nhƣng sẽ tăng lên nhanh

chóng ngay sau đó.

American Management Systems was an early believer in the

functionpoint concept. With over 2200 systems professionals supporting 28

product lines, AMS needed a methodology that worked. The company had

been measuring productivity for years, but found that its traditional metrics

of lines of code and work-months was hiding some very important

information: not all work-months are created equal. The problem was that

there are experienced people and not so experienced people, expensive

people and not so expensive people. If the company could find a way of

optimizing this mix, then AMS would find increased productivity. To this





end, AMS needed a measure that would foster economic productivity.

Function points filled the bill.

Hệ thống quản lý của ngƣời Mỹ đã sớm đặt niềm tin vao khái niệm

function point. Với hơn 2200 hệ thống chuyên nghiệp hỗ trợ 28 dòng sản

phầm, AMS cần một phƣơng pháp lam việc. Các công ty đã đo lƣờng năng

suất lam việc trong nhiểu năm, nhƣng nhận ra rằng những tiêu chuẩn truyền

thống nhƣ số dòng code va việc – tháng đã giấu đi một vai thông tin rất

quan trọng: không phải tất cả công việc – tháng đều đƣợc tạo ra một cách

công bằng. Vấn đề la có những ngƣời có giá trị va những ngƣời không có

giá trị, có giá trị it hay nhiều. Nếu công ty có thể tìm ra một cách tối ƣu

những thứ trộn lẫn đó, thì sẽ tìm ra đƣợc cách để tăng năng suất. Cho vấn

đề nay, ASM cần một biện pháp có thể nuôi dƣơng năng suất kinh tế.

Function point có thể đáp ứng những đòi hỏi nay.

Function points were created in an era prior to the Internet and prior

to the introduction of object-oriented systems. As technologies and

methodologies must grow to meet new business requirements, so too must

our metrics.

Dr. Chris Kemerer, now at the University of Pittsburgh, but then a

professor at MIT‘s prestigious Sloan School of Management, wrote a paper

entitled, ―Towards a Metrics Suite for Object-Oriented Design‖. This paper,

authored with Dr. Shyam Chidamber, was presented at the October, 1991,

ACM OOPSLA conference (object-oriented programming, systems,





languages, and applications). Kemerer asserts his position as perhaps the

first person to talk about measurement for object-oriented systems and

proposes a series of six metrics that serve to measure the depth and breath

of object-oriented design:

Function point đƣợc tạo ra trong thời đại thiên về Internet va việc

giới thiệu các hệ thống hƣớng đối tƣợng. Khi những kĩ thuật va những

phƣơng pháp phát triển để theo kịp các yêu cầu về kinh tế thì cũng có nhiều

việc phải lam với các tiêu chuẩn.

Giáo sƣ Kemerer đã viết một bai báo với tiêu đề ―Hƣớng đến một

chuẩn mới cho thiết kế hƣớng đối tƣợng‖ đề xuất một chuỗi 6 tiêu chuẩn

đƣợc sử dụng cho việc tinh toán độ sâu va rộng của thiết kế hƣớng đối

tƣợng:

• Metric 1: WMC (weighted methods per class). This relates to the

definition of complexity of an object. The number and complexity of

methods involved are indicators of how how much time and effort is

required to develop and maintain the object.

• Chuẩn 1: WMC (weighted methods per class) liên quan đến định nghĩa

độ phức tạp của một đối tƣợng. Số phƣơng thức va độ phức tạp của nó

đƣợc xác định thông qua việc mất bao nhiêu thời gian va công sức để

phát triển va duy trì đối tƣợng.





• Metric 2: DIT (depth of inheritance tree). DIT is a measure of how

many ancestor classes can potentially affect a class. It is useful to have

a measure of how deep a particular class is in the hierarchy so that the

class can be designed with reuse of inherited methods.

• Chuẩn 2: DIT (depth of inheritance tree) tinh toán bao nhiêu lớp cha có

tiềm năng ảnh hƣởng tới một lớp. Vấn đề nay hữu dụng để đo độ sâu

của một lớp riêng biệt trong một hệ thống cấp bậc để lớp nay có thể

đƣợc thiết kế với phƣơng pháp sử dụng lại hoặc kế thừa.

• • Metric 3: NOC (number of children). NOC is a measure of

how many subclasses will inherit the methods of a parent class. NOC

gives an idea of the potential influence a class has on the design. If a

class has a large number of children, it may require more testing of the

methods in that class.

• Chuẩn 3: NOC (number of children) để tinh toán xem bao nhiêu lớp

con sẽ kế thừa các phƣơng thức của lớp cha. NOC đƣa ra một ý tƣởng

của tiềm năng ảnh hƣởng của một lớp có trong thiết kế (các lớp con có

thể sử dụng các phƣơng thức của nó). Nếu một lớp có một lƣợng lớn

các lớp con, sẽ có nhiều yêu cầu kiểm tra hơn đối với các phƣơng thức

của lớp đó.

• Metric 4: CBO (coupling between objects). This is a count of the

number of noninheritance-related couples with other classes. Excessive





coupling between objects outside the inheritance hierarchy is

detrimental to modular design and prevents reuse. This measure is

useful to determine how complex the testing of various parts of the

design is likely to be

• Chuẩn 4: CBO (coupling between objects). Đây la một tinh toán trên số

lƣợng các mối liên hệ liên quan đến không kế thừa của những lớp khác

nhau. Mối quan hệ quá mức giữa các đối tƣợng bên ngoai cấu trúc kể

thừa gây bất lợi cho việc thiết kế các module va việc tái sử dụng. Cách

đo nay la hữu dụng cho việc xác định độ phức tạp của việc testing

nhiểu phần khác nhau của thiết kế.

• Metric 5: RFC (response for a class). The response set is a set of meth

ods available to the object. Because it specifically includes methods

called from outside the object, it is also a measure of communication

between objects. If a large number of methods can be invoked, the

testing and debugging of the object become more complicated.

• Chuẩn 5: RFC (response for a class). Tập các phản hồi la một tập các

phƣơng pháp có giá trị đối với đối tƣợng. Bởi vì nó bao gồm một cách

cụ thể các phƣơng pháp đƣợc gọi bên ngoai đối tƣợng, đồng thời nó

cũng la một cách tinh toán việc giao tiếp giữa các đối tƣợng. Nếu một

số lƣợng lớn phƣơng thức yêu cầu quá trình nay, việc kiểm thử va tìm

lỗi của một đối tƣợng trở nên phức tạp hơn nhiều.





• Metric 6: LCOM (lack of cohesion in methods). LCOM uses the notion

of degree of similarity of methods. Fewer disjoint sets imply greater

similarity of methods. Cohesiveness of methods within a class is

desirable because it promotes encapsulation of objects.

• Chuẩn 6: LCOM (lack of cohension in methods) sử dụng khái niệm độ

giống nhau giữa các phƣơng thức. Sự liên quan giữa các phƣơng thức

trong một lớp la cần thiết bởi vì nó lam cho quá trình đóng gói đối

tƣợng trở nên chặt chẽ hơn.

It is easy to pinpoint how Kemerer‘s metrics differ from

conventional measurements. Object-oriented metrics are specifically

oriented to object oriented methodologies, which are quite different from

conventional meth odologies. The notion is to try to go after those things

that are different about the object-oriented approach.

Thật la dễ dang để xác định sự khác nhau giữa các tiêu chuẩn của

Kemerer va cách tinh toán thông thƣờng. Các tiêu chuẩn hƣớng đối tƣợng

la hƣớng đến các phƣơng pháp hƣớng đối tƣợng một cách cụ thể, đây la

điểm khác biệt so với cách thông thƣờng.

The easiest one to explain to most people is the notion of inheritance.

Our metric is to measure depth of inheritance. In this way we can determine

to what degree people are using inheritance. The goal here is to address the

optimal mix between complexity and usability. When a programmer uses





no inheritance, then he is not taking advantage of reusability and therefore

negates productivity gains of the object-oriented technique. When the

programmer ―goes really deep‖, this may also be bad because it will be hard

to test. Indeed it may be too much for one person to keep in mind.

Cách dễ nhất để giải thich cho hầu hết mọi ngƣời la khái niệm kế

thừa. Tiêu chuẩn của chúng la la đo độ sâu của việc kế thừa. Trong cách

nay chúng ta có thể xác định mức độ ma ngƣời ta đang sử dụng kế thừa.

Mục đich ở đây la để giải quyết tối ƣu sự trộn lẫn giữa độ phức tạp va tinh

tiện dụng. Khi một lập trình viên không sử dụng kế thừa, anh ta không biết

đến khả năng sử dụng lại (reusability) do đó không tận dụng đƣợc năng suất

đạt đƣợc của việc sử dụng kĩ thuật hƣớng đối tƣợng.

20.6 CÂN BẰNG CHẤT LƢỢNG

Quality and productivity are tightly linked; the approaches used to

address these issues — metrics, methodology, and tools — must be

interconnected. Simply throwing technology or methodology at the problem

is not enough. Information technology (IT) departments must also use

―peopleware‖ solutions (Exhibit 20-2.).

Chất lƣợng va năng suất có rang buộc chặt chẽ với nhau: những cách

tiếp cận đã từng đƣợc sử dụng để giải quyết những vấn đề nay (chất lƣợng,

năng suất) la đo lƣờng (metrics), các phƣơng pháp (methodology) va các

công cụ (tools) phải có mối quan hệ với nhau. Nói một cách đơn giản hơn





la việc sử dụng các phƣơng pháp va kĩ thuật để giải quyết vấn đề la chƣa

đủ. Công nghệ thông tin phải cần đến giải pháp con ngƣời.

Ed Yourdon (www.yourdon.com), an esteemed software guru, says

that one way to improve development is to hire better developers. This

solution is the closest thing to a silver bullet.

Ed Yourdon, một chuyên gia phần mềm có tiếng đã nói rằng có một

cách để cải thiện quá trình phát triển la thuê những lập trình viên giỏi hơn.

Giải pháp nay la cách gần nhất với cái gọi la ―viên đạn bạc‖ (silver bullet).

Rather than spend lots of money trying to bring in a new

methodology, why not simply bring in better people? We know that there is

a 25 to 1 differential between the best and the worst people and a 4 to 1

differentia between the best and the worst teams, so maybe the best way to

improve productivity and quality is to improve hiring practices.





Ta biết rằng 25 ngƣời tồi nhất chỉ bằng một ngƣời giỏi nhất, tỷ lệ đó

với team tốt nhất va tồi nhất la 4-1, nhƣ vậy có lẽ cách tốt nhất để nâng cao

năng suất va chất lƣợng la nâng cao chất lƣợng nhân viên.

If you take a random group of 100 people and put them in a room

with a complex programming exercise, one of them will finish 25 times

faster than the others, Yourdon says. Another ―peopleware‖ improvement

to productivity is to help managers improve their skills, as well as to foster

a teamwork approach among developers. Yourdon and many others believe

that ―peopleware‖ solutions boost productivity and quality more than any

tools or techniques.





Nếu bạn lấy một nhóm 100 ngƣời bất kì va đặt vao trong một phòng

với một bai tập lập trình phức tạp, một trong số họ sẽ lam xong sớm nhanh

hơn 25 lần những ngƣời khác, Yourdon nói. Một cách khác để nâng cao

năng suất la giúp cho những ngƣời quản lý nâng cao kĩ năng của họ, cũng

nhƣn khuyến khich việc lam việc theo nhóm giữa những ngƣời phát triển

phần mềm (developer). Yourdon va nhiều ngƣời khác tin rằng giải pháp

―phần ngƣời‖ nâng cao chất lƣợng va năng suất sản phầm hơn bất kì một

công cụ hay kĩ thuật nao khác.

20.7 KẾT LUẬN

TQM is actually a process by which one manages continuous

improvement. You need to learn the lessons in as close to real time as

possible and implement lessons learned across the organization. For quality

programs to be successful, you need to get scared enough to act.

TQM thực sự la một quá trình ma từ đó một ngƣời có thể quản lý

việc cải tiến liên tục. Bạn cần phải học cang nhiều bai học trong thế giới

thực cang tốt va bổ sung những bai học qua các tổ chức. Để cho những

chƣơng trình chất lƣợng thanh công, bạn cẩn phải có đủ can đảm để hanh

động.






A.J. Albrecht, A.J. (1983). Software function, source lines of code

and development effort prediction: a software science validation, IEEE

Trans. Software Eng., 10, 1.

Conte, Dunsmore, and Shen, (1986). Software Engineering Metrics

and Models, Benjamin/Cummings Publishing Company, San Francisco.

Hansen, W.J. (1978). Measurement of program complexity by the pair,

(Cyclomatic Number,

Operator Count) [ACM SIGPLAN Notices). Kemerer, C. and

Chidamber, S. (1991). Towards a metrics suite for object-oriented design,

ACM OOPSLA Conference (object-oriented programming, systems,

languages and applications).

Keyes, J. (1993). A Survey on IT productivity/quality, in Software

Engineering Productivity Handbook, Keyes, J., Ed., McGraw-Hill, New

York.

McCabe, T. (1976). A complexity measure, IEEE Trans. Software

Eng., SE-2, 4, 308.




Chương 21: Putnam’s software equation and slim 758

CHƢƠNG 21 PUTNAM’S SOFTWARE

EQUATION AND SLIM

Người dịch: Nguyễn Quang Anh

21.1 TỔNG QUAN

Putnam developed a constraint model called SLIM that would be

useful for projects exceeding 70,000 lines of code. This model assumes that

effort for software projects is distributed similarly to a collection of

Rayleigh curves.





Putnam phát triển một mô hình rang buộc gọi la SLIM khá hữu ich

cho các dự án vƣợt quá 70.000 dòng mã. Mô hình nay giả định rằng nỗ lực

cho các dự án phần mềm đƣợc phân phối tƣơng tự nhƣ đƣờng cong

Rayleigh.

The Norden-Rayleigh curve (Exhibit 21-1) represents manpower as a

function of time. Norden observed that the Rayleigh distribution provides a

good approximation of the manpower curve for various hardware

development processes. Development effort is assumed to represent only 40

percent of the total life cycle cost. Requirements specification is not

included in the model. Estimation using SLIM is not expected to take place

until design and coding.

Các đƣờng cong Norden-Rayleigh (hình 21-1) biểu diễn nhân lực

nhƣ la các ham về thời gian.. Norden quan sát thấy sự phân bố Rayleigh

cung cấp một xấp xỉ tốt của đƣờng cong nhân lực trong nhiều qui trình phát

triển phần cứng. Nỗ lực phát triển đƣợc giả định chỉ đại diện cho 40 phần

trăm chi phi tổng chi phi. Yêu cầu đặc tả không không đƣợc đinh kèm trong

mô hình. Đo lƣờng bằng cách sử dụng SLIM không đƣợc khuyến khich tới

khi thiết kế va cai đặt xong.

Putnam suggests that staffing rises smoothly during the project and

then drops sharply during acceptance testing. The SLIM model is expressed

as two equations describing the relation between the development effort and

the schedule. The first equation, called the software equation, states that





development effort is proportional to the cube of the size and inversely

proportional to the fourth power of the development time. The second

equation, the manpower-buildup equation, states that the effort is

proportional to the cube of the development time.

Putnam chỉ ra rằng chi phi tăng nhanh trong suốt trong dự án va sau

đó giảm mạnh trong thời gian kiểm thử dự án. Mô hình Slim trình bay 2

phƣơng trình mô tả mối quan hệ giữa nỗ lực phát triển phần mềm va thời

gian phát triển. Phƣơng trình đầu tiên gọi la software equation, còn phƣơng

trình thứ hai có tên manpower-buildup.

21.2 THỦ TỤC- VẤN ĐẾ- CHÍNH SÁCH

The software equation is calculated as follows:

Công thức tinh software equation nhƣ sau:





Với:

• Ss: Kich thƣớc của phần mềm

• C: Hằng số về công nghệ

• Td: Thời gian phát triển (năm)

• K: Tổng nỗ lực





Vi dụ:

Ss = 100 K va ymax = 40 ngƣời





Coi số lƣợng nhân lực la hằng số, ta có thể tinh đƣợc thời

gian ngắn nhất để phát triển dự án.

Số lƣơng nhân lực nhiều nhất tai thời điểm phát hanh (t=td)

Giả sử rằng

Cho ra:

Giả sử rằng hằng số công nghệ xấp xỉ 1000, ta có thể ráp vô

công thức

Bằng cách tinh K va thế vao, ta có đƣợc

Thế giá trị vao td, ta có K = 113.57 ngƣời

Chi phí phát triển la 40% của K tức la bằng 45.26 ngƣời

Năng suất của lập trình viên cũng có thể tinh đƣợc. Gỉa sử rằng có

250 ngay lam việc trong năm, năng suất lam việc sẽ bằng S/(0.4K * 250)

dòng hay 8.837 dòng 1 ngày.

To allow effort estimation, Putnam introduced the manpower-

buildup equation:





where D is a constant called manpower acceleration, E is the total

project effort in years, and t is the elapsed time to delivery in years.

The manpower acceleration is 12.3 for new software with many

interfaces and interactions with other systems, 15 for standalone systems,

and 27 for reimplementations of existing systems.

Using the software and manpower-buildup equations, we can solve

for effort:

Để đo lƣờng nỗ lực phát triển, Putnam đề xuất công thức manpower-

buildup:

Với D la nhân lực cần trong năm, E la tổng thời gian phát triển dự án

trong năm. Nếu phần mền có nhiều giao diện va phải giao tiếp với các phần

mềm khác sẽ cần 12.3, các hệ thống tiêu chuẩn cần 15 va các hệ thống tái

sử dụng cần 27 nhân lực.





Sử dụng công thức software-bulidup chúng ta có thể tinh đƣợc nỗ lực

bằng công thức:


Fenton, N.E. and Pfleeger, S.L. (1997). Software Metrics: a

Rigorous and Practical Approach, International Thomson Computer Press.

Stamford, CN. Johnson, K. Software Cost Estimation: Metrics and Models,

University of Calgary, Canada.

http://sern.ucalgary.ca/courses/seng/621/W98/johnsonk/cost.htm#Th

e%20Software%20Equation.

Putnam, L.H. (1978). A general empirical solution to the macro

software sizing and estimating problem, IEEE Transactions on Software

Engineering, SE-4:4.

Dr. Shmuel Rotenstreich, Software cost estimation,

http://www.seas.gwu.edu/~ shmuel/ cs272/14/index.htm. September 1999.

George Washington University, Washington, D.C.




Chương 22: Mô hình COCOMO II 766

CHƢƠNG 22 MÔ HÌNH COCOMO II

Người dịch: Phạm Ngọc Vân Anh

22.1 MỞ ĐẦU

COCOMO is very useful when used for custom, build-to-

specification software projects; however, COCOMO II is useful for a much

wider collection of techniques and technologies. COCOMO II provides up-

to-date support for business software, object-oriented software, software

created via spiral or evolutionary development models, and software





developed using commercial off-the-shelf application composition utilities.

COCOMO II provides models for early prototyping efforts and the more

detailed early design and post-architecture models for subsequent portions

of the life cycle.

COCOMO la rất hữu ich khi đƣợc sử dụng cho khách hang, đƣợc

xây dựng đến chi tiết các dự án phần mềm, tuy nhiên, COCOMO II la hữu

ich cho một bộ sƣu tập rộng hơn kỹ thuật va công nghệ. COCOMO II cung

cấp sự hỗ trợ hiện đại cho phần mềm kinh doanh, phần mềm hƣớng đối

tƣợng, phần mềm tạo ra thông qua đƣờng xoắn ốc hoặc các mô hình phát

triển tiến hóa, va phần mềm đƣợc phát triển bằng cách sử dụng thƣơng mại

ra ngoai thềm ứng dụng thanh phần tiện ich. COCOMO II cung cấp các mô

hình cho các nỗ lực mẫu thử ban đầu va chi tiết hơn thiết kế ban đầu va sau

các mô hình kiến trúc cho các phần tiếp theo của chu kỳ sồng.

22.2 MÔ HÌNH THÀNH PHẦN ỨNG DỤNG

The application composition model is used in prototyping to resolve

potential high-risk issues such as user interfaces, software–system

interaction, performance, or technology maturity. Object points are used for

sizing rather than the traditional LOC metric.

Các mô hình thành phần ứng dụng đƣợc sử dụng trong mẫu đầu tiên

để giải quyết các vẫn đề tiềm năng nguy cơ cao nhƣ giao diện ngƣời dùng,

tƣơng tác phần mềm hệ thống, hiệu suất, hoặc tinh trƣởng thanh công nghệ.





Những điểm đối tƣợng đƣợc sử dụng để định cơ hơn la độ đo LOC truyền

thống.

An initial size measure is determined by counting the number of

screens, reports, and third-generation components that will be used in the

application. Fenton and Pfleeger (1997) classify objects as simple, medium,

or difficult using the guidelines shown in Exhibits 22-1 and 22-2.

Đo lƣờng kich thƣớc ban đầu đƣợc xác định bằng cách đếm số lƣợng

man hình, báo cáo, va các thanh phần thứ ba sẽ đƣợc sử dụng trong các ứng

dụng. Fenton va Pfleeger (1997) phân loại các đối tƣợng nhƣ vừa đơn

giản,trung bình, hoặc khó khăn bằng cách sử dụng các nguyên tắc thể hiện

trong 22-1 và 22-2.

The number in each cell is then weighted according to Exhibit 22-3.

The weights represent the relative effort required to implement an instance

of that complexity level (Fenton and Pfleeger, 1997). The weighted

instances are summed to provide a single object point number. Reuse is

then taken into account. Assuming that r percent of the objects will be

reused from previous projects, the number of new object points (NOP) is

calculated to be:

NOP = (object points) × (100 – r)/100

Số trong mỗi ô sau đó đƣợc lam nặng theo 22-3. Cái trọng lƣợng

đại diện cho các nỗ lực có liên quan cần thiết để thực hiện một thể hiện của





mức độ phức tạp đó (Fenton va Pfleeger, 1997). Các độ nặng của thể hiện

đƣợc tổng kết để cung cấp một con số điểm đối tƣợng duy nhất. Tái sử

dụng sau đó đƣợc tinh đến. Giả sử r phần trăm của các đối tƣợng sẽ đƣợc sử

dụng lại từ các dự án trƣớc đó, số lƣợng các điểm đối tƣợng mới (NOP)

đƣợc tinh toán la:

NOP = (các điểm đối tƣợng) × (100 - r) / 100

Hình 22-1

Hình 22-2





Hình 22-3

Hình 22-4

A productivity rate (PROD) is determined using Exhibit 22-4. Effort

can then be estimated using the following equation:

E = NOP/PROD

Một tỉ lệ hiệu suất (PROD) đƣợc xác định bằng cách sử dụng 22-4.

Sau đó nỗ lực có thể đƣợc ƣớc tinh bằng cách sử dụng các phƣơng trình sau

đây:

E = NOP / PROD





22.3 MÔ HÌNH THIẾT KẾ BAN ĐẦU

The early design model is used to evaluate alternative software or

system architectures and concepts of operation. An unadjusted function

point count (UFC) is used for sizing. This value is converted to LOC using

tables such as those published by Capers Jones (1996), excerpted in Exhibit

22-5.

Các mô hình thiết kế ban đầu đƣợc sử dụng để đánh giá các kiến trúc

phần mềm hay hệ thống thay thế va các khái niệm của hoạt động. Một điểm

chức năng không thich ứng (UFC) đƣợc sử dụng cho định cở. Giá trị nay

đƣợc chuyển đổi sang LOC sử dụng các bảng nhƣ đƣợc công bố bởi

Capers Jones (1996), trich đoạn trong 22-5.

Hình 22-5





Hình 22-6

The early design model equation is:

E = aKLOC × EAF

where a is a constant, provisionally set to 2.45.

Các phƣơng trình mô hình thiết kế ban đầu la:

E = aKLOC × EAF

trong đó a la hằng số, tạm đặt là 2,45.

The effort adjustment factor (EAF) is calculated as in the original

COCOMO model using the seven Boehm cost drivers shown in Exhibit 22-

6.





Yếu tố sự điều chỉnh nổ lực (EAF) đƣợc tinh nhƣ trong mô hình

COCOMO nguyên gốc bằng cách sử dụng các trình điều khiển chi phi

Boehm thứ bẩy thể hiện trong 22-6.

22.4 MÔ HÌNH POST_ARCHITECTURE

The post-architecture model is used during the actual development

and maintenance of a product. Function points or LOC can be used for

sizing, with modifiers for reuse and software breakage. Boehm advocates

the set of guidelines proposed by the Software Engineering Institute in

counting lines of code. The post-architecture model includes a set of 17 cost

drivers and a set of 5 factors determining the project‘s scaling component.

The five factors (Exhibit 22-6) replace the development modes (organic,

semidetached, embedded) of the original COCOMO model.

Mô hình Post-architecture đƣợc sử dụng trong quá trình phát triển va

bảo trì thực tế của một sản phẩm. Các điểm chức năng hoặc LOC có thể

đƣợc sử dụng để định cơ, với ý nghĩa bổ sung cho tái sử dụng va đoạn nứt

phần mềm. Boehm chủ trƣơng tập các nguyên tắc đề nghị bởi Viện Kỹ

thuật Ứng Dụng Phần Mềm trong việc đếm dòng mã. Mô hình Post-

architecture bao gồm một bộ 17 các trình điều khiển chi phi va một bộ 5

yếu tố xác định tỉ lệ thanh phần của dự án. Năm yếu tố (triển lãm 22-6) thay

thế các phƣơng thức phát triển (hữu cơ, liền vách, sự nhúng) của mô hình

COCOMO gốc.





Hình 22-7

The post-architecture model equation is:

E = aKLOCb x EAF

where a is set to 2.55 and b is calculated as:

b = 1.01 + 0.01 x SUM(Wi)

where W is the set of five scale factors shown in Exhibit 22-7.

Phƣơng trình mô hình Post-architecture là:

E = aKLOCb x EAF

trong đó, a đƣợc đặt la 2,55 va b đƣợc tinh nhƣ:

b = 1,01 + 0,01 x SUM (Wi)





W la nơi tập hợp của năm yếu tố phân chia thể hiện trong 22-7.

The EAF is calculated using the 17 cost drivers shown in Exhibit 22-

8.

The EAF đƣợc tinh bằng cách sử dụng 17 các trình điều khiển chi

phi đƣợc hiển thị trong 22-8.


Boehm, B. (1981). Software Engineering Economics, Prentice-Hall,


Boehm, B. (1975). The high cost of software, in Practical Strategies

for Developing Large Soft-ware Systems, Horowitz, E., Ed., Addison-

Wesley, Reading, MA, 4–14.

Boehm, B.W., Abts, C., Clark, B., and Devnani-Chulani, S. (1997).

COCOMO II Model Definition Manual, The University of Southern

California. http://sunset.usc.edu/research/COCOMOII/index.html.

Fenton, N.E. and Pfleeger, S.L. (1997). Software Metrics: a

Rigorous and Practical Approach, International Thomson Computer Press,.

Johnson, K. Software Cost Estimation: Metrics and Models,

University of Calgary.





http://sern.ucalgary.ca/courses/seng/621/W98/johnsonk/cost.htm#The%20S

oftware%20Equation.

Jones, C. (1996). Applied Software Measurement, McGraw-Hill, New

York.

Hình 22-8.




Chương 23: Mẫu ước tính chi phí Putnam 777

CHƢƠNG 23 MẪU ƢỚC TÍNH CHI PHÍ

PUTNAM

Người dịch: Lê Anh Dũng

23.1 TỔNG QUAN

Putnam‘s (1978) cost estimation model is a macroestimation model

that computes the relationship between cost and the amount of time

available for the development effort. The model supports the ―mythical





man-month‖ idea first put forth by Frederick Brooks, who asserted that

people and time are not always interchangeable.

Mẫu ƣớc tinh chi phi Putnam la một mẫu ƣớc tinh vĩ mô dùng để

tinh toán mối liên hệ giữa chi phi va thời gian hiện có cho nỗ lực của việc

phát triển phần mềm. Mẫu nay ủng hộ ý tƣởng ―nhân viên của tháng‖ lần

đầu đƣợc đƣa ra va đƣợc sử dụng về sau bởi Frederick Brooks, ngƣời luôn

khẳng định rằng con ngƣời va thời gian không phải lúc nao cũng có thể

thay thế cho nhau đƣợc.

23.2 THỦ TỤC/VẤN ĐỀ/CHÍNH SÁCH

The Putnam formula is as shown in Exhibit 23-1.

Công thức Putnam đƣợc trình bay nhƣ trong hình 23-1.

Hình 23-1. Công thức Putnam

Where

y = instantaneous programmer power





y = total life cycle cost in programmer years

y = time from beginning of project

td = delivery time

e = 2.71828.

Trong đó:

y =khả năng hiện tại của lập trình viên.

K = tổng chi phi vòng đời sản phẩm trong thời gian lập trình.

t = thời gian từ lúc bắt đầu dự án.

td = thời gian chuyển giao dự án.

e = hằng số Euler = 2.71828.












Ghi chú: do paper có các công thức về thống kê và các phép toán

phức tạp nên phần báo cáo này chỉ trình bay theo nhƣ sách. Ngoai ra có thể

tham khảo paper đƣợc đinh kèm theo bai dịch và slide này.




Chương 24: Malcolm Baldrige Quality Award 781

CHƢƠNG 24 MALCOLM BALDRIGE QUALITY

AWARD

Người dịch: Huỳnh Thảo Hạnh Duy

24.1 TỔNG QUAN

The Malcolm Baldrige Quality Award is an annual award to

recognize U.S. companies that excel in quality achievement and quality

management. The award promotes awareness of quality as an increasingly

important element in competitiveness, understanding of the requirements





for quality excellence, and sharing of information on successful quality

strategies and on benefits derived from implementation of these strategies.

Although only one part of the examination is related to technology, all the

Baldrige award tenets of quality apply to the IT process. In this chapter, a

synopsis of the requirements is highlighted.

Malcolm Baldrige Quality Award la giải thƣởng thƣờng niên cho

những công ty Hoa Kỳ có những thanh tựu chất lƣợng va những sự quản lý

chất lƣợng vƣợt bậc. Giải thƣởng đánh giá cao mối quan tâm về chất lƣợng

va những yếu tố quan trọng không ngừng gia tăng trong sự cạnh tranh, sự

hiểu biết về yêu cầu chất lƣợng tốt, va sự chia sẻ thông tin ở những chiến

thuật chất lƣợng thanh công cùng với lợi nhuận thu đƣợc từ những phần

trong chiến lƣợc đó. Mặc dù chỉ có một phần trong cuộc kiểm tra liên quan

tới công nghệ, tất cả nguyên lý cho sự quyết định về chất lƣợng của

Baldrige áp dụng cho tiến trình công nghệ thông tin. Chƣơng nay la một

bản tóm tắt các yêu cầu quan trọng

24.2 THỦ TỤC/ VẤN ĐỀ/ CHÍNH SÁCH

24.2.1 The award is built upon a number of key concepts:

• Quality is defined by the customer.

• The senior leadership of business needs to create clear quality values

and build the values into the way the company operates.





• Quality excellence derives from well-designed and wellexecuted

systems and processes.

• Continuous improvement must be part of the management of all

systems and processes.

• Companies need to develop goals, as well as strategic and operational

plans, to achieve quality leadership.

• Shortening the response time of all operations and processes of the

company needs to be part of the quality improvement effort.

• Operations and decisions of the company need to be based upon facts

and data.

• All employees must be suitably trained and developed, and involved in

quality activities.

• Design quality and defect and error prevention should be major

elements of the quality system.

• Companies need to communicate quality requirements to suppliers and

work to elevate suppliers‘ quality performance.

• Chất lƣợng định nghĩa bởi ngƣời dùng





• Lãnh đạo cấp cao của công ty cần đƣa ra những giá trị chất lƣợng rõ

ràng va xây dựng các giá trị nay trên việc hoạt động của công ty

• Sự phát triển không ngừng phải la một phần của sự quản lý các hệ

thống va tiến trình

• Công ty phải phát triển các mục tiêu cũng nhƣ các chiến lƣợc, kế hoạch

chi tiết để đạt đƣợc chất lƣợng lãnh đạo

• Giảm thiểu tối đa thời gian phản hồi của các hoạt động, tiến trình ma

công ty cần thiết phải la một phần của sự cố gắng nâng cao chất lƣợng.

• Các hoạt động va quyết định của công ty phải dƣa trên thực tế va dữ

liệu. Tất cả nhân viên phải đƣợc huấn luyện va phát triển hợp lý va liên

quan đến các hoạt động chất lƣợng

• Chất lƣợng thiết kế va việc phòng tránh lỗi phải la những yếu tố chinh

trong hệ thống chất lƣợng

• Công ty phải thông báo các yêu cầu chất lƣợng đến các nha cung cấp

va thực hiện đánh giá chất lƣợng của nha cung cấp

24.2.2 Examination categories/items

1.0. Leadership 100

1.1 Senior executive leadership 40





1.2 Quality values 15

1.3 Management for quality 25

1.4 Public responsibility 20

2.0. Information and analysis 70

2.1 Scope and management of quality data and

information 20

2.2 Competitive comparisons and benchmarks 30

2.3 Analysis of quality data and information 20

Thông tin và phân tích (70)

Quản lý chất lƣợng va dữ liệu (20)

So sánh cạnh tranh (30)

Phân tich dữ liệu va thông tin (20)

3.0. Strategic quality planning 60

3.1 Strategic quality planning process 35

3.2 Quality goals and plans 25





Kế hoạch chất lƣợng có chiến lƣợc (60)

Tiến trình kế hoạch chất lƣợng có chiến lƣợc (35)

Kế hoạch va mục tiêu chất lƣợng (25)

4.0. Human resource utilization 150

4.1 Human resource management 20

4.2 Employee involvement 40

4.3 Quality education and training 40

4.4 Employee recognition and performance measurement 25

4.5 Employee well-being and morale 25

Việc sử dụng nhân lực (150)

Quản lý nhân lực (20)

Employee involvement (40)

Huấn luyện chất lƣợng (40)

Đánh giá nhân viên (25)

Tinh thần nhân viên (25)





5.0. Quality assurance of product and services 140

5.1 Design and introduction of quality products

and services 35

5.2 Process quality control 20

5.3 Continuous improvement of processes 20

5.4 Quality assessment 15

5.5 Documentation 10

5.6 Business process and support service quality 20

5.7 Supplier quality 20

Bảo đảm chất lƣợng sản phẩm va dịch vụ (140)

Thiết kế, giới thiệu chất lƣợng sản phẩm, dịch vụ (35)

Kiểm soát chất lƣợng (20)

Quá trình phát triển không ngừng của các tiến trình (20)

Đánh giá chất lƣợng (15)

Tai liệu hóa (15)





Quá trình kinh doanh va chất lƣợng dịch vụ hỗ trợ (20)

Chất lƣợng cung cấp (20)

6.0. Quality results 180

6.1 Product and service quality results 90

6.2 Business process, operational and support

service quality results 50

6.3 Supplier quality results 40

Kết quả chất lƣợng (180)

Kết quả chất lƣợng sản phẩm va dịch vụ (90)

Kết quả chất lƣợng tiến trình kinh doanh, tổ chức va dịch vụ hỗ trợ

(50)

Kết quả chất lƣợng nha cung cấp (40)

7.0. Customer satisfaction 300

7.1 Determining customer requirements and expectations 30

7.2 Customer relationship management 50





7.3 Customer service standards 20

7.4 Commitment to customers 15

7.5 Complaint resolution for quality improvement 25

7.6 Determining customer satisfaction 20

7.7 Customer satisfaction results 70

7.8 Customer satisfaction comparison 70

Sự hai lòng của khách hang (300)

Những mong đợi va yêu cầu khách hang (30)

Quản lý quan hệ khách hang (50)

Chuẩn dịch vụ khách hang (20)

Chuyển giao cho khách hang (15)

Hƣớng giải quyết phê bình cho việc phát triển chất lƣợng (25)

Sự thỏa mãn khách hang (20)

Kết quả sự thỏa mãn khách hang (70)

So sánh sự thỏa mãn của khách (70)





Chuyển giao cho khách hang (15)

Hƣớng giải quyết phê bình cho việc phát triển chất lƣợng (25)

Sự thỏa mãn khách hang (20)

Kết quả sự thỏa mãn khách hang (70)

So sánh sự thỏa mãn của khách (70)




Chương 25: Zachman’s Framework 791

CHƢƠNG 25 ZACHMAN’S FRAMEWORK

Người dịch: Đam Quỳnh Giang

25.1 TỔNG QUAN

In his seminal work, Zachman (1987) makes the observation that,

just as a builder needs a detailed set of plans for a building, a systems

developer needs a detailed set of plans for a complex system. He continues

this observation by saying that different types of plans are prepared by





differentparties for different purposes and represent very different views of

the same building. Zachman created an architectural framework that is

basically a ―set of representations‖ of differing orientations and focuses.

This chapter gives a brief overview of Zachman‘s framework.

Tại hội thảo công việc của mình, Zachman (1987) đã thực hiện một

nhận xét rằng, cũng giống nhƣ một ngƣời xây dựng cần một bộ chi tiết của

kế hoạch cho một tòa nha, một nha phát triển hệ thống cần một bộ chi tiết

của kế hoạch cho một hệ thống phức tạp. Ông tiếp tục sự nhận xét nay bằng

cách nói rằng các loại kế hoạch khác nhau đƣợc chuẩn bị bởi các bên khác

nhau cho các mục đich khác nhau va đại diện cho những cách nhìn rất khác

nhau của cùng tòa nha. Zachman tạo ra một khung(framework) kiến trúc là

một "bộ đại diện‖ của các định hƣớng va tập trung khác nhau một cách cơ

bản. Chƣơng nay cung cấp tổng quan về framework Zachman.

25.2 THỦ TỤC / VẤN ĐỀ / CHÍNH SÁCH

1. The framework is a two-dimensional classification of the various

components of an information systems architecture. One dimension

consists of scope description, business model, information system

model, technology model and detailed description. The second

dimension consists of data description, process description, and

network description.





Framework la một phân loại hai chiều của các thanh phần khác

nhau của một kiến trúc hệ thống thông tin. Một chiều gồm có mô tả

phạm vi, mô hình nghiệp vụ, mô hình hệ thống thông tin, mô hình công

nghệ va mô tả chi tiết. Chiều thứ hai bao gồm các mô tả dữ liệu, mô tả

tiến trình, va mô tả mạng.

2. Framework Zachman (xem hình 25-1)

Mô tả dữ liệu Mô tả tiến trình Mô tả mạng

Mô tả phạm vi

Mô hình nghiệp vụ

Mô hình hệ thống

thông tin





Mô hình công nghệ

Mô tả chi tiết

Hình 25-1 Framework Zachman

3. At the scope description level:

• Data description: a list of entities relevant to the business or project

• Process description: a list of business processes

• Network description: a list of locations at which the business operates

or at which the processes of interest are performed

• Mô tả dữ liệu: một danh sách các thực thể có liên quan đến nghiệp vụ

hoặc dự án

• Mô tả tiến trình: một danh sách các quy trình nghiệp vụ

• Mô tả mạng: một danh sách nơi ma tại đó các hoạt động nghiệp vụ hay

các quá trình quan tâm đƣợc thực hiện

4. At the business model level:

• Data description: an entity-relationship diagram





• Process description: possibly a functional flow diagram

• Network description: some form of logistic definition of the enterprise

• Mô tả dữ liệu: một sơ đồ thực thể - kết hợp

• Mô tả tiến trình: có thể la một lƣu đồ chức năng

• Mô tả mạng: một số hình thức định nghĩa hậu cần của doanh nghiệp

5. At the information system model level:

• Data description: a detailed logical data model with all the necessary

data element definitions

• Process description: possibly a detailed data flow diagram with

supporting documentation

• Network Description: plan for system distribution

• Mô tả dữ liệu: một mô hình dữ liệu hợp lý chi tiết với tất cả các định

nghĩa yếu tố dữ liệu cần thiết

• Mô tả tiến trình: có thể la một sơ đồ luồng dữ liệu chi tiết với các tai

liệu hỗ trợ

• Mô tả mạng: kế hoạch cho hệ thống phân phối





6. At the technology model level:

• Data description: detailed definition of the external schemas

• Process description: detailed structure chart with complete module

specifications

• Network description: system architecture of processors, nodes, and

communication lines

• Mô tả dữ liệu: định nghĩa chi tiết của lƣợc đồ bên ngoai

• Mô tả tiến trình: cấu trúc biểu đồ chi tiết với đặc tả mô-đun hoan chỉnh

• Mô tả mạng: kiến trúc hệ thống của bộ xử lý, các nút, va đƣờng liên lạc

7. At the detailed description level:

• Data description: describing actual files, records, fields, etc. as

understood by the data management software

• Process description: consisting of the programs

• Network description: in the form used by the communications software

• Mô tả dữ liệu: mô tả tập tin, hồ sơ, lĩnh vực,… thực tế nhƣ đƣợc hiểu

bởi phần mềm quản lý dữ liệu





• Mô tả tiến trình: bao gồm các chƣơng trình

• Mô tả mạng: trong những hình thức đƣợc sử dụng bởi các phần mềm

truyền thông


Zachman, J.A. (1987), Một framework cho kiến trúc hệ thống thông

tin, IBM Syst. J., 26(3)




Chương 26:Phương pháp Linkman cho việc kiểm soát chương trình 798

CHƢƠNG 26 PHƢƠNG PHÁP LINKMAN CHO

VIỆC KIỂM SOÁT CHƢƠNG TRÌNH THÔNG

QUA CÁC PHÉP ĐO

Người dịch: Nguyễn Minh Hùng

26.1 TỔNG QUAN

A controlled development and maintenance program is essential for

bringing down the cost associated with software development life cycle.

The control mechanism can be implemented first by setting up specific





goals and then selecting the right set of metrics for measurements against

those goals. Goals must be tangible and balanced or they will be too remote

to be considered achievable. Intermediate targets are needed for monitoring

the progress of the project and making sure it is on the right track. Project

data collection and analysis should also be part of the control mechanism.

Sự phát triển va bảo trì chƣơng trình có kiểm soát la nguyên tắc thiết

yếu cho việc giảm chi phi trong quá trình phát triển phần mềm.Cơ chế kiểm

soát có thể đƣợc thiết lập trƣớc bằng cách định rõ những mục tiêu xác định

va lựa chọn đúng các độ đo cho việc đo lƣờng các mục tiêu đó. Những mục

tiêu phải đƣợc số liệu hóa va phải hợp lý. Các mục tiêu trung gian la cần

thiết để theo dõi quá trình thực hiện của dự án va đảm bảo rằng dự án đang

đi đúng hƣớng. Thu thập va phân tich dữ liệu của dự án cũng la một phần

của cơ chế kiểm soát.

A four-step procedure is outlined for establishing targets and means

for assessment (Linkman and Walker, 1991). The procedure is not focused

on any particular set of metrics; rather, metrics should be selected on the

basis of goals. This procedure is suitable for setting up goals for the entire

project deliverables or for any partial product created in the software life

cycle.

Phƣơng pháp Linkman thực chất một thủ tục gồm 4 bƣớc đóng vai

trò lam khung cho việc xác định các mục tiêu va phƣơng pháp đánh giá.

Thủ tục nay không tập trung vao bất kỳ bộ các độ đo nao, thay vao đó, các





độ đo sẽ đƣợc lựa chọn tùy thuộc vao mục đich cụ thể. Nó thich hợp cho

việc thiết lập các mục tiêu cho toan bộ dự án hoặc cho mỗi phần sản phẩm

đƣợc tạo thanh trong quá trình phát triển phần mềm.


1. Định nghĩa các mục tiêu có thể đo đƣợc:

Define measurable goals: the project goals establishment process is

similar to the development process for project deliverables. Software

projects usually start with abstract problem concepts; the final project

deliverables are obtained by continuously partitioning and refining the

problem into tangible and manageable pieces. Final quantified goals can be

transformed from initial intangible goals by following the same divide-and-

conquer method for software deliverables.Three sources of information are

helpful to establishing the targets:

• Historical data is useful under the assumptions that data is available,

development environment is stable, and projects are similar in terms of

type, size, and complexity.

• Synthetic data such as modeling results is useful if models used are

calibrated to specific development environment.

• Expert opinions can be helpful.





Dự án phần mềm thƣờng bắt đầu với những quan niệm vấn đề mơ

hồ; dự án phát hanh cuối cùng đƣợc đạt đƣợc bằng quá trình phân chia liên

tục va biến những vấn đề trở thanh cụ thể, có thể quản lý đƣợc. Những mục

tiêu định lƣợng cuối cùng có thể đƣợc chuyển từ các mục tiêu chƣa xác

định lúc đầu bằng phƣơng pháp chia để trị cho quá trình quản lý dự án phần

mềm. Ba nguồn thông tin sau la hữu ich cho việc xác định mục tiêu:

• Dữ liệu từ các dự án đã thực hiện trong quá khứ với giả sử rằng các dữ

liệu nay còn tồn tại, môi trƣờng phát triển ổn định va các dự án la

tƣơng tự nhau xét trên về loại, độ lớn va độ phức tạp.

• Dữ liệu tổng hợp nhƣ các kết quả đƣợc mô hình hóa la hữu ich nếu các

mô hình đƣợc sử dụng đƣợc xác định trong môi trƣờng phát triển nhất

định.

• Ý kiến chuyên gia.

2. Duy trì cân bằng giữa các mục tiêu:

Maintain balanced goals: the measurable goals are usually

established on the basis of four factors: cost, schedule, effort, and quality. It

is feasible to achieve just a single goal, but it is always a challenge to

deliver a project with the minimum staff and resources, on time, and within

budget. It needs to be kept in mind that trade-off is always involved and all

issues should be addressed to reach a set of balanced goals.





Các mục tiêu có thể đo đƣợc thƣờng đƣợc thiết lập trên cơ sở 4 nhân

tố: giá cả, thời gian, nhân lực va chất lƣợng. Với 1 mục tiêu thì có thể dễ

dang đạt đƣợc, nhƣng sẽ la một thử thách nếu phải phát triển một dự án với

nhân viên va nguồn lực giới hạn, đúng thời gian va giới hạn chi phi. Phải

luôn nhớ rằng việc cân bằng các yếu tố la cần thiết, va phải giải quyết tất cả

các mục tiêu để đạt đến tập các mục tiêu cân bằng.

3. Thiết lập các mục tiêu trung gian:

Set up intermediate goals: a project should never be measured only at

its end point. Checkpoints should be set up to provide confidence that the

project is running on course. The common practice involves setting up

quantifiable targets for each phase, measuring the actual values against the

targets, and establishing a plan to make corrections for any deviations. All

four aforementioned factors should be broken down into phase or activity

for setting up intermediate targets. Measurements for cost and effort can be

divided into machine and human resources according to software life cycle

phase so that expenditures can be monitored to ensure the project is running

within budget. The schedule should always be defined in terms of

milestones or checkpoints to ensure that intermediate products can be

evaluated and the final product will be delivered on time. Quality of

intermediate products should always be measured to guarantee the final

deliverable will meet its target goal.





Không bao giờ đặt ra cho dự án chỉ một mục tiêu cuối cùng.

Checkpoint cần đƣợc thiết lập để xác định rằng dự án đang đi đúng hƣớng.

Việc thông thƣờng cần lam la xác định những mục tiêu cho mỗi giai đoạn

va những việc cần phải lam để đạt đƣợc mục tiêu đó. Cả 4 yếu tố nói trên

(giá cả, thời gian, nhân lực va chất lƣợng) cần phải đƣợc phân ra thanh từng

phần va xác định mục tiêu cho từng phần đó. Việc xác định chi phi va nhân

lực có thể chia ra thanh các tai nguyên máy móc va con ngƣời dựa trên

vòng lặp phát triển phần mềm (xác định yêu cầu – phân tích – thiết kế - cài

đặt – kiểm chứng) để có thể theo dõi phi tổn trong từng giai đoạn, đảm bảo

cho chi phi của toan dự án trong phạm vi cho phép. Thời gian cũng phải

luôn đƣợc chia nhỏ dƣới dạng những milestone hoặc chekpoint để đảm bảo

rằng các sản phẩm trung gian đƣợc đánh giá va giao hang đúng hẹn. Chất

lƣợng của từng sản phẩm trung gian cũng phải luôn đƣợc đánh giá để đảm

bảo rằng sản phẩm cuối cùng đáp ứng đƣợc mục tiêu ban đầu đề ra.

4. Thực thi các phƣơng pháp đánh giá:

Establish means of assessment: two aspects are involved in this

activity:

• Data collection: based on project characteristics such as size,

complexity, level of control, etc., a decision should be made in terms of

whether a manual or an automated data collection process should be

used. If a nonautomated process is applied, then the availability of the

collection medium at the right time should be emphasized.





• Data analysis: the following two types of analyses should be

considered:

- Project analysis — this type of analysis, consisting of checkpoint

analysis and continuous analysis (trend analysis), is concerned with

verifying that intermediate targets are met to ensure that the project

is on the right track.

- Component analysis — this type of analysis concentrates on the

finer level of details of the end product and is concerned with

identifying those components in the product that may require

special attention and action. The complete process includes

deciding on the set of measures to be analyzed, identifying the

components detected as anomalous using measured data, finding

out the root pause of the anomalies, and taking actions to make

corrections.

Hai phƣơng diện liên quan đến quá trình nay:

• Thu thập dữ liệu: dựa trên những đặc điểm của dự án nhƣ quy mô, độ

phức tạp, mức độ kiểm soát… để đƣa ra quyết định rằng dữ liệu sẽ

đƣợc thu thập một cách tự động hay bằng tay, nếu bằng tay thì phải xác

định xem dữ liệu đó sẽ đƣợc thu thập bằng cách nao.

• Phân tich dữ liệu: 2 loại phân tich sau sẽ đƣợc xét đến:





- Phân tich dự án: bao gồm phân tich các checkpoint va phân tich

theo xu hƣớng, liên quan đến việc xác thực các mục tiêu trung gian

qua đó đảm bảo dự án đang đƣợc đi đúng hƣớng.

- Phân tich các nhân tố: loại phân tich nay tập trung vao phân tich

chi tiết của sản phẩm cuối cùng, nhận ra các nhân tố trong sản

phẩm yêu cầu sự chú ý va hanh động đặc biệt. Kết quả cuối cùng

bao gồm việc quyết định độ đo, nhận ra những nhân tố đƣợc phát

hiện la những nhân tố bất thƣờng sử dụng dữ liệu đo đƣợc, tìm ra

nguồn gốc va cách khắc phục những lỗi đó.




Chương 27: Kellner’s Nontecnological issues in software engineering 800

CHƢƠNG 27 KELLNER’S

NONTECHNOLOGICAL ISSUES IN

SOFTWARE ENGINEERING

Người dịch: Trần Ngọc Hiệu

27.1 TỔNG QUAN

Although much of the emphasis in current literature is on the

technical issues of software engineering, a number of substantive

nontechnological problems pose dangers to the effective practice of





software engineering. A lack of software engineering productivity can be

caused by managerial, organizational, economic, political, legal, behavioral,

psychological, and social factors.

To achieve an acceptable level of software engineering productivity,

as much emphasis must be placed on ―people‖ issues as on technological

issues. As Boehm puts it, ―Personnel attributes and human relations

activities provide by far the largest source of opportunity for improving

software productivity‖ (Boehm, 1981).

Mặc dù phần lớn các vấn đề đƣợc nhấn mạnh trong tai liệu nay la các

vấn đề về kỹ thuật trong công nghệ phần mềm, nhƣng một số nội dung

không liên quan đến kĩ thuật (nontechnological) cũng gây ảnh hƣởng đến

tinh hiệu quả của quá trình lam phần mềm. Việc thiếu năng suất công nghệ

phần mềm có thể đƣợc gây ra bởi các yếu tố nhƣ sự quản lý, tổ chức, kinh

tế, chinh trị, pháp lý, tâm lý, va các yếu tố xã hội.

Để đạt đƣợc một mức độ chấp nhận đƣợc về năng suất công nghệ

phần mềm, nhƣ la chú trọng nhiều đến yếu tố ―con ngƣời‖ va các vấn đề

nhƣ trên. Nhƣ Boehm đã nói, "các vấn đề, hoạt động liên quan tới con

ngƣời la nguồn tai nguyên lớn nhất lam cải thiện năng suất lam phần mềm‖

(Boehm, 1981).






1. Phải thừa nhận rằng quá trình lam phần mềm la "có khả năng rất lộn

xộn va rời rạc do các yếu tố không liên quan đến kĩ thuật lam ảnh

hƣởng đến hiệu quả của các ứng dụng công nghệ ― (Humphrey, 1989).

2. Many nontechnological issues are intertwined with software

engineering. Although any of these is a potential impediment, the

Kellner panel focused on three:

Nhiều vấn đề không liên quan tới kĩ thuật đƣợc ẩn giấu trong quá

trình lam phần mềm. Nhƣng bất kỳ trong số nay có thể la một trở ngại tiềm

ẩn, các bảng của Kellner tập trung vao ba điểm sau:

• The software engineering profession, for the most part, has not

developed a block of capable and competent managers.

• In spite of a concerted effort toward making software development an

engineering discipline, it is still very much of an individual creative

activity, rather than a team effort.

• Little has been done to reduce performance differences among

individuals or across teams.

• Các nganh công nghệ phần mềm, phần lớn, không có phát triển một

nhóm nha quản lý đủ khả năng va thẩm quyền





• Mặc dù có một số nỗ lực hƣớng tới việc phát triển phần mềm, nhƣng

trong số đó vẫn còn rất nhiều sự sáng tạo của một cá nhân hơn la một

tập thể.

• Chỉ có một it thực hiện để lam giảm sự khác biệt về hiệu suất lam việc

giữa các cá nhân hoặc của cả nhóm.

3. Poor management produces:

• Unrealistic project plans due to poor planning, scheduling, and

estimation skills

• Unmotivated staff due to inability of management to manage a creative

staff

• Lack of teamwork due to inability to build and manage effective teams

• Poor project execution due to inadequate organization, delegation, and

monitoring

• Technical problems due to lack of management understanding of

disciplines such as quality assurance and configuration management

• Inadequately trained staff due to a short-sighted rather than a long-term

perspective

• Yếu trong quản lý sản xuất:





• Kế hoạch dự án không thực tế vì sự yếu kém trong quy hoạch, lập kế

hoạch, va

đánh giá.

• Không quản lý đƣợc nhân viên vì không có khả năng của ngƣời quản lý

để phát triển khả năng sáng tạo của nhân viên.

• Yếu vì không có khả năng lam việc theo nhóm để xây dựng va quản lý

hiệu quả

nhóm.

• Nghèo dự án do tổ chức thực hiện không đầy đủ, sự yếu kém của ngƣời

đại điện giám sát.

• Thiếu kỹ thuật do thiếu hiểu biết về quản lý của các vấn đề kỷ luật nhƣ:

bảo đảm chất lƣợng va cấu hình quản lý.

• Không đao tạo nhân viên một cách tƣơng xứng vì tầm nhìn bị hạn chế

hơn la nhìn thấy một chiến dịch lâu dai

4. Possible solutions to poor management problems:

• Definition of dual career paths for technical and managerial staff

• Training in managerial skills and techniques

• Active mentoring and supervision by senior managers





• Increased delegation of responsibility and matching authority

Có thể có giải pháp cho các vấn đề yếu trong quản lý:

• Định hƣớng phát triển cho cán bộ kỹ thuật va quản lý.

• Đao tạo kỹ năng quản lý va kỹ thuật

• Các hoạt động tƣ vấn va giám sát đƣợc thực hiện bởi các nha quản lý

cấp cao.

• Đoan đại diện có trách nhiệm va thẩm quyền phù hợp

5. Reasons for lack of teamwork:

• Desire for autonomy

• A culture that reinforces individual efforts more than team efforts

• Concentration of key application knowledge by a few individuals

• Desire for privacy

• The ―not invented here‖ syndrome translated to the ―not invented by

me‖ syndrome

• Large productivity differences from one individual to another





• Political considerations between powerful individuals and managers

Lý do thiếu tinh thần lam việc nhóm

• Tự cho quyền tự chủ

• Có suy nghĩ rằng tăng cƣờng những nỗ lực cá nhân nhiều hơn những nỗ

lực của cả nhóm.

• Sự tập trung vao những phần chinh của ứng dụng đƣợc lam bởi vai cá

nhân trong nhóm

• Tự cho sự riêng tƣ

• Các hội chứng "không phát minh ra ở đây‖ chuyển thanh hội chứng

"cái đó không phát minh bởi tôi"

• Sự khác biệt lớn về hiệu xuất từ một cá nhân so với những ngƣời khác.

• Sự quan tâm đến quyền lực giữa các cá nhân có năng lực tốt va ngƣời

quản lý.

6. Possible solutions to teamwork problems:

• Objective assessment of team contributions with appropriate rewards

• Development of an organizational culture that condones and rewards

group efforts





• Active efforts to disperse crucial application knowledge across project

staff

• Improvements in communication and coordination across

organizational layers

• Adoption of ―egoless‖ programming techniques

Có thể có giải pháp cho các vấn đề lam việc theo nhóm:

• Đánh giá khách quan các đóng góp của nhóm với phần thƣởng phù hợp

• Việc phát triển về đặc trƣng cách hanh xử của nhóm ma có sự tha thứ

và thƣởng tặng cho những nỗ lực của nhóm.

• Các hoạt động nhằm nỗ lực để phân tán những kiến thức quan trọng

trong ứng dụng trên toan nhân viên của dự án.

• Những cải thiện trong giao tiếp va phối hợp tổ chức trên toàn nhóm

7. Large performance differences between individuals negate productivity

increases. Boehm estimates that productivity ranges of 3:1 to 5:1 are

typical, with some studies documenting differences as high as 26:1

among experienced programmers (Boehm, 1981). This variability is

often due to:

• Misguided staffing practices





• Poor team development

• Inattention to the critical role of motivation

• Poor management

Lý do lam giảm năng suất lam việc của nhân viên:

• Nhân viên thực hiện lệch hƣớng.

• Thiếu sự phát triển nhóm.

• Không lƣu y đến vai trò quan trọng của động lực thúc đẩy.

• Thiếu sự quản lý.

8. Techniques to increase effective level of productivity:

• Enhanced training

• Investment in productivity tools (tools, methods)

• Standard practices

• Professional development opportunities

• Recognition

• Effective staffing





• Top talent

• Job matching

• Career progression

• Team balance

• Improved management

Kỹ thuật để tăng mức hiệu quả của năng suất:

• Tăng cƣờng việc đao tạo.

• Sự đầu tƣ vao những công cụ hựu ich (công cụ, phƣơng thức).

• Tiêu chuẩn trong thực hanh.

• Cơ hội phát triển nghề nghiệp.

• Sự nhận thức.

• Hiệu quả của nhân viên.

• Tai năng.

• Công việc phù hợp.

• Tiến triển nghề nghiệp.





• Sự cân bằng của nhóm.

• Cải thiện quản lý.


Boehm, B.W. (1981). Software Engineering Economics, Prentice-

Hall, Inc., New York.

Ηυμπηρεψ, W.. (1989). Μαναγινγ ηηε οθηωαρε Προχεζζ,

Αδδιζον−Wεζλεψ, Ρεαδινγ, ΜΑ.

27.4 CHUYÊN ĐỀ CHỌN LỌC

Brooks, F.P. (1987). No silver bullet, Computer, 20, 10–19.

Curtis, B., Krasner, H., and Iscoe, N. (1988). A field study of the

software design process for large systems, Commn. ACM, 31, 1268–1287.

Humphrey, W.S., Kitson, D.H., and Kasse, T.C. (1989). The State of

Software Engineering Practice: a Preliminary Report. Tech Rept.

CMU/SEI-89-TR-1, Software Engineering Institute, Carnegie Mellon

University, Pittsburgh.

Kellner, M.I. Software Engineering Institute, with panelists Bill

Curtis, Software Engineering Institute, Tom DeMarco, The Atlantic





Systems Guild, Kouichi Kisida, Software Research Associates, Inc.,

Maurice Schlumberger, Cap Gemeini Innovation, Colin Tully, Independent

Consultant for IEEE, 1991, 144–146.




Chương 28: Martin and Carey’s survey 811

CHƢƠNG 28 MARTIN AND CAREY’S SURVEY

OF SUCCESS IN CONVERTING

PROTOTYPES TO OPERATIONAL SYSTEMS

Người dịch: Trịnh Quang Huy

28.1 TỔNG QUAN

The use of prototyping has increased within the ranks of MIS groups

during the last few years; however, a difference of opinion exists as to how

a prototype should be implemented as well as about the steps taken to make





the prototype operational. One school of thought stresses that the prototype

is never meant to become an operational system. Therefore, the languages

used as well as the platform selected should be experimental. On the other

side of the argument are those stressing that the prototypical system should

be as close to the operational system as possible. This disagreement has left

MIS organizations without clear guidelines for the use of prototypes in their

companies.

Xu hƣớng sử dụng prototype trong nhóm MIS ngay cang tăng trong

suốt vai năm trở lại đây.Tuy nhiên cũng có những ý kiến khác nhau về

prototype. Một luồng suy nghĩ nhấn mạnh rằng prototype không bao giờ có

nghĩa để trở thanh 1 hệ thống thực thi.Vì vậy ngôn ngữ đƣợc sử dụng tốt

nhƣ la nền tảng đƣợc chọn để sử dụng.Trên khia cạnh khác thì cũng có

những ý kiến nhấn mạnh rằng bản thiết kế prototype cũng có thể độc lập

với hệ thống lam ra nếu có thể.Sự không đồng ý nay bắt nguồn từ những

việc sử dụng prototype không đúng qui tắc trong những công ty của họ.

Martin and Carey (1991) conducted an extensive survey of a sector

of MIS shops within the manufacturing industry and found that ―prototype

models were usually not thrown away, prototypes were usually

programmed in the same language as the operational system, prototyping in

third generational languages was common, and prototyping models were

documented as they were developed‖. These findings, although contrary to

much of the literature on prototyping, are important in that they open a

fresh perspective on an important topic.





Martin va Carey (1991) đã thấy đƣợc rằng ―mô hình prototype

thƣờng không phải la kiểu ―thrown away‖ (tức la lam xong thì vứt

đi),prototype thƣờng đƣợc lập trình trong giống với ngôn ngữ hệ

thống,prototype trong ngôn ngữ thứ 3 đƣợc phổ biến va mô hình prototype

đã đƣợc dẫn chứng nhƣ la những gì họ đã phát triển‖.Đây thật sự la những

sự khám phá mặc dù có nhiều tai liệu có nội dung đối lập về prototype, và

quan trọng trong việc mở ra những khia cạnh mới trong đề tai quan trọng

này.

According to Martin and Carey, ―prototyping is the process of

quickly building a model of the final software system which is used

primarily as a communication tool to assess and meet the information needs

of the user‖.

Theo Martin va Carey thì prototype la quá trình xây dựng mô hình

phần mềm cuối cùng một cách nhanh chóng va nó dùng lam phƣơng tiện

giao tiếp giữa các user với nhau

Their survey found that the use of prototyping was born out of some

major difficulties in the traditional software development approach,

including:

End users do not often possess a clear and concise understanding of

what they need and what they want.





The methodologies and tools currently employed by MIS, data-flow

diagrams and the like cannot demonstrate the workings of an actual

system to the liking, or understanding, of a naive end user.

As the development team grows, so does the complexity of the task of

communication between group members.

Systems developed along traditional lines are often difficult to learn

and use.

As the technology becomes more complex, so do the systems created.

As a result, systems are often developed over longer time periods.

Traditional approaches have been plagued by late delivery and costly

overruns.

It comes as no surprise to MIS staff that a rather large application

development backlog exists. According to Martin and Carey, ―the users

who requested them are frustrated, disillusioned, and ready to revolt‖.

Khảo sát của họ đã cho thấy đƣợc rằng việc sử dụng prototype khác

với những cách tiếp cận phần mềm truyền thống,bao gồm:

End users thƣờng không hiểu về những gì họ cần va họ muốn





Những phƣơng pháp va công cụ hiện tại đƣợc thuê bởi MIS,sơ đồ DFD

va những gì thuộc dạng nhƣ vậy không thể chứng minh rằng sự hoạt

động của những hệ thống thật sự giống va hiểu những yêu cầu của end

users

Khi ma team coding phát triển nhiều về số lƣợng thì sự phức tạp trong

khâu liên lạc giữa những thanh viên với nhau sẽ trở nên khó khăn

Hệ thống ma đƣợc phát triển dựa trên những phƣơng pháp cũ sẽ khó để

học va sử dụng

Những công nghệ ngay cang trở nên phức tạp vì thế một hệ thống đƣợc

tạo ra phải trải qua nhiều giai đoạn

Cách tiếp cận phần mềm truyền thống lam cho hệ thống chậm trễ va

tốn chi phi.

Dựa theo Martin va Carey thì users la những ngƣời ảo tƣởng,và luôn

sẵn sang cho sự thay đổi yêu cầu.


1. In general, the use of prototyping appears more appropriate for

small decision support systems than for large transaction processing

systems. Decision support systems may beneficially use Type I iterative





systems. However, it has also been found that a transaction processing

system might benefit from a Type II throwaway prototype.

1.Tổng quát,việc sử dụng prototype sẽ lam xuất hiện những quyết

định chinh xác hơn để hỗ trợ hệ thống.so với những bộ xử lý lớn của hệ

thống đó.Ta có thể chọn prototype loại 1 va prototype loại 2 để hỗ trợ hệ

thống.

2. In planning a prototype, the development team should take note of

possible differences between the prototype and operational environments,

including:

Language

Range of transactions

Documentation requirements

Computer architecture

Access control

Procedures





2.Trong kế hoạch của một prototype,team phát triển hệ thống sẽ lƣu

ý những sự khác nhau giữa prototype va môi trƣờng phần mềm đich,bao

gồm:

• Ngôn ngữ

• Các loại xử lý

• Tai liệu yêu cầu

• Kiến trúc máy tinh

• Kiến trúc máy tinh

• Quản lý quyền truy cập

• Thủ tục

3. The programming language for the ultimate operational system

should be self-documenting. There are inherent differences between third

generation languages of the operational environment and fourth generation

languages of the prototype environment. These include:

• 4GLs are not as self-documenting as 3GLs.

• 4GLs more than likely have features not available in 3GLs, such as

rapid database inquiry.





• 4GLs often use recursive paths not compatible with the structured, top–

down operational language requirements.

3.Ngôn ngữ lập trình cho hệ thống cuối cùng phải đƣợc tai liệu hóa

4. Of a system‘s inputs, 4.20 percent usually represent 80 percent of

the transaction volume. Therefore, it is this 20 percent that should be the

domain of prototyping, according to Martin and Carey, be cause ―a

prototype is designed to show users what typically will happen, rather than

all that can happen‖.

4.Theo Martin va Carey thì ―một prototype show ra cho ngƣời dùng

tiêu biểu những gì ma phần mềm lam đƣợc,va hơn thế nữa là tất cả những

chức năng của nó―.

5. Turning a prototype into an operational system requires the

development team to account for 100 percent of the system‘s transactions,

rather than the 20 percent accountable in the prototype.

5.Chuyển từ prototype sang một hệ thống trong thế giới thực thì cần

đội ngũ phát triển tốt.Yêu cầu la 100% đều phải chịu trách nhiệm giải quyết

các vấn đề về hệ thống.Thêm vao đó la 20% ngƣời chịu trách nhiệm về

prototype.

6. Prototypes are often run on a microcomputer because:





• The PC is portable for demonstrations.

• It will not be disrupted by operational problems.

• It will not disrupt operations systems.

6.Prototype thƣờng chạy trên những máy tinh nhỏ bởi vì:

• Máy PC có thể linh động để thể hiện

• Nó sẽ không bị phá vơ bởi những vấn đề hoạt động.

• Nó sẽ không phá vơ những hoạt động của hệ thống.

7. Systems are composed of more than just software. Systems also

include hardware, people, and data. The procedures used to tie all ofthese

together in the prototype are far less complex than procedures required in

an operational system.

7.Một hệ thống thƣờng bao gồm nhiều phần mềm.Va những hệ thống

nay cũng bao gồm phần cứng, ngƣời va dữ liệu.Thủ tục sẽ sử dụng tất cả

những gì quen thuộc trong prototype thì sự phức tạp sẽ it hơn thủ tục đƣợc

dùng đến trong hoạt động của hệ thống.

8. Conversion from an iterative prototype to a full operational system

is complex and time consuming. Steps required include:





• Language conversion

• Expansion to full transaction range

• Extensive documentation

• Change from microenvironment to operational platform

• Establishment of access control

• Development of procedures

8. Quá trình chuyển đổi từ một prototype sang một hệ thống đƣa vao

sử dụng đƣợc la rất phức tạp va tốn nhiều thời gian.Những bƣớc yêu cầu

bao gồm:

• Quá trình chuyển đổi ngôn ngữ

• Mở rộng cho đến khi đầy đủ các loại xử lý.

• Mở rộng tai liệu

• Thay đổi từ những môi trƣờng nhỏ sang nền tảng sẵn sang hoạt động

• Thiết lập quyền truy cập

• Phát triển các thủ tục





9. The pain of prototype to operational system conversion can be

eased somewhat by careful development of the prototype. Approaches that

accomplish this goal include:

• The prototype should be programmed in the same language as the

ultimate operational system.

• The prototype should be documented as it evolves.

• The prototype should be developed on the ultimate platform. If the

system is intended for use on a mainframe, then prototype iton a

mainframe

9. Những lỗi ma khi ta chuyển từ prototype sang hệ thống trong thế

giới thực có thể nhẹ nếu có sự cẩn thận trong quá trình thiết kế

prototype.Một cách tiếp cận để hoan thanh mục tiêu nay bao gồm:

• Prototype có thể đƣợc lập trình trong ngôn ngữ giống với ngôn ngữ ma

thiết kế ra hệ thống

• Prototype nên đƣợc tai liệu hóa

• Prototype nên đƣợc phát triển dựa trên nền tảng cuối cùng.Nếu một hệ

thống đƣợc dự định sẽ chạy trên máy mainframe thì prototype của nó

cũng phải đƣợc thiết kế để chạy trên máy mainframe





10. The Martin and Carey survey documented the prototyping charac

teristics discussed above as the techniques used in a segment of commercial

industry. The specific survey results follow:

• Prototype models were not usually thrown away.

• Throwaway prototypes were not actually thrown away; they were often

used for other purposes, such as training.

• Prototypes were usually programmed in the same language as the

operational system.

• Prototyping in 3GLs was not uncommon. According to Martin and

• Carey, ―the power of reusable code for a 3GL such as COBOL should

not be underestimated‖.

• Prototyping models were documented as they were developed.

• The primary goal of the prototype process was user communications

and involvement, not system development efficiency.

10. Kết quả khảo sát của Martin and Carey:

• Mô hình prototype không thƣờng la ―thrown away‖





• Thrownaway prototype ko phải la thrown away,chúng thƣờng đƣợc sử

dụng cho những mục đich khác nhƣ la tranning

• Prototype thƣờng sử dụng ngôn ngữ giống với ngôn ngữ lam ra hệ

thống đó

• Mô hình prototype có thể đƣợc dẫn chứng bằng tai liệu nhƣ khi thiết kế

1 hệ thống thật sự.

• Cái đich của quá trình thiết kế prototype chính là sự liên lạc giữa các

user(cụ thể ở đây la developer va customer).




Chương 29: Khuynh hướnf của Putnam trong sự đo lưởng, dự đoán 823

CHƢƠNG 29 KHUYNH HƢỚNG CỦA PUTNAM

TRONG SỰ ĐO LƢỜNG, DỰ ĐOÁN VÀ KIỂM

SOÁT

Người dịch: Trần Duy Khang

29.1 TỒNG QUAN

Although most MIS managers have read about the different

techniques of measurement, estimation, and control, they are still confused

about how to apply them to their own situations. In addition, a plethora of

information about this topic has served only to confuse these practitioners,

rather than enlighten them.

Mặc dù hầu hết các nha quản lý MIS đã đọc về các kỹ thuật khác

nhau về đo lƣờng, dự toán, va kiểm soát, họ vẫn nhầm lẫn về cách áp dụng

chúng vao hoan cảnh riêng của họ. Ngoai ra, trạng thái thừa của các thông

tin về chủ đề nay đã phục vụ duy nhất để nhầm lẫn những ngƣời hanh nghề,

thay vì day dô chúng.

Putnam estimates that, in the development of complex systems, from

50 to 70 percent of these projects come in late, over budget, or in error.





Most academicians as well as notables in the field, Putnam included,

conclude that one of the major problems is that MIS departments have not

developed the facilities to gauge where they are or where they should be.

The old stand-by, lines of code (LOC), is, according to Putnam, ―the worse

metric‖. Twelve years of Putnam‘s research has shown that ―both the

numerator (number of lines) and the denominator (number of manonths)

vary with a host of factors related to the environment and management

practices in complex, ill-understood, nonlinear ways that cause it to behave

unintuitively‖ (Putnam, 1991). The result is that the LOC metric is wrong

approximately 90 percent of the time.

Putnam ƣớc tinh rằng, trong sự phát triển của các hệ thống phức tạp,

50-70 phần trăm của các dự án nay bị trễ hạn, vƣợt ngân sách hoặc bị lỗi.

Hầu hết các chuyên gia trong lĩnh vực nay, bao gồm Putnam, kết luận rằng

một trong những vấn đề lớn la bộ phận MIS đã không phát triển các cơ sở

để đo lƣờng ở nơi họ đang hoặc nơi họ cần. Các đứng tuổi-by, dòng mã

(LOC), la, theo Putnam, "những số liệu tồi tệ hơn". Kết quả nghiên cứu

trong 12 năm của Putnam đã chỉ ra rằng "cả hai tử số (số dòng) va mẫu số

(số của con ngƣời - tháng) khác nhau với một máy chủ của các yếu tố liên

quan đến môi trƣờng va thực tiễn quản lý phức tạp, khó hiểu, phi tuyến gây

ra những cách ma nó cƣ xử unintuitively ― (Putnam, 1991). Kết quả la các

số liệu (LOC)la sai khoảng 90 phần trăm của thời gian.

In the late 1980s and in the 1990s, emphasis on measurement has

been renewed. MIS shops are now attempting to evaluate the reliability of





soft ware. In this chapter, a series of issues is raised in this area that the

professional intent on installing a measurement program will want to

review carefully

Trong cuối thập niên 1980 va trong những năm 1990, sự đánh giá đã

đƣợc coi trọng trở lại. MIS cửa hang va đang cố gắng để đánh giá độ tin cậy

của phần mềm. Trong chƣơng nay, một loạt các vấn đề đƣợc nêu ra trong

khu vực nay có mục đich chuyên nghiệp về cai đặt một chƣơng trình đo

lƣờng sẽ muốn xem xét cẩn thận


1. Putnam defines a set of workable metrics as that which is simple, single

valued, and which the boss understands. The following is the set that he

recommends:

• Quantity of function (such as source lines of code and function points)

• Schedule (the elapsed calendar time)

• People (the monthly head count)

• Effort (the sum of the people applied over time)

• Defects (the number of valid problem trouble reports over some time

interval. This can easily be converted to mean time to defect.)





Putnam định nghĩa một tập hợp các số liệu hoan toan khả thi vì đó la

đơn giản, duy nhất có giá trị, va đó la ông chủ hiểu đƣợc. Sau đây la tập ma

ông đề nghị:

• Số lƣợng các chức năng (nhƣ các dòng mã nguồn va các điểm chức

năng)

• Lịch trình (thời gian trôi qua lịch)

• Số giờ lam việc hằng tháng

• Nỗ lực (tổng của ngƣời dân đƣợc áp dụng theo thời gian)

• Số lƣợng các báo cáo vấn đề rắc rối có giá trị hơn một số khoảng thời

gian nay có thể dễ dang đƣợc chuyển đổi sang có nghĩa la thời gian để

khuyết tật..

2. Making total quality realistic in a software engineering environment:

• Take quality seriously.

• Take productivity improvement seriously.





• Measure progress with the right metrics.

• Set realistic goals.

• Focus MIS investment and education on the weaker spots.

• Aim for a small gain every day.

Tạo chất lƣợng tổng số trong môi trƣờng thực tế công nghệ phần

mềm:

• Cải thiện chất lƣợng

• Cải thiện năng suất.

• Đo lƣờng sự tiến bộ với các số liệu đúng.

• Đặt mục tiêu thực tế.

• Tập trung đầu tƣ va giáo dục cho các MIS về những điểm yếu.

• Mục tiêu cho một lợi nhỏ mỗi ngay.

3. Use statistical process control on projects. This technique couples

statistical techniques with the metrics outlined above. The basics of

software control:





• Milestone accomplishments (schedule)

• Effort expenditure (in man-months)

• Code production

• Defect identification (trouble reports)

Sử dụng thống kê để kiểm soát các dự án. Kỹ thuật thống kê theo lặp

trình cặp đôi với số liệu nêu ở trên. Các vấn đề cơ bản của phần mềm kiểm

soát:

• Lịch trình thực hiện

• Nỗ lực - kinh phí (hàng tháng)

• Code đƣợc trình bay

• Báo cáo sự cố mắc phải

These statistics should be captured each month and compared with

the plan.

Sự thống kê nay đƣợc thực hiện hằng tháng va đƣợc đối chiếu với kế

hoạch lý thuyết

4. Unfavorable variations indicate slippage and overrun.





Chỉ ra các biến đổi không thuận lợi để lam giảm sự lan tran của

chúng.

5. Statistical software packages should be used because a simple

extrapolation to predict the future is not useful. Statistical curve-fitting

techniques, readily available in this type of software, are a desirable

tool for control.

Nên sử dụng các phần mềm thống kê đóng gói bởi vì một phép suy

diễn đơn giản để dự đoán tƣơng lai không phải la có ich. Thống kê đƣờng

cong-kỹ thuật lắp, sẵn trong loại phần mềm, la một công cụ mong muốn để

điều khiển.

6. Putnam‘s outlook for the future: Control offices will be established to

measure, plan, and controlprojects. This will be called the software-

data repository and will be responsible for measuring process–

productivity improvement as well as for generating realistic and

consistent work plans for the individual project teams.

Putnam 's Nhận định cho tƣơng lai: chức vụ kiểm soát sẽ đƣợc thanh

lập để đo lƣờng, kế hoạch va điều khiển dự án. Điều nay sẽ đòi hỏi các kho

dữ kiệu phần mềm, chịu trách nhiệm việc đo lƣờng quá trình cải thiện năng

suất xử lý cũng nhƣ tạo ra kế hoạch công tác thực tế va phù hợp cho các đội

dự án riêng lẻ.





7. Executive managers will begin to take a more active interest in

development because they realize that it is strategically important to the

organization.

Giám đốc quản trị sẽ chủ động quan tâm hơn trong phát triển bởi vì

họ nhận ra rằng đó la chiến lƣợc quan trọng để tổ chức




Chương 30: Kỹ thuật của Sprague cho quản trị cấu hình phần mềm 831

CHƢƠNG 30 KỸ THUẬT CỦA SPRAGUE CHO

QUẢN TRỊ CẤU HÌNH PHẦN MỀM TRONG

KỸ NGHỆ PHẦN MỀM DỰA VÀO ĐO LƢỜNG

Người dịch: Huỳnh Lâm Linh

30.1 TỔNG QUAN

The role of software configuration management (SCM) has increased

in significance over the last few years. Sprague enumerates several reasons

for SCM‘s expanded role:





Vai trò của quản lý cấu hình phần mềm (SCM) đã tăng tầm quan

trọng trong vai năm qua. Sprague liệt kê một số lý do mở rộng vai trò của

SCM:

The size of software projects has grown meaning that there are more

components to manage.

Kich cơ của dự án phần mềm đã tăng trƣởng, nghĩa la có thêm các

thanh phần để quản lý.

The introduction of CASE tools has increased the number and types

of machine-readable objects that must be maintained.

New computing topologies and application structures have come on

the scene.

Các cấu trúc topo tinh toán mới va cấu trúc ứng dụng đã đến trên ngữ

cảnh.

These reasons, coupled with an increasing awareness of the

competitive and strategic organizational issues vis-a-vis technology, have

placed an emphasis on being able to control the technology environment.

Những lý do nay, cùng với một nhận thức ngay cang tăng của tổ

chức cạnh tranh va chiến lƣợc các vấn đề công nghệ vis-a-vis, đã nhấn

mạnh vao việc có thể để kiểm soát môi trƣờng công nghệ.





Sprague‘s definition of SCM expands on the traditional meaning,

which is control over the source code. Sprague emphasizes that SCM

should con-sider all of the work products associated with a project

including:

• Contracts

• Memorandums

• Letters

• Project plans

• Schedules

• System and software requirements

• Design documentation

• Source, object, and executable code

• Data

• Build and installation files

• Test descriptions, results, and reports

• Systems and network options





• Metrics

• Technical reports

• Education and training documents

• Presentation slides

• Videos

• Business models and plans

Định nghĩa của Sprague về SCM mở rộng dựa trên ý nghĩa truyền

thống,cái ma kiểm soát trên mã nguồn. Sprague nhấn mạnh rằng SCM nên

xét tất cả các sản phẩm công việc liên quan đến một dự án, bao gồm:

• Hợp đồng

• Biên bản ghi nhớ

• Thƣ

• Kế hoạch dự án

• Lịch lam việc

• Các yêu cầu hệ thống va phần mềm





• Thiết kế tai liệu hƣớng dẫn

• Nguồn, file object, va mã thực thi

• Data

• Các file build va file cai đặt

• Kiểm tra mô tả, kết quả, va báo cáo

• Hệ thống va các tùy chọn mạng

• Metrics

• Các báo cáo kỹ thuật

• Tai liệu training

• Các slide trình diễn

• Các video

• Kế hoạch va mô hình kinh doanh

SCM is a formal engineering discipline, as described in the 1983

IEEE standard 828–1983. ―Standard for Software Configuration

Management Plans‖ is the means through which the integrity of the

software product is recorded, communicated, and controlled. Derived from





hardware-oriented configuration management (CM), SCM‘s objective is the

cost-effective management of a software system‘s life cycle and the

resultant configuration.

As Sprague (1991) suggests, ―it is the process of ensuring the

software and associated products are visible, traceable, and formally

controlled throughout their evolution‖.

SCM la một lĩnh vực kỹ thuật chinh thức, nhƣ mô tả trong IEEE

1983 828-1.983. "Tiêu chuẩn đối với kế hoạch quản lý cấu hình phần mềm―

la phƣơng tiện ma qua đó sự toan vẹn của các sản phẩm phần mềm đƣợc

ghi lại, truyền đạt, va kiểm soát. Bắt nguồn từ quản lý cấu hình (CM) định

hƣớng theo phần cứng, mục tiêu của SCM la sự quản lý chi phi hiệu quả

của vòng đời một hệ thống phần mềm va cấu hình các kết quả. Nhƣ

Sprague (1991) cho thấy, "nó la quá trình đảm bảo phần mềm va các sản

phẩm liên quan có thể nhìn thấy, theo dõi, va chinh thức kiểm soát trong

suốt sự tiến hóa của nó‖.

Perhaps the most important concept behind SCM is baseline

management. A baseline is a specification or product, formally reviewed

and agreed upon, which thereafter serves as the basis for further develop-

ment — one that can be changed only through formal change control

procedures.





Có lẽ các khái niệm quan trọng nhất đằng sau SCM la sự quản lý các

base-line. Một baseline la một đặc tả kỹ thuật hoặc sản phẩm, đƣợc xem

xét và thoả thuận chinh thức, ma sau đó phục vụ nhƣ la cơ sở cho sự phát

triển hơn nữa - trong nó đó có thể đƣợc thay đổi chỉ có thông qua các thủ

tục kiểm soát thay đổi.

Four functions are employed to manage the baseline and its products:

configuration identification, configuration control, configuration status

accounting, and configuration auditing. This chapter presents an overview

of SCM as well as a process for implementing it.

Bốn chức năng đƣợc dùng để quản lý baseline va các sản phẩm của

nó: cấu hình xác định (configuration identification), cấu hình điều khiển

(configuration control), cấu hình tình trạng kế toán (configuration status

accounting) va cấu hình kiểm toán (configuration auditing). Chƣơng nay

giới thiệu tổng quan về SCM cũng nhƣ quá trình thực hiện nó.


Configuration identification is the process of designating the

configuration items in a system and recording their characteristics. This

process entails determination of the constituent parts of the software and of

the relationship of those parts, assignment of a label and a name to each

part, and graphical depiction of the identified software.





Cấu hình nhận dạng (configuration identification) la quá trình chỉ

định các mục cấu hình trong hệ thống va ghi lại các đặc trƣng của nó. Quá

trình nay đòi hỏi phải xác định các bộ phận cấu thanh của phần mềm va các

mối quan hệ giữa các thanh phần nay, đánh nhãn va tên cho mỗi phần, thể

hiện đồ họa cho phần mềm đƣợc xác định.

Configuration control provides the administrative mechanism for

precipitating, preparing, evaluating, approving or disapproving, and

implementing every change to all the products in a baseline. The purpose of

configuration control is to assure:

• Comprehensive system impact analysis

• Cost and schedule impact analysis

• Optimum and coordinated implementation

• Accurate configuration records

• Supportability

Cấu hình kiểm soát cung cấp cơ chế hanh chinh, chuẩn bị, đánh giá,

phê duyệt hoặc từ chối, va thực hiện mọi thay đổi đến tất cả các sản phẩm

trong một baseline. Mục đich của cấu hình kiểm soát la để đảm bảo:

• Sự phân tich tác động hệ thống một cách toan diện





• Chi phi va tác động lịch lam việc

• Tối ƣu va phối hợp thực hiện

• Tinh chinh xác các bản ghi cấu hình

• Khả năng hỗ trợ

Configuration status accounting is the process of collecting,

recording, and reporting on configuration control information. The

following information is typically maintained as well as archived:

• The time at which each baseline was established

• The time at which each item and change was included in the baseline

• A description of each software configuration item

• The status of each software-related engineering change

• The description of each software change

• The documentation status for each baseline

• The changes planned for each identified future baseline.





Cấu hình tình trạng kế toán la quá trình thu thập, ghi âm, va báo cáo

trên thông tin điều khiển cấu hình. Nhữnghông tin sau thƣờng đƣợc duy trì

cũng nhƣ lƣu trữ:

• Thời gian ma ở đó mỗi baseline đƣợc hoan thanh

• Thời gian ma mỗi mục va thay đổi đƣợc đƣa vao trong baseline

• Mô tả của mỗi mục cấu hình phần mềm

• Tình trạng document cho mỗi baseline

• Tình trạng của mỗi sự thay đổi lỹ thuật liên quan đến phần mềm

• Các mô tả của mỗi phần mềm thay đổi

• Những kế hoạch thay đổi cho từng baseline xác định trong tƣơng lai

Configuration auditing is the process of verifying that all required

configuration items have been produced, that the current version agrees

with the specified requirements, that the technical documentation describes

the configuration items, and that all change requests have been resolved.

Cấu hình kiểm toán la quá trình xác minh rằng tất cả các yêu cầu cấu

hình đã đƣợc thực hiện, ma phiên bản hiện tại thich hợp với các yêu cầu

quy định (các document kỹ thuật mô tả các mục cấu hình), va tất cả yêu

cầu thay đổi đã đƣợc giải quyết.





30.3 THỦ TỤC PHÁT TRIỂN MỘT QUY TRÌNH SCM

1. Develop an SCMP.

• The first step is to develop a plan tailored to the needs of the project

and organization. The plan addresses the four components of SCM

described above. The SCMP should address thefollowing:

• The characteristics of the work products controlled

• The work products to be controlledThe different interfaces to be

managed

• The expected duration of the project

• The available resources

• The organizational responsibilities of project members

• The identification procedures that will be used on each project

• The procedures for checking items into and out of the software libraries

• The procedures for managing the change process

• The authority, membership, and decision-making process of the group

charged with this information‘s control





• The procedures to create and approve the promotion of a baseline

• The membership data that will be collected, stored, and reported

• The procedures to collect, store, and report the measurement data

• The mechanism to transfer objects between repositories

• The procedures for releasing versions

• The automated tools that will be used to support the SCM process

• The procedure for recovering work products in the event of a Disaster

Phát triển một kế hoạch SCM.

• Bƣớc đầu tiên la phát triển một kế hoạch phù hợp với nhu cầu của dự

án va tổ chức. Kế hoạch nay nhắm đến bốn thanh phần của SCM đƣợc

mô tả ở trên. SCMP nên nhắm đến:

• Các đặc tinh của các sản phẩm công việc ma đƣợc kiểm soát

• Các sản phẩm công việc phải đƣợc kiểm soát

• Các giao diện khác nhau nên đƣợc quản lý

• Thời hạn dự kiến của dự án





• Các nguồn lực sẵn có

• Các trách nhiệm mang tinh tổ chức của các thanh viên dự án

• Các thủ tục nhận dạng sẽ đƣợc sử dụng trên từng dự án

• Các thủ tục kiểm tra ghi vao va ra của các thƣ viện phần mềm

• Các thủ tục để quản lý quá trình thay đổi

• Các quá trình ủy quyền, va ra quyết định của nhóm đƣợc giao với sự

kiểm soát của các thông tin nay

• Các thủ tục để tạo ra va chấp thuận việc xúc tiến của một baseline

• Dữ liệu thanh viên ma đƣợc thu thập, lƣu trữ, va báo cáo

• Các thủ tục để thu thập, lƣu trữ, va báo cáo về dữ liệu đo lƣờng

• Các cơ chế để chuyển các đối tƣợng giữa các kho

• Các thủ tục phát hanh các phiên bản

• Các công cụ tự động ma sẽ đƣợc sử dụng để hỗ trợ các quá trình SCM

• Thủ tục phục hồi các sản phẩm công việc trong trƣờng hợp có sự cố

2. Implement the SCMP:





This step requires that those charged with the SCM take actions to

ensure that it is implemented. This implies that the SCMP be periodically

reviewed — and revised, if necessary.

Thực hiện kế hoạch SCM:

Bƣớc nay đòi hỏi những cái đƣợc giao với SCM phải đƣợc tiến hanh

để đảm bảo kế hoạch SCM đƣợc thực thi. Điều nay ngụ ý rằng kế hoạch

SCM đƣợc định kỳ xem xét lại - va sửa đổi, nếu cần thiết.

3. Identify and control the work products.

This task is accomplished by identifying each object checked into the

repository, securing an electronic or paper copy of the object, placing the

object in a location where it cannot be modified, and, finally, making a log

entry describing the events that took place during the transaction.

Xác định va kiểm soát các sản phẩm công việc

Nhiệm vụ nay đƣợc thực hiện bằng cách xác định mỗi đối tƣợng

đƣợc kiểm tra vao kho, bảo vệ một bản sao điện tử hoặc giấy của đối tƣợng,

đặt đối tƣợng ở một vị tri ma nó không thể bịthay đổi va, cuối cùng, lam

cho một mục nhật ký mô tả những sự kiện ma đã diễn ra trong quá trình

giao dịch.

4. Collect, store, and report preliminary measurements.





This should be done at each phase of the development project. The

benefits derived from collecting and analyzing the measurements at each

stage provide the manager with insight into how the project is doing in

terms of cost, schedule, and size.

Thu thập, lƣu trữ, va báo cáo sơ bộ các đo đạt

Điều nay nên đƣợc thực hiện ở từng giai đoạn của dự án. Những lợi

ích thu đƣợc từ thu thập va phân tich các đo đạt ở từng giai đoạn cung cấp

cho ngƣời quản lý với cái nhìn sâu sắc lam thế nao dự án đƣợc thực hiện về

chi phi, lịch trình, va kich cơ.

5. Transfer the work products to the work group responsible for SCM,

who will secure and control it.

Chuyển giao các sản phẩm công việc vao nhóm lam việc chịu trách

nhiệm về SCM, những ngƣời sẽ bảo mật va kiểm soát nó.

6. Deliver the work products to the customer.

Cung cấp những sản phẩm lam việc với khách hang.

7. Collect, store, and report the final measurements to project members

and users, as well as to senior management.





Thu thập, lƣu trữ, va báo cáo các số đo cuối cùng cho các thanh viên

dự án va ngƣời sử dụng, cũng nhƣ cho quản lý cấp cao.


Sprague, K.G. (1991). The role of software configuration

management in a measurement-based software engineering program, ACM

SIGSOFT Software Eng. Notes, 16, 1–10.


Bryan, W.L. and Siegel, S. (1988). Software Product Assurance:

Techniques for Reducing Software Risk, Elsevier Science Publishing, New

York.

Forte, G. (1990). Configuration management survey, CASE Outlook,

90, 24–51.

Humphrey, W.S. (1989). Managing the Software Process, Addison-

Wesley Publishing Co., Reading, MA.

Tichy, W.F. (1989). Tools for software configuration management,

11th International Conference on Software Engineering, May 15–18, 1989.




Chương 31: Hệ phương pháp luận của Cobin 847

CHƢƠNG 31 HỆ PHƢƠNG PHÁP LUẬN CỦA

CORBIN VỀ THIẾT LẬP MÔI TRƢỜNG

PHÁT TRIỂN PHẦN MỀM

Người dịch: Nguyễn Thị An Nhơn

31.1 TỔNG QUAN

The software development environment (SDE) is actually the

integration of a number of processes, tools, standards, methodologies, and





related elements whose purpose is to provide a framework for building

quality software (Corbin, 1991). This chapter discusses the elements of

SDE and shows how to develop one.

Môi trƣờng phát triển phần mềm (SDE) la trộn lẫn của một số quy trình,

công cụ, tiêu chuẩn, phƣơng pháp, va các yếu tố liên quan với mục đich la cung

cấp một cấu trúc nền tảng để xây dựng phần mềm chất lƣợng (Corbin, 1991).

Chƣơng nay ban về các yếu tố của SDE va cho thấy lam thế nao để phát triển

SDE.


1. The elements of SDE

• Project management

• Business plan

• Architecture

• Methodologies

• Techniques

• Tools

• Metrics





• Policies and procedures

• Technology platform

• Support

• Standards

• Education and training

Các nhân tố của SDE

• Quản lý dự án

• Kế hoạch kinh doanh

• Cấu trúc

• Hệ phƣơng pháp

• Kỹ thuật

• Các công cụ

• Độ đo

• Các chinh sách va các thủ tục

• Nền tảng công nghệ





• Hỗ trợ

• Các tiêu chuẩn

• Giáo dục va đao tạo.

2. The benefits of SDE

• Improved problem definition

• Selection of the ―right‖ problem according to the customer

• Joint customer and IS responsibility and accountability

• Acknowledgment of customer ownership of system

• Reduced costs of systems development and maintenance

• Reusability of software, models, and data definitions

• Acceptance of the disciplined approach to software engineering using a

consistent methodology

• Productivity improvements through team efforts and tools such as

CASE.

Lợi ich của SDE

• Định nghĩa các vấn đề đƣợc chinh xác hơn.





• Việc lựa chọn vấn đề theo đúng ý khách hang.

• Nhóm khách hang va trách nhiệm về hệ thống thông tin (IS) va trách

nhiệm.

• Thừa nhận quyền sở hữu hệ thống của khách hang.

• Giảm chi phi của các phát triển va bảo trì hệ thống.

• Tái sử dụng phần mềm, các mô hình, va định nghĩa dữ liệu.

• Chấp nhận phƣơng pháp có kỷ luật thống nhất vao kỹ thuật phần mềm

(software engineering).

• Năng suất cải tiến thông qua các nỗ lực của đội va các công cụ nhƣ

CASE.

3. Sample goals of SDE

• Reduce systems development costs

• Reduce maintenance costs

• Reduce MIS turnover rate

These goals should be quantifiable wherever possible. For example,

the first goal could be stated as ―reduce systems development costs by 50

percent over the next five years‖.





Các mục đich mẫu của SDE

• Giảm chi phi phát triển hệ thống.

• Giảm chi phi bảo trì.

• Giảm tỷ lệ MIS turnover.

Các mục đich nên đƣợc địn lƣợng bất cứ khi nao cần thiết. Vi dụ:

mục đich đầu tiên có thể đƣợc phát biểu la ―giảm 50% chi phi phát triển hệ

thống trong vòng 5 năm tới‖.

4. Architecture

Many organizations do not have a formal, documented architecture.

There are three types:

• Business architecture is a model of the business and identifies such

things as processes and entities in the form of models.

• Computing architecture, at a minimum, identifies hardware, software,

and data communications. This breaks out into components such as

operating systems, data resource management, network protocols, and

user interface.

• Enterprise architecture is a combination of business and computing

architectures.





Kiến trúc

Nhiều tổ chức không có một kiến trúc chinh thức va đƣợc tai liệu hóa.

Có 3 loại:

• Kiến trúc kinh doanh: la một mô hình kiến trúc của doanh nghiệp va

xác định những thứ nhƣ quy trình va các tổ chức dƣới hình thức các mô

hình.

• Kiến trúc máy tinh, ở mức tối thiểu, xác định phần cứng, phần mềm, va

việc truyền thông dữ liệu. Điều nay chia ra thanh các thanh phần nhƣ

hệ thống điều hanh, quản lý tai nguyên dữ liệu,mạng lƣới giao thức, va

giao diện ngƣời dùng. Enterprise architecture is a combination of

business and computing architectures.

• Kiến trúc doanh nghiệp la một sự kết hợp giữa kiến trúc kinh doanh va

kiến trúc máy tinh

5. Business plan

• Create a steering committee that provides direction to the MIS

function.

• Translate the organization‘s business plan into an actionable MIS plan

that supports the company‘s goals and objectives.





• The steering committee should be responsible for funding projects,

setting priorities, resolving business issues, and reviewing MIS policies

and procedures.

• Kế hoạch kinh doanh

• Tạo một ban chỉ đạo hƣớng đi đến chức năng MIS.

• Chuyển kế hoạch kinh doanh của tổ chức thanh kế hoạch MIS để hỗ trợ

mục tiêu của công ty.

• Ban chỉ đạo phải có trách nhiệm cấp vốn cho dự án, thiết lập mức độ

ƣu tiên, giải quyết các vấn đề kinh doanh, va xem xét các chính sách và

thủ tục MIS.

6. Education and training

Make sure that analysts, programmers, and users are trained and

ready to start the development project. Training might include the

following:

• Software engineering concepts

• Prototyping

• System development life cycle





• Joint application development

• Software quality assurance and testing

• Project management

• Data and process modeling

• CASE

Giáo dục va đao tạo:

Đảm bảo rằng các nha phân tich, lập trình, va ngƣời dùng đƣợc huấn

luyện va sẵn sang để bắt đầu phát triển dự án. Đao tạo có thể bao gồm:

• Các khái niệm công nghệ phần mềm

• Chu kỳ phát triển hệ thống

• Nhóm phát triển ứng dụng.

• Đảm bảo chất lƣợng phần mềm va testing.

• Quản lý dự án.

• Mô hình hóa dữ liệu va tiến trình

• CASE.





7. Methodologies

Whether the methodology chosen by the MIS department is a

standard one, supplied from a vendor, or developed internally, the MIS

group must follow one to ensure consistency from project to project. This

will enable staff to be able to move from project to project without

retraining while, at the same time, ensuring consistent deliverables.

Questions to ask when selecting a methodology are:

• Does your methodology support the entire systems development life

cycle?

• Does it include maintenance?

• Is it clearly documented?

• Does it focus on deliverables instead of activities?

• Is it CASE tool-independent?

• Can you use your metrics and techniques with it?

Hệ phƣơng pháp luận

Cho dù các phƣơng pháp lựa chọn bởi bộ phận MIS la một phƣơng pháp

chuẩn, cung cấp từ nha cung cấp, hoặc đƣợc phát triển nội bộ, nhóm MIS phải

tuân theo một phƣơng pháp để bảo đảm tinh nhất quán từ dự án để dự án. Điều





nay sẽ cho phép nhân viên để có thể di chuyển từ dự án nay sang dự án khác

ma không cần đao tạo lại va đảm bảo sản phẩm cuối cùng thống nhất. Các câu

hỏi khi nao chọn một hệ phƣơng pháp luận la:

• Liệu phƣơng pháp luận của bạn hỗ trợ phát triển toan bộ chu trình hệ

thống?

• Liệu nó bao gồm việc bảo dƣơng?

• Có đƣợc tai liệu hóa rõ rang không?

• Liệu nó có tập trung vao sản phẩm hƣớng đến thay vì các hoạt động?

• Có độc lập với công cụ CASE không?

• Bạn có thể sử dụng độ đo va kỹ thuật của bạn với nó?

8. Project Management

Questions to ask include:

• Do you have a formal project management discipline in place?

• Do you have a training program to support this?

• Is a software tool used?

• Do you have program planning and control to help manage the project?





• Do you get routine reports showing the project work breakdown

structure, status reports, resource loading, and cost projections?

• Is there a formal reporting mechanism done on a timely basis to resolve

problems?

Quản lý dự án:

Các câu hỏi để hỏi bao gồm:

• Bạn đã có một kỷ luật quản lý dự án chinh thức tại địa điểm?

• Bạn đã có một chƣơng trình đao tạo để hỗ trợ chƣa?

• Có sử dụng công cụ nao không?

• Bạn có chƣơng trình lập kế hoạch va kiểm soát để giúp quản lý dự án?

• Bạn nhận đƣợc báo cáo định kỳ trình bay những cấu trúc công việc của

dự án, báo cáo về tình trạng, tai nguyên, va dự trù chi phi?

• Có cơ chế báo cáo chinh thức thực hiện một cách kịp thời để giải quyết

vấn đề?

9. Standards

Some of the areas in which standards are required are:





• Systems analysis and design

• Data administration

• Database administration

• Systems testing

• Prototyping

• Documentation

• Data entry

• Systems production

Change/configuration management questions to ask:

• Have you identified all of the standards required to support your

• SDE?

• Do you have someone responsible for developing and maintaining

standards?

Tiêu chuẩn

Một số lĩnh vực, trong đó các tiêu chuẩn đƣợc yêu cầu la:





• Phân tich va thiết kế hệ thống

• Quản trị dữ liệu.

• Quản trị cơ sở dữ liệu.

• Thử nghiệm hệ thống.

• Prototyping

• Tai liệu hóa.

• Dữ liệu nhập

• Sản xuất hệ thống.

Các câu hỏi về Quản lý thay đổi / cấu hình:

• Bạn đã xác định đƣợc tất cả các tiêu chuẩn bắt buộc để hỗ trợ SDE của

bạn chƣa?

• Bạn có một ngƣời chịu trách nhiệm về các tiêu chuẩn phát triển va duy

trì không?

10. Support options:

• External consulting





• A sharing arrangement where you can provide services in exchange for

those needed

• User groups

• Special-interest groups

Các lựa chọn về hỗ trợ:

• Tƣ vấn ngoai.

• Cam kết chia sẻ bằng cách cung cấp các dịch vụ để trao đổi những điều

ma bạn cần.

• Nhóm ngƣời dung.

• Nhóm quan tâm đặc biệt.

11. Automated tool questions:

• Have you identified the tools you need in the SDE?

• Have they been approved, acquired, and installed?

• Do they support the methodologies?

• Do they support the technology platform?





• Do they support the standards?

• Is technical support available to support the tools?

• Do you have templates for use in systems development?

• Do you have a data dictionary or repository for your data?

• Do you have tools to support each phase of the life cycle?

Câu hỏi về Công cụ tự động:

• Bạn đã xác định được các công cụ bạn cần trong SDE chưa?

• Các công cụ đã đƣợc chấp thuận, mua lại, va cai đặt không?

• Chúng có hỗ trợ các phƣơng pháp luận?

• Chúng có hỗ trợ nền tảng công nghệ?

• Chúng có hỗ trợ các tiêu chuẩn?

• Có hỗ trợ kỹ thuật cho các công cụ không?

• Bạn có template để sử dụng trong việc phát triển hệ thống không?

• Bạn đã có một từ điển dữ liệu hoặc kho dữ liệu của bạn?





• Bạn có công cụ để hỗ trợ mỗi giai đoạn của chu kỳ phát triển hệ thống

không?




Chương 33: Bảy nguyên tắc của chất lượng 847

CHƢƠNG 32 BÀY NGUYÊN TẮC CỦA CHẤT

LƢỢNG

Người dịch: Nguyễn Tấn

32.1 TỔNG QUAN

YK Shetty, la một giáo sƣ tại khoa quản lý nha nƣớc của trƣờng đại

học kinh tế Utah va la đồngbiên tậpcủa The Quest for Competitiveness

(QuorumBooks, 1991), cho thấy rằng mặc dù hầu hết các công ty điều hanh

đều tin rằng chất lƣợng va năng suất la những vấn đề quan trọng nhất phải

đối mặt trong kinh doanh.

Thế nhƣng nhiều công ty lại không biết lam thế nao để đạt đƣợc

nó. Vì vậy Shetty đã nghiên cứu từ danh sách 16tổ chức đã rất thanh





côngtrong việc giải quyết thách thức nay: Hewlett-Packard,IBM, Procter và

Gamble, Johnson & Johnson, Maytag, DanaCorporation,Intel,

TexasInstruments,3M, Caterpillar, Delta,Marriott,McDonald's, Dow

Chemical, Xerox, và General electric.

Từ đó Shetty đã đề ra 7 nguyên tắc sau để định hƣớng cho các công

ty giải quyết bai toán cho mình.

32.2 THỦ TỤC/ VẤN ĐÊ/ CHÍNH SÁCH

Principle 1: Quality improvement requires the firm commitment of

top management. All top management, including the CEO, must be

personally committed to quality. The keyword here is ―personally‖. Many

CEOs pay only lip service to this particular edit. Therefore, top

management must be consistent and reflect its commitment through the

company‘s philosophy, goals, policies, priorities, and executive behavior.

Steps that management can take to accomplish this end include:

Nguyên tắc 1: Nâng cao chất lƣợng đòi hỏi sự tham gia của những

ngƣời quản lý hang đầu của công ty.Tất công ty cả quản lý cao nhất, bao

gồm cả các giám đốc điều hanh(CEO), phải tìm ra những phƣơng án thich

hợp nhất để đề ra mục tiêu cụ thể va chinh sách hỗ trợ cho việc nâng cao

chất lƣợng sản phẩm. Cụ thể hơn sẽ có thể bao gồm những việc sau:





Establish and communicate a clear vision of corporate philosophy,

principles, and objectives relevant to product and service quality.

Có một tầm nhìn rõ rang về tinh chất của công ty, để từ đó đề ra các

nguyên tắc va mục tiêu cụ thể có liên quan đến sản phẩm va chất lƣợng

dịch vụ.Cụ thể la:

• Channel resources toward these objectives and define roles and

responsibilities in this endeavor.

• Invest time to learn about quality issues and monitor the progress of

any initiatives.

• Encourage communication between management and employees,

among departments, and among various units of the firm and

customers.

• Be a good role model in communication and action.

• Kênh nguồn lực hƣớng tới những mục tiêu va xác định vai trò va trách

nhiệm rõ rang trong việc nâng cao chất lƣợng sản phẩm dịch vụ.

• Đầu tƣ thời gian để tìm hiểu về các vấn đề chất lƣợng va giám sát tiến

độ để đƣa ranhững sáng kiến hay.





• Khuyến khich giao tiếp giữa quản lý va nhân viên,giữa các sở, ban va

giữa các đơn vị khác nhau của công ty vakhách hang.(điều nay không

phần không nhỏ vao thanh công của Apple)

• Hãy la một mô hình tốt vai trò trong giao tiếp va hanh động.

Principle 2: Quality is a strategic issue.

• It must be a part of a company‘s goals and strategies.

• Must be consistent with and reinforce a company‘s other strategic

• objectives.

• It must be integrated into budgets and plans — the way the company

does business.

• It must be a corporate mission with planned goals and strategies.

• Quality should be at the heart of every action.

Nguyên tắc 2: Chất lƣợng la một vấn đề chiến lƣợc:

• Nó phải la một phần của mục tiêu va chiến lƣợc của công ty.

Phải luôn luôn củng cố va điều chỉnh phù hợp chiến lƣợc để đạt mục

tiêu.

• Nó phải đƣợc tinh toán vao ngân sách kế toán của công ty.





• Nó phải đƣợc xem la một nhiệm vụ của công ty với mục tiêu kế hoạch

va chiến lƣợc rõ rang.

• Chất lƣợng nên đƣợc đặt ở trung tâm của mọi hanh động.

Principle 3: Employees are the key to consistent quality.

• The organization must have a people-oriented philosophy.

• Poorly managed people convey their disdain for quality and service

when they work.

• Pay special attention to employee recruitment, selection, and

socialization.

• Reinforce socialization and quality process with continuous training

and education. This should include training in:

- Awareness of quality

- Each employee‘s role in the process

- Statistical process control

- Problem-solving techniques

• Incorporate quality into performance appraisal and reward systems.





• Encourage employee participation and involvement.

• Effective communication throughout the department, between

departments, and throughout the organization is required to reinforce

the deep commitment of management and create an awareness and

understanding of the role of quality and customer service.

Nguyên tắc 3: Nhân viên la chìa khóa cho việc nâng cao chất lƣợng:

• Việc tổ chức phải có một ngƣời định hƣớng va quản lý nghiêm túc

• Giám sát và quản lý nhân viên khi họ lam việc.

• Chú ý đặc biệt đến việc tuyển dụng nhân viên, lựa chọn, va phân chia

công việc.

Tăng cƣờng đao tạo liên tục cho nhân viên về khả năng chuyên

môn. Việc đao tạo nay có thể bao gồm đạo tạo tại:

• Nhận thức về chất lƣợng sản phẩm dịch vụ.

• Vai trò của mỗi nhân viên trong tiến trình.

• Thống kê quá trình kiểm soát.

Giải quyết các vấn đề về kỹ thuật gặp phải.





• Kết hợp vao đánh giá chất lƣợng va hiệu suất của mỗi công nhân để

phê bình va khen thƣởng.

• Khuyến khich sự hao hứng tham gia của nhân viên.

• Nâng cao hiệu quả truyền thông giữa các nganh, phòng ban va trong

toan công ty, tổ chức, điều nay la vô cùng cần thiết để tạo nên sự thanh

công.

Principle 4: Quality standards and measurements must be

customerdriven.

They can be measured by:

• Formal customer surveys

• Focus groups

• Customer complaints

• Quality audits

• Testing panels

• Statistical quality controls

• Interaction with customers





Nguyên tắc 4: Tiêu chuẩn đo lƣờng chất lƣợng va phải đƣợc hƣớng

đến khách hang.

Nó có thể đƣợc đo bằng các tiêu chuẩn sau:

• Khảo sát trực tiếp từ khách hang

• Phản hồi từ các nhóm phát triển sản phẩm

• Sự khiếu nại phản hồi từ khách hang

• Từ việc kiểm tra chất lƣợng của đội ngũ Tester

• Qua thống kê kiểm soát chất lƣợng.

• Quá trình tƣơng tác với khách hang.

Principle 5: Many programs and techniques can be used to improve

quality, such as:

• Statistical quality control

• Quality circles

• Suggestion systems

• Quality-of-work-life projects





• Competitive benchmarking

Nguyên tắc 5: Tham khảo nhiều chƣơng trình va kỹ thuật có thể

đƣợc áp dụng để cải thiện chất lƣợng,chẳng hạn nhƣ:

• Thống kê kiểm soát chất lƣợng.

• Chất lƣợng hình tròn

• Hệ thống gợi ý.

• Quality-of-work-life

• Cạnh tranh điểm chuẩn

Principle 6: All company activities have potential for improving

product quality; therefore, teamwork is vital.

• Quality improvement requires close cooperation between managers

• and employees and among departments.

• Total quality management involves preventing errors at the point

• where work is performed.

• Every employee and department is responsible for quality.





Nguyên tắc 6: Mọi hoạt động của công ty có tiềm năng cho việc cải

thiện chất lƣợng sản phẩm, do vậylam việc theo nhóm la rất quan trọng.

• Cải thiện chất lƣợng đòi hỏi phải hợp tác chặt chẽ giữa các nha quản lý,

nhân viên va giữa các phòng ban.

• Quản lý chất lƣợng của mỗi nhân viên ngay tại điểmnơi lam việc đƣợc

thực hiện nhằm giảm bớt thời gian công sức sau nay.

• Mỗi nhân viên va bộ phận phải chịu trách nhiệm về chất lƣợng của sản

phẩm do mình lam ra.

Principle 7: Quality is a never-ending process.

• Quality must be planned.

• Quality must be organized.

• Quality must be monitored.

• Quality must be continuously revitalized.

Nguyên tắc 7: Nâng cao chất lƣợng la một quá trình không bao giờ

kết thúc:

• Nâng cao chất lƣợng phải đƣợc quy hoạch ngay từ đầu va cụ thể.

• Nâng cao chất lƣợng phải đƣợc tổ chức rõ ràng.





• Nâng cao chất lƣợng phải đƣợc giám sát nghiêm ngặt.

• Nâng cao chất lƣợng phải đƣợc tiếp tục vòng tuần hoan của nó.




Chương 34: Thống kê của Simon về năng suất làm việc nhóm 857

CHƢƠNG 33 THỐNG KÊ CỦA VỀ NĂNG SUẤT

LÀM VIỆC NHÓM

Người dịch: Dƣơng Hữu Thanh

33.1 TỔNG QUAN

In this chapter Simmons (1991) details the many factors that

dominate software group productivity. He defines dominator as a single





factor that causes productivity to decline tenfold. The two dominators

discussed are communications and design partition. What follows is a set of

rules and statistics that the reader can use as a comparison in his or her own

efforts to increase productivity.

Chƣơng nay trình bay chi tiết nhiều tác nhân chi phối năng suất lam

việc nhóm phần mềm. Ông chỉ rõ dominator nhƣ tác nhân riêng rẻ nguyên

nhân sản xuất suy giảm gấp 10 lần. Hai dominator đƣợc thao luận đến la

truyền thông (communications) va thiết kế phần chia công việc. Sau đâuy

la tập hợp các luật va thông kế độc giả có thể sử dụng so sánh với những nổ

lực của riêng mình để tăng năng suất


1.Factors that developers must cope with in developing large

systems:

• Personnel turnover

• Hardware/software turnover

• Major ideas incorporated late

• Latent bugs





1.Các tác nhân ma những ngƣời phát triển cần đƣơng đầu với phát

triển những hệ thống lớn

• Doanh thu của thanh viên

• Doanh thu phần cứng/ phần mềm

• Những ý chinh trể kết hợp

• Những lỗi tiềm tang

2.A Delphi survey performed by Scott and Simmons (1974) to

uncover factors that affect productivity found that the main factors are:

• External documentation

• Programming language

• Programming tools

• Programmer experience

• Communications

• Independent modules for task assignment (design partition)

• Well-defined programming practices





2.một khảo sát Delphi thực hiễn bởi Scott va Simmons (1974) thấy

rõ rằng những ảnh hƣờng chinh trong sản xuất la:

• Tai liệu dẫn chứng ngoai

• Ngôn ngữ lập trình

• Công cụ lập trình

• Sự truyền thông

• Đôc lập các modun trong phânc công trách nhiệm

3.Improvement statistics:

• Any step toward the use of structured techniques, interactive

development, inspections, etc. can improve productivity by up to 25

percent.

• Use of these techniques in combination could yield improvements of

between 25 and 50 percent.

• Change in programming language can, by itself, yield a productiv-ity

improvement of more than 50 percent.

• Gains of between 50 and 75 percent can be achieved by single high

achievers or teams of high achievers.





• Gains of 100 percent can be achieved by database user languages,

application generators, and software reuse.

3.Cải thiện số liệu thông kế

• Một vai bƣớc nhằm mục đich sử dụng kỉ thuật kết cấu, sự phát triển, sự

xem xét ảnh hƣởng lẩn nhau,... có thể cải thiện năng suất 25%

• Sử dụng những kỉ thuật nay kết hợp với nhau có thể mang lại sử cải

thiện 25 đến 50 %

• Thay đổi ngôn ngữ lập trình có thể năng suất sẽ cải thiện trên 50%

• Lợi ich giừa 50 va 75 % có thể la đạt đƣợc bới những cá nhân lam việc

năng suất cao hoặc một nhóm có những cá nhân lam việc cao

• Lợi ich của 100% có thể đạt đƣợc bới cơ sở dữ liệu những ngôn ngữ,

ứng dụng, những ngƣời phát minh, va dùng lại phần mềm

4.Dominators are factors that can suppress the effects of other fac-

tors and can reduce software group productivity by an order of magnitude.

4. Dominator la những tác nhân có thể chặn hiệu quả của các tác

nhân khác va có thể rút ngắn năng suất lam việc nhóm

5.Poor design partition can dominate group productivity. To obtain

high productivity in the development of large software systems, the





designer must break down the system in chunks that can be developed in

parallel. The difference between great and average designers is an order of

magnitude.

5.Sự thiết kế phân công dở có thể chi phối sản xuất nhóm. Để đạt

đƣợc sản xuất cao trong phát triển các hệ thông phần mềm lớn, ngƣời thiết

kế cần phá vở hệ thống vụng về để có thể phát triển song song. Sự khác

nhau giữa một ngƣời thiết kế lớn va trung bình la trình tự những cái quan

trọng.

6.Communications can dominate productivity. Most project

problems arise as the result of poor communications between workers. If n

workers are on the team, then there are n(n — 1)/2 interfaces across which

communications problems may occur.

6.Truyền thông có thể chi phối quá trình sản xuất. Hầu hết vần đề

các dự án nay sinh kết quả của việc truyền thông tệ giữa những thanh viên.

Nếu có n thành viên trong nhóm, thì có n(n-1)/2 giao diện, dẫn đến những

rắc rối trong truyền thông sẽ xảy ra

7.Productivity of individual programmers varies as much as 26 to 1.

7.Hiệu năng của những lập trình viên riêng rẻ biến đổi nhiều từ 26

đến 1





8.An individual working alone has no interruptions from fellow

group members and, therefore, the productivity can be quite high for a mo-

tivated individual. It is estimated that one programmer working 60 hours a

week can complete a project in the same calendar time as two others

working normal hours, but at three-quarters of the cost.

8.Nếu chỉ lam việc một cách đơn độc không có sự ngắt của những

đồng nghiệp những thanh viên trong nhóm, bởi vậy sản xuất có thể hoan

toán cáo... Ngƣời ta tinh toán đƣợc một lập trình viên lam việc 60 giờ một

tuần có thể hoan thanh đƣợc dự án tƣơng đƣơng 2 ngƣời khác lam việc

trong giờ bình thƣờng, nhƣng ¾ chi phi

9.Small groups of experienced and productive software

developerscan create large systems. An example is given of a company,

Pyburn Systems, which scours the country for the best analytical thinkers.

Its senior programmers typically earn $125,000 a year and can be paid

bonuses of two to three times that amount. They work in small teams, never

more than five, to produce large, complex systems. In comparison, most

MIS departments produce large systems using normal development teams

with developers of average ability.

9.Những nhóm nhỏ những ngƣời phát triển phần mềm có kinh

nghiệm có thể tạo ra những hệ thông lớn. Vi dụ một công ty, Pyburn

Systems, ùng sục tìm trong quốc gia những ngƣời phân tich tốt nhất. Những

lập trình viên lớn tuổi rõ rang kiếm đƣợc 125000$ một năm va có thể đƣợc





trả phần thƣờng cho hai đến ba lớn tổng số. Họ lam việc trong những nhóm

nhỏ, không bao giờ hơn 5 ngƣời để sản xuất ra những hệ thông lớn phức

tạp. So sanh, hầu hết các lĩnh vực hoạt động MIS sản xuất ra những hệ

thống lớn áp dụng cho những nhóm phát triển bình thƣờng với những lập

trình viên có khả năng trung bình

10.In general, the difference between the cost to produce an

individual program to be run by the program author and the cost to produce

a programming system product developed by a software group is at least

nine times more expensive.

10.Nó chung, sự khác nhau giữa chi phi sản xuất chƣơng trình riêng

rẻ bới một tác giả va chi phi để sản xuất ra một hệ thống đƣợc phát triển

bởi nhóm phần mềm it nhất mắc hơn 9 lần

11.At some point coordination overheads outweigh any benefits that

can be obtained by the addition of further staff. Statistics that support this

were pioneered during the 19th century in work on a military organization.

It was noted that as the number of workers who had to communicate

increased arithmetically, from two to three to four to five…, the number of

communication channels among them in-creased geometrically, from one to

three to six to ten…. From this study, it was concluded that the upper limit

of effective staff size for cooperative projects is about eight.





11.Một vai điểm chi phi thƣờng lệ vƣợt quá trọng tải vai lợi ich có

thể đƣợc đạt bởi ban xúc tiến. Thông kê đƣợc ủng hộ, đây la tiên phong

suốt thế kỉ 19 trong phân công trong tổ chức quân đội. Nó đƣợc chú ý nhiều

thanh viên cần giao tiếp tăng theo phƣơng pháp số học, từ hai ba bôn rồi

đến năm,... số lƣợng các kênh truyền thông giửa họ tăng về phƣơng diện

hình học, từ một đến ba đến sáu rồi đến 10... Từ những nghiên cứu nay,

ngƣời ra kết luận rằng cận trên của kich thƣớc nhóm lam việc hiệu quả la

khoảng 8

12.It has been shown in studies that when the number of staff

increased to 12 or more, the efficiency of the group decreased to less than

30 percent.

12.Thể hiện trong nghiên cứu nay, số lƣợng các ban tăng từ 12 hoặc

hơn, khả năng của nhóm giảm it nhất 30%

13.The productive time of a typical software developer during a

working day can vary from 51 to 79 percent. It was found that the average

duration of work interruption was five minutes for a typical programmer.

The average time to regain a train of thought after an in-terruption was two

minutes. Thus, the average total time spent on an interruption was seven

minutes. If we assume five productive





13.hours each day, then each interruption takes 2.33 percent of the

working day; ten interruptions would take up 23 percent of the day and 20

interruptions would take approximately 50 percent.

13.Thời gian sản xuất của ngƣời phát triển phần mềm suốt ngay lam

việc có thể khác nhau từ 51 đến 79%. Ngƣời ta thấy rằng thời gian trung

bình gián đoạn lam việc la 5 phút cho lập trình viên điển hình. Vì vậy, tổng

thời gian trung bình trải qua cho việc ngắt quãng la 7 phút. Nếu chúng ta

đƣợc 5 giờ sản xuất mổi ngay, thì mỗi gián đoạn 2.33 % trong ngay lam

việc, 10 gián đoạn sẽ 23% trên ngay va 20 gián đoạn sẽ la 50%

14.The optimum group size for a software development team is be-

tween five to eight members. The overall design should be parti-tioned into

successively smaller chunks, until the development group has a chunk of

software to develop that minimizes intragroup and intergroup

communications.

14.Số lƣơng thanh viến tốt nhât của một độ phát triển phần mềm nên

từ 5 đến 8 thanh viên. Mọi thiết kế nên đƣợc phân chia nhóm nhỏ, cho đến

khi việc phát triển nhóm có khoảnh phần mềm để phát triển it nhất la truyền

thông trong nhòm va giữa các nhóm




Chương 35: Quan điểm của Gould về tính tiện dụng 867

CHƢƠNG 34 QUAN ĐIỂM CỦA GOULD VỀ

TÍNH TIỆN DỤNG

Người dịch: Lê Quang Thảo

34.1 TỔNG QUAN

Few in the industry have added usability design to their rostrum of

design issues. However, Gould, Boies, and Lewis (1991) note that this





process leads to usable, useful, likable computer systems and applications.

The authors present Strong evidence that readers can use to support their

own efforts in this, perhaps, new terrain. This chapter also details a process

that can be used to design effective and usable systems. In effect, this

chapter proposes:

• Greater reliance on existing methodologies for establishing testable

usability and productivity-enhancing goals

• A new method for identifying and focusing attention on long-term

trends about the effects that computer applications have on end-user

productivity

• A new approach to application development, particularly the

development of user interfaces

Một vai tổ chức trong công nghiệp đã thêm thiết kế tinh tiện dụng

vao các vấn đề của thiết kế. Tuy nhiên, Gould, Boies va Lewis (1991) chú ý

rằng quá trình nay tạo ra các hệ thống máy tinh hay ứng dụng có ich, tiện

dụng. Các tác giả trình bay bằng chứng mạnh mẽ rằng đọc giả có thể đóng

góp sự cố gắng của mình vao việc nay, la địa thế mới. Chƣơng nay cũng kể

ra chi tiết một quy trình có thể đƣợc dùng để thiết kế các hệ thống hiệu quả

va tiện dụng. Chƣơng nay đƣa ra:

• Sự tin cậy lớn hơn vao các phƣơng pháp hiện nay dùng để xác lập các

tiêu chuẩn nâng cao năng suất va tinh tiện dụng có thể kiểm tra đƣợc.





• Một phƣơng pháp mới để nhận dạng va tập trung vao xu thế lâu dai

xung quanh những lợi ich ma các ứng dụng máy tinh đem lại cho ngƣời

dùng cuối.

• Một hƣớng tiếp cận mới trong phát triển phần mềm, đặc biệt la phát

triển giao diện ngƣời dùng.

The authors conclude that a three-way split among style of the user

interface, content of the user interface, and the functional code allows

changes to be made in the user interface that still preserve the integrity of

the functional code. Iterative design, a necessity when looking toward

usability, proceeds rapidly. On the style side, a particular style can be

prototyped and iteratively engineered. From the set of styles developed over

time, a subset of workable, usable styles will emerge that have attained the

favor of organizations or end users. Ultimately, the best work of the style

side and the functional side of development will be better leveraged.

Tác giả kết luận có 3 cách phân chia các loại giao diện ngƣời dùng,

nội dung của giao diện ngƣời dùng, va code thực thi cho phép ngƣời dùng

tùy chỉnh ma vẫn đảm bảo tình toan vẹn của code thực thi. Thiết kế xoay

vòng, 1 sự cần thiết khi hƣớng đến tinh tiện dụng va xử lý nhanh. Mặt khác,

một kiểu đặc biệt có thể đƣợc lấy lam mẫu va xử lý xoay vòng. Từ tập các

kiểu đƣợc phát triển qua thời gian, một tập con các kiểu tiện dụng va hoạt

động đƣợc sẽ xuất hiện va đáp ứng mong muốn của các tổ chức hay ngƣời





dùng cuối. Sau cùng, kết quả của phƣơng diện kiểu va phƣơng diện chức

năng của việc phát triển sẽ tốt hơn.


1. The usability process consists of four activities:

• Early focus on users should be via interviews, surveys, observations,

and participatory design with an aim toward understanding users‘

cognitive, behavioral, and attitudinal characteristics.

• All facets of usability, for example, user interface, help system, training

plan, and documentation, should evolve in parallel, rather than be

defined sequentially and be under one management.

• User testing should be early and continual. This should include

observation and measurement of user behavior and careful evaluation

of feedback. Ultimately, a strong motivation to make design changes

should exist.

• Iterative design must be used. Because the system under design must be

continually modified due to results of behavioral tests of function, the

system must have the ability to be changed continually.





• Sớm tập trung vao những ngƣời dùng sẽ đƣợc phỏng vấn, khảo sát,

quan sát va đặt biệt thiết kế với mục đich hƣớng đến la hiểu đƣợc quan

điểm, thị hiếu của ngƣời dùng.

• Tất cả các khia cạnh của tinh tiện dụng, vi dụ nhƣ giao diện ngƣời

dùng, hệ thống hỗ trợ, kế hoạch huần luyện, va tai liệu, có thể đƣợc xét

chung với nhau, hơn la định nghĩa một cách tuần tự va chịu một sự

quản lý.

• Việc cho ngƣời dùng kiểm tra nên thực hiện sớm va liên tục. Bao gồm

quan sát va đánh giá các phản hồi của ngƣời dùng một cách cẩn thận.

Sau cùng, cần một động lực mạnh mẽ để quyết định thay đổi thiết kế.

• Thiết kế xoay vòng phải đƣợc sử dụng. Bởi vì hệ thống bên dƣới thiết

kế phải đƣợc điều chỉnh liên tục tùy theo kết quả kiểm tra về mặt chức

năng, hệ thống phải có khả năng thay đổi liên tục.

2. This type of development effort has been used with great success:

• Xerox‘s Star system

• Apple‘s Lisa system

• IBM Audio Distribution Systems (ADS)

• IBM‘s Rexx





• Tektronix‘s Graphic Input Workstation

• Boeing‘s banking terminal

• Digital Equipment Corporation‘s VAX text processing utility

• IBM‘s QMF

• Lotus Development Corporation‘s Lotus 1–2–3

3. Six interacting, organizational reasons why usability design is not used:

• Usability is seldom a goal in development.

• There is a belief that usability cannot be measured — even though there

is much evidence to the contrary.

• An apparent conflict between meeting deadlines and achieving

usability exists. Project managers often lack confidence in managing

something that does not have clear goals or the tools to address

problems efficiently as they arise.

• Designers report that software development is not organized to carry

out the process of usability. Iterative design is thought to be too risky,

time consuming, and too difficult.

• Designers need better tools to do iterative design.





• Nearly every new application creates its own user interface, which

creates an enormous amount of work. Also, these interfaces are not

usually developed by people skilled in user-interface design.

• Tinh tiện dụng hiếm khi la một mục tiêu trong việc phát triển.

• Ngƣời ta tin rằng tinh tiện dụng không thể đƣợc đo lƣờng – mặc dù có

rất nhiều bằng chứng chứng minh điều ngƣợc lại.

• Một mâu thuẩn giữa deadline va tinh tiện dụng cần đạt đƣợc. Project

Manager thƣờng thiếu niềm tin vao việc quản lý cái gì đó ma không có

mục tiêu rõ rang hoặc không có công cụ xác định đƣợc các vấn đề phát

sinh một cách hiệu quả.

• Ngƣời thiết kế nói rằng việc phát triển phần mềm không đƣợc tổ chức

để đảm nhận quá trình xây dựng tinh tiện dụng. Sự thiết kế xoay vòng

đƣợc xem la quá mạo hiểm, tốn thời gian va quá khó khăn.

• Ngƣời thiết kế cần các công cụ tốt hơn để dùng trong thiết kế xoay

vòng.

• Gần nhƣ mỗi ứng dụng mới đều tạo ra giao diện ngƣời dùng riêng,

nghĩa la tạo ra một lƣợng lớn công việc. Những giao diện nay cũng

không thƣờng xuyên đƣợc phát triển bởi những ngƣời có kĩ năng trong

thiết kế giao diện ngƣời dùng.





4. Độ đo về tinh tiện dụng

Usability metrics can be created. They must be clearly stated, easily

communicated, and verifiable. The results must be made public. Experience

has shown that these results are then taken seriously by management. This

has always been the case in logging system performance data. This

operation-room metric is a viable usability metric.

Measures here include percent system available, downtime per day,

and average user satisfaction rating. Digital Equipment Corporation has

developed an analogous usability engineering approach, as shown in

Exhibit 1.

Các tiêu chuẩn đánh giá tinh tiện dụng có thể đƣợc hình thanh.

Chúng phải rõ rang, dễ truyền đạt va có thể chỉnh sửa (verifiable). Kết quả

phải đƣợc cho mọi ngƣời biết. Kinh nghiệm cho thấy những kết quả nay

phải đƣợc đƣa ra một cách nghiêm túc. Điều nay luôn rơi vao trƣờng hợp

dữ liệu xử lý hệ thống. Tiêu chuẩn operation-room nay la một tiêu chuẩn

tiện dụng có thể đứng vững.

Những đo lƣờng ở đây bao gồm tỉ lệ phần trăm hệ thống sẵn sang,

thời gian ngƣng hoạt động trên ngay, va tỉ lệ thỏa mãn nhu cầu ngƣời dùng

trung bình. Tập đoan Digital Equipment Corporation đã phát triển một

hƣớng tiếp cẩn kĩ thuật xây dựng tinh tiện dụng nhƣ hình 1.





Hình 1

5. Lam việc nhóm

Creation of goals is a group process. The group must decide what the

relevant usability attributes are, how to measure them, and what the target

goals should be. The goals are clearly stated and communicated, just as they

are for other components of the system.

Việc xác định mục tiêu la một quá trình lam việc nhóm. Nhóm phải

xác định đâu la các thuộc tinh tiện dụng, lam sao đo đạc chúng, va mục tiêu

gì cần đề ra. Các mục tiêu phải đƣợc trình bay rõ rang, dễ truyền đạt, vì

chúng sẽ đƣợc dùng trong các thanh phần khác của hệ thống.





6. Công việc của ngƣời dùng

End-user activity involves four operations: filling in forms, selecting

among prescribed choices, manipulating lists, and reading information.

Công việc của ngƣời dùng cuối bao gồm 4 công việc: nhập thông tin,

chọn lệnh xử lý, thao tác trên danh sách va đọc thông tin.

7. Thiết kế 4-block

The four end-user operations can be tied to four corresponding

building blocks that are sufficient to describe user interfaces abstractly:

• Form blocks

• Choice blocks

• List blocks

• Info blocks

Bốn công việc của ngƣời dùng cuối có thể xem tƣơng ứng với các

thanh phần sau:

• Form blocks

• Choice blocks





• List blocks

• Info blocks

8. Phân chia thiết kế

It is possible to separate the design of these blocks, i.e., the user

interface, from functional code. In the process described here, experts

structure their applications in terms of the form, choice, list, and info

blocks. Style designers write rules about how these blocks will be rendered

on an end user‘s screen under various circumstances. The benefits of this

approach are that groups can work in parallel and independently, and it

promotes code reuse and iterative design.

Có thể phân phân chia thiết kế thanh những phần nay, vi dụ, giao

diện ngƣời dùng, từ code thực thi. Trong quá trình đƣợc mô tả ở đây, các

chuyên gia cấu trúc ứng dụng của họ thanh các phần form, choice, list va

info blocks. Ngƣời thiết kế kiểu (style designer) viết các quy luật hiển thị va

hoạt động của các block nay trên man hình của ngƣời dùng cuối theo các

kịch bản cụ thể. Lợi ich của hƣớng tiếp cận nay la các nhóm có thể lam việc

song song va độc lập, va lam tăng tinh tái sử dụng của code va thiết kết

xoay vòng.

9. Chuyên gia ứng dụng





Content or application experts know the jobs of the end users. They

can structure this knowledge into a computer-executable form. Application

experts create the user-interface content specifications.

Chuyên gia về nội dung hay ứng dụng biết công việc của ngƣời dùng

cuối. Họ có thể cấu trúc sự hiểu biết nay vao trong form có thể thực thi trên

máy tinh. Chuyên gia về ứng dụng tạo ra đặc ta nội dung của giao diện

ngƣời dùng.

10. Lập trình ứng dụng

Application (content) programmers write the programs.

Lập trình viên ứng dụng viết chƣơng trình.

11. Style designer

Style designers have skills in human factors and graphic design.

Their role is mainly of advocacy; they identify problems and describe

solutions. They specify style rules.

Style designer có kĩ năng về thiết kế đồ họa va nhân tố con ngƣời.

Vai trò của họ la phát hiện ra vần đề va mô tả hƣớng giải quyết. Họ xác

định quy luật về kiểu (style rule).

12. Style programmer





Style programmers write programs necessary for making an

interaction work.

Lập trình viên viết chƣơng trình cần thiết để lam cho quá trình tƣơng

tác hoạt động.

13. Đặc tả nội dung

Content (application) specifications are created by the application

expert and include the messages to end users, flow of control, connections

to function, and guidance to style.

Đặc tả nội dung đƣợc tạo bởi chuyên gia về ứng dụng va bao gồm

các thông báo đến ngƣời dùng cuối, dòng kiểm soát, kết nối, va hƣớng dẫn

về kiều (style).

14. Content (application) action

Content (application) actions are created by application

programmers. These are atomic programs with general utility. For example,

a module might transfer the contents of one list to another.

Ngƣời lập trình ứng dụng sẽ viết các chƣơng trình nhỏ với tiện ich

thông thƣờng. Vi dụ nhƣ một module chuyển nội dung từ list nay sang list

khác.

15. Đặc tả kiểu





Style specifications are created by the style designers. These are the

rules regulating the set of human–computer interaction techniques used to

render content, including interaction methods (e.g., entry vs. selection),

appearance of the end user‘s screen, and the interaction devices.

Đặc tả style đƣợc tạo bởi style designer. Đó la những quy luật liên

quan đến các kĩ thuật tƣơng tác ngƣời-máy đƣợc dùng để tao ra nội dung,

bao gồm phƣơng pháp tƣơng tác, sự hiển thị trên man hình ngƣời dùng

cuối, va các thiết bị tƣơng tác.

16. Công cụ hỗ trợ

The team works with a series of tools. Over time, they build up a

library of well-tested approaches to human interface, which can then be

mapped onto an application‘s content blocks.

Đội lam việc với hang loạt các công cụ. Sau đó họ xây dựng nên một

thƣ viện các hƣớng tiếp cận giao diện ngƣời dùng đã đƣợc kiểm tra kĩ,

những cái ma sau đó đƣợc đƣa lên tƣơng ứng với từng block nội dung của

một ứng dụng.


Gould, J.D., Boies, S.J., and Lewis, C. (1991). Making usable,

useful, productivity-enhancing computer applications, Commn. ACM, 34.




Chương 36: Nguyên tắc chỉ đạo của Prescott 881

CHƢƠNG 35 NGUYÊN TẮC CHỈ ĐẠO CỦA

PRESCOTT VỀ VIỆC SỬ DỤNG PHƢƠNG

PHÁP CÓ CẤU TRÖC

Người dịch: Trịnh Đắc Thắng

35.1 TỔNG QUAN

The science of software engineering is composed of many

methodologies and each has its own variations. In this chapter, Prescott





(1991) offers an itemized set of guidelines for those interested in using

structured methodology to ensure their project‘s success.

Nganh khoa học công nghệ phần mềm gồm có nhiều phƣơng pháp va

từng phƣơng pháp có các biến thể riêng. Trong chƣơng nay, Prescott (1991)

cung cấp một tập các hƣớng dẫn đƣợc chia thanh từng nhóm cho những

ngƣời quan tâm đến việc sử dụng phƣơng pháp cấu trúc để đảm bảo sự

thanh công của dự án của họ.

Structured methodology is an approach to defining a particular task

and in defining a solution to that task. It provides a methodology for

partitioning a complex task into a manageable series of ―black boxes‖. The

underlying organization of this network of black boxes progresses from

abstraction at the top level to details at the lower levels. Not only are the

specifics of each black box charted out, but the interfaces between each of

these black boxes are also specified.

Phƣơng pháp có cấu trúc la một cách tiếp cận để xác định một nhiệm

vụ cụ thể va trong việc xác định một giải pháp cho nhiệm vụ đó. Nó cung

cấp một phƣơng pháp phân vùng một nhiệm vụ phức tạp thanh một loạt các

"hộp đen‖ có thể quản lý. Việc tổ chức lớp dƣới của mạng lƣới các hộp đen

nay phát triển từ mức cao nhất, va cụ thể ở những mức thấp hơn. Không chỉ

la những đặc trƣng (specifics) của từng hộp đen đƣợc biểu diễn (charted),

ma các giao diện giữa mỗi của các hộp đen cũng phải đƣợc chỉ rõ.





One of the main reasons for using structured methodology is the

sheer complexity and cost of a problem. The discipline associated with this

technique is reflected in the need to document each particular phase of

development to ensure compliance with demanding requirements for

quality, performance, and reliability.

Một trong những lý do chinh để sử dụng phƣơng pháp có cấu trúc là

do vấn đề hoan toan phức tạp va tốn chi phi. Những kỷ luật liên quan đến

kỹ thuật nay đƣợc phản ánh trong nhu cầu tai liệu hóa(to document) từng

phần của giai đoạn phát triển để bảo đảm tuân thủ các yêu cầu các yêu cầu

về chất lƣợng, hiệu suất va độ tin cậy.


1. Structured methodology will only be successful if:

• The company‘s management is willing to make a firm commitment to

the substantial time investment required to build a quality project.

• Quản lý của công ty sẵn sang thực hiện một cam kết mạnh để đầu tƣ

đáng kể thời gian cần thiết để xây dựng một dự án có chất lƣợng.

• A software development plan for the development of software is used.

It provides management with the means to coordinate schedules,

control resources, initiate actions, and monitor progress of the

development effort. It also provides detailed knowledge of the





schedule, organization, and resource allocation planned by the

contractor. In addition, it contains definitions and discussions of

software quality and configuration management, as well as design and

programming standards and conventions.

• Một kế hoạch phát triển phần mềm cho việc phát triển các phần mềm

cần đƣợc sử dụng. Nó cung cấp việc quản lý trung bình để sắp xếp lịch,

kiểm soát tai nguyên, bắt đầu các hoạt động, va theo dõi tiến trình nỗ

lực phát triển. Nó cũng cung cấp những kiến thức cụ thể về việc sắp

xếp lịch trình, tổ chức, tai nguyên (nguồn lực) đƣợc lên kế hoạch bởi

nha thầu (contractor).Thêm vao đó, nó chứa các định nghĩa va những

thảo luận về chất lƣợng phần mềm va quản lý cấu hình, cũng nhƣ tiêu

chuẩn thiết kế, lập trình va quy ƣớc.

• Walkthroughs of at least five people for up to one and three quarters

hours at the most are held in the requirements, design, coding, and

testing phases.

• ‖Những bƣớc thông qua‖ của it nhất năm ngƣời cần hơn một va ba

phần tƣ giờ ở hầu hết đều đƣợc tổ chức tại các yêu cầu, thiết kế, mã

hóa, va giai đoạn kiểm tra.

2. A software requirement must be expressed in very clear English

Một yêu cầu phần mềm phải đƣợc thể hiện bằng tiếng Anh rõ rang





3. Decompose each function into related subfunctions. For example,

initialization may be decomposed into initialize local variables and

initialize global variables subfunctions

Phân tách từng chức năng thanh những chức năng phụ có quan hệ

với nhau. Vi dụ, việc khởi tạo có thể đƣợc phân tách ra thanh việc khởi tạo

những biến cục bộ va những biến chức năng phụ toan cục.

4. For each function or task and subfunction, a narrative is written that

clearly describes the function in terms of what the function does. The

source of the required data and its destination as output from the

function must also be defined and documented. The narrative should

include the following:

• Module name

• Module called by

• Module purpose

• Inputs

• Outputs

• Unit description





Đối với mỗi chức năng hoặc nhiệm vụ va chức năng phụ, một bai

tƣờng thuật đƣợc viết để mô tả rõ các chức năng trong điều khoản (terms)

va những chức năng đó lam gì. Nguồn của các dữ liệu cần thiết va đich của

nó nhƣ la một output từ chức năng cũng phải đƣợc xác định va tai liệu hóa.

Bai tƣờng thuật nên bao gồm những điều sau:

• Tên Module

• Module đƣợc gọi bởi

• Mục đich của Module

• Inputs

• Outputs

• Miêu tả ở mức đơn vị

5. Define a local database that will house the data items pertinent to the

data requirements

Xác định một cơ sở dữ liệu cục bộ, cái ma sẽ ở trong the data items

thich hợp tới các yêu cầu của dữ liệu.

6. For each function, a detailed design document must be created that

will, ultimately, be used to create the code. This document contains the

following information





• Name of function

• Function‘s purpose

• Description

• Calling sequence — if this submodule is called by another module or

calls another module

• Calling parameters — if called or calling, then what are the parameters

passed

• Updates — the files that it updates

• Variables — the variables that it uses

• Algorithm — pseudocoded processing logic such as:

- Clear error flag

- If code entered is equal to code in table

- Update table.

Đối với mỗi chức năng, tai liệu thiết kế đƣợc cụ thể phải đc tạo, ma

sẽ, cuối cùng, đƣợc sử dụng để tạo code(mã). Tai liệu nay chứa các thông

tin sau:





• Tên của chức năng

• Mục đich của chức năng

• Miêu tả

• Việc gọi liên tục — nếu module phụ nay đƣợc gọi bởi module khác

hoặc gọi module khác

• Việc gọi tham số — nếu bị gọi hoặc gọi, cái ma tham số truyền qua

• Cập nhật — Những files cập nhật

• Biến — Biến sử dụng

• Thuật toán — logic thuật toán đƣợc tiến hanh bằng code giả nhƣ:

- Xóa cờ lỗi

- Nếu code nhập vao trùng code trong bảng

- Cập nhật bảng.

7. Module is then coded using programming standards that enforce

readability and understanding.

Module nay sau đó đƣợc mã hóa bằng cách sử dụng các tiêu chuẩn

lập trình, cái ma có thể dễ đọc va hiểu.





8. A test plan is created that takes into consideration schedule,

environment, and available resources.

Một kế hoạch kiểm tra đƣợc tạo ra, cái sẽ đƣa vao lịch trình xem xét,

môi trƣờng, va các nguồn lực sẵn có.

9. Test procedures that test each requirement must be documented. This

translates into a series of test cases or scenarios. The test, the input, and

the expected output are documented. This document is known as a

requirements traceability matrix, which establishes the correspondence

between a software product specification and the successful testing of

each such specification.

Ham(Thủ tục) kiểm tra, kiểm tra mỗi yêu cầu phải đc tai liệu hóa.

Điều nay tạo thanh một loạt các trƣờng hợp kiểm tra hoặc các kịch bản.

Việc kiểm tra, input, va output đƣợc mong đợi cũgn đc tai liệu hóa. Tai liệu

nay đƣợc biết đến nhƣ những việc đòi hỏi một ma trận có thể truy vết đc,cái

ma thiết lập sự tƣơng ứng giữa đặc điểm của sản phẩm phần mềm va việc

kiểm tra thanh công của mỗi đặc điểm nhƣ vậy.

10. Systems integration and maintenance must be considered.

Tich hợp hệ thống va bảo dƣơng phải đƣợc xem xét.

11. Tools and techniques that assist in the process of structured

methodology:





• Use of formal walkthroughs

• A structured approach to software design, coding, and testing

• Use of structured programming

• The use of standardized coding conventions

• The use of graphics devices such as a functional block diagram for

module specification

Công cụ va kỹ thuật ma hỗ trợ trong quá trình của phƣơng pháp có

cấu trúc:

• Sử dụng đúng theo walkthroughs

• Một cách tiếp cận có cấu trúc để thiết kế phần mềm, mã hóa, va kiểm

tra

• Sử dụng lập trình cấu trúc

• Việc sử dụng các quy ƣớc code đc chuẩn hóa

• Việc sử dụng các thiết bị đồ họa nhƣ một sơ đồ khối chức năng cho

đặc tả mô đun




Chương 37: Kemayel’s controllable factors 891

CHƢƠNG 36 KEMAYEL’S CONTROLLABLE

FACTORS IN PROGRAMMER

PRODUCTIVITY

Người dịch: Trần Xuân Tiến

36.1 TỔNG QUAN

Based on extensive research performed in Tunisia by Kemayel et al.,

this chapter seeks to identify the characteristics of the programmer‘s work

potential. The impact of certain controllable factors in the productivity of

programmers is investigated. These factors are divided into three





categories: factors pertaining to personnel, factors pertaining to the process,

and factors pertaining to the user community.

Dựa trên các nghiên cứu mở rộng ở Tunisia bởi Kemayel, chƣơng

nay đánh giá về các thanh phần của việc lập trình viên phải lam. Sự tác

động của các yếu tố về khả năng lam việc của lập trình viên đƣợc nghiên

cứu tỉ mỉ. Những yếu tố đƣợc chia lam 3 loại: yếu tố liên quan đến nhân sự,

liên quan đến quy trình sản xuất, yếu tố liên quan đến cộng đồng ngƣời sử

dụng.

36.2 THỦ TỤC/VẤN ĐỀ/ CHÍNH SÁCH

1. Programmer productivity paradoxes:

Sự nghịch biến trong khả năng sản xuất của progarammer

• There is an enormous variance in the productivity of programmers.This

variance can be as wide as a factor of one to ten. (Other researchers

report an even wider variance.) There is a large opportunity to improve

programmer productivity within this wide range.

• Có rất nhiều sự biến đổi trong khả năng lam việc của lập trình viên. Sự

biến đổi đó có thể thay đổi từ 1 đến 10. (một số nghiên cứu khác thậm

chi còn có mức giao động rộng hơn.) đó la một cơ hội tốt để tăng khả

năng lam việc của một lập trình viên.





• Productivity invariance with respect to experience. According to

statistical measures by Boehm (1981), when the experience of a

programmer increases from one month to three years (36-fold

increase), productivity is improved by only 34 percent. This appears to

show that experience has no effect on software project costs.

• Khả năng lam việc thì không biến đổi nhiều về mặt kinh nghiệm. Dựa

vao bảng thống kê đo lƣờng của Boehm (1981), khi kinh nghiệm của

lập trình viên tăng từ 1 tháng đến 3 năm (36 lần) thì hiệu quả sản xuất

chỉ tăng 34%. Điều nay nói lên rằng kinh nghiệm không ảnh hƣởng

nhiều đến chi phi của một dự án phần mềm.

• Productivity invariance with respect to tools. According to Boehm, the

difference in productivity between a programmer who uses no tools at

all and one who uses the most up-to-date, powerful tools available, on

the most powerful machines, is no larger than 50 percent.

• Khả năng sản xuất không đổi với khia cạnh với công cụ (tool). Cũng

theo Boehm, sự khác biệt về khả năng sản xuất của lập trình viên gữa

những ngƣời không sử dụng công cụ va những ngƣời sử dụng công cụ

mới nhất, cùng với các máy móc hiện đại thì không vƣợt quá 50 %.

• Suitability of motivation factors. Studies have shown that programmers

have a motivation pattern different from that of their managers and

those of workers in other industries. This difference might well explain





why some well-intentioned software managers fail to motivate their

programmers.

• Sự thich hợp của các nhân tố thúc đẩy. Nghiên cứu chỉ ra rằng lập trình

viên sẽ có một sự thúc đẩy khác từ ngƣời quản lý của họ, va từ những

những công nhân khác. Sự khác biệt có thể giải thich lý do tại sao một

vai cố gắng ngƣời quản lý phần mêm lại thất bại trƣớc việc thúc đẩy

những ngƣời lập trình viên của họ.

2. The 33 productivity factors that are proposed can be divided into three

categories:

• Factors related to personnel

• Factors related to the software process

• Factors related to the user community

33 nhân tố về hiệu quả lam việc có thể đƣợc chia ra lam 3 loại:

• Nhân tố liên quan đến nhân sự.

• Nhân tố liên quan đến quá trình san xuất

• Nhân tố liên quan đến cộng đồng ngƣời sử dụng





3. Personnel factors. Two sets of controllable factors are likely to affect

the productivity of data processing personnel: motivation factors and

experience factors.

Nhân tố tổ chức nhân sự. 2 tâp hợp điều khiển nhân tố có sự tác động

đến hiệu quả của tiến trình tổ chức nhân sự la: yếu tố thúc đẩy va yếu tố

kinh nghiệm.

4. Personnel motivation consists of many factors; 16 derived from

research appear below:

Personnel motivation (sự thúc đẩy về nhân sự) lại bao gồm nhiều yếu

tố; có 16 yếu tố từ các nghiên cứu sẽ đƣợc trình bay:

• Recognition. This is the reaction of the organization to the

programmer‘s performance. Indifference leads to a drop in motivation,

which leads to a decline in productivity.

• Recognition (sự thừa nhận): la sự phản ứng lại của công ti đối với thể

hiện của một lập trình viên. Sự thờ ơ, lãnh đạm sẽ dẫn tới giảm về động

cơ thúc đẩy, cái lam cho hiệu quả lam việc đi xuống.

• Achievement. This represents the satisfaction that the programmer gets

from doing a challenging task. This implies that the organization must

keep supplying the programmer with challenging tasks to maintain

motivation.





• Achievement (thanh tựu): điều nay trình bay sự thoả mãn của lập trình

viên nhận đƣợc từ công việc. Nó ngụ ý rằng công ty phải giữ việc cung

cấp cho lập trình viên các công việc có tinh thử thách để duy trì động

lực.

• The work. The nature of the tasks that must be executed is a powerful

tool to motivate a programmer.

• The work (Công Việc). bản chất công việc phải thú vị, đó la một công

cụ mạnh để duy trì động lực.

• Responsibility. This is derived from basic management theory. That is,

if you want something to happen, make someone specifically

responsible for it.

• Responsibility (sự chịu trách nhiệm) nó đƣơc rút ra từ những lý thuyết

quản lý cơ bản. Nó nói rằng: nếu bạn muốn môt công việc đƣợc hoan

thanh, hãy giao rõ trách nhiệm về nó cho một ai đó.

• Advancement. A programmer who feels that he or she has the

possibility of career advancement in the organization is more motivated

than one who does not.

• Advancement.(sự thăng tiến) Những lập trình viên ngƣời ma cảm thấy

rằng có khả năng thăng tiến trong công ty thì sẽ có động lực lam việc

hơn không có.





• Salary. A programmer who feels that he or she is paid adequately, and

who anticipates that salary increases will continue on par with

performance, will be more motivated than one who does not.

• Salary. (Lƣơng) Lập trình viên nếu cảm thấy rằng họ đƣợc trả một mức

lƣơng hợp lý, va thấy rằng mức lƣơng sẽ đƣợc tăng lên sẽ cố gắng lam

việc, va sẽ có động lƣc lam việc hơn.

• Possibility for growth. This factor measures the possibilities for

professional growth within a programmer‘s company.

• Possibility for growth.(Triển vọng phát triển) Nhân tố nay nhấn mạnh

rằng khả năng phát triển của một cá nhân khi ở trong một công ty.

• Interpersonal relations with subordinates.

• Mối quan hệ với những ngƣời câp dƣới.

• Status. This measures the importance of the worker in his or her

company, e.g., participation at meetings, participation in decision

making, ceremonial functions, usage of restricted services, and

privileges of the corporation.

• Status.(tình trạng)điều nay nhấn mạnh tầm quan trọng của mỗi công

nhân trong một công ty vd: tham gia vao các cuộc họp, tham gia vao





các quyết định, các buổi lễ, sử dụng các dịch vụ đặc biệt, các quyền lợi

ƣu tiên trong công ty.

• Interpersonal relations, superiors. This is controllable to the extent that

the manager has latitude in assigning group leaders.

• Interpersonal relations, superiors (Mối quan hệ với nhân viên cấp trên)

nó có thể kiểm soát với phạm vi nhất định rằng ngƣời quản lý có phạm

vi trong việc phân công lãnh đạo nhóm.

• Interpersonal relations, peers. Because teamwork is a key ingredient for

the success of any group effort, the manager should take care in

dividing staff into working groups.

• Interpersonal relations, peers (quan hệ giữa các cá nhân ngang hang)bởi

vì team work la chìa khoá cấu thanh sự thanh công của mọi nhóm, nên

ngƣời quản lý phải quan tâm đến sự phân bổ nhân sự khi phân công vao

nhóm.

• Technical supervision. This measures the willingness of the

programmer‘s supervisor to help the programmer solve technical

problems, orient efforts, and make choices.

• Technical supervision.(sự giám sát kĩ thuật) nó đánh giá sự sẵn lòng

của những giám sát kỹ thuật khi giúp đơ những lập trình viên giải quyết

các vần đề kỹ thuật, chỉ hƣớng, tạo ra sự lựa chọn.





• Company policy and administration. This factor measures how clearly

the command structure of the company is defined, how rational it is,

and how easy it is to determine to whom each worker reports.

• Company policy and administration. (Chinh sách va sự quản lý của

công ty) nhân tố nay đánh giá cấu trúc lãnh đạo của công ti đƣợc định

nghĩa rõ rang nhƣ thế nao, va lam cách nao xác định rõ mỗi nhân viên

phải báo cáo cho ai.

• Working conditions. This factor represents working conditions in the

traditional sense, such as office space, light.

• Working conditions.(điều khiện lam việc)nhân tố nay trình bay điều

kiện lam viêc, về mặt truyền thống nó la không gian văn phòng, ánh

sáng …

• Factors in personal life. Given that the programmer‘s personal life

influences motivation and job performance, the manager can assign key

positions or tasks to those that have the best conditions.

• Factors in personal life. (Nhân tố về đời tƣ) Đời tƣ của một nhân viên

ảnh hƣởng rất lớn đến động lực va kết quả công việc, ngƣời quản lý có

thể bổ nhiệm vao các vị tri hay nhiệm vụ có điều kiện tốt nhất.

• Job security. This factor is very important.





• Job security.(sự ăn toan của công viêc) Yếu tố nay rất quan trong.

5. Personnel experience is equally important. Four factors are discussed:

Personnel experience (Kinh nghiệm của nhân sự) cũng quan trọng

không kém. 4 nhân tố đƣợc thảo luận ở đây la:

• Applications domain experience (kinh nghiệm về các ứng dụng tên

miền)

• Virtual machine experience — the aggregate of hardware, operating

system, utilities, and software packages

• Virtual machine experience (kinh nghiệm máy ảo) sự tập hợp của các

phần cứng va hệ điều hanh, tiện ich va các gói phần mềm.

• Programming language experience (kinh nghiệm về ngôn ngữ lập trình)

• Experience with the user community — to what extent the programmer

is familiar with the user community as a working partner

• Experience with the user community (kinh nghiệm trong việc giao tiếp

với ngƣời sử dụng) – đến một mức độ ma lập trình viên quen với cộng

đồng ngƣời sử dụng nhƣ la một cộng sự trong công việc.





6. Two classes of controllable factors pertaining to the software process

have been identified by the authors: project management and

programming environments.

2 lớp của những cái đặc tinh có thể kiểm soát về mặt software

process đƣợc định nghĩa bởi tác giả: project management (quản lý dự án) va

programming environments (môi trƣờng lập trình)

7. Project management consists of four controllable factors:

Project management bao gồm 4 nhân tố có thể kiểm soát:

• Using a goal structure — to what extent the programming team uses a

goal structure, and to what extent the team depends on it for its day-to-

day decision making.

• Using a goal structure (sủ dụng goal structure) – đội ngũ lập trình viên

sử dụng goal structure tới một mức độ nao đó, va phụ thuộc vao nó

trong các quyết định hằng ngay.

• Adherence to a software life cycle — to what extent a team uses and

depends on a software life cycle.





• Adherence to a software life cycle (sự gắn bó với vòng đời của phần

mềm) – một đội ngũ đƣợc sử dụng va phụ thuộc vao vòng đời của phần

mềm.

• Adherence to an activity distribution — to what extent the

programming team uses a precise definition of life cycle activities, and

to what extent they depend on it for decision making.

• Adherence to an activity distribution (sự gắn bó với hoạt động phân

phối) – đội ngũ lập trình viên định nghĩa một cách rõ rang vòng đời của

phần mềm va họ dựa vao nó để đƣa ra các quyết định.

• Usage of cost estimation procedures — to what extent the

programming team uses a software cost-estimation model and to what

extent they depend on it for decision making.

• Usage of cost estimation procedures (sử dụng về khả năng ƣớc lƣợng

giá thanh sản phầm) đội ngũ lập trình sẽ sử dụng mô hình software

cost-estimation để ƣớc lƣợng giá thanh sản phẩm tới mức nao va dụa

vao đó để đƣa ra quyết định.

8. Programming environment is composed of four controllable factors:

Môi trƣờng lập trình la một sự kết hợp cảu 4 nhân tố:





• Programming tools.To what extent the programmer uses software tools

and how powerful these tools are (i.e., debuggers, editors).

• Programming tools (công cụ lập trình) Lập trình viên sử dụng các công

cụ phần mềm đến mức độ nao, va những công cụ đó mạnh ra sao ? (vd

debuggers, editors)

• Modern programming practices. To what extent does the programmer

use modern programming practices and how powerful are they? This

includes modular programming, program libraries, and reuse.

• Modern programming practices. (phong cách lập trình hiện đại) – Lập

trình viên sử dụng những phong cách lập trình mới nhƣ thế nao va

chúng có lợi ra sao. nó bao gồm modular programming, program

libraries, và reuse.

• Programming standards. To what extent are standards used, how

stringent are they, and how strictly are they adhered to? Examples

include test standards, verification standards, validation standards, and

standards of unit size.

• Programming standards.(tiêu chuẩn lập trình) những tiêu chuẩn đƣợc

sử dụng đến mức nao, sự khắt ke của chúng đến mức nao, sự gán bó

với chúng ra sao ? VD: tiêu chuẩn về kiểm thử, tiêu chuẩn về sự đánh

giá xác minh, tiêu chuẩn về hiệu lực, tiêu chuẩn về quy mô của đơn vị.





• Power of equipment used. Barry Boehm introduced two factors

pertaining to the power of equipment used: a factor that measures

memory space limitations and a factor that measures time limitations.

• Power of equipment used (Chất lƣợng thiết bị đƣợc sử dụng) Barry

Boehm đƣa ra 2 yếu tố liên quan đến chất lƣơng của thiết bị đƣợc sử

dụng: la nhân tố hạn chế về mặt bộ nhớ va nhân tố về giới hạn thời gian

sử lý.

9. The participation of users has been found to have an important impact

on programmer productivity. Well prepared users reduce the cost of

software maintenance.

Sự tham gia của ngƣời sử dụng đƣợc nhận ra la có ảnh hƣởng lớn

đến hiệu quả của lập trình viên. Việc nay giảm chi phi cho việc bảo trì phần

mềm.

• Previous education in computing. What is the duration level of the

users‘ previous education in computing.

• Previous education in computing (Trƣớc đao tạo về sử dụng máy tinh)

Khoảng thời gian ma ở mức độ ngƣời sử dụng chƣa qua đao tạo la bao

lâu.

• Experience in computing. To what extent has the user used computers

in the past? Previous experience gives users a better sense of what





computers can do for them and enables them to express their desires

more effectively.

• Experience in computing.(có kinh nghiệm về mặt sử dụng máy tinh)

ngƣời dung đã sử dụng máy tinh trong quá khứ ở mức độ ra sao ?

những kinh nghiệm trƣớc có cho ngƣời dụng một khả năng tốt hơn về

những việc ma máy tinh có thể lam cho họ va cho phép họ bay tỏ mong

muốn của mình một cách hiệu quả

• Experience with the type of application. Experience in building

computer systems in the same application domain is valuable. The

major incentive for rapid prototyping is to have a high rating for this

factor.

• Experience with the type of application.(có kinh nghiệm với kiểu ứng

dụng đó) có kinh nghiệm với hệ thống máy tinh ở cùng một miền ứng

dụng la rất có ich. Khich lệ chinh cho những mẫu đầu tiên đƣợc đánh

giá cao cho yếu tố nay

• Experience with the group of programmers and analysts (kinh nghiệm

với những nhóm lập trình viên va ngƣời phân tich)

10. Survey results on Tunisian subjects:

Kết quả của cuộc nghiên cứu về đề tai Tunisian:





• Of the 16 motivation factors, 5 were statistically significant and

account for 18.89 percent of programmer productivity: technical

supervision, working conditions, achievement, responsibilities, and

recognition.

• Trong 16 nhân tố thúc đẩy, 5 nhân tố quan trọng va giải thich cho 18.89

% hiệu quả lam việc của lập trình viên: technical supervision, working

conditions, achievement, responsibilities, and recognition.

• Of the four personnel experience factors, only two were found to be

statistically significant and account for 7.49 percent of programmer

productivity: experience with the virtual machine and user community.

• Trong 4 nhân tố về nhân sự, chỉ có 2 nhân tố đƣợc nhận thấy la có ảnh

hƣởng va chiếm 7,49 % hiệu quả lam việc của lập trình viên:

experience with the virtual machine and user community.

• Of the factors used to assess project management, two were proved

significant and explain 5.57 percent of programmer productivity: the

definition and use of a software life cycle and software cost estimation.

• Trong những nhân tố đƣợc sử dụng để quản lý dự án, 2 nhân tố đƣợc

chúng minh quan trọng va giải thich cho 5.57% hiệu quả lam việc của

lập trình viên: the definition and use of a software life cycle and

software cost estimation.





• In the programming environment area two factors explained 9.62

percent of programmer productivity: the use of modern programming

practices and the power of equipment used for development.

• Trong phạm vi môi trƣờng lập trình 2 nhân tố giải thich cho 9.62 %

hiệu quả lam việc của lập trình viên: the use of modern programming

practices and the power of equipment used for development.

• Two user factors were found to be significant and explained a 5.33

percent of programmer productivity: experience of the user community

with computers and the experience of the user community with the

group of programmers and analysts.

• 2 nhân tố về ngƣời dùng đƣơc nhận thấy có ảnh hƣởng va giải thich co

5.33 % hiệu quả lam việc của lập trình viên: experience of the user

community with computers and the experience of the user community

with the group of programmers and analysts.


Boehm, B.W. (1981). Software Engineering Economics. Prentice-

Hall, Englewood Cliffs, NJ.

Kemayel, L., Mili, A., and Ouederni, I. (1991). Controllable factors

for programmer productivity:a statistical study, J. Syst. Software, 16, 151–

163.






Basili, V.R. and Weiss, D.M. (1984). A methdology for collecting

valid software engineering data,IEEE Trans. Software Eng., SE-10, 728–

737.

Mills, H.D. (1983). Programmer Productivity, Little, Brown and

Co., Boston, MA.




Chương 38: The AT&T’s “Estimeeting”Process 908

CHƢƠNG 37 THE AT&T’S “ESTIMEETING’

PROCESS FOR DEVELOPING ESTIMATES

Người dịch: Nguyễn Thanh Tòng

37.1 TỔNG QUAN

This chapter presents a method for estimating a software

development effort in the early phases of a large software-intensive project.

For each feature of the project to be estimated, a ―feature team‖ generates a

detailed feature definition that is used in what the Taff, Borchering, and





Hudgins (1991) term an ―estimeeting‖. Using this process it is possible to

build in software quality, by design, in the early stages of development and

not added on later in a series of fixes to problems uncovered in testing.

Building in quality requires ―front loading‖ the development process,

yielding better designs and fewer errors that are more easily and cleanly

isolated and repaired.

Chƣơng nay trình bay một phƣơng pháp để đánh giá một sự nổ lực

phát triển phần mềm nằm trong giai đoạn đầu của một dự án phần mềm lớn.

Đối với mỗi tinh năng của dự án đƣợc ƣớc tinh, một đội ngũ tinh năng

(feature team) tạo ra một định nghĩa tinh năng chỉ tiết ma đƣợc sử dụng

trong Taff, Borchering, va Hudgins (1991) gọi la thuật ngữ ―estimeeting‖.

Sử dụng quá trình nay la khả thi trong việc xây dựng trong chất lƣợng phần

mềm, bẳng cách thiết kế, ở giai đoạn đầu của sự phát triển va không đƣợc

thêm vao sau nay trong một loạt các bản sửa lỗi cho các vấn đề không đƣợc

phát hiện trong thử nghiệm. Xây dựng chất lƣợng đòi hỏi phải "nạp trƣớc‖

quá trình phát triển, xây dụng tốt hơn thiết kế va it lỗi để dễ dang hơn trong

việc cô lập va sửa chữa.

More complete work in the early stages can serve to identify tools or

special testing needs earlier. If the estimates for a project are too low, then

project staffing will also be too low. As needs become apparent, staff are

―back-end loaded‖, which is the reverse of what is desirable for a high-

quality product. The ―estimeeting‖ process described in this chapter can be





used to estimate a software project accurately. The benefits of this process,

as identified by the authors, are as follows:

Cang nhiều công việc hòan thiện ở giai đoạn đầu có thể phục vụ để

xác định các công cụ hoặc các nhu cầu kiểm thử đặc biệt sớm hơn. Nếu quá

trình đánh giá/ƣớc tinh cho một dự án quá thấp, sau đó việc bố tri nhân sự

cho dự án cũng thấp, khi nhu cầu trở nên rõ rang, đội ngũ nhân viên đƣợc

tái cơ câu lại, đó la đảo ngƣợc của những gì đƣợc mong muốn cho một qui

trình chất lƣợng cao.quá trình estimeeting đƣợc mô tả trong chƣơng nay có

thể đƣợc sử dụng để ƣớc tinh một dự án phần mềm chinh xác. Những lợi

ich của quá trình nay, nhƣ đƣợc xác định bởi các tác giả, nhƣ sau:

• Better estimates. There is an ability to predict resources more

accurately.

• Uớc lƣợng tốt hơn. Có một khả năng dự đoán tai nguyên hơn chinh

xác.

• Earlier and closer subsystem involvement. Subsystem owners attend

meetings earlier, see what new features may be down the pike, and as a

result, can make allowances.

• Sớm hơn va gần hơn sự tham gia của hệ thống phụ. Chủ sở hữu của hệ

thống con tham dự các cuộc họp sớm hơn, xem những tinh năng mới có

thể chƣa ổn, va kết quả la, có thể tăng phụ cấp cho chức năng đó.





• Early direct relationships. The meetings foster teamwork.

• Có mối quan hệ trực tiếp với nhau sớm hơn. Các cuộc họp nuôi dƣơng

tinh thần đồng đội.

• Early expert high-level designs. Byproducts of these meetings are ideas

that are useful for the next level of design.

• Sớm đạt tới bản thiết kế cao cấp. Sản phẩm từ các cuộc họp nay la ý

tƣởng có ich đối với các cấp độ tiếp theo của thiết kế.

• Problem detection. There is a better understanding of potential

problems of resources and performance.

• Vấn đề phát hiện. Có một sự hiểu biết tốt hơn về những vấn đề tiềm

năng của các nguồn lực va hiệu suất.

• Better quality. Multiexpertise team leads to better definition,

requirements, and design.

• Chất lƣợng tốt hơn. Nhiều ý kiến dẫn đến định nghĩa tốt hơn, yêu cầu

tốt hơn, va thiết kế tốt hơn.

• Features interactions and synergy. This leads to a better understanding

of how all features interact.





• Tinh năng tƣơng tác va tổng hợp. Điều nay dẫn đến một sự hiểu biết tốt

hơn về tất cả các tinh năng tƣơng tác nhƣ thế nao.

• Project knowledge base. This improves the expertise and knowledge

base for stimators, helping to produce more system experts.

• kiến thức cơ bản về dự án. Điều nay nâng cao chuyên môn va kiến thức

cơ sở cho nha đánh giá(estimators), giúp đơ đao tạo các chuyên gia hệ

thống nhiều hơn nữa.

37.2 THỦ TỤC/CHÍNH SÁCH/VẤN ĐỀ

An estimeeting is a standardized working meeting with regularly

attending estimators. The meeting capitalizes on the synergy of having the

key people together. Success requires good feature requirements and a

high-level design proposal in advance and attendance by a specific group of

experienced people.

Estimeeting la một cuộc họp với việc thƣờng xuyên tham dự của các

estimator. Cuộc họp dựa trên việc có nhiều key-people lam việc với nhau.

Thanh công đòi hỏi những yêu cầu tinh năng tốt va một đề nghị thiết kế cấp

cao đƣợc trình bay, va đƣợc tham gia đánh giả bởi một nhóm cụ thể của

những ngƣời có kinh nghiệm.

The front-end process constitutes the selection process through

which feature candidates are picked for development. It begins with a list of





feature candidates and ends when a subset has been approved for

development. This process attempts to balance the conflicting needs of

business.

Cuộc họp bắt đầu với quá trình lựa chọn tinh năng ứng viên việc phát

triển. Nó bắt đầu với một danh sách tinh năng ứng viên va kết thúc khi một

tập hợp con đã đƣợc chấp thuận để phát triển. Quá trình nay cố gắng để cân

bằng các xung đột nhu cầu của việc kinh doanh.

Project-planning. Estimates are used for project management once

the project begins. In addition to project planning, long-range planning is

also based on development estimates. Multirelease planning ries to account

for: 1) experienced staff, 2) test facilities, and 3) interactions with other

products such as billing, etc.

Kế họach dự án. Quá trình đánh giá đƣợc sử dụng cho quản lý dự án

khi dự án bắt đầu. Ngoai việc lập kế hoạch dự án, quy hoạch tầm xa cũng

dựa trên các số ƣớc lƣợng phát triển. Việc quy hoạch dự án cố gắng tinh

tóan các số liệu sau: 1) đội ngũ nhân viên giau kinh nghiệm, 2) kiểm tra các

tinh năng, 3) tƣơng tác với các sản phẩm khác nhƣ thanh toán, v.v..

Software is grouped into subsystems. The subsystems are organized

functionally for the various tasks that the ultimate product must perform.





Hệ thống phần mềm đƣợc chia thanh các nhóm hệ thống phụ. Các hệ

thống phụ đƣợc tổ chức chức năng cho các nhiệm vụ khác nhau ma các sản

phẩm cuối cùng phải thực hiện.

The large size of a project has implications. Project planning and

management have large economic impacts; errors in estimation can have

serious consequences.

Kich thƣớc lớn của một dự án có liên quan đến việc quy hoạch va

quản lý,ƣớc lƣợng có tác động lớn về kinh tế; sai sót trong dự toán có thể có

hậu quả nghiêm trọng.

Estimation can be broken down into two major parts. The first is job

size, which is the size and complexity of the code. The second part of

estimation is the effort required once the size is known. This effort depends

on the productivity of the development organization.

Dự toán/ƣớc tinh có thể đƣợc chia thanh hai phần chinh. Đầu tiên la

công việc tinh kich thƣớc, kich cơ va độ phức tạp của mã. Phần thứ hai dự

toán la những nỗ lực cần thiết khi kich thƣớc đƣợc biết đến. Nỗ lực nay phụ

thuộc vao năng suất của tổ chức phát triển.

The estimeeting methodology evolved from three principles:

• Estimates are important numbers because they help determine product

content. Underestimating can cause failure to meet commitments with





dire consequences for business. Estimates impact quality because they

control the distribution of effort over the development cycle

• Experienced people give the best values. Estimators compare the job to

be estimated with one from their own experience. Therefore, the more

extensive the experience, the more likely it is that the estimate will be

accurate.

• Cooperative meetings give excellent results. It has been proven that

team consensus improves on the best individual solution.

Các phƣơng pháp estimeeting phát triển từ ba nguyên tắc:

• Ƣớc tinh đem đến những số liệu quan trọng bởi vì chúng giúp xác định

nội dungsản phẩm.

• Những ngƣời có kinh nghiệm cho các giá trị tốt nhất.

• Hợp tác xã cuộc họp cho kết quả tuyệt vời.

The concept behind the estimeeting is to get into one room people

highly experienced in all the major aspects of feature and subsystem

development and with the authority to represent the technical viewpoint of

their organizations. In this meeting, they come to a common understanding

of a new feature, agree on an informal, nonbinding, high-level design

proposal, and estimate development effort in their own areas of expertise.





Việc tiếp cận phia sau Estimeeting la để có một phòng tòan những

ngƣời giau kinh nghiệm về về lĩnh vực các tinh năng ma đƣợc phát triển bởi

tổ chức của họ.Tại cuộc họp nay họ đi đến một hiểu biết chung cơ bản về

tinh năng mới,một bản thiết kế cao cấp,đánh giá nổ lục phát triển đối với

các lĩnh vực chuyên môn của riêng họ.

With a preliminary recommendations feature list, a schedule is set

down and for each feature on the list a feature team is formed. Over a

chosen time period, each team produces two outputs — the external feature

requirements (FSPs) and the internal feature design (FAP).

Với một kiến nghị sơ bộ danh sách tinh năng đƣợc đƣa ra, một kế

họach lam việc đƣợc thiết lập xuống va cho mỗi tinh năng trong danh sách

một nhóm phát triển tinh năng đƣợc hình thanh. Qua một khoảng thời gian

đã chọn, mỗi đội sản xuất hai output gồm các yêu cầu ngoai tinh năng

(FSPS) va những thiết kế tinh năng nội bộ(FAP)

These documents are distributed to estimators, the engineers with in-

depth knowledge of the subsystems. The estimators are not on feature

teams; they represent the development interests of their subsystems and

receive these requirements and design documents for every feature that

impacts their subsystems.

Những tai liệu nay đƣợc phân phối đến các nha đánh giá, các kỹ sƣ

với chiều sâu kiến thức về các hệ thống phụ. Các estimators không phải la





một ngƣời của nhóm đảm trách tinh năng; họ đại diện cho lợi ich phát triển

của hệ thống con va nhận các yêu cầu nay va các tai liệu thiết kế cho mọi

tinh năng ma các tác động đến hệ thống con.

Team members are drawn from the concerned organizations

(systems engineering, development). Some individuals join more than one

feature team. Each feature team is responsible for estimeeting preparation,

presentation, and follow-up for its feature. Although composition of the

team may evolve, it is initially composed of:

• Systems engineer

• The feature engineer

• The system architect

• The planner

• The product manager

Thanh viên mỗi đội đƣợc rút ra từ các tổ chức có liên quan (hệ thống

kỹ thuật, phát triển). Một số cá nhân tham gia nhiều hơn một đội phát triễn

tinh năng. Mỗi nhóm tinh năng chịu trách nhiệm đánh giá,chuẩn bị, trình

bay, va theo dõi cho các tinh năng ma đội phụ trách. Mặc dù thanh phần của

đội có thể tiến triển thêm, ban đầu gồm có:

• Kỷ sƣ hệ thống





• Kỷ sƣ phát triển tinh năng.

• Kiến trúc sƣ hệ thống.

• Ngƣời lập kế họach.

• Ngƣời quản lý sản phẩm.

The FAP (feature architecture proposal) contains:

• Description of new internal architectures where applicable AT&T‘s

―Estimeeting‖ Process for Developing Estimates

• High-level functional description of how the feature works from

hardware and software design viewpoints

• Expected feature performance

• Dependencies and interactions with other new or existing features

• Open issues of design and architecture and proposed solutions

FAP bao gồm:

• Mô tả một tinh năng nội bộ ma phù hợp với AT&T‘s ―Estimeeting‖ để

phát triển đánh giá.





• Một mô tả chi tiết cách tinh năng tƣơng tắc với phần mềm va phần

cứng ra sao.

• Mong muốn tinh năng họat động ra sao

• Sự độc lập va ảnh hƣởng lẫn nhau giữ các tinh năng đã có va sắp them

vào.

• Những vần đề mở về việc thiết kế va kiến trúc va những giải pháp đề

xuất.

The FSP (feature selection proposal) consists of:

• Feature operation (typical user scenarios)

• Feature interaction with other features

• Feature impact

• Constraints

• Restrictions

FSP bao gồm:

• Cách họat động của tinh năng

• ảnh hƣởng lẫn nhau giữ các tinh năng





• sự tác động của tinh năng

• các rang buộc

• sự hạn chế.

Prior to the first estimeeting, the following package is assembled:

• People expected to attend

• FSP (external requirements)

• FAP (design and system-impact checklis

Những tai liệu sau đây đƣợc thu thập cho Estimeeting đầu tiên:

• Những ngƣời đuợc mong đợi sẽ tham gia

• FSP

• FAP

The estimeeting takes about two hours for a single feature. A

moderator begins by introducing the feature team members and may briefly

discuss the agenda and ground rules.

Estimeeting mất khoảng hai giờ cho một tinh năn. Một ngƣời quan lý

bắt đầu bằng việc giới thiệu các thanh viên trong nhóm tinh năng va có thể





có một thời gian ngắn thảo luận về chƣơng trình nghị sự va các quy tắc

chung.

The system engineer presents feature description and requirements

and delineates what is optional and mandatory.

Các kỹ sƣ hệ thống trình bay,mô tả yêu cầu của tinh năng

va vạch những yêu cầu nao la tùy chọn va nhữg yêu cầu nao la bắt buộc.

A secretary, often the planner, takes notes and records assumptions

and issues. A question and answer period typically follows the

presentations.

Một thƣ ký, thƣờng la các nha quy hoạch, cần ghi chú va lƣu lại các

giả định về các vấn đề,những câu hỏi va câu trả lời thƣờng kèm theo trong

khoảng thời gian sau các thuyết trình.




Chương 39: Khung Burn để xây hệ thống đáng tin cậy 921

CHƢƠNG 38 KHUNG BURN ĐỂ XÂY HỆ

THỐNG ĐÁNG TIN CẬY

Người dịch: Nguyễn Hoang Việt

38.1 TỔNG QUAN

The role and importance of nonfunctional requirements in the

development of complex critical applications have, up until now, been

inadequately appreciated. It has been shown, through experience, that this

approach fails to produce dependable systems





Cho đến nay, vai trò và tầm quan trong của những yêu cầu phi chức

năng trong phát triển các ứng dụng phức tạp chƣa đƣợc đánh giá cao. Nó

đƣợc thực hiện thông kinh nghiệm, đây la cách tiếp cận sai để tao ra hệ

thống tin cậy.

Nonfunctional requirements include dependability (e.g., reliability,

availability, safety, and security), timeliness (e.g., responsiveness,

orderliness, freshness, temporal predictability, and temporal controllability)

and dynamic change management (i.e., incorporating evolutionary changes

into a nonstop system).

Yêu cầu phi chức năng gồm tính tin cậy (an toàn, bảo mật). Tính kịp

thời hiện đại (phản ứng, dự báo thời, điều khiển), quản lý sự thanh đổi năng

động(kết hợp những thay đổi tiến hoá mà không làm dừng hệ thống).

The purpose of the framework described in this chapter (Burns and

Lister, (1991) is to:

• Impose a design discipline that ensures that appropriate abstractions

are used at each level of the design

• Allow assertions to be developed that the nonfunctional requirements

can be met by the design if implemented in a particular environment

• Allow interactions between these nonfunctional requirement to be

analyzed so that dependencies can be identified





• Allow the nonfunctional and functional requirements to be traded off

against each other

Mục đich của khung mô tả trong chƣơng nay(Burns and Lister,

1991) là:

• Áp đặt một kỷ luật thiết kế ma bao đảm rằng áp sự trừu tƣợng sử dụng

trong mỗi mức thiết kế một cách hơp lý.

• Cho phép khẳng định sẽ phát triển các yêu cầu phi chức năng có thể

đáp ứng bằng đƣợc bằng việc thiết kế., nếu thực hiện trong một môi

trƣờng cụ thể.

• Cho phép tƣơng tác giữa các yêu cầu phi chức năng để phân tich những

sự phụ thuộc lẫn nhau.

• Cho phép các yêu cầu chức năng va phi chức năng kết hợp va trao đổi

lẫn nhau.


1. A constructive way of describing the process of system design is a

progression of increasingly specific commitments that define properties

of the system design which designers operating at a more detailed level

are not at liberty to change. For example, early in the design there may





already be commitments to the structure of a system, in terms of

module definitions and relationships

Một cách mô tả các quá trình thiết kế hệ thống la chuỗi chỉ ngay

cang rõ sự chuyển giao ma xác định (định rõ) các đặc tinh của thiết kế hệ

thống cái ma ngƣời thiết nó tinh toán nó ở mỗi mức cụ thể hơn. Không tự

do thay đổi. Vi dụ, đầu tiên của thiết kế thật sự la cam kết cấu trúc của hệ

thống. vế các đinh nghĩa moudle va quan hệ.

2. Those aspects of a design to which no commitment is made at some

particular level in the design hierarchy are the subject of obligations

that lower levels of design must address. For example, the behavior of

the defined ―committed to modules‖ is the subject of obligations that

must be met during further design and implementation

Những khia cạnh của một thiết kế để có thể cam kết không đƣợc

thực hiện ở một số cấp độ cụ thể trong hệ thống phân cấp thiết kế la đối

tƣợng của nghĩa vụ ma các cấp thấp hơn của thiết kế phải giải quyết. Vi dụ,

hanh vi của các định nghĩa "cam kết mô-đun‖ la chủ đề của nghĩa vụ đó

phải đƣợc đáp ứng hơn nữa trong quá trình thiết kế va thực hiện.

3. The process of refining a design — transforming obligations into

commitments — is often subject to constraints imposed primarily by

the execution environment





Quá trình cải tiến một thiết kế - chuyển đổi thanh các nghĩa vụ hanh

cam kết- thƣờng chịu những khó khăn chinh từ môi trƣờng thực thi

4. The execution environment is the set of hardware and software

components on top of which a system is built. It may impose resource

constraints (e.g., processor speed) and constraints of mechanism(e.g.,

data locking).

Môi trƣờng thực thi la phần cứng va các phần mền điều hanh hệ

thống. Nó có thể áp đặt các hạn chế tai nguyên (tốc tộ xủ lỳ, bộ nhớ) hoặc

các rang buộc khó khăn(khóa dữ liệu).

5. The framework controls the introduction of necessary implementation

details into the design process by distinguishing two phases in the

construction of an architectural design of any application:

• Logical architecture — embodies commitments that can be made

independently of the constraints imposed by the execution environment

and is aimed at satisfying the functional requirements.

• Physical architecture — takes constraints into account and embraces

nonfunctional requirements.

Khung kiểm soát việc đƣa vao những chi tiết thực thi cần thiết vao

thiết kế hệ thống bởi 2 quá trình quá trình phân biệt trong sự xây dựng kiến

trúc của bất kỳ hệ thống ứng dụng nao





Kiến trúc logic: gốm các cam kết thực hiện có thể thực hiện đƣợc nó

độc lập với các rang buộc khó khăn trong môi trƣờng thực thi va mục tiêu

la đáp ứng các nhu cầu chức năng.

Kiến trúc vật lý: rang buột tiền va bao trùm các yêu cầu phi chức

năng.

6. The nonfunctional requirements of an application can be considered as

projections onto the physical architecture. Distinct projects apply to

timeliness, safety, etc. The physical architecture makes it explicit where

projections interact and enables criteria to be developed that cater for

these interactions.

Yêu cầu phi chức năng đƣợc xem nhƣ la phần phô ra của thiết kế vật

lý. Mục đich của thiết kế vật lý la sự hợp thời(tinh tiến hoá), an toan. Thiết

kế vật lý lam cho nó rõ rang ở những nơi có sự giao tác va sự phát triển

giao tác.

7. The framework is grounded in the object-oriented approach to system

design. This approach is widely regarded as offering a conceptual

framework for mastering the complexities of the design process:

• Objects are an adequate modeling tool for the functional requirements

of the system.





• They can be used to provide traceability through all stages of the design

process.

• They are an adequate basis for expressing nonfunctional requirements.

• They provide an appropriate granularity for replication, checkpointing,

dynamic change management, configuration, and dynamic

reconfiguration.

• They assist error containment through encapsulation.

• They can support dynamic security by access right mechanisms on

operations.

• They can represent schedulable entities.

• Commonly encountered standard architectures can be implemente by

means of redefined classes and methods.

Khung đƣợc áp dụng trong phƣơng pháp hƣớng tƣợng để thiết kế hệ

thống. Cách tiếp cận náy khá rộng rãi đƣợc xem nhƣ la một sự đề nghị cho

khái niệm khung chinh yếu cho những tiến trình thiết kế phức tạp:

• Đối tƣợng la một mô hình công cụ đầy đủ cho yêu cầu chức năng của

hệ thống.





• Chúng ta có thể dùng để truy vấn các thông tin của các giai đoạn thiết

kế.

• Chúng la một nền tảng đẩy đủ để thể hiện các yêu cầu phi chức năng.

• Chúng cung các chức năng thich hợp để nhân rộng, kiểm tra,thay đổi

quản lý năng động, cấu hình va cấu hình lại năng động.

• Ngăn chặn lỗi thông quá đóng gói.

• Chúng hỗ trợ an ninh truy cập năng động qua các quyền truy cập vao

hệ thống.

• Chúng có thể hiện đại hoá các thực thễ

• Thƣờng gặp kiến trúc tiêu chuẩn thƣờng đƣợc thực hiện bằng các

phƣơng pháp định nghĩa lại lớp va phƣơng thức.

8. The logical architecture is concerned with defining a se of object

classes, their interfaces, and relationships, which together meet all the

functional requirements. In the logical architecture, communication

between the classes is represented by invocation of methods.

Các kiến trúc logic có liên quan tới định nghĩa tập các lớp đối

tƣợng, giao diện, va mối quan hệ, ma cùng nhau đáp ứng đủ các yêu cầu về

chức năng. Trong kiến trúc logic, giao tiếp giữa các lớp đƣợc đại diện bởi

lời yêu cấu các phƣơng thức.





9. The physical architecture is concerned with objects, that is, instances of

the classes defined in the logical architecture. It refines the logical

architecture in two ways:

• It instantiates objects from the classes defined in the logical

architecture and maps them onto the target execution environment.

• It annotates the objects and their methods with attributes (such as

deadlines) derived from t e nonfunctional requirements.

Kiến trúc vật lý có liên quan với các đối tƣợng, có nghĩa la, liên quan

đến các thể hiện của những lớp đƣợc định nghĩa trong kiến trúc logic. Nó

cải tiến lớp logic ở 2 phƣơng diện:

• Nó thể hiện những đối tƣợng của lớp đƣợc định nghĩa trong trong kiến

trúc logic va maps(vẽ chúng) chúng vao trong môi trƣờng thực thi.

• Nó chú giải các đối tƣợng va phƣơng thức của chúng với các thuộc tinh

bắt nguồn từ các yêu cầu phi chức năng.




Chương 40: Phương pháp tiếp cận đa diện của Avison 930

CHƢƠNG 39 PHƢƠNG PHÁP TIẾP CẬN ĐA

DIỆN CỦA AVISON

Người dịch: Lê Hoang Vũ

39.1 TỔNG QUAN

The proliferation of systems development methodologies has

resulted in much confusion. In fact, it has been estimated that hundreds of

more or less similar methodologies exist. In practice, most organizations





have developed their own methodology. There have been many attempts to

compare methodologies; past research by Avison managed to categorize

methodologies into six broad themes. This chapter describes a contin-

gency framework, called Multiview (Avison and Wood-Harper,1991),

which includes descriptions of relevant techniques and tools. Analysts and

users select those aspects of the approach appropriate to the application, in

effect, creating a unique methodology for each application.

• Sự phát triển của hệ thống dẫn tới nhiều phƣơng pháp đƣợc phát sinh

• Mỗi tổ chức có 1 phƣơng pháp riêng

• Avison phân loại các phƣơng pháp thanh 6 chủ đề rộng


1. Problems with methodologies in practice:

• Failure to meet needs of management

• Unambitious systems design

• Inflexibility due to the output-driven design

• User dissatisfaction





• Problems with documentation

• Maintenance workload

• Application backlog

• Không đáp ứng đƣợc nhu cầu của sự quản lý.

• Không hƣớng tới thiết kế của hệ thống.

• Không có tinh linh động theo các hƣớng thiết kế.

• Ngƣời dùng không hai lòng.

• Vấn đề với tai liệu hƣớng dẫn.

• Bảo trì khối lƣợng công việc.

2. Categories:

• Category 1: Systems approach highlights the importance of the

relationship between an organization and its environment, and of

multidisciplinary teams to understand organizations.

• Category 2: Planning approaches involve strategic management in

information systems work so that their needs are analyzed and

information systems are implemented that do more than comput- erize





the operations level applications. This approach attempts to identify the

needs of management and plans the ways of meeting these needs.

• Category 3: In a participative approach all users are expected to

contribute to and gain from any information system; this should

increase the potential for success.

• Category 4: Prototyping enables users to comment on the proposed

information system and its inputs, processing, and outputs before the

system has been designed in its final form.

• Category 5: Structured approaches aid the understanding of a complex

problem through functional decomposition and the associated

documentation techniques. This approach tends to emphasize decision

trees, decision tables, data-flow diagrams, etc.

• Category 6: Data analysis is a useful modeling tool in which the data

model produced is likely to be relevant for a longer period than models

of processes, which can be unstable.

• Hệ thống phƣơng pháp tiếp cận.

• Kế hoạch liên quan đến phƣơng pháp tiếp cận quản lý chiến lƣợc trong

hệ thống thông tin.

• Ngƣời dùng đóng góp ý kiến.





• Dùng Prototype (Mẫu thử) để lấy ý kiến ngƣời dùng.

• Phƣơng pháp tiếp cận một vấn đề phức tạp thông qua chức năng phân

tích va các tai liệu kỹ thuật liên quan.

• Phân tich dữ liệu.

3. The multiview meta-methodology:

• Step 1: Analysis of human activity. This stage concerns the search for

view of the organization, representing a subjective as well as objective

perception of the problem situation in diagrammatic and pictorial form.

It is used to identify problem themes. Through debate within the

organization, it is possible to identify relevant systems that may relieve

problem themes. The root definition describes the system on which to

focus attention. The root definition is analyzed to make sure that all

necessary elements have been identified including the owner of the

system, the client, the transformation that takes place, and the

environment in which it takes place.

• Step 2: Analysis of information. At this stage, the entities and func-

tions of the system described are analyzed. By using functional

decomposition, it is possible to break down the main function (clear in

a well-formed root definition) into subfunctions.Using data-flow

diagrams, it is possible to analyze the sequence of events. In

developing an entity model, the problem solver extracts and names





entities, relationships between entities, and attributes that describe the

entities.

• Step 3: Analysis and design of sociotechnical aspects. At this stage, the

problem solver produces a design from an analysis of people and their

needs and the working environment along with consideration for the

organizational structure, computers, and the necessary work tasks.

The social and technical objectives are set and alternatives specified

and compared so that the best solution can be selected. Once selected,

computer tasks, role tasks, and people tasks can be defined. The

emphasis at this stage is not on development, but on a statement of

alternatives, according to important social and technical considerations.

• Step 4: Design of the human computer interface. Decisions are made

as to batch versus online versus ommand, etc. Specific conversations

and interactions are then designed; users are expected to be the major

contributors of this stage. Technical requirements to fulfill these

human–computer interfaces can then be designed. technical

considerations. The technical design will include the application

subsystems and the nonapplication subsystems. These include the

information retrieval subsystem, database, database maintenance

subsystem, control subsystem, etc.

• Step 5: Design of technical aspects. Using the entity model created in

Step 2 and the technical requirements from Step 4, a more technical





view can be taken by the analyst because human considerations are

already integrated with the forthcoming

• Bƣớc 1: Phân tich các hoạt động của con ngƣời. Giai đoạn nay la mối

quan tâm va tìm hiểu của tổ chức, đại diện cho một chủ quan cũng nhƣ

nhận thức khách quan của tình hình vấn đề

• Bƣớc 2: Phân tich các thông tin. Ở giai đoạn nay, các thực thể chức

năng của hệ thống đƣợc mô tả la phân tich. Bằng cách sử dụng chức

năng phân tich, có thể để phân tich những chức năng chinh thanh các

chức năng nhỏ hơn.

• Bƣớc 3: Phân tich các khia cạnh kĩ thuật. Ở giai đoạn nay, giải quyết

vấn đề sản xuất một thiết kế từ phân tich của khách hang va nhu cầu

của họ va môi trƣờng lam việc cùng với các cơ cấu tổ chức, máy tinh,

va nhiệm vụ công tác cần thiết. Các mục tiêu xã hội va kỹ thuật đƣợc

thiết lập va lựa chọn, so sánh để chọn ra các giải pháp tốt nhất có thể

đƣợc chọn. Một khi đã chọn, máy tinh có thể đƣợc xác định đƣợc vai

trò va nhiệm vụ.

• Bƣớc 4: Thiết kế của giao diện máy tính dựa trên con ngƣời. Các quyết

định đƣợc thực hiện khớp với lệnh trực tuyến, nhƣ cuộc hội thoại tƣơng

tác cụ thể va sau đó đƣợc thiết kế; ngƣời dùng dự kiến sẽ la những

ngƣời đóng góp chinh của giai đoạn nay. Yêu cầu kỹ thuật để hoan

thành các giao diện ngƣời-máy tinh có thể đƣợc thiết kế.





• Bƣớc 5: Thiết kế của các khia cạnh kỹ thuật. Sử dụng mô hình thực thể

trong Bƣớc 2 va các yêu cầu kỹ thuật từ Bƣớc 4, một lần nữa cân nhắc

xem các kỹ thuật có thể đƣợc thực hiện bởi các nha phân tich không vì

con ngƣời đã đƣợc quen với các cân nhắc kỹ thuật. Thiết kế kỹ thuật sẽ

bao gồm các hệ thống phụ ứng dụng. Hệ thống nay bao gồm các hệ

thống con truy vấn thông tin, cơ sở dữ liệu, hệ thống phụ bảo trì cơ sở

dữ liệu, hệ thống phụ điều khiển, vv

Năm giai đoạn trên đã kết hợp năm điểm khác nhau cho sự phát triển

của một phân tich va thiết kế dự án. một cách tiếp cận MultiView.

These five stages incorporate five different views that are appropri-

ate to the progressive development of an analysis and design project.

Because it is a multiview approach, it covers computer- related questions

and also matters relating to people and business functions Each step

addresses one of the following five questions:

• How is the information system supposed to further the aims of the

organization using it?

• How can it be fit into the working lives of the people in the organi-

zation who will use it?

• How can individuals concerned best relate to the computer in terms of

operating it and using the output from it?





• What information processing function is the system to perform?

• What is the technical specification of a system that will come close

enough to doing the things written down in the answers to the other

four questions?

Cách tiếp cận nay sẽ trả lời đầy đủ các câu hỏi sau:

• Lam thế nao hệ thống thông tin thỏa mãn tổ chức sử dụng nó.

• Lam thế nao hệ thống phù hợp với từng cá nhân trong tổ chức.

• Lam thế nao những cá nhân liên quan tới hệ thống có thể sử dụng nó

hiệu quả.

• Chức năng thông tin ma hệ thống đảm nhận.

• Đặc tả kỹ thuật của một hệ thống đủ để trả lời 4 câu hỏi trên.


Avison, D.E. and Wood-Harper, A.T. (1991). Information systems

development research: an exploration of ideas in practice, Computer J.,

34(2).






Avison, D.E. and Wood-Harper, A.T. (1986). Multiview — an

exploration in informal system de-

velopment, Aust. Computer J., 18,.

Avison, D.E. and Fitzgerald, G. (1988). Information Systems

Development Ñ Methodologies,

Techniques and Tools, Blackwell Scientific Publications, Oxford.

Avison, D.E. and Wood-Harper, A.T. (1990). Multiview: an

Exploration in Information Systems

Development, Blackwell Scientific Publications, Oxford.

Davies, L.J. and Wood-Harper, A.T. (1989). Information systems

development: theoretical

frameworks, J. Appl. Syst. Anal., 16.

Hirschheim, R. and Klein, H.R. (1989). Four paradigms for

information systems development,

Commn. ACM, 32.





Iivari, J.A. (1989). Methodology for IS development as an

organizational change: a pragmatic contingency approach, in Klein &

Kumar (1989).




Chương 41: Byrne’s reverse engineering technique 940

CHƢƠNG 40 BYRNE’S REVERSE

ENGINEERING TECHNIQUE

Người dịch: Nguyễn Tiến Vũ

40.1 TỔNG QUAN

The problem of reimplementing an existing system in a different

programming language is a problem around which there are three general

approaches:





• Manually rewrite the existing system.

• Use an automatic language translator.

• Redesign and reimplement the system.

Vấn đề của việc sử dụng lại hệ thống có sẵn trong những ngôn ngữ

lập trình khác nhau thông qua 3 phƣơng pháp cơ bản:

• Tự tay viết lại hệ thống có sẵn.

• Sử dụng công cụ biên dịch ngôn ngữ tự động.

• Thiết kế lại va thực hiện lại hệ thống.

There are problems with each of these approaches. Manually

translated source code often retains the style and flavor of the original

implementation. This approach is labor intensive and error prone.

Automatic translation, a better technique, has problems as well.

Mỗi phƣơng pháp trên có những vấn đề nhƣ:

Nếu biên dịch bằng tay thƣờng gặp phải phong cách va mùi vị của

việc thực hiện gốc. Phƣơng pháp nay tốn chi phi lao động va tăng nguy cơ

lỗi.





Nếu dùng công cụ tự động thì có lỗi tƣơng tự.

The source language may not yield itself to simple translation into

the target language. Most automated translator tools perform the easier

parts of the translation process, leaving the more complex details for a

human.

Perhaps the biggest problem with this technique is, as Byrne (1991)

suggests, its tendency to replicate the same problems plaguing the original

version — in other words, ―garbage in, garbage out‖.

Ngôn ngữ nguồn có lẽ không dễ dang biên dịch thanh ngôn ngữ đich.

Hầu hết các công cụ biên dịch đều thực hiện những phần dễ dang, để lại

những phần phức tạp cho con ngƣời. Có lẽ vấn đề lớn nhất của quá trình

này là (nhƣ Byrne đề nghị), nó có khuynh hƣớng tạo lại cái vấn đề của

phiên bản cũ hay nói cách khác ―có rác vao, thì có rác ra ―

Of the three approaches, redesign and reimplementation has the best

chance of producing a successful system; however, this technique has its

disadvantages too. This approach has the highest cost because it is the

equivalent of building a new system. Perhaps the most serious disadvantage

is that, for many systems, it may not be possible to redesign from system

requirements because the requirements may not exist.





Trong 3 phƣơng pháp đó thì phƣơng pháp thiết kế lại va thực hiện lại

hệ thống la cơ hội tốt nhất để tạo ra 1 hệ thống thanh công, Tuy nhiên kĩ

thuật nay cũng có nhƣợc điểm. Nó tốn chi phi cao nhất bởi vì nó tƣơng

đƣơng với việc xây dựng lại hệ thống. Có lẽ nhƣợc điểm quan trọng nay,

cho nhiều hệ thống, nó không thể thiết kế lại từ những yêu cầu hệ thống vì

những yêu cầu nay có lẽ không còn tồn tại.

Reverse engineering provides a new approach by producing a

reconstructed design that captures the functionality of the system. This

chapter describes a reverse engineering technique that successfully

translated a FORTRAN program into the Ada language.

Thiết kế đối chiếu cung cấp phƣơng pháp mới bằng cách tạo ra thiết

kế cấu trúc lại dựa vao chức năng của hệ thống. Chƣơng nay mô tả kĩ thuật

thiết kế đối chiếu từ việc biên dịch thanh công chƣơng trình fortran thanh

ngôn ngữ ada.

40.2 THỦ TỤC/ VẤN ĐẾ/ CHÍNH SÁCH

1. Collect information. The reverse engineering process begins by

extracting detailed design information and from that extracting a high

level design abstraction. Detailed design information is extracted from

the source code and existing design documents. This information

includes structure charts as well as data descriptions to describe

processing details. In the collect information step, all possible





information about the program is collected. Sources of information

include source code, design documents, and documentation for system

calls and external routines. Personnel experienced with the software

should also be identified. This last requirement is not to be

underestimated; lack of ―domain knowledge‖ can make design

recovery extremely difficult, if not impossible.

Thu thập thông tin. Quá trình thiết kế đối chiếu bắt đầu bởi việc rút

trich chi tiết thiết kế thông tin va từ sự rút trich thiết kế tóm tắt cấp cao.

Thông tin thiết kế chi tiết đƣợc rút trich từ mã nguồn va từ văn bản thiết kế.

Thông tin nay bao gồm mô hình cấu trúc nhƣ quá trình mô tả dữ liệu chi

tiết. Trong bƣớc thu thập thông tin, tất cả thông tin có thể về chƣơng trình

đƣợc chọn lọc. Nguồn thông tin gồm mã nguồn, thiết kế văn bản, va văn

bản của hệ thống va lộ trình bên ngoai. Kinh nghiệm của con ngƣời với

phần mềm nên đƣợc nhận ra. Yêu cầu cuối không đƣợc đánh giá thấp; thiếu

kiến thức về tên miền có thể lam cho việc thiết kế phục hồi trở nên khó, nếu

không phải không thể.

2. Examine information. In this step the information collected in step one

is examined to allow the person doing the recovery work to become

familiar with the system and its parts. Staff responsible for reverse

engineering formulate a plan for dissecting and recording the recovered

information. It should be noted that becoming familiar with the

language implementation of the module can bias the reverse





engineering effort by influencing the perspective of what should be

recovered and how it should be expressed.

Kiểm tra thông tin. Trong bƣớc nay thông tin đƣợc chọn lựa trong

bƣớc 1 đƣợc kiểm tra để cho phép con ngƣời lam công việc phục hồi để

quen với hệ thông va các thanh phần của nó. Nhân viên chịu trách nhiệm

cho kế hoạch công thức thiết kế đối chiếu để phân tich mổ xẻ va ghi lại

thông tin đƣợc phục hồi. Nó nên đƣợc ghi chú sự quen với ngôn ngữ thực

hiện của theo khuynh hƣớng của nổ lực thiết kế đối chiếu bởi sự tác động

lên phối cảnh của cái nên đƣợc phục hồi va nên đƣợc nhấn mạnh.

3. Extract the structure. The information is reviewed in an attempt to

identify the structure of the program. This is used to create a set of

structure charts where each node in the chart corresponds to a routine

called in the program. Therefore, the chart created actually records the

calling hierarchy of the program. For each edge in the chart, the data

passed to a node and returned by that node must be recorded. It should

be noted that software tools are generally available to assist in the

development of structure charts. Associating structure chart nodes with

source code routines raises the issue of traceability. In reverse

engineering, it is desirable to record the links between the recovered

design and the original source code or documentation. In this case, it

would be desirable to give a node a meaningful name and record the

name of the implemented function to which it corresponds. As the





structure chart is recorded, the data items passed between nodes should

also be recorded.

Rút trich cấu trúc. Thông tin đƣợc xem trong sự cố gắng nhận ra cấu

trúc chƣơng trình. Nó đƣợc dùng để tạo ra tập biểu đồ cấu trúc, mỗi đỉnh

trong biểu đồ phù hợp với lộ trình gọi la chƣơng trình. Vì thế ma, biểu đồ

đƣợc tạo ra thật sự ghi lại sự phân cấp của chƣơng trình. Mỗi đỉnh trong

biểu đồ, dữ liệu chuyển qua đỉnh va trở về bởi đỉnh đƣợc ghi lại. Nó nên

đƣợc ghi chú rằng công cụ phần mềm la luôn sẵn sang để giúp cho phát

triển cấu trúc biểu đồ. Các đỉnh trong đồ thị liên quan đến mã nguồn lam

tăng khả năng tìm lại bản gốc.Trong quá trình thiết kế đối chiếu, nó đƣợc

mong đợi để ghi lại sự liên kết giữa thiết kế phục hồi va mã nguồn hay tai

liệu văn bản. Trong trƣờng hợp nay, nó đƣợc mong đợi đem đến đỉnh có

nghĩa va ghi lại tên của chức năng thực hiện thich hợp.

4. Record functionality. For each node, the processing done by that node

is recorded. At this step, the program routines‘ functionality as well as

the functionality of system and library routines is described in English

or using a more formal notation. If debugging statements are used

within the program, then they should be recorded as well.Conditional

compilation code, that is, the procedural code that directs the software

to a particular hardware platform, needs to be reviewed carefully.





Ghi lại chức năng. Cho mỗi đỉnh, quá trình nay thực hiện khi các

đỉnh đƣợc ghi lại. Tại bƣớc nay, chức năng của lộ trình chƣơng trình nhƣ

chức năng của hệ thống va lộ trình thƣ viện đƣợc mô tả bằng tiếng anh hay

sử dụng ghi chú. Nếu trạng thái gơ rối đƣợc dùng suốt chƣơng trình, sau đó

nó nên đƣợc ghi lại. Điều kiện biên dịch mã theo thủ tục điều khiển phần

mềm với nền phần cứng, cần đƣợc xem xét cẩn thận.

5. Record data-flow. The recovered program structure and processing

logic can be analyzed to identify the data transformations in the

software that show the actual data processing done in the program.This

information can be used to develop a set of hierarchical dataflow

diagrams that model the software.

Ghi lại luồn dữ liệu. Phục hồi cấu trúc chƣơng trình va quá trình

logic có thể đƣợc phân tich để nhận ra sự chuyển đổi dữ liệu trong phần

mềm cái đƣa ra quá trình dữ liệu thật đƣợc thực hiện trong chƣơng trình.

Thông tin nay có thể đƣợc dùng để phát triển tập mô hình dữ liệu biểu đồ

phân cấp cho phần mềm.

6. Record control flow. At this stage the high-level control of the program

is identified. This refers to the level of control that affects the overall

operation of the software. A problem in this step might be in

distinguishing between low-level control structures that involve the

implementation of a routine and high-level control structures that serve

to control the software operation. The former should be included as part





of the processing described in the detailed design;the latter needs to be

recorded in a control-flow diagram and its control specification. Byrne

found that there is a temptation to recover too much of the control

structure.

Ghi lại luồng điều khiển. Tại bƣớc nay, điều khiển cấp cao của

chƣơng trình đƣợc nhận ra. Nó tham chiếu đến mức điều khiển cái ma tác

động lên toan bộ hoạt động của hệ thống. Vấn đề của bƣớc nay la sự nhận

ra giữa tầng điểu khiển cấp thấp với cấu trúc liên quan đến sự thực thi lộ

trình với cấu trúc tầng điều khiển cấp trên. Phần đầu gồm phần mô tả quá

trình thiết kế chi tiết. Phần sau cần đƣợc ghi lại trong biểu đồ luồng điều

khiển. Byrne tìm thấy rằng cái khuôn mẫu để phục hồi cấu trúc điểu khiển

quá nhiều.

7. Review the recovered design for consistency. At this stage, missing

items are identified and an attempt is made to locate them. The design

is now checked to see if it accurately represents the program.

Kiên định xem lại thiết kế phục hồi. Tại bƣớc nay, những mục mất đi

đƣợc nhận ra va cố gắng xác định chúng. Thiết kế bây giờ đƣợc kiểm tra để

xem nó có thể hiện chinh xác chƣơng trình hay không.

8. Generate documentation. This last step‘s purpose is to generate design

documentation. Information explaining the purpose of the program,

program overview, history, etc. will be recorded.





Tạo ra văn bản. Mục đich của bƣớc cuối cùng nay tạo ra văn bản

thiết kế. Mục đich của thông tin đƣợc giải thich của chƣơng trình, chƣơng

trình tổng quan, lịch sử,...vv đƣơc ghi lại.




Chương 42: Mô hình tái sử dụng của Perieto-Diaz 949

CHƢƠNG 41 MÔ HINH TAI SỬ DỤNG CỦA

PERIETO-DIAZ

Người dịch: Lê Văn Chân

42.1 TỔNG QUAN

Software reuse is still far from a standard practice in the software

engineering community even though it was first conceived of over 20 years

ago. The problem, according to Prieto-Diaz (1991), is not one of technology

but of unwillingness to address the most important issues influencing

software reuse.





A model for implementing software reuse programs is discussed in

this chapter. This model is based on an incremental strategy and addresses

many issues that were thought to be external to the software process. This

includes managerial, economic, performance, cultural, and technology

transfer issues. The approach addressed here is practical and effective, and

has potential to make reuse a regular practice in the software development

process.

Tái sử dụng phần mềm vân con xa so vơi thƣc tê chuân trong công

đông công nghê phân mêm măc dâu y niêm na y đa đƣơc hinh thanh tƣ 20

năm trƣơc. Vân đê, theo Perieto-Diaz, không phai la vân đê ky thuât ma la

môt vân đê vê viêc tai sƣ dung phân mêm nhƣng ngƣơi ta không muôn nhăc

đến.

Chƣơng nay thao luân môt mô hinh thƣc thi nhƣng chƣơng trinh tai

sƣ dung phân mêm . Mô hinh nay dƣa trên môt chiên lƣơc gia tăng va tâp

trung nhiêu vân đê bên ngoai qua trinh lam phân mêm bao gôm cac vân đê

mang tinh quan ly , kinh tê , thi hanh , xã hội va những v ấn đề chuyển giao

công nghê . Cách tiếp cận ở đây rất thực tế va hiệu quả va nó có tiềm năng

để tai sử dụng một thực tế đều đặn trong quá trình phát triển phần mềm.


1. Factors that influence reuse include:





• Managerial factors — organizational, motivational, and financial

• Economic factors — integrating reuse in cost/benefit analysis, system

costing and estimation, pricing criteria, contracting strategies, and

support costs

• Legal factors — software copyright, liabilities, proprietary issues,

contractual requirements

Các nhân tô anh hƣơng đên tai sƣ dung bao gôm

• Quản trị - Tô chƣc, đông lƣc, tai chinh

• Kinh tê - Kêt hơp viêc tai sƣ dung trong phân tich chi phi / lơi nhuân ,

chi phi hiệu thống va dự toán , giá tiêu chuẩn , ký kết hợp đồng chiến

lƣơc va chi phi hô trơ.

• Pháp lý - Bản quyền phần mềm , trách nhiệm pháp lý , các vấn đề độc

quyên, các yêu cầu hợp đồng.

2. Justifications for an incremental approach:

• Provides an immediate return on investment

• Builds confidence within the organization

• Easier to manage





• Allows for tuning and refining the reuse process

• Facilitates monitoring and evaluating reuse

Luân cƣ cho tiêp cân gia tăng

• Cung câp phan hôi tƣc thơi vê đâu tƣ

• Xây dƣng sƣ tƣ tin bên trong tô chƣc.

• Quản lý dễ dang hơn.

• Cho phep điêu chinh va tinh chinh qua trinh tai sƣ dung.

• Tạo điều kiện cho việc giám sát va đánh giá tái sử dụng.

3. A key ingredient is management support, which is a common factor in

all successful reuse programs (Raytheon, Toshiba, Hartford). This

commitment is necessary because reuse programs demand changes in

the way software is developed.

Môt thanh phân chinh la hô trơ quan ly , nhân tô chung trong tât cac

các chƣơng trình tái sử dụng thanh công (Raytheon, Toshiba, Hartford).

Cam kêt nay la cân thiêt vi nhu câu cua nhƣng chƣơng trinh tai sƣ dung

thay đôi theo cach ma phân mêm đƣơc phat triên.





4. Inputs to the reuse program include software from existing systems and

requirements for future systems.

Đầu vao cho các chƣơng trình tái sử dụng phần mềm cho những hệ

thông hiên co va nhƣng yêu câu cho nhƣng hê thông trong tƣơng lai.

5. The products of a reuse program include a series of software catalogs,

an automated library system, generic architectures, and a collection of

reusable components.

Sản phẩm của một chƣơng trình tái sử dụng gồm có chuỗi bảng danh

mục phần mềm , hê thông thƣ viên tƣ đông , nhƣng kiên truc chung va tâp

các thanh phần tái sử dụng.

6. The assessment report includes: feasibility analysis, domain stability

assessment, cost/benefit analysis, and an implementation pla

Báo cáo đánh giá bao gồm: phân tich kha thi, đanh gia miên ôn đinh,

phân tich chi phi, lơi nhuân va kê hoach thƣc hiên.

7. Questions for a feasibility analysis:

• Does the organization have enough financial and human resources to

implement a reuse program?

• Can the organization afford it?





• Is reuse necessary in the organization?

• Does the organization want to do it?

• Is management committed to implementing a reuse program?

• How many systems of the same kind will be produced?

• Are variations from implementation to implementation large or small?

• Is existing software already available for reuse? What would be the

estimated cost for each alternative?

• Does a critical mass of software engineers exist?

• Is software production large enough to justify a reuse program?

Các câu hỏi về vấn đề phân tich khả thi:

• Liêu tô chƣc co đu nguôn lƣc tai chinh va nguôn lƣc con ngƣơi đê thƣc

hiên chƣơng trinh tai sƣ dung?

• Liêu tô chƣc co đu tiên đê mua no?

• Có phải tái sử dụng la cần thiết trong tổ chức?

• Liêu tổ chức có muốn lam nó?





• Có sự quản lý cam kết để thức hiện một chƣơng trình tái sử dụng hay

không?

• Có bao nhiêu hệ thống cùng loại đƣợc sản xuất?

• Nhƣng sƣ đôi tƣ viêc thƣc hiên đên viêc thƣc hiên la lơn hay nho?

• Nhƣng phân mêm hiên co co săn sang tai sƣ dung đƣơc ko ? Cái gì la

chi phi ƣơc tinh cho môi thay đôi?

• Sô lƣơng quan trong cua ky sƣ phân mêm hiên co?

• Sản phẩm phần mềm có đủ lớn để biện hộ cho phần mềm tái sử dụng?

8. Questions for an analysis of domain suitability:

• Is the domain, line of business, broad or narrow?

• Is the domain mature and well understood or is it new and not well

understood?

• Is the domain complex or simple?

• Is the domain stable or rapidly changing?

• Is the domain very technology dependent?





• Is it in a state of developing concepts or does it rely on well-established

principles, methods, and formalisms?

Các câu hỏi về vấn đề phân tich phù hợp miền.

• Miên, đƣơng kinh doanh thi mơ rông hay thu hep?

• Miên thi hoan thiên va đƣơc hiêu tôt hay la mơi va chƣa năm ro?

• Miên phƣc tap hay đơn gian?

• Miên ôn đinh hay thay đôi nhanh chong?

• Miên co phu thuôc nhiêu vao công nghê?

• Miên trong tinh trang phat triên nhƣng khai niê m hay dƣa vao nhƣng

nguyên tăc, phƣơng phap, hình thức đã tồn tại trong một thời gian dai?

9. Questions for cost/benefit analysis:

• How much does it cost?

• Is a reuse program economically feasible?

• What alternatives exist for implementing a reuse program?

• What is the scope?





• How big a program is contemplated?

• What are the expectations?

• What is the desired level of reuse (partial, opportunistic, formal, total)?

Các câu hỏi cho phân tich chi phi/lơi nhuân

• Bao nhiêu tiên?

• Nó la một chƣơng trình tai sƣ dung kha thi trên phƣơng diên kinh tê?

• Nhƣng lƣa chon thay thê tôn tai trong viêc thƣc hiên môt chƣơng trinh

tái sử dụng?

• Phạm vi la gì?

• Độ lớn chƣơng trình đƣợc dự tinh nhƣ thế nao?

• Sƣ mong đơi la gi?

• Mƣc mong muôn cua tai sƣ dung la gi (môt phân , cơ hôi , hình thức ,

tông thê)?

10. The following organizational structure is recommended to establish a

successful reuse program:





• Asset management group — provides initiatives, funding, and policies

for reuse.

• Identification and qualification group — identifies potential reusability

areas and collects and certifies new additions to the collection.

• Maintenance group — maintains and updates reusable software

components.

• Development group — creates new reusable components.

• Reuser support group — assists and trains users and runs tests and

evaluations of reusable components.

• Librarian — updates and distributes catalogs, classifies new assets,

maintains library system, and manages asset orders. Several roles may

be assigned to one person. However, staff size for a large corporate

endeavor might exceed ten.

Môt câu truc tô chƣc nhƣ sau đƣơc tiên cƣ đê thiêt lâp môt chƣơng

trình tái sử dụng thanh công.

• Nhóm quả lý tài sản – cung câp sang kiên, tai trợ va các chinh sách cho

tái sử dụng.

• Nhóm nhận dạng và chuyên môn – xác định khu vực tái sử dụng tiềm

năng, tông hơp va chƣng thƣc nhƣng phân phu thêm mơi vao tâp.





• Nhóm bảo dương – Bảo dƣơng va cập nhật các tha nh phân phân mêm

tái sử dụng.

• Nhóm phát triển – tạo ra những thanh phần tái sử dụng mới.

• Nhóm hỗ trợ người sử dụng lại – trơ giup va đao tao ngƣơi sƣ dung ,

chạy kiểm tra va đánh giá các thanh phần có thể tái sử dụng.

• Quản thủ thư viện – câp nhât va phân phôi danh sach muc luc , phân

loại tai sản mới, bảo dƣơng hệ thống thƣ viện va quản lý trật tự tai sản .

Môt ngƣơi co thê đong nhiêu vai tro . Tuy nhiên , sô lƣơng nhân viên

cho môt sƣ cô găng cua môt tâp đoan lơn không đƣơc vƣơt qua mƣơi.

11. A reuse program can be implemented in four basic stages:

initiation,expansion, contraction, and steady state.

Môt chƣơng trinh tai sƣ dung co thê đƣơc thƣc hiên vơi 4 giai đoạn

cơ ban: khơi tao, mơ rông, co rut va trang thai ôn đinh.

12. Stage 1: Initiation. Existing software is analyzed to select potentially

reusable components. Descriptors of these components are extracted

manually or automatically and a preliminary index is produced. A stage

1 catalog is produced. This catalog informs software engineers in the

organization about potentially reusable software.





Trạng thái 1: Khơi tao . Phân mêm hiên co đƣơc phân tich đê lƣa

chọn các thanh phần tái sử dụng tiềm năng . Phân mô ta cua nhƣng thanh

phân nay đƣơc trich ra thu công hoăc tƣ đông va sinh ra môt chi muc sơ bô .

Bảng danh mục của trạng thái 1 đƣơc sinh ra . Bảng danh mục nay cho kỹ

sƣ phân mêm biêt phân mêm tai sử dụng tiền năng.

13. Stage 2: Expansion. The size of the catalogs increases as more of the

existing software is identified for reuse. At this point, a classification

scheme is necessary. An initial faceted classification scheme is

produced and included with the stage 2 catalog. Based on the feasibility

study, a case can be made to support an automated library system. The

faceted classification scheme requires the resources of a librarian and a

domain expert. A faceted scheme provides basic domain models in the

form of taxonomies and standard descriptions or lexicons,which in turn

support bootstrapping the domain analysis process

Trạng thái 2:Mơ rông . Kich thƣớc của bảng danh mục tăng khi có

nhiêu hơn cac phân mêm hiên co đƣơc tai sƣ dung. Thơi điêm nay, hê thông

phân loai la cân thiêt . Hê thông phân loai măt ban đâu đƣơc sinh ra năm

trong bang danh muc trang thai 2. Căn cƣ vao viêc nghiên cƣu tinh kha thi ,

môt trƣơng hơp co thê đƣơc tao ra đê hô trơ hê thông thƣ viên tƣ đông . Hê

thông phân loai đơn măt yêu câu tai nguyên quan thu thƣ viên va sƣ thanh

thạo miền . Đê an măt cung câp mô hinh linh vƣc cơ ban dƣơi dang phân

loại va mô tả chuẩn hoặc từ vựng, cái hỗ trợ quá trình phân tich miền.





14. Stage 3: Contraction. In this stage, domain analysis is the key activity.

Early domain models from stage 2 coupled with more detailed

information from existing systems and from requirements for future

systems are used for domain analysis. Standard architectures and

functional models are derived and common components are grouped to

support basic generic functions. Redundant and ineffective components

are identified and retired from the collection. This results in contraction

in the size of the collection. The collection and classification are

updated and a stage 3 catalog is made available. In this stage, a domain

analyst, one or more domain experts, a software engineer, and a

librarian are required.

Trạng thái 3:Co. Trong giai đoa n nay, phân tich miên la công viêc

chinh. Nhƣng mô hinh miên ơ giai đoan 2 đƣơc kêt hơp vơi thong tin chi

tiêt hơn tƣ hê thông hiên co va tƣ nhƣng yêu câu cho hê thông tƣơng lai

đƣơc sƣ dung cho viêc phân tich miên. Nhƣng kiên truc chuân va nhƣng mô

hình chức năng có nguồn gốc va các chức thanh phần phổ biến đƣợc nhóm

để hổ trợ các chức năng chung cơ bản . Nhƣng thanh phân dƣ thƣa va thiêu

hiêu qua đƣơc xac đinh va loai bo tƣ tâp. Điêu nay dân đên sƣ co kich thƣơc

tâp. Tâp va sƣ phân loai đƣơc câp nhât va bang danh muc trang thai 3 đƣơc

sinh ra. Giai đoan nay đoi hoi ngƣơi phân tich miên , môt hay nhiêu chuyên

gia miên, kỹ sƣ phần mềm va quỹ thủ thƣ viên.

15. Stage 4: Steady State. Now that the essential components have been

identified for a specific domain, these components are progressively





replaced by components supporting domain-specific functions. These

components are reusable because they are designed to plug directly into

the architecture.

Trạng thái 4: Ôn định. Giơ đây khi ma cac thanh phân cân thiêt đa

đƣơc xac đinh cho miên cu thê , nhƣng thanh phân nay dân dân đƣơc thay

thê bơi nhƣng thanh phân chƣc năng hô trơ m iên cu thê . Nhƣng chƣc năng

nay có thể tái sử dụng va chúng đƣợc thiết kế để cắm trực tiếp vao kiến

trúc.




Chương 43: Nhận xét của Farbey về các thước đo chất lượng 962

CHƢƠNG 42 NHẬN XÉT CỦA FARBEY VỀ CÁC

THƢỚC ĐO CHẤT LƢỢNG PHẦN MỀM

TRONG GIAI ĐOẠN QUẢN LÝ YÊU CẦU

Người dịch: Đặng Hoang Hải

42.1 TỔNG QUAN

In this chapter Farbey (1990) expands on the general view of quality

as the difference between what is expected and what is experienced:





quality = expectations – experience

Four questions are addressed:

• Effectiveness. Does the specification, considered as a solution, solve

the right problem?

• Serviceability. Does the specification, considered as a starting point,

provide a firm basis on which to proceed?

• Prediction. Does the requirement specification (together with the

system test specification) provide useful measures for predicting the

final quality outcome?

• Process. Does the process by which the specification is produced

encourage effectiveness, serviceability, and quality prediction?

Trong phần nay Farbey mở rộng cách nhìn tổng quan về chất lƣợng

nhƣ la sự khác biệt giữa những gì đƣợc kỳ vọng va những gì thực tế đƣợc

trải nghiệm.

chất lƣợng = kỳ vọng – thực tế

Bốn câu hỏi đƣợc đặt ra:

• Hiệu quả: Các đặc tả, đƣợc coi la giải pháp, có giải đúng vấn đề hay

không?





• Hữu dụng: Các đặc tả, đƣợc coi la điểm khởi đầu, có cung cấp nền tảng

vững chắc để phát triển hay không?

• Dự đoán: Các đặc tả yêu cầu (cùng với những đặc tả kiểm thử hệ

thống) có cung cấp những thƣớc đo hiệu quả để dự đoán chất lƣợng đầu

ra cuối cùng hay không?

• Quy trình: Quy trình đƣợc đề ra bởi các đặc tả có phát huy đƣợc sự

hiệu quả, hữu dụng va dự đoán chất lƣợng hay không?

42.2 THỦ TỤC/VẤN ĐỀ/ CHÍNH SÁCH

Effectiveness. The first question concerns the quality of the

specification as a solution — how well does the specification capture the

problem? The ultimate effectiveness of a system depends not on the quality

of software or specification, but on the degree to which the problem is

correctly perceived. Focus on the specification as a product by asking

questions like the ones that follow:

Câu hỏi đầu tiên liên quan đến chất lƣợng của bản đặc tả với tƣ cách

la một giải pháp – bản đặc tả đã mô tả vấn đề chi tiết đến mức nao? Hiệu

quả cao nhất của một hệ thống không dựa trên chất lƣợng của phần mềm

hay đặc tả, ma dựa trên mức độ thấu hiểu chinh xác vấn đề. Coi bản đặc tả

nhƣ một sản phẩm bằng cách đặt các câu hỏi nhƣ sau:





• Is the process by which it has been produced conducive to bringing out

and clarifying objectives?

• Is it complete in that it exhausts the objectives and needs that are

known?

• Is the specification maintainable?

• Is it readable?

• Quá trình tạo ra bản đặc tả có giúp lam lộ ra va lam rõ các mục tiêu?

• Nó đã vét hết các mục tiêu va các yêu cầu đƣợc biết?

• Bản đặc tả có dễ duy trì không?

• Nó có dễ đọc không?

Quality attributes covered here include:

• Functionality. Does the specification capture all of the required

functions?

• Performance. Does the specification meet the users‘ demands?

• Usability. Does the specification offer ease of use, learning, and

relearning?





Các đặc tinh chất lƣợng kể đến ở đây bao gồm:

• Chức năng. Bản đặc tả đã bao gồm đƣợc hết mọi chức năng yêu cầu?

• Hiệu năng. Bản đặc tả có đáp ứng đƣợc nhu cầu của ngƣời dùng?

• Tiện lợi. Bản đặc tả có giúp việc sử dụng, học va học lại đƣợc dễ dang?

Serviceability. The second question concerns the quality of its

content and implications for later system development. The following is a

list of questions of efficiency, in this context meaning ―doing things right:‖

Câu hỏi thứ hai liên quan đến chất lƣợng nội dung va các gợi ý của

bản đặc tả cho việc phát triển hệ thống sau nay. Dƣới đây la danh sách các

câu hỏi về tinh hiệu quả, trong ngữ cảnh nay có nghĩa la ―lam đúng‖:

• Are the requirements consistent?

• Are the requirements unambiguous?

• Are the requirements compatible with the methods of later

development stages?

• Are the requirements readable?

• Are the requirements modifiable?

• Are the requirements traceable?





• Are the requirements usable after implementation?

• Are the requirements maintainable?

• Are the requirements in compliance with documentation standards?

• Các yêu cầu có nhất quán?

• Các yêu cầu có rõ rang, không mơ hồ?

• Các yêu cầu có phù hợp với các phƣơng pháp sử dụng trong các giai

đoạn phát triển sau nay?

• Các yêu cầu có dễ đọc?

• Các yêu cầu có dễ chỉnh sửa?

• Các yêu cầu có lƣu vết?

• Các yêu cầu có còn sử dụng đƣợc sau khi cai đặt?

• Các yêu cầu có dễ duy trì?

• Các yêu cầu có đƣợc trình bay theo các chuẩn tai liệu hóa?

Prediction. The third question concerns the value of measures of

quality that will act as predictor measurements for the eventual quality of

the finished software. A predictor metric is used to predict the value of a





property of a system that will become directly observable only during a

later stage of system development.

Câu hỏi thứ ba liên quan đến giá trị của các thƣớc đo chất lƣợng ma

sẽ đƣợc sử dụng để dự đoán chất lƣợng cuối cùng của sản phẩm hoan thiện.

Một thƣớc đo dự đoán đƣợc dùng để dự đoán giá trị của một thuộc tinh của

hệ thống, ma giá trị của thuộc tinh nay chỉ có thể thấy rõ ở một giai đoạn

phát triển hệ thống sau nay.

Process. Three processes of development are worth considering:

Ba quy trình phát triển cần đƣợc xem xét:

• A life-cycle process such as SSADM (structured systems analysis and

design) is based on a waterfall model. In this model requirements

specification occurs at an early stage and is then fixed as any associated

metrics would be.

• Một quy trình mang tinh vòng đời nhƣ SSADM (structured systems

analysis and design – phân tich va thiết kế hệ thống có cấu trúc) dựa

trên mô hình thác nƣớc. Trong mô hình nay các đặc tả yêu cầu xuất

hiện ở giai đoạn đầu va sau đó đƣợc sửa đổi khi ma các thƣớc đo liên

quan thay đổi.





• A prototyping approach offers an early normalization, but also offers a

more flexible model of system development that recognizes the

problem of changing requirements.

• Một cách tiếp cận dùng bản mẫu sẽ gợi ý một chuẩn ban đầu, va cũng

gợi ý một mô hình phát triển hệ thống linh hoạt nhận biết đƣợc vấn đề

trong thay đổi yêu cầu.

• Approaches recognize specifically the social setting in which

requirements specifications takes place. Control of quality during any

process will probably be one of instituting checklists together with a

program for completing them and acting on the results. Questions to

ask at this point include:

- Is the system easy to learn?

- Is the system easy to relearn?

- Is there stability and maturity in the system?

• Các cách tiếp cận nhận biết môi trƣờng xã hội ma các đặc tả yêu cầu

đƣợc sinh ra. Kiểm soát chất lƣợng trong bất kì quy trình nao cũng sử

dựng một bảng đánh dấu va một phần mềm để hoan thiện các bảng đó

va lam việc trên các kết quả. Các câu hỏi đặt ra ở đây gồm:

- Hệ thống có dễ học không?





- Hệ thống có dễ học lại không?

- Hệ thống có ổn định va chuyên nghiệp không?


Farbey, B. (1990). Software quality metrics: considerations about

requirements and requirement specifications, Inf. Software Technol., 32,

60–64.




Chương 44: Những xem xét về chất lượng của RedMill 970

CHƢƠNG 43 NHỮNG XEM XÉT VỀ CHẤT

LƢỢNG CỦA REDMILL TRONG VIỆC QUẢN

LÝ QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM

Người dịch: Trần Thanh Hải

43.1 TỔNG QUAN

It comes as no surprise that the majority of software development

projects are late, over budget, and out of specification. Project managers

point to a number of technical problems, most of which are related to





technical tasks specific to software development. This chapter shows that

inadequate management and a lack of attention to quality are the main

causes of the problem (Redmill, 1990).

Hầu hết các dự án phát triển phần mềm đều gặp phải các vấn đề nhƣ

không hoan thanh tiến độ, kinh phi vƣợt quá dự trù ban đầu va không đáp

ứng đƣợc yêu cầu. Đó không phải la một điều đáng ngạc nhiên. Các nhân

viên quản lý dự án chỉ ra rằng một lƣợng lớn các vấn đề kỹ thuật, hầu hết

chúng la những nhiệm vụ kỹ thuật la đặc trƣng của phát triển phần mềm.

Chƣơng nay sẽ chỉ ra rằng việc quản lý không đầy đủ va sự thiếu chú ý tới

chất lƣợng sản phẩm la những nguyên nhân chinh lam nảy sinh các vấn đề.


Most common reasons given by project managers for failure to

meet budget, time scale, and specification are as follows:

• Incomplete and ambiguous requirements

• Incomplete and imprecise specifications

• Difficulties in modeling systems

• Uncertainties in cost and resource estimation

• General lack of visibility





• Difficulties with progress monitoring

• Complicated error and change control

• Lack of agreed-upon metrics

• Difficulties in controlling maintenance

• Lack of common terminology

• Uncertainties in software or hardware apportionment

• Rapid changes in technology

• Determining suitability of languages

• Measuring and predicting reliability

• Problems with interfacing

• Problems with integration

Hầu hết các nguyên nhân (những ngƣời quản lý dự án chỉ ra) gây ra

các vấn đề liên quan tới kinh phi, thời gian va bản ghi chi tiết kỹ thuật đƣợc

nêu dƣới đây:

• Yêu cầu phần mềm không đầy đủ hoặc nhập nhằng.





• Bản ghi chi tiết kỹ thuật không đầy đủ hoặc không chính xác.

• Những khó khăn trong việc mô hình hóa hệ thống.

• Ƣớc lƣợng tai nguyên va chi phi không chinh xác.

• Thiếu tầm nhìn.

• Những khó khăn trong quá trình giám sát.

• Những lỗi phức tạp va kiểm soát thay đổi.

• Thiếu hụt các tiêu chuẩn đo lƣờng.

• Những khó khăn trong việc duy trì bảo dƣơng.

• Thiếu những thuật ngữ dùng chung.

• Sự thiếu chắc chắn của các thiết bị phần cứng va phần mềm.

• Sự thay đổi nhanh chóng của công nghệ.

• Xác định sự thich hợp của ngôn ngữ.

• Đo lƣờng va dự đoán sự tin cậy.

• Những vấn đề liên quan tới giao diện.

• Những vấn đề liên quan tới sự tich hợp.





Audits of systems development efforts reveal shortcomings in

projects:

• Lack of standards

• Failure to comply with existing standards

• Nonadherence to model in use

• No sign-off at end of stages

• Lack of project plans

• No project control statistics recorded or stored

• No quality assurance (QA) procedures

• No change-control procedures

• No configuration control procedures

• No records of test data and results

Sự kiểm soát những nỗ lực phát triển hệ thống tìm ra lỗi trong dự án:

• Thiếu hụt tiêu chuẩn.

• Lỗi trong quá trình tich hợp với các tiêu chuẩn đã có.





• Không tuân theo triệt để mô hình đang dùng.

• Không có hanh báo kết thúc tại lúc cuối của các giai đoạn.

• Thiếu hụt kế hoạch đồ án.

• Những thống kê liên quan tới việc kiểm soát đồ án không đƣợc lƣu trữ.

• Không có những thủ tục đảm bảo chất lƣợng (QA).

• Không có những thủ tục kiểm soát thay đổi.

• Không có các thủ tục kiểm soát cấu hình.

• Không ghi lại dữ liệu kiểm tra va kết quả.

The three causes for the lack of control of projects:

• Attitude to quality

• Attitude to quality

• Attitude to project

Có ba nguyên nhân cho việc thiếu sự kiểm soát của dự án:

• Quan điểm về chất lƣợng.

• Quan điểm về quản lý.





• Quan điểm về dự án.

In finding solutions, the principal reasons for project

management shortcomings should be reviewed, e.g., the project

manager:

• Has no experience working where a quality culture predominates

• Has not been trained in TQM (total quality management)

• Has not received adequate management training

• Has not been managed in accordance with TQM principles by

supervisors

• Has not overcome an inclination toward technical matters and finds that

they offer a more friendly environment than the less familiar affairs of

management

Khi tìm kiếm giải pháp, những nguyên nhân cơ bản gây ra lỗi quản

lý dự án nên đƣợc xem xét lại, vi dụ nhƣ ngƣời quản lý dự án:

• Không có kinh nghiệm lam việc tại những nơi có văn hóa chất lƣợng

trội hơn.

• Không đƣợc huấn luyện về quản lý chất lƣợng tổng thể (TQM).





• Không nhận đƣợc sự huấn luyện quản lý đầy đủ.

• Không đƣợc quản lý theo cách phù hợp với những nguyên tắc cơ bản

của TQM bởi ngƣời giám sát.

• Không vƣợt qua đƣợc những xu hƣớng liên quan tới vấn đề kỹ thuật va

tìm ra rằng họ cung cấp một môi trƣờng thân thiện hơn việc quản lý

công việc it quen thuộc.

Solutions:

• Training: project manager and team must be trained in TQM.

• Management commitment: must always be seen to be 100 percent.

• Standards: a comprehensive set of standards for all aspects of work

should be instituted and used. The project life cycle must be covered as

well as other pertinent issues.

• Guidelines, procedures, and checklists: assist workers to meet the

standards and QA agents to check the products.

• Quality assurance: should be carried out at all stages of the life cycle

and for all end-products.

• QA team: should be independent of the development team.





• Audits: should be carried out during the project to ensure that

management and QA procedures are adhered to. The project manager

should always initiate a review of the auditors‘ recommendations and

of all resulting correction action.

• Planning: the project manager should be fastidious in drawing up plans

and ensuring their use for control. Plans should include the project

plan, stage plans, and a quality plan, which details the quality

requirements of the project.

• Reporting: a reporting system should be instituted to ensure that

problems are quickly escalated to the management level appropriate to

the action needed.

• Feedback: statistics that assist in project control and the improvement

of quality should be collected, analyzed, and used.

• Continuous review: the whole quality system (components, mode of

operation, and quality of results) should be reviewed and improved

continuously.

• Project manager: must not be too technically involved. Technical duties

should be delegated to a development team manager who reports to the

project manager.





• Nontechnical support team: should be appointed to assist in

nondevelopmental matters including coordination and interpretation of

resource and time statistics, recording all expenditures and tracking

against budget, and tracking milestones. This team should report to

project manager.

Giải pháp:

• Việc huấn luyện: ngƣời quản lý dự án va đội thực hiện cần đƣợc quản

lý theo TQM.

• Trách nhiệm quản lý: phải đƣợc đảm bảo 100%.

• Những tiêu chuẩn: một tập hợp đầy đủ các tiêu chuẩn về những khia

cạnh khác nhau của công việc nên đƣợc phát hanh va sử dụng. Vòng

đời dự án cũng nhƣ các vấn đề thich hợp phải đƣợc bao phủ.

• Hƣớng dẫn, thủ tục va danh sách kiểm tra: giúp đơ công nhân trong

việc đáp ứng các tiêu chuẩn va nhân viên kiểm tra chất lƣợng kiểm tra

sản phẩm.

• Sự đảm bảo chất lƣợng: cần đƣợc thực hiện trong toan bộ giai đoạn của

vòng đời va toan bộ sản phẩm cuối.

• Đội đảm bảo chất lƣợng: nên hoạt động độc lập với đội ngũ phát triển.





• Sự kiểm soát: nên đƣợc thực hiện trong suốt dự án để đảm bảo rằng

việc quản lý va các thủ tục đảm bảo chất lƣợng đƣợc tuân thủ triệt để.

Ngƣời quản lý dự án nên thƣờng xuyên đề xuất việc xem xét lại các đề

nghị của thinh giả va tất cả hanh động đúng.

• Việc lập kế hoạch: ngƣời quản lý dự án nên khó tinh trong việc lập kế

hoạch va đảm bảo sử việc sử dụng chúng cho kiểm soát. Các bản kế

hoạch nên bao gồm kế hoạch dự án, kế hoạch các giai đoạn va kế hoạch

chất lƣợng (bao gồm những chi tiết về đòi hỏi chất lƣợng của dự án).

• Việc báo cáo: hệ thống báo cáo nên đƣợc thanh lập để đảm bảo rằng

vấn đề sẽ đƣợc phát hiện tại cấp quản lý thich hợp va có hanh động cần

thiết.

• Phải hồi: những thống kê giúp ich cho kiểm soát dự án va tăng chất

lƣợng nên đƣợc thu thập, phân tich va sử dụng.

• Ngƣời quản lý dự án: không đi quá sâu vao chi tiết kỹ thuật. Nhiệm vụ

liên quan chi tiết tới kỹ thuật nay sẽ đƣợc ủy nhiệm cho ngƣời quản lý

đội phát triển – ngƣời sẽ báo cáo cho ngƣời quản lý dự án.

• Đội ngũ hỗ trợ không dùng từ ngữ chuyên môn: nên đƣợc chọn để hỗ

trợ trong những vấn đề không liên quan tới sự phát triển, bao gồm việc

phối hợp va sự thể hiện tai nguyên va thống kê thời gian, ghi lại tất cả

khoản chi tiêu va theo dõi ngân sách, va theo dõi các bƣớc quan trọng.

Đội ngũ nay nên báo cáo cho ngƣời quản lý dự án.






Redmill, F.J. (1990). Considering quality in the management of

software-based development projects, Inf. Software Technol., 32, 18–22.


Rathbone, M. (1988). Software quality system, Computer Tech.,

February.

Redmill, F.J. (1987). Difficulties of specifying users‘ requirements

for computer systems and methods of mitigating them, Br. Telecommn.

Eng., 6, Part 1, April.

Wingrove, A. (1987). Software failures are management failures, in

Software Reliability: Achievement and Assessment, Littlewood, B., Ed.,

Blackwell, Oxford, U.K.




Chương 45: Độ đo Contel trong khung hoàn thiện quy trình 982

CHƢƠNG 44 ĐỘ ĐO CONTEL TRONG KHUNG

HOÀN THIỆN QUY TRÌNH

Người dịch: Lê Văn Huy

44.1 TỔNG QUAN

The Contel Technology Center‘s software engineering lab has as one

of its prime goals the improvement of software engineering productivity.

As a result of work in this area, Pfleeger and McGowan (1990) have





suggested a set of metrics for which data is to be collected and analyzed.

This set of metrics is based on a process maturity framework developed at

the Software Engineering Institute at Carnegie Mellon University. The SEI

framework divides organizations into five levels based on how mature (i.e.,

organized, professional, aligned to software tenets) the organization is. The

five levels range from initial, or ad hoc, to an optimizing environment.

Contel recommends that metrics be divided into five levels as well. Each

level is based on the amount of information made available to the

development process. As the development process matures and improves,

additional metrics can be collected and analyzed.

Phòng thi nghiệm Công Nghệ Phần Mềm của Trung tâm Công nghệ

Contel xem việc nâng cao năng suất công nghệ phần mềm la một trong

những mục tiêu hang đầu. Nhƣ la một kết quả của những nỗ lực trong lĩnh

vực nay, Pfleeger va McGowan (1990) đã đề nghị một tập hợp các độ đo

ma dữ liệu đƣợc thu thập va phân tich. Tập hợp các độ đo nay dựa trên một

khung hoan thiện quy trình (Process Maturity Framework) phát triển ở Viện

Công Nghệ Phần Mềm (SEI) tại Đại học Carnegie Mellon. Khung SEI chia

công ty thanh năm cấp độ dựa trên sự hoan thiện của công ty (nhƣ cách tổ

chức, tinh chuyên nghiệp, sự sắp xếp cho đến những nguyên tắc sản xuất

phần mềm). Năm cấp độ từ sơ khởi, hoặc không quy chuẩn, cho đến một

môi trƣờng đƣợc tối ƣu hóa. Contel khuyến cáo rằng các độ đo cũng nên

đƣợc chia thanh năm cấp độ. Mỗi cấp độ dựa trên số lƣợng thông tin đã có





sẵn cho quy trình phát triển. Khi quy trình phát triển đƣợc cải thiện va trở

nên hoan thiện, các số liệu bổ sung có thể đƣợc thu thập và phân tích.


1. Level 1 – Cấp độ 1:

Initial Process. This level is characterized by an ad hoc approach to

software development. Inputs to the process are not well defined but the

outputs are as expected. Preliminary baseline project metrics should be

gathered at this level to form a basis for comparison as improvements are

made and maturity increases. This can be accomplished by comparing new

project measurements with the baseline ones.

Quy trình sơ khởi. Cấp nay đƣợc đặc trƣng bởi một cách tiếp cận

không quy chuẩn trong phát triển phần mềm. Đầu vao cho quá trình nay

không đƣợc xác định rõ nhƣng kết quả đầu ra phải nhƣ dự kiến. Đƣờng cơ

sở cho độ đo của dự án cần đƣợc tập hợp ở cấp độ nay để tạo ra cơ sở so

sánh khi những cải tiến đƣợc thực hiện va tinh hoan thiện tăng lên. Điều

nay có thể đƣợc thực hiện bằng cách so sánh các phép đo dự án mới với

những đƣờng cơ sở.


Repeatable Process. At this level the process is repeatable in much

the same way that a subroutine is repeatable. The requirements act as input





and the code as output; constraints are such things as budget and schedule.

Even though proper inputs produceproper outputs, there is no means to

discern easily how the outputs are actually produced. Only project-related

metrics make sense at this level because the activities within the transitions

from input to output are not available to be measured. Measures at this level

can include:

Quy trình lặp lại được. Ở cấp độ nay quy trình đƣợc lặp lại tƣơng tự

nhƣ cách ma một chƣơng trình con đƣợc lặp lại. Những yêu cầu đóng vai

trò nhƣ đầu vao va mã nguồn nhƣ la đầu ra; với rang buộc la những thứ nhƣ

ngân sách va lịch trình. Mặc dù đầu vao đúng sẽ cho đầu ra phù hợp, vẫn

không có cách dễ dang để phân biệt đầu ra thực tế đƣợc tạo ra nhƣ thế nao.

Chỉ những độ đo liên quan đến dự án la có ý nghĩa ở cấp độ nay vì các hoạt

động trong quá trình chuyển đổi từ đầu vao đến đầu ra không thể đo đƣợc.

Các độ đo tại cấp nay có thể bao gồm:

• Amount of effort needed to develop the system

• Lƣợng nỗ lực cần thiết để phát triển hệ thống

• Overall project cost

• Tổng chi phi dự án

• Software size: noncommented lines of code, function points, object and

method count





• Kich thƣớc phần mềm: đếm số lƣợng những dòng mã không có ghi chú

(comment), các hàm, đối tƣợng va phƣơng thức

• Personnel effort: actual person-months of effort, reported person-

months of effort

• Nỗ lực nhân sự: nỗ lực thực sự tinh theo ngƣời-tháng, nỗ lực đƣợc báo

cáo tinh theo ngƣời-tháng

• Requirements volatility: requirements changes

• Tính kém linh hoạt của yêu cầu: những thay đổi của yêu cầu


Defined Process. At this level the activities of the process are clearly

defined. This additional structured means that the input to and output from

each well-defined functional activity can be examined, which permits a

measurement of the intermediate products. Measures include:

Quy trình xác định sẵn. Ở cấp độ nay các hoạt động trong quy trình

phải đƣợc xác định rõ rang. Điều thêm vao nay có nghĩa la mọi đầu vào và

đầu ra từ mỗi chức năng hoạt động xác định đều có thể đƣợc kiểm tra, tức

cho phép đo lƣờng các sản phẩm trung gian. Các biện pháp bao gồm:

• Requirements complexity: number of distinct objects and actions

addressed in requirements.





• Độ phức tạp yêu cầu: số lƣợng phân biệt các đối tƣợng va hanh động

đƣợc xác định trong yêu cầu.

• Design complexity: number of design modules, Cyclomatic complexity,

McCabe design complexity.

• Độ phức tạp thiết kế: số lƣợng các mô-đun thiết kế, độ phức tạp vòng,

độ phức tạp McCabe.

• Code complexity: number of code modules, Cyclomatic complexity

• Độ phức tạp mã nguồn: số lƣợng các mô-đun mã, độ phức tạp vòng.

• Test complexity: Number of paths to test, of object-oriented

development, then number of object interfaces to test.

• Độ phức tạp kiểm thử: số lƣợng các đƣờng kiểm thử, các đối tƣợng

theo hƣớng đối tƣợng, va các giao diện đối tƣợng cần đƣợc kiểm thử.

• Quality metrics: defects discovered, defects discovered per unit size

(defect density), requirements faults discovered, design faults

discovered, fault density for each product.

• Độ đo chất lượng: các khuyết tật đƣợc phát hiện, khuyết tật đƣợc phát

hiện trên một kich thƣớc đơn vị (mật độ khuyết tật), lỗi yêu cầu đƣợc

phát hiện, lỗi thiết kế đƣợc phát hiện, mật độ lỗi cho mỗi sản phẩm.





• Pages of documentation

• Số trang tai liệu


Managed Process. At this level, feedback from early project

activities is used to set priorities for later project activities. Activities are

readily compared and contrasted, and the effects of changes in one activity

can be tracked in the others. At this level measurements can be made across

activities and are used to control and stabilize the process so that

productivity and quality can match expectation. The following types of data

are recommended to be collected. Metrics at this stage, although derived

from the following data, are tailored to the individual organization.

Quy trình được quản lý. Ở cấp độ nay, phản hồi từ các hoạt động

sớm của dự án đƣợc sử dụng để thiết lập mức ƣu tiên cho các hoạt động sau

nay của dự án. Các hoạt động đƣợc dễ dang so sánh, va những ảnh hƣởng

từ các thay đổi trong một hoạt động có thể đƣợc theo dõi từ các hoạt động

khác. Ở cấp độ nay, độ đo lƣờng có thể đƣợc thực hiện xuyên suốt qua các

hoạt động va đƣợc sử dụng để kiểm soát va ổn định quy trình sao cho năng

suất va chất lƣợng đạt đƣợc nhƣ kỳ vọng. Các loại dữ liệu sau đây đƣợc đề

nghị thu thập. Độ đo ở giai đoạn nay đƣợc thiết kế riêng cho tổ chức, cá

nhân.





• Process type. What process model is used and how is it correlated to

positive or negative consequences

• Loại quy trình. Mô hình quy trình đƣợc sử dụng la gì va hệ quả la nó

ảnh hƣởng tich cực hay tiêu cực nhƣ thế nao?

• Amount of producer reuse. How much of the system is designed for

reuse? This includes reuse of requirements, design modules, test plans,

and code.

• Mức độ tái sử dụng từ nhà sản xuất. Hệ thống đƣợc thiết kế để tái sử

dụng bao nhiêu? Bao gồm tái sử dụng yêu cầu, mô-đun thiết kế, các

bản kiểm tra, va mã nguồn.

• Amount of consumer reuse. How much does the project reuse

components from other projects? This includes reuse of requirements,

design modules, test plans, and code. (By reusing tested, proven

components, effort can be minimized and quality can be improved.)

• Mức độ tái sử dụng từ người dùng. Dự án sử dụng các thanh phần từ

các dự án khác đƣợc bao nhiêu? Bao gồm cả việc tái sử dụng yêu cầu,

các mô-đun thiết kế, các bản kiểm thử, va mã nguồn. (Bằng cách sử

dụng các thanh phần đã đƣợc kiểm nghiệm va thử nghiệm, công sức bỏ

ra có thể đƣợc giảm thiểu trong khi chất lƣợng đƣợc nâng cao)





• Defect identification. How and when are defects discovered? Knowing

this will indicate whether those process activities are effective.

• Nhận dạng khuyết tật. Lam thế nao va khi nao khuyết tật đƣợc phát

hiện? Hiểu đƣợc điều nay sẽ cho biết liệu quy trình đang hoạt động có

hiệu quả hay không.

• Use of defect density model for testing. To what extent does the number

of defects determine when testing is complete? This controls and

focuses testing as well as increases the quality of the final product.

• Sử dụng mô hình mật độ khuyết tật trong kiểm thử. Số lƣợng các

khuyết tật đƣợc xác định trên phạm vi nao khi quá trình kiểm thử hoan

tất? Việc nay kiểm soát va tập trung vao việc thử nghiệm cũng nhƣ lam

tăng chất lƣợng của sản phẩm cuối.

• Use of configuration management. Is a configuration management

scheme imposed on the development process? This permits traceability,

which can be used to assess the impact of alterations.

• Sử dụng quản lý cấu hình. Bản quản lý cấu hình có đƣợc sử dụng trong

quy trình phát triển hay không? Điều nay cung cấp khả năng truy vết,

đƣợc sử dụng để đánh giá sự ảnh hƣởng của các thay đổi.





• Module completion over time. At what rates are modules completed?

This reflects the degree to which the process and development

environment facilitate implementation and testing.

• Sự hoàn thiện mô-đun theo thời gian. Các mô-đun đƣợc hoan thanh ở

tốc độ nao? Điều nay phản ánh mức độ ma quy trình va môi trƣờng

phát triển lam cho việc cai đặt va kiểm thử trở nên thuận lợi nhƣ thế

nào.


Optimizing Process. At this level measures from activities are used

to change and improve the process; this change can affect the organization

and the project as well. Studies by SEI report that 85 percent of

organizations are at level 1, 14 percent at level 2, and 1 percent at level 3.

None of the firms surveyed had reached levels 4 or 5; therefore, the authors

have not recommended a set of metrics for level 5.

Quy trình tối ưu. Ở cấp độ nay, các đo lƣờng từ những hoạt động

đƣợc sử dụng để thay đổi va cải thiện quy trình; thay đổi nay có thể tác

động đến công ty cũng nhƣ dự án. Nghiên cứu của SEI báo cáo rằng 85%

các tổ chức đƣợc ở cấp độ 1, 14% ở cấp độ 2, va 1% ở cấp độ 3. Không một

công ty đƣợc khảo sát đạt đến cấp độ 4 hoặc 5, do vậy, các tác giả đã không

đề nghị một tập hợp các độ đo cho cấp độ 5.

6. Steps to take in using metrics - Các bƣớc đƣa vao sử dụng độ đo:





• Assess the process: determine the level of process maturity

• Đánh giá quy trình: xác định mức độ hoan thiện của quy trình

• Determine the appropriate metrics to collect

• Xác định độ đo thich hợp để thu thập số liệu

• Recommend metrics, tools, and techniques

• Đề nghị các độ đo, công cụ, va kỹ thuật

• Estimate project cost and schedule

• Ƣớc lƣợng chi phi va lịch trình dự án

• Collect appropriate level of metrics

• Thu thập số liệu tại cấp độ thich hợp

• Construct project database of metrics data that can be used for analysis

and to track value of metrics over time

• Xây dựng CSDL dự án cho các số liệu đo đạc, để có thể sử dụng trong

phân tich va theo dõi giá trị của các số liệu nay theo thời gian

• Cost and schedule evaluation: when the project is complete, evaluate

the initial estimates of cost and schedule for accuracy and determine





which of the factors may account for discrepancies between predicted

and actual values

• Đánh giá chi phi va tiến độ: khi dự án hoan thanh, đánh giá ƣớc lƣợng

ban đầu của chi phi va tiến độ cho sự chinh xác va xác định những yếu

tố có thể giải thich cho sự sai biệt giữa dự báo va giá trị thực tế

• Form a basis for future estimates.

• Lập một cơ sở cho các ƣớc lƣợng trong tƣơng lai


Pfleeger, S.L. and McGowan, C. (1990). Software metrics in the

process maturity framework, J. Syst. Software, 12, 255–261.


Boehm, B.W. (1988). A spiral model of software development and

enhancement, IEEE Computer, May.

Conte, S.D., Dunsmore, H.E., and Shen, V.Y. (1986). Software

Engineering Metrics and Models, Benjamin-Cummings Publishing Co.,

Menlo Park, CA.





Humphrey, W. (1989). Managing the Software Process, Addison-

Wesley, Reading, MA.

Pfleeger, S.L. (1989). Recommendations for an initial set of metrics,

Contel Technology Center Technical Report CTC-TR-89–017, Chantilly,

VA.




Chương 46: Kydd’s technique to induce productivity 994

CHƢƠNG 45 KYDD’S TECHNIQUE TO INDUCE

PRODUCTIVITY THROUGHT SHARED

INFORMATION TECHNOLOGY

Người dịch: Nguyễn Bá Huy

45.1 TỔNG QUAN

Organizations have made large investments in shared information

technology(SIT) over the years under the guise of electronic mail systems,

distributed databases, and group decision support systems. Kydd and





Jones(1989) contend that SIT may not be appropriate for every organization

—that, in order for SIT to be successful, the corporate culture must be one

that supports sharing of information across boundaries. In this chapter, the

authors give general guidelines that can be used concerning conditions

under which high-return SIT can be implemented.

Các tổ chức tạo ra một sự đầu tƣ lớn trong việc chia sẻ công nghệ

thông tin(SIT) trên nhiều năm dƣới cái vỏ hệ thống thƣ từ điện tử, cơ sở dữ

liệu phân tán, và nhóm hệ thống cung cấp quyết định, Kydd and

Jones(1989) đấu tranh rằng có thể không thich hợp với nhiều tổ chức, để

SIT thành công. Những nền văn hóa kết hợp phải phải la một để cung cấp

chia sẻ thông tin dọc ranh giới. Trong chƣơng nay, tác giả hƣớng dẫn tổng

quan để có thể sử dụng điều kiên liên quan dƣới cái ma SIT trở lại cao hơn

để có thể thực hiện


1. There are two organizational prerequisites for successful investment in

SIT:

• The organizational culture must be ―right‖, that is, appropriate for and

supportive of the sharing of information.

• Successful execution of a significant number of jobs must require

timely access to shared information.





Có 2 tổ chức tiên quyết cho sự đầu tƣ thanh công trong SIT:

• Các văn hóa tổ chức cần phải ―đúng‖, thich hợp va khuyến khich việc

chia sẻ thông tin.

• Thực thi thanh công với một số lƣợng công việc đầy ý nghĩa đƣợc đòi

hỏi phải kịp thời tiếp cận thông tin đƣợc chia sẻ.

2. In ―excellent‖ companies, a great deal of communication takes place

among people in different functional areas. There may also be cross

functional management of cost, quality, and scheduling. This implies

that communication occurs across traditional organizational

boundaries and that information is shared.

Trong một công ty ―tốt‖, một số lƣợng lớn các giao tiếp diễn ra giữa

những ngƣời có những chức năng khác nhau. Có thể có quản lý chức năng

chéo của giá cả, chất lƣợng, lập lịch. Điều nay ngụ ý rằng Giao tiếp xảy ra

giữa ranh giới tổ chức truyền thống chéo va những thông tin đó đƣợc chia

sẻ.

3. In traditional American businesses, the organization is through a

hierarchical structure in which corporate norms have dictated that

communications paths follow the hierarchy — allowing certain

managers to monopolize information. SIT, in contrast, allows workers

to work in a cooperative manner across traditional organizational

boundaries.





Trong truyền thống kinh doanh của ngƣời Mỹ, tổ chức nay thông qua

một cấu trúc thứ bậc, trong đó tập hợp những qui tắc tiêu chuẩn đƣợc chỉ rõ

có con đƣờng giao tiếp phân cấp, cho phép một quản lý nao đó giữ độc

quyền thông tin, SIT, ngƣợc lại, cho phép ngƣời lao động lam việc trong

một cách tuyền thống, hợp tác chéo trên một ranh giới tổ chức truyền thống.

4. Rich communications media foster productivity:

• Group meetings

• One-on-one meetings

• Telephone contact

Phƣơng tiện truyền thông giau năng suất:

• Họp nhóm.

• Cuộc họp một đối một.

• Liên lạc điện thoại.

5. Guidelines for implementing high-return SIT:

• Assess the environment within the organization to determine whether

shared information will further the strategic objectives of the





organization. In addition, determine whether or not the culture of the

organization fosters information sharing.

• Đánh giá môi trƣờng trong tổ chức để xác định việc chia sẻ thông tin la

mục tiêu chiến lƣợc của tổ chức. Ngoài ra, xác định có hay không các

nền văn hóa của các tổ chức thúc đẩy chia sẻ thông tin

• If SIT is not strategically important, defer SIT until it is.

• Nếu SIT không phải la chiến lƣợc quan trọng thì hoãn nó cho tới khi nó

đƣợc lam.

• If it is strategically important but the culture does not encourage

information sharing, then plan and implement an improvement program

that focuses on a single, measurable objective of strategic

importance(such as a quality improvement program) and requires

involvement by everyone in the organization. The objecttive is to

develop a culture in which everyone is concerned with continuous

improvement, measurable results, and shared information. Ensure that

management behavior is consistent with theobjectives of the program

and that the organization‘s reward system encourages information

sharing.





• Nếu đó la chiến lƣợc quan trọng nhƣng văn hóa không khuyến khich

việc chia sẻ thông tin, lên kế hoạch va thực hiện một chƣơng trình cải

tiến, chú tâm vao một mục tiêu duy nhất, đối tƣợng có thể đo lƣờng của

của tầm quan trọng chiến lƣợc(nhƣ la một chƣơng trình cải tiến chất

lƣợng) va đòi hỏi sự tham gia của tất cả mọi ngƣời trong tổ chức. Mục

tiêu la để phát triển một nền văn hóa, trong đó tất cả mọi ngƣời đều có

liên quan tới việc liên tục cải tiến, kết quả có thể đo lƣờng đƣợc, và

thông tin đƣợc chia sẻ. Đảm bảo các hanh vi quản lý la phù hợp với

mục tiêu của chƣơng trình va hệ thống khen thƣởng của tổ chức khuyến

khich chia sẻ thông tin.

• If the improvement program is successful, develop a plan for

implementing SIT. This plan should include plans for developing an

information infrastructure with standardized definitions of key data

elements, an information technology infrastructure that provides access

to corporate and external data bases, and a uniform set of user-friendly

tools. This set should include tools that establish communication

protocols between individuals and reinforce the new collaborative

norms.

• Nếu chƣơng trình cải tiến thanh công, phát triển kế hoạch triển khai

SIT. Kế hoạch nay bao gồm các kế hoạch phát triển một cơ sở hạ tầng

thông tin với các định nghĩa tiêu chuẩn của yếu tố dữ liệu khóa. Một cơ

sở hạ tầng công nghệ thông tin cung cấp quyền truy cập vao cơ sơ dữ

liệu của công ty va bên ngoai, va thống nhất một bộ các công cụ ngƣời





sử dụng thân thiện, điều nay thiết lập nên bao gồm các công cụ ma giao

thức truyền thông đƣợc thiết lập giữa các cá nhân va củng cố các chỉ

tiêu hợp tác mới.


Κydd, C. Σ. and Jonh, L. Η.(1989). Corporate productivity and

shared information technology, Ιnf. Μanage., 17, 277281.


Draft, R. L. and Lengel, R. H.(1986). Organizational information

requriements, media richness and structural design, Manage. Sci., 5, 554–

571.




Chương 47: Thước đo chất lượng phần mềm Bellcore 1001

CHƢƠNG 46 THƢỚC ĐO CHẤT LƢỢNG PHẦN

MỀM BELLCORE

Người dịch: Lê Anh Khoa

46.1 TỔNG QUAN

The Bellcore quality assurance engineering software (QAES)

group for Bellcore client companies (BCCs) has developed and

implemented a comprehensive quality assurance program that focuses on

resolving the underlying problems associated with developing quality





software (Hon, 1990). The objective of QAES‘ surveillance program is to

develop ―cooperative‖ relationships that cause vendors to focus on (1)

implementing methods and techniques to improve control of software

development, (2) improving the effectiveness of the underlying process

used to develop and support software, thus improving the quality, and (3)

understanding the needs and requirements of the BCCs. This chapter

discusses this approach and explores measurements utilized whose

objectives are to assure adequate vendor quality control, minimize defects,

and optimize buyer satisfaction.

Nhóm bảo hiểm chất lƣợng phần mềm (QAES) Bellcore cho những

công ty khách hang (BCCs) đã phát triển va đƣa ra một chƣơng trình đánh

giá va bảo hiểm chất lƣợng cho phần mềm, tập trung vao việc giải quyết

những bai toán bên dƣới có liên quan đến chất lƣợng phần mềm (Hon,

1990). Mục tiêu của chƣơng trình nay của QAES la để phát triển một mối

quan hệ ―hợp tác‖ giúp cho các công ty tập trung vao (1) đƣa ra những

phƣơng pháp, kĩ thuật để phát triển khả năng kiểm soát quá trình phát triển

phần mềm, (2) tăng cƣờng tinh hiệu quả của những quá trình bên dƣới đƣợc

dùng để phát triển va hỗ trợ phần mềm, từ đó tăng chất lƣợng phần mềm, va

(3) hiểu đƣợc yêu cầu va đòi hỏi của BCCs. Chƣơng nay tập trung thảo luận

về hƣớng tiếp cận nay va cho ra những thƣớc đo với mục tiêu la bảo đảm

khả năng kiểm soát, giảm thiểu tác hại, va tối ƣu hóa sự hai lòng của khách

hàng.






1. Assure adequate vendor quality control. Measures have been

implemented in the surveillance program to track the accomplishment

of milestone criteria. These include:

Requirements, design, coding, and unit test-phase measurements:

- Phase deliverable completion

- Number of open correction actions requests

- Review coverage

• Test-phase measurements:

- Test coverage as measured by structure, functions, or paths

- Number of test cases executed and passed

- Number of trouble reports

- Number of open trouble reports by severity

- Trouble report initiation rates

- Product-specific quality, reliability, and stability





Bảo đảm khả năng kiểm soát của các công ty phần mềm. Những độ

đo đƣợc đƣa ra để kiểm tra mức độ hoan tất những bƣớc quan trọng trong

quá trình phát triển. Trong đó bao gồm:

• Yêu cầu, thiết kế, lập trình va các yêu cầu của quá trình kiểm tra cục

bộ:

- Mức độ hoan tất các quá trình.

- Số lƣợng các thao tác đƣợc thực hiện đúng.

- Báo cáo sơ lƣợc.

• Độ đo bƣớc kiểm tra:

- Báo cáo kiểm tra tinh bởi cấu trúc, ham hoặc phần.

- Số trƣờng hợp kiểm tra đƣợc thực hiện va số kết quả đúng.

- Số lƣợng báo cáo lỗi.

- Số lƣợng báo cáo do lỗi nghiêm trọng.

- Tỉ lệ báo cáo.

- Tinh ổn định, tin cậy va chất lƣợng sản phẩm.





2. Minimize defects and improve the effectiveness of the software

development process:

• Review of software development artifacts (e.g.,

requirements,specifications, and code) and testing results provide

measurable evidence about the effectiveness of the implemented

software development process, that is, specific information about the

type and quantity of defects produced.

• Specific measurements used in ―real time‖ to minimize defects include:

- Average number of defects detected in modules and subsystems by

type

- Historical system, subsystem, and module fault densities

- Number of defects detected during reviews

Giảm thiểu tác hại va tăng tinh hiệu quả của quá trình phát triển phần

mềm:

• Tóm tắt các bản thảo về phát triển phần mềm (vi dụ, yêu cầu, những

đặc điểm va mã) va kết quả kiểm tra về tinh hiệu quả của quá trình phát





triển phần mềm đã đề ra, đó la, những thông tin về kiểu va số lƣợng tác

hại gây ra.

• Độ đo đặc biệt dùng trong thực tiễn để giảm thiểu tác hại bao gồm:

- Số lỗi trung bình tinh theo loại trong từng phần, từng hệ thống con

của phần mềm.

- Những lỗi đã xảy ra trong quá khứ.

- Số tác hại tìm ra trong quá trình duyệt lại.

3. A long-term approach is to collect comprehensive defect data.

Information about defect type, its origin, the mechanism used for

detection, and defect severity are required to isolate ineffective

processes and detection mechanisms. Defects found during reviews and

testing are classified according to the phase detected (x axis) and

originated (y axis). After defect data is accumulated, simple

calculations will determine the percentage of total defects attributable

to certain phases of the life cycle and the effectiveness of phase defect

detection efforts. For example, the percentage of total defects

attributable to ―requirements‖ is calculated as the total number of

requirements defects divided by the total number of defects multiplied

by 100.





Một cách tiếp cận dai hơi la thu thập những thông tin về các tác hại.

Thông tin về loại tác hại, nguồn gốc, máy móc đƣợc sử dụng trong quá

trình tìm kiếm lỗi, va các tác hại nghiêm trọng đòi hỏi phải cô lập hóa

những phần không hiệu quả va những phƣơng tiện tìm lỗi. Tác hại tìm ra

trong quá trình duyệt lại va kiểm tra sẽ đƣợc phân loại dựa trên khâu tìm ra

lỗi (trục x) va loại lỗi (trục y). Sau khi thông tin về tác hại đã đƣợc thu thập,

một phép tinh đơn giản sẽ xác định phần trăm tác hại trên từng khâu va tinh

hiệu quả của khâu tìm lỗi. Vi dụ, tỉ lệ lỗi với nhƣng yêu cầu khách hang

đƣợc tinh la số lỗi trên yêu cầu khách hang chia cho tổng số lỗi, va nhân

cho 100.

4. Quality and reliability measures include:

• Number and duration of system outages due to software failure

• Number of customer trouble reports

• Customer trouble report cause analysis

• Patch statistics where a patch is defined as an interim fix

Thƣớc đo chất lƣợng va tinh tin cậy bao gồm:

• Số lƣợng va thời gian hệ thống ngừng hoạt động khi phần mềm có lỗi.

• Số báo cáo lỗi từ khách hàng.





• Khâu phân tich nguyên nhân gây ra lỗi cho khách hang.

• Thống kê các phiên bản cập nhật tạm thời.

5. Buyer support measures include:

• Customer service response time

• Number of open trouble reports

• Site distribution of open fault reports

• Aging of open customer trouble reports by severity

• Time-to-correct customer trouble reports

Thƣớc đo khả năng hỗ trợ khách hang bao gồm:

• Thời gian trả lời khách hang.

• Số báo cáo lỗi mở.

• Những trang cung cấp các báo cáo lỗi mở.

• Thời gian kiểm tra lỗi nghiêm trọng của khách hang.

• Thời gian sửa lỗi cho những báo cáo lỗi từ ngƣời dùng.





46.3 TẢI LIỆU THAM KHẢO

Hon, S.E. (1990). Assuring software quality through measurements:

a buyer‘s perspective, J. Syst. Software, 13, 117–130.


Grady, R.B. (1987). Measuring and managing software

maintenance, IEEE Software, September, 35–45.

Jones, T.C. (1986). Programmer Productivity, McGraw-Hill, New

York.




Chương 48: Giá trị thông tin của Keyes 1009

CHƢƠNG 47 GIÁ TRỊ THÔNG TIN CỦA KEYES

Người dịch: Nguyễn Tƣờng Minh

47.1 TỔNG QUAN

If it will be difficult to make the point that the corporate information

resource is a worthy vehicle to protect with a dictionary workbench, then

calculating the value of information (VOI) will be a useful exercise (Keyes,

1992). It will assist the organization in determining the true worth of its

investment in information. The ultimate goal of this exercise is to assign a





monetary value to each unitary piece of information. In this way an

organization accustomed to assessing relative worth based on bottom-line

statistics can instantly recognize the value of information in terms that it

understands.

Sẽ rất khó để thấy rằng những nguồn thông tin tổng hợp la một

phƣơng tiện hữu ich đáng đƣợc bảo vệ. Vì vậy việc tinh toán giá trị của

thông tin (VOI) sẽ la một bai tập hữu dụng (Keyes, 1992). Nó sẽ hỗ trợ

công ty trong việc quyết định giá trị chinh xác việc đầu tƣ vao thông tin.

Những mục đich của bai tập nay la gán giá trị tiền tệ cho những mảnh thông

tin nhỏ. Bằng cách nay một công ty đã quen với việc định giá những giá trị

liên quan dựa trên những thống kê bottom-line có thể nhận ra ngay giá trị

của thông tin trong lĩnh vực tƣơng ứng.


The following steps should be taken for this assessment:

• Assign each system (i.e., payroll) a weighting relative to its importance

to the organization. Permissible weights for the entirety of this exercise

are one for a low relative value, two for a middle relative value, and

three for a high relative value.





• For each data element within a system, assign a weighting that shows

that data element‘s importance relative to that system. Again, use

weightings one through three.

• Multiply these two numbers to get the total weighting of a data element

relative to all data in the organization.

• Each data element should have an annotation next to it indicating the

number of systems in which this data element is cross referenced. For

example, it is possible that ―customer name‖ is used in the sales,

inventory, and marketing systems. This would give a total of three

systems. The product calculated in instruction three is now multiplied

by the number determined in this instruction.

• Convert this number to a percentage.

• Using the last audited net income amount for the organization (for a

quarter or for an entire year), calculate the VOI by multiplying the

percentage calculated in instruction five by the net income amount.

Những bƣớc sau cần đƣợc thực hiện cho việc định giá:

1. Gán cho mỗi hệ thống (vi dụ: tiền lƣơng) một trọng số liên quan đến sự

quan trọng của nó đối với công ty. Trọng số chấp nhận đƣợc cho toan

bộ bai tập nay 1 cho giá trị liên quan thấp, 2 cho giá trị liên quan trung

bình va 3 cho giá trị liên quan cao.





2. Với mỗi dữ liệu nguyên tố trong hệ thống, gán trọng số cho thấy sự

quan trọng của dữ liệu nguyên tố đó đối với hệ thống. Một lần nữa, sữ

dụng trọng số từ 1 đến 3.

3. Nhân hai giá trị nay với nhau để lấy đƣợc trọng số của dữ liệu nguyên

tố đối với toan bộ dữ liệu trong công ty.

4. Mỗi dữ liệu nguyên tố nên có phần chú giải kế bên để chỉ ra số lƣợng

hệ thống ma dữ liệu nay có liên quan. Vi dụ: ―Tên Khách Hang‖ đƣợc

dùng trong buôn bán, kiểm kê va trong hệ thống marketing. Ta có tổng

cộng 3 hệ thống. Sản phẩm đƣợc tinh toán theo hƣớng dẫn 3 bây giờ

đƣợc nhân với con số đƣợc xác định trong hƣớng dẫn nay.

5. Chuyển con số nay sang phần trăm

6. Sử dụng số lƣợng mạng thu nhập đƣợc kiểm tra lần mới nhất cho công

ty (cho mỗi quý hoặc cả năm), tinh toán VOI bằng cách nhân phần trăm

đã tinh đƣợc trong hƣớng dẫn 5 với số lƣợng mạng thu nhập.


Keyes, J. (1992). INFOTRENDS: the Competitive Use of

Information, McGraw-Hill, New York.




Chương 49: Phương pháp của Pfleeger để lựa chọn công cụ case 1013

CHƢƠNG 48 PHƢƠNG PHÁP CỦA PFLEEGER

ĐỂ LỰA CHỌN CÔNG CỤ CASE DỰA TRÊN

SỰ TRƢỞNG THÀNH CỦA QUÁ TRÌNH

Người dịch: Dƣơng Tùng Sơn

48.1 TỔNG QUAN

A wide variety of computer-assisted software engineering (CASE)

tools are available in the software market for various types of applications





in the software development process. It is not a trivial issue for an

organization to make the appropriate selections and incorporate the CASE

tools at the right stages for its own environment. The five process maturity

levels defined by the Software Engineering Institute can be used as

guidelines for an organization to determine the proper types of CASE tools

to use based on its own process maturity (Pfleeger and Fitzgerald, Jr.,

1991).

Một số lƣợng lớn công cụ CASE trên thị trƣờng phần mềm có thể

đƣợc dùng cho các ứng dụng khác nhau trong quá trình phát triển phần

mềm. Đối với một tổ chức, việc lựa chọn thich hợp va tich hợp các công cụ

CASE vao đúng giai đoạn trong môi trƣờng của họ không phải điều dễ

dang. 5 cấp độ trƣởng thanh đƣợc xác định bởi học viện công nghệ phần

mềm có thể đƣợc dùng nhƣ đƣờng lối để một tổ chức xác định đúng loại

công cụ CASE cần thiết.

It is obvious that the CASE tools chosen for a particular project have

direct impacts on its success in terms of productivity, schedule, quality, etc.

Without any clearly defined procedures or guidelines, it is rather difficult

for an organization to make intelligent decisions on selecting proper CASE

tools to use for a particular process and for a particular project. The method

presented here clearly defines the most suitable types of tools to use based

on the software development process maturity of an organization. It is

valuable for organizations that have already introduced CASE tools with

emphasis on continuous process improvement or organizations that plan on





migrating from no previous CASE tools involvement to a process with fully

integrated CASE tools support.

Rõ rang các công cụ CASE đƣợc dùng trong một dự án cụ thể có tác

động trực tiếp đến thanh công trên các mặt năng suất, kế hoạch, chất lƣợng,

v.v… Nếu không có thủ tục hoặc nguyên tắc rõ rang, một tổ chức sẽ gặp

khó khăn trong việc xác định đúng công cụ CASE cần dùng trong một quá

trình hay dự án cụ thể. Phƣơng pháp trình bay ở đây xác định rõ rang các

loại công cụ CASE thich hợp dựa vao sự trƣởng thanh của quá trình phát

triển phần mềm của một tổ chức. Điều đó rất có giá trị đối với các tổ chức

bắt đầu đƣa công cụ CASE vao sử dụng hoặc đang có kế hoạch chuyển từ

không dùng công cụ CASE sang sử dụng CASE hoàn toàn.


The table in Exhibit 49-1 describes the characteristics for each

process maturity level defined by the Software Engineering Institute.

Bảng Exhibit 49-1 miêu tả tinh chất của từng cấp độ trƣởng thanh

xác định bởi học viện công nghệ phần mềm:





Cấp độ 1

For this level of process maturity, the inputs to the process are not

well defined; however, the outputs are usually defined. The software

process neither defines nor controls the transition from inputs to outputs.

The CASE tools selection for this level should focus on adding structure

and definition to the inputs and outputs of the process. A tool that structures

and controls the requirements is useful for process at this level of maturity.

Đối với cấp độ nay, input của quá trình không đƣợc xác định tốt; tuy

nhiên output đã đƣợc xác định. Quá trình lam phần mềm không xác định

hay kiểm soát sự chuyển dịch từ input sang output. Lựa chọn công cụ

CASE cho cấp độ nay nên tập trung vao việc thêm vao cấu trúc va định

nghĩa cho input va output trong quá trình. Một công cụ tạo cấu trúc va kiểm

soát các yêu cầu sẽ có ich ở cấp độ nay.

Cấp độ 2





For this level of process maturity, the inputs, outputs, and constraints

are identified for the process. This process is repeatable. Proper inputs will

always produce proper outputs even though there is no mechanism to keep

track of how the outputs are produced. The process at this level is

completely dependent on individuals working on the project. The CASE

tools selection for this level should focus on documenting and retaining the

information produced in the software development process and making it

available to other members in the project team. Tools for requirements

modeling, specification, and analysis are useful and project management

tools will help track the project constraints at this level of process maturity.

Đối với cấp độ nay, input, output va các giới hạn của quá trình đã

đƣợc xác định. Quá trình nay có thể đƣợc lặp lại. Input thich hợp sẽ luôn

luôn tạo ra output thich hợp mặc dù không có cơ chế để theo dõi output

đƣợc tạo ra nhƣ thế nao. Ở cấp độ nay quá trình phụ thuộc hoan toan vao

các cá nhân lam việc trong dự án. Lựa chọn công cụ CASE cho cấp độ nay

nên tập trung vao việc tai liệu hóa va duy trì những thông tin đƣợc tạo ra

trong quá trình phát triển phần mềm để các thanh viên trong team có thể

xem. Công cụ cho các yêu cầu mô hình hóa, chi tiết kỹ thuật va phân tich sẽ

có ich va các công cụ quản lý dự án sẽ giúp theo dõi các giới hạn của dự án

ở cấp độ nay.

Cấp độ 3





For this level of process maturity, the process is now refined into

activities according to various phases in the development cycle. The entry

and exit criteria for all activities in the process are clearly defined. The

inputs for any particular activity should be ready and evaluated before the

actual activity takes place. The inputs and outputs associated with each

activity are considered intermediate products. The CASE tools selection for

this level should focus on measuring the characteristics of the intermediate

products to ensure the goals are met and to monitor the process deviations.

CASE tools should be selected to produce, analyze, and organize those

intermediate products at this level of process maturity.

Ở cấp độ nay, quá trình bây giờ đƣợc cải tiến trong các hoạt động

theo các giai đoạn khác nhau trong vòng đời phát triển. Tiêu chuẩn bắt đầu

va kết thúc cho các hoạt động trong quá trình đƣợc xác định rõ. Input cho

bất cứ hoạt động cụ thể nao cũng đƣợc đánh giá trƣớc khi đƣợc thực hiện.

Input và output đi với mỗi hoạt động đƣợc xem nhƣ những sản phẩm trung

gian. Lựa chọn công cụ CASE cho cấp độ nay nên tập trung vao việc đánh

giá các sản phẩm trung gian để đảm bảo những mục tiêu khớp với nhau va

để theo dõi sự sai lệch của quá trình. Công cụ CASE nên đƣợc chọn để sản

xuất, phân tich va tổ chức các sản phẩm trung gian đó ở cấp độ nay.

Cấp độ 4

For this level of process maturity, the software development process

tends to be dynamic in the sense that feedback and experience learned from





early project activities can be used to determine and modify the priority of

later project activities. The effectiveness of process factors such as reuse,

testing, and reviews can be evaluated. The causal analysis can be done

throughout the development process to prevent future mistakes and to

analyze defects injected in the early activities. The software development

process is now carefully controlled rather than just monitored. The CASE

tools selection for this level should focus on collecting and analyzing

process-wide metrics for confidence measurement and course correction to

allow management and control of the development process.

Ở cấp độ nay, quá trình phát triển phần mềm có xu hƣớng linh động

theo nghĩa la các phản hồi va kinh nghiệm từ các hoạt động trƣớc đƣợc

dùng để xác định va chỉnh sửa sự ƣu tiên của các hoạt động sau nay. Sự

hiệu quả của các công việc nhƣ tái sử dụng, kiểm tra va xem xét có thể

đƣợc đánh giá. Sự phân tich nguyên nhân có thể đƣợc thực hiện trong quá

trình phát triển để ngăn chặn các lỗi trong tƣơng lai va phân tich các nhƣợc

điểm tìm thấy trong các hoạt động trƣớc. Quá trình phát triển phần mềm

bây giờ đƣợc kiểm soát cẩn thận hơn la chỉ theo dõi. Lựa chọn công cụ

CASE cho cấp độ nay nên tập trung vao việc thu thập va phân tich số liệu

cho việc đánh giá va sửa chữa để quản lý va kiểm soát quá trình phát triển.

Cấp độ 5

This is the ultimate level of process maturity. Projects in this level

are fully dynamic in terms of real-time intra- and interprocess





improvements and modifications. The software process evolves and

corrects itself. The CASE tools selection for this level should focus on

dynamic evaluation, configuration, and reconfiguration of an environment

based on the current status of the process to ensure product confidence level

is met. Process programming and process simulation tools should be

considered for process at this level of maturity.

Đây la cấp độ trƣởng thanh cuối cùng. Các dự án ở cấp độ nay đƣợc

linh động hoan toan trong sự cải tiến va chỉnh sửa quá trình bên trong theo

thời gian thực. Quá trình phát triển phần mềm tự tiến hóa va sửa chữa. Lựa

chọn công cụ CASE cho cấp độ nay nên tập trung vao việc đánh giá, cấu

hình môi trƣờng dựa vao tình trạng hiện tại của quá trình để đảm bảo độ tin

tƣởng của sản phẩm. Các công cụ lập trình va giả lập quá trình nên đƣợc

xem xét ở cấp độ nay.


Pfleeger, S.L. and Fitzgerald, Jr., J.C. (1991). Software metrics tool

kit: support for selection, collection and analysis, Inf. Software Technol.,

September, 33(7).




nhập môn công nghệ phần mềm,nguyễn tấn trần minh khang ...

Documents

Transcript of nhập môn công nghệ phần mềm,nguyễn tấn trần minh khang ...