week 03-software process

1

Software Process

Trình bày:

ThS. Lâm Quang VũBộ Môn Công Nghệ Phần MềmKhoa Công Nghệ Thông TinTrường Đại Học Khoa Học Tự Nhiên TPHCM

TpHCM, 6/2005

(Ti�n trình ph�n m�m – SP)

9/18/2006Software Process 2

Tài liệu tham khảo� SEI – www.sei.cmu.edu� OpenCourseWare - MIT� Bài giảng Software Engineering của CMU,

UIUC� Bài giảng CNPMNC – TS Trần Đan Thư� Luận Văn Thạc Sĩ – “Nghiên cứu và vận hành

các tiến trình phần mềm hữu dụng”, ThS Lâm Quang Vũ

� Các bài báo và các thông tin khảo sát từIEEE, ACM

2


Nội dung

� Giới thiệu � Các khái niệm cơ bản trong Software

Process � Software Life Cycle Models� Giới thiệu một số tiến trình phần mềm� Tổng kết và thảo luận


1. Giới thiệu

� Một số vấn đề quan tâm trong việc phát triển phần mềm

� Một số nguyên nhân� Bản chất vấn đề …

3


Kinh tế thế giới ngày càng phụ thuộc hơn vào CNPM

Các ứng dụng mở rộng vềkích thước, độ phức tạp, và phân bố

Thương trường đòi hỏi nâng cao năng suất, chất lượng vàgiảm thời gian

Không đủ nhân lực có trình độ

Một số vấn đề


• Nhiều thành công

• Cũng nhiều thất bại

Chúng ta đã làm việc ra sao?

ProjectManager

PerformanceEngineer

ReleaseEngineer

Analyst

Tester

Developer

$$$

Chất lượng

Thời gian

Chi phí Nhân lực

4


Một ví dụ về nguyên nhân thất bại ? [SEI]

� Dự án lớn càng lớn, càng khó kiểm soát� Thực tế, có ít nhân viên có thói quen lập kế

hoạch, tổ chức công việc khoa học� Không có kế hoạch � không biết được

trạng thái công việc� Nếu bạn không biết � quản lý làm sao

biết?� Quản lý không biết � họ không thể quản lý

dự án


Một số lý do khác …[Rational, RUP]� Hiểu không đúng những gì người dùng cần� Không thể thích ứng với các thay đổi về yêu cầu của

hệ thống � Các Module không khớp với nhau� Phần mềm khó bảo trì và nâng cấp, mở rộng� Phát hiện trễ các lỗ hổng của dự án � Thiếu công cụ hỗ trợ và quản lý� Hiệu năng của phần mềm thấp� Các thành viên trong nhóm không biết được ai đã

thay đổi cái gì, khi nào, ở đâu, tại sao phải thay đổi � Quá trình build-and-release không đáng tin cậy

5


Bản chất vấn đề ?

� Làm sao để dung hòa các yếu tố� Con người ?� Độ phức tạp, khối lượng công việc ?� Thời gian ?� Công cụ hỗ trợ ?

� Mục tiêu chính:� Đúng thời gian� Đảm bảo ngân sách� Thỏa mãn nhu cầu người sử dụng


Cái mà chúng ta cần ???

6


2. Tiến trình phần mềm – tổng quan

TIẾN TRÌNH định nghĩa:

AI phải LÀM GÌ,KHI NÀO,làm BẰNG CÁCH NÀO làm ra SẢN PHẨM gì ?


Một định nghĩa khác

� Tiến trình phần mềm là một tập hợp các hoạt động được thực hiện bởi con người theo một kế hoạch dự kiến nhờ vào:� Vận dụng các phương pháp, tri thức, kinh nghiệm� Sử dụng các công cụ hỗ trợ (CASE Tools)

� Để sản sinh ra các sản phẩn phần mềm (chương trình, đặc tả yêu cầu, hồ sơ thiết kế, hồ sơ kiểm chứng ….)

7


Các thuật ngữ trong SP

� Tiến trình phần mềm (software process)� Tiến trình con / bộ phận (sub-process)� Hoạt động (Activities)� Vai trò (Roles)� Sản phẩm (Products)� Công cụ hỗ trợ(Tools)


Các thành phần chính yếu nhất

Hoaït ñoäng(thuû coâng)

Hoaït ñoäng(töï ñoäng)

Saûnphaåmphaànmeàm

Luoàng döõ lieäu

Luoàng döõ lieäu

Luoàng ñieàu khieån

Vai troø (Role)

Hoaït ñoäng(Activity)

Saûn phaåm(Product)

8


Hoạt động (Activities)

� Mô tả một công việc trong tiến trình� Các ràng buộc tuyến tính áp đặt thứ tự

thực hiện những hoạt động này gọi là các luồng điều khiển (control flow) trong tiến trình

� Phân loại� Tự động� Bán tự động� Thủ công


Vai trò (Roles)

� Tập các đối tượng có trách nhiệm thực hiện một hoạt động của một tiến trình nào đó.

� Phân loại:� Con người� Tác tử đại diện (Software Agents)

9


Sản phẩm (Products hoặc Artifacts)

� Là những sản phẩm thông tin cần được tạo thành trong tiến trình phần mềm (chương trình, mã nguồn, báo cáo, mô hình thiết kế ….)

� Phân loại� Đầu vào (có sẵn)� Đầu ra (kết quả)� Trung gian


Công cụ hỗ trợ (CASE Tools)

� Hỗ trợ thực hiện các hoạt động trong tiến trình phát triển phần mềm

� Hỗ trợ một vài công đoạn hoặc toàn bộcác hoạt động trong tiến trình phát triển phần mềm

10


Ví dụ - Tiến trình kiểm lỗi tài liệu

� Hoạt động: chuẩn bị, tìm lỗi ….� Sản phẩm: tài liệu kiểm lỗi, ds lỗi …� Vai trò: tác giả tài liệu, người kiểm lỗi …� Công cụ hỗ trợ (tuỳ thuộc vào thể hiện của SP):

� Đọc tài liệu: Notepad, Word, Visual Studio 6.0 …� Ghi nhận lỗi: Excel, CaseTools tự thiết kế …


Một tiến trình phần mềm hiệu quả …� Cung cấp các chỉ dẫn để phát triển một cách hiệu quả

một phần mềm có chất lượng� Giảm thiểu rủi ro tăng khả năng tiền định (trưởng

thành trong việc phát triển phần mềm)� Nắm giữ và thể hiện các kinh nghiệm tốt

� Học từ các kinh nghiệm khác� Nắm vững các kiến thức nền tảng� Mở rộng các tài liệu huấn luyện

� Nâng cao năng lực và tầm nhìn trong phát triển phần mềm

� Cung cấp hướng dẫn về cách dùng các công cụ hỗtrợ một cách hiệu quả.

� Chuyển tải thông tin trực tuyến, chỉ dẫn chi tiết

11


Một ví dụ về tiến trình phát triển PM

Các Workflownhóm các công việc một cách logic

Trong mộtbước lặp, bạn đi qua tất cảcác workflow


Các pha (phases) trong tiến trình phần mềm

� Đặc tả phần mềm� Phát triển, xây dựng

phần mềm� Xác nhận phần

mềm� Tiến hoá phần mềm

Tùy theo mô hình chu kỳ sống phần mềm, các hoạt động nầy sẽ được tổ chức, phân rã, sắp xếp đểthực hiện theo các thứtự khác nhau…

Việc tổ chức dựa trên các phương pháp luận, kỹthuật, kinh nghiệm …

12


Cách tổ chức các hoạt động

� Software Life-Cycle Models


Phân biệt !!!

� Software Process Models� Activities� Software Life Cycle Models

� Thường phân biệt tiến trình phát triển phần mềm dựa trên mô hình chu kỳsống của phần mềm (Software Life Cycle Models)

13


Một số yếu tố phân biệt các mô hình chu kỳ sống

� Theo phiên bản (Version)� Single-Version Model� Multi-Version Model

� Theo hình thức tổ chức� Waterfall Models (mô hình thác nước)� Incremental Models (mô hình tăng trưởng)� Iterative Models (mô hình lặp)


Phân biệt Incremental và Interative

� Nghe có vẻ tương tự và thật sự đôi khi có một số điểm giống nhau

� Khác biệt:� Incremental: sản phẩm được bổ sung thêm

dần dần sau mỗi pha� Iterative: sản phẩm được thực hiện lại sau

mỗi pha

� Một số mô hình áp dụng cả hai cách tổchức này

14


Một ví dụ cụ thể - Xây một căn nhà

� Incremental: bắt đầu với một căn nhànhỏ sau đó sẽ thêm từng phòng, từng phòng để nâng cấp căn nhà

� Iterative: sau mỗi bước lặp, căn nhà được tái thiết kế và xây lại mới

� Khác biệt: � Incremental: chúng ta có thể sống trong

suốt thời gian xây dựng căn nhà� Iterative: chúng ta phải “di chuyển” sang

căn nhà được xây dựng mới


3. Một số mô hình chu kỳ sống PM� Big-Bang Model� Build-and-fix model� Waterfall model

� Waterfall Model with “back flow”

� Rapid prototyping model� Synchronize-and-stabilize model� Incremental Model� Iterative Model� Spiral model� Extreme programming and agile processes

15


Big-Bang Model

� Tổ chức đơn giản� Developer

� nhận yêu cầu� làm việc độc lập trong một khoảng thời gian

xác định� đưa kết quả� hy vọng thoả mãn nhu cầu người dùng


Build-and-Fix Model

Implement the 1st Version

Modify until client is satisfied

Postdelivery Maintenance

Maintenance

Development

16


Built-and-Fix Model (tt)

� Đặc trưng� Không lập kế hoạch, không phân tích� Chương trình là sản phẩm duy nhất

� Ưu điểm� Thích hợp cho các ứng dụng nhỏ viết bởi 1

người

� Khuyết điểm� Tính dễ hiểu và dễ bảo trì của chương trình

giảm đi nhanh chóng khi kích thước chương trình tăng


Waterfall Model

Requirements

Design

Implementation

TestHoàn thành từng pha, từng pha một và chuyển tới Pha kế tiếp, không quay lại. (Cách chia Pha tuỳ vào tổ chức)

17


Waterfall Model with “Back flow”

Requirements

Design

Implementation

TestDựa trên các vấn đề ở Pha hiện tại, các hiệu chỉnh sẽ được thực hiện ngay ở Pha trước đó


Waterfall Model

� Đặc trưng� Tuyết tính và tuần tự� Không thể quay lại� Yêu cầu phải được xác định trước

� Ưu điểm� Các cột mốc xác định rõ ràng� Chỉ một hoạt động (Pha) tại một thời điểm� Dễ dàng đánh giá tiến độ� Tiếp cận dễ hiểu

18


Waterfall Model (tt)� Khuyết điểm

� Khó có thể xác định hết các yêu cầu tại thời điểm bắt đầu dự án, khách hàng chỉ làm việc trong Pha đầu � rủi ro cao

� Yêu cầu có thể thay đổi:o Thị trường thay đổio Kỹ thuật thay đổio Nhu cầu của người dùng thay đổi

� Bảng thiết kế có thể thay đổi trong khi cài đặt � không đáp ứng

� Sản phẩm được hình thành ở cuối giai đoạn của tiến trình


“V“ ModelRequirements

Analysis

System Design

Program Design

Implementation

Unit Test

Integration Test

Acceptance Test

19


“V” model (tt)

� Đặc trưng� Mỗi pha đều có kết hợp với việc kiểm

chứng

� Ưu điểm� Giống Waterfall, nhưng có kiểm chứng

thường xuyên � sớm phát hiện

� Khuyết điểm� Không uyển chuyển� Thích hợp với dự án vừa và nhỏ


Synchronize-and-stabilize model� Đặc trưng

� Các nhóm làm việc trên các Module độc lập nhau� Thường xuyên đồng bộ mã nguồn với các nhóm

khác và hiệu chỉnh mã nguồn trong suốt tiến trình phát triển

� Ưu điểm� Uuyển chuyển, cho phép hiệu chỉnh với bất kỳ

thay đổi nào� Không nghiêm ngặt như Waterfall Model

� Khuyết điểm� Chỉ thích hợp với các dự án nhỏ

20


Rapid prototyping model


Rapid prototyping model (tt)� Đặc trưng

� Dùng mẫu prototyping ban đầu để giúp xác định yêu cầu của khách hàng (có thể lặp) � sau đó Kết hợp với Waterfall

� Luôn có kiểm tra, kiểm chứng ở các pha

� Ưu điểm� Phát triển nhanh (rapid)� Giống Waterfall: tuyến tính nhưng có ít hoặc không

có feedback

� Khuyết điểm� Chỉ thích hợp với dự án vừa và nhỏ

21


Incremental Model

� Là một dạng mô hình lặp� Các yêu cầu được xác định trước và xếp loại ưu tiên� Các YC có độ ưu tiên cao sẽ được đưa vào vòng lặp đầu� Mỗi phiên bản phát hành được bổ sung thêm chức năng mới


Incremental Model

� Ưu điểm� Có thể thấy sản phẩm trong thời gian ngắn� Bảng đặc tả yêu cầu ban đầu có thể dùng

trong hợp đồng ký kết� Thấy được sản phẩm tăng trưởng

� Khuyết điểm� Khó có thể nắm bắt hoàn toàn yêu cầu nếu

không có kinh nghiệm trong lĩnh vực chuyên môn

22


Loại Iterative Model

� Là dạng mô hình lặp� Mỗi bước lặp phát sinh ra một phiên bản

mới


Loại Iterative Model

� Ưu điểm� Cho phép quản lý rủi ro tốt� Những phiên bản đầu có thể gợi ra những yêu cầu

cho các bước lặp sau� Thấy được sự tiến hóa của sản phẩm� Vẫn có thể tiếp tục phát triển sau khi phát hành

sản phẩm� Các tiến trình Agile Process sử dụng mô hình này

� Khuyết điểm� Phạm vi dự án lớn, tốn chi phí quản lý tiến trình

23


Spiral Model

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2

Prototype 3Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

Code

Unit test

Integrationtest

AcceptancetestService Develop, verify

next-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW


Spiral Model (tt)� Xác định các rủi ro� Đặt độ ưu tiên cho các rủi ro� Thiết lập các Prototype cho các rủi ro đã xác

định và bắt đầu với cái có độ ưu tiên cao nhất� Sử dụng mô hình Waterfall cho mỗi bước phát

triển Prototype� Nếu một rủi ro được giải quyết thành công,

đánh giá kết quả và lập kế hoạch cho vòng (Prototype) kế tiếp

� Nếu một rủi ro nào đó không giải quyết được � kết thúc dự án ngay lập tức

24


Một vài ví dụ về rủi ro

� Khách hàng không biết chính xác những gì họ muốn � thay đổi có thể xảy ra trong quá trình tiến hành

� Đội ngũ nhân viên không có kinh nghiệm trong lĩnh vực chuyên môn (của ứng dụng phát triển) hoặc không thích hợp với các kỹ thuật mới được dùng trong dự án


WinWin Spiral Model

� Ngoài việc phân tích rủi ro� Xác định “điều kiện thoả mãn khách hàng”� Đàm phán với khách hành về điều kiện

thoả mãn� Các bước lặp hướng theo các “điều kiện

thỏa mãn khách hàng”

25


Extreme programming

� Đặc trưng� Qui trình phát triển nhanh, uyển chuyển� Dựa trên khái niệm “Stories” (những tính năng

mà người dùng muốn)o Ước lượng thời gian và chi phí cho mỗi Storyo Chọn Story cho lần phát triển kế tiếpo Chi nhỏ công việc trong mỗi lần phát triển

� Công việc cho 2 người (Pair programming)

o Luôn đưa ra các trường hợp kiểm chứng cho từng công việc trước khi thực hiện

o Việc tích hợp diễn ra liên tục


Extreme programming

Spike : vấn đề “gai góc”

26


� Một số đặc trưng khác� Khách hàng luôn hiện diện� Không có nhóm nào thực hiện công việc quá 2

tuần� Không có sự chuyên môn hóa (không phân vai trò)

� Ưu điểm� Gọn, uyển chuyển, phát triển nhanh� Thích hợp cho những tổ chức vừa và nhỏ

Extreme programming


Agile processes

� Một tập các hướng tiếp cận mới trong việc phát triển phần mềm

� Đặc trưng� Không quan trọng việc phân tích thiết kế� Cài đặt sớm

o Phần mềm thực thi luôn quan trọng hơn sưu liệu

� Sẵn sàng đáp ứng thay đổi� Cộng tác chặt chẽ với khách hàng

27


Đánh giá Agile Processes và XP

� Hữu dụng khi yêu cầu mập mờ hoặc cókhả năng thay đổi cao.

� Chưa thật sự chuẩn hóa � có nhiều cách tiếp cận khi sử dụng � khó đánh giá

� Ý tưởng mang tính đột phá� Lập trình nhóm 2 (Pair Programming)


Khái niệm …- Driven

� Document-Driven� Feature-Driven� UseCase-Driven� Function-Driven

28


Một số so sánh

Không thích hợp cho các dự án lớn

Thích hợp trong các trường hợp yêu cầu người dùng mơ hồ và hay thay đổi.

Feature-Driven

Extreme programming model and Agile Process

Không thích hợp cho các dự án lớn

Đảm bảo sản phẩm thoả mãn nhu cầu người dùng.

Function-Driven

Rapid Prototyping model

Sản phẩm có thể không đáp ứng được nhu cầu của người dùng cuối.

Cách tiếp cận mang tính nguyên tắc, chuẩn.

Thấy rõ tình trạng dự án

Document-Driven

Waterfall model

Không thoả mãn cho các dự án lớn

Tốt cho các chương trinh nhỏ vàkhông cần phải bảo trì

Build and fix model

Tốn thời gian và nhân lực, chi phí quản lý

Gần với cách sản xuất phần mềm thực tế hiện nay. Dựa trên nền tảng kết hợp nhiều mô hình bên dưới � tăng độ an toàn

UseCase-Driven

Iterative and incremental model

Điểm yếuĐiểm mạnhLife-Cycle Model


Tổng kết phần (3)

� Mỗi mô hình đều có ưu và khuyết điểm riêng

� Lựa chọn mô hình thích hợp dựa trên:� Phạm vi của tổ chức� Trình độ quản lý� Kỹ năng của đội ngũ nhân viên� Loại sản phẩm thực hiện

� Có thể kết hợp sử dụng nhiều mô hình cùng lúc

29


4. Sự hỗ trợ của các chuẩn

� Các chuẩn ISO� Các phương thức đánh giá

(CMMI,Bootstrap,SPICE…)� PSP� …


Chuẩn CMM

Initial

(Level 1)

Repeatable

(Level 2)

Defined

(Level 3)

Managed

(Level 4)

Optimized

(Level 5)

Ris

kC

om

petitiv

eness

•Largely Ad-hoc

•Phụ thuộc vào cá nhân

•Bắt đầu có khả năng quản lý

•Quản lý dựa vào kinh nghiệm tương

tự

•Xác lập các tiêu chuẩn quản lý

•Các vấn đề documentation đã xác lập

•Có khả năng dự đoán (Predictability)

•Các quy trình quản lý và tiêu chuẩn

được chi tiết hóa

•Continuous Improvement

•Các hệ thống quality control và qualify

đã được sử dụng hiệu quả

30


Giới thiệu qui trình RUP


Kết luận

� Tiến trình phần mềm rất phức tạp, đòi hỏi nhiều sự cộng tác

� không như các ngành công nghệ khác, tiến trình phần mềm lại không xác định chắc chắn và có nhu cầu tiến hóa cao.

�Ứng dụng/vận hành tiến trình trở nên rất khó kiểm soát, khó đạt hiệu quả, nhất làkhi quy mô của tiến trình lớn..

31

Kết thúc

Cảm ơn quý vị đã quan tâm theo dõi !

Thông tin liên hệ: [email protected], 6/2005

week 03-software process

Documents