Qui trình phát triển phần mềm

„ Những qui trình giới thiệu là những qui trình cơ bản có tính nghiêm ngặt, hiện nay người ta áp dụng những qui trình mới có tính linh hoạt cao, tạo sự thoải mái cho người làm việc và ph

Chương 2 : Qui trình phát triển phần mềm

Yêu cầu

„ Hiểu rõ một số qui trình phát triển cơ bản

„ Trong thực tế người ta thường áp dụng những qui trình tổng hợp kết hợp nhiều qui trình

„ Những qui trình giới thiệu là những qui trình cơ bản có tính nghiêm ngặt, hiện nay người ta áp dụng những qui trình mới

có tính linh hoạt cao, tạo sự thoải mái cho người làm việc và phát huy tính sáng tạo nhưng vẫn phải tuân thủ các nguyên tắc

1 Qui trình trong công nghệ phần mềm

Software Engineering

a “quality” focus process model methods tools

Qui trình

„ Qui trình phần mềm bao gồm một tập hợp các hoạt động

được tổ chức mà mục đích của nó là xây dựng và phát triển phần mềm

„ Qui trình: Phải thực hiện những công việc gì?

„ Phương pháp: Chỉ ra cách thực hiện những công việc cụ thể (“how to”)

Khung tiến trình (Process framework)

Process framework

Framework activities

work tasks work products milestones & deliverables

QA checkpoints Umbrella Activities

Các hoạt động khung (Framework activities)

„ Quản lý rủi ro.

Lựa chọn mô hình phát triển dựa vào:

„ Bản chất của dự án và ứng dụng

„ Phương pháp và công cụ được dùng

„ Cách thức kiểm soát và các kết quả chuyển giao được

yêu cầu

Năm mô hình phát triển phần mềm

„ Mô hình Thác nước (Waterfall Model)

„ Mô hình Xử lý tăng dần (Incremental Process Models)

„ Mô hình Qui trình tiến hóa (Evolutionary Process models)

Không có qui trình?

„ Không thể biết khi nào hoàn thành do không có phân tích và thiết kế chính thức

„ Không có cách đánh giá các yêu cầu, và tiêu chuẩn chất

lượng có được thỏa mãn hay không

2.1 Mô hình thác nước (Waterfall Model)

„ Mô hình thác nước [Winston Royce] đưa ra vào năm 1970

nhằm thay thế cho phương pháp “code-and-fix”

„ Lần đầu tiên đưa ra chính thức một khung mẫu gồm các giai đoạn phát triển phần mềm dựa vào các yêu cầu đã xác định

và được tạo tài liệu trong giai đoạn đầu

Mô hình thác nước

Mô hình thác nước

„ Phát triển theo trình tự các bước Mỗi giai đoạn xác định tiêu chuẩn vào và ra Mô hình dễ hiểu và dễ thực hiện đối với mọi người liên quan Nó cung cấp một cấu trúc rõ ràng cho những nhân viên thiếu kinh nghiệm hay yếu về kỹ thuật

„ Việc chuyển từ một giai đoạn này tới giai đoạn kế tiếp được thực hiện khi thỏa một kiểm tra (review) chính thức, xác định một sự đồng thuận giữa những thành viên dự án và khách

hàng

„ Áp dụng cho những phần mềm chất lượng cao, khi yêu cầu

chất lượng nổi trội hơn những yêu cầu về lịch biểu và chi phí

Mô hình thác nước – nhược điểm

„ Mô hình có tính tuần tự theo 5 giai đoạn nên khi muốn quay lui

để làm đúng một vấn đề hay một kết quả thì sẽ tốn kém nhiều chi phí và thời gian Do đó cần phải quản lý chặt chẽ các hoạt động, phải đặc tả tất cả yêu cầu một cách chính xác và đầy đủ ngay từ ban đầu

„ Khó đánh giá tình trạng của dự án, đánh giá kết quả của dự

án ở thời điểm kiểm tra do việc tích hợp chỉ thực hiện ở giai đoạn cuối

„ Tồn tại việc phải chờ (“delay”) trong nhóm làm việc

„ Việc thực hiện trình tự không tự nhiên, tính lặp thường diễn ra trong thực tế

Khi nào sử dụng mô hình thác nước

„ Khi xác định sản phẩm ổn định và những vấn đề về kỹ thuật

đã biết rõ:

„ Nếu một công đã xây dựng một hệ thống như kế toán, bán

hàng… thì những dự án xây dựng những sản phẩm tương tự có thể sử dụng mô hình thác nước.

„ Tạo một phiên bản mới của một sản phẩm đang tồn tại trong đó những thay đổi (change) được xác định và kiểm soát

2.2 Mô hình tăng dần (Incremental Model)

Mô hình tăng dần

„ Các yêu cầu được xác định và phân loại theo độ ưu tiên, độ

ưu tiên cao cho những chức năng chính và những chức năng

có độ rủi ro cao

„ Phân chia các yêu cầu cho các vòng và thiết kế kiến trúc của toàn bộ hệ thống

„ Vòng đầu tiên tạo ra sản phẩm lõi (core product)

„ Các bước sau bổ sung các chức năng khác và tích hợp vào

hệ thống nhằm hoàn thiện dần sản phẩm

„ Hệ thống tích hợp phải được kiểm tra đánh giá thường xuyên theo từng giai đoạn

Mô hình tăng dần – ưu điểm

„ Những chức năng của hệ thống có thứ tự ưu tiên càng cao

(chức năng chính, chức năng rủi ro cao) sẽ được thực hiện trước, do đó chúng sẽ được kiểm thử nhiều hơn, sản phẩm hoàn thành phần sớm phần cơ bản

„ Sau mỗi lần tăng vòng thì có thể chuyển giao kết quả cho

khách hàng Những kết quả này đóng vai trò là mẫu thử để

giúp tìm hiểu thêm các yêu cầu ở những vòng tiếp theo

„ Có thể thực hiện nhiều bước đồng thời Nhân viên có thể thực hiện những công việc tương tự ở các vòng một cách liên tục

Mô hình tăng dần – khuyết điểm

„ Phải xác định chức năng đầy đủ và hoàn chỉnh trước khi xác định các vòng gia tăng (thác nước?)

„ Phải xác định rõ các giao tiếp (interface) cho các module mà thời gian hoàn thành cách biệt nhiều

„ Việc kiểm tra khó khăn hơn trên một hệ thống hoàn chỉnh

„ Khách hàng khi thấy sản phẩm lõi có thể nghĩ là công việc

đơn giản ít tốn kém

„ Đòi hỏi phải có kế hoạch và thiết kế tốt, phân chia công việc hợp lý, các nhân viên phải cộng tác tốt

Mô hình tăng dần– khi nào sử dụng

„ Khi tất cả yêu cầu được hiểu khá rõ nhưng mong muốn có sự tiến hóa dần của sản phẩm

„ Khi cần phải nhanh chóng đưa sản phẩm với chức năng cơ bản ra thị trường sớm

„ Áp dụng cho những sản phẩm có thời gian phát triển dài hơn

1 năm

2.3 Mô hình RAD (Rapid Application Development Models)

„ Mô hình này được đưa ra bởi IBM vào những năm 1980,

qua sách của James Martin

„ Rapid Application Development một mô hình tiến trình phần mềm gia tăng với chu kỳ phát triển ngắn (60-90 ngày)

„ Mô hình RAD dựa vào sử dụng thành phần (component) và

sử dụng các ứng dụng tạo mã tự động

Mô hình RAD

Mô hình RAD – điểm yếu

„ Người phát triển phải có kỹ năng và được huấn luyện tốt cho việc sử dụng công cụ và cho việc phát triển nhanh

„ Hệ thống có khả năng phân tách module rõ ràng

„ Cần các thành phần sử dụng lại

„ Người phát triển và khách hàng cần phải nỗ lực cộng tác

Mô hình RAD – khi nào sử dụng

„ Hệ thống dễ dàng phân chia module và có thể mở rộng

„ Người dùng có thể tham gia tốt qua toàn bộ chu kỳ sống (life cycle)

„ Dự án thời gian phát triển ngắn, 60-90 ngày

„ Những thành phần sử dụng lại có sẵn trong kho phần mềm

„ Những hệ thống nhỏ, những hệ thống không có tính nghiêm ngặt (critical)…

2.4 Mô hình Tạo bản mẫu (Prototyping)

listen

to customer

build

mock-up (mẫu)

customer

test-drives

Mô hình tạo bản mẫu

„ Mô hình bản mẫu dựa trên ý tưởng xây dựng một mẫu thử ban đầu (Prototype – nguyên mẫu) và đưa cho người sử dụng xem xét; sau

đó, tinh chỉnh mẫu thử qua nhiều phiên bản cho đến khi thỏa mãn yêu cầu của người sử dụng thì dừng lại.

„ Mẫu thử ban đầu như là một cơ chế để nhận diện chính xác yêu

cầu của khách hàng (Throwaway Prototyping)

„ Mẫu thử ban đầu có thể trở thành sản phẩm Khi các yêu cầu của người sử dụng được thỏa mãn thì cũng là lúc chúng ta đã xây dựng xong hệ thống (Evolutionary Prototyping)

Mô hình tạo bản mẫu – ưu điểm

„ Khách hàng tương tác sớm với hệ thống.Khách hàng và

người phát triển dễ dàng trao đổi

„ Người phát triển có thể xác định nhanh chóng và chính xác được yêu cầu nhờ vào nguyên mẫu

„ Có thể phát hiện những yêu cầu mới hoặc những yêu cầu bất ngờ

Mô hình tạo bản mẫu - Nhược điểm

„ Là phương pháp Quick-and-dirty thường thiếu tư liệu hay tư

liệu không phù hợp Người phát triển có thể rơi vào chu kỳ

code-and-fix

„ Hệ thống được xây dựng có thể mang cấu trúc một cách nghèo nàn với những lựa chọn không tốt Hệ thống này sẽ có chất

lượng thấp và khó bảo trì sau một thời gian dài

„ Khách hàng hối thúc nhà phát triển hoàn thành sản phẩm một khi thấy được các nguyên mẫu (prototype) đầu tiên

Mô hình Tạo bản mẫu – khi nào sử dụng

„ Khi yêu cầu không được biết rõ, khi các yêu cầu không ổn

định, việc thông tin không được đáp ứng tốt

„ Khi người phát triển không chắc chắn việc dùng giải thuật hay kiến trúc nào là tối ưu Trên những hệ thống dựa vào kỹ thuật mới mà những yêu cầu khó xác định rõ

„ Một vài phần của hệ thống lớn có thể thích hợp cho mô hình bản mẫu (giao diện người dùng)

„ Phù hợp với những hệ thống:

„ user-interface intensive systems

„ interactive online systems

2.5 Mô hình xoắn ốc (Spiral Model)…

Mô hình xoắn ốc…

R isk analys is Risk

analys is

R isk analys is

Risk analysis Prot o-

C oncept o f Operati on

Sim ul ati ons, m odels, b en ch marks

S/W requi rement s Prod uct

Commitment

Ratio

Mô hình xoắn ốc…

„ Đề nghị bởi Berry Boehm, 1988

„ Mô hình xoắn ốc có thể xem là siêu mô hình (metamodel) do

nó có thể xem là các mô hình khác trong những tình huống

thích hợp

„ Mỗi vòng lặp đều có phân tích rủi ro, chỉ báo sớm những rủi ro không thể khắc phục với phí tổn không cao

Mô hình xoắn ốc – nhược điểm

„ Cần kiến thức đánh giá rủi ro chuyên sâu Việc đánh giá rủi ro tốn nhiều chi phí, không không thích hợp cho những dự án rủi

ro thấp hay nhỏ

„ Mô hình phức tạp, khó sử dụng

„ Khó quản lý tiến trình và thuyết phục khách hàng

3 Các vấn đề khác: Dùng thành phần

„ Phát triển dựa vào thành phần (component): xây dựng hệ

thống từ việc tích hợp các thành phần đang có hoặc các

thành phần thương mại COTS (Commercial-off-the-shelf)

„ Dùng thành phần giảm 70% thời gian và 84% chi phí

„ Việc bảo trì cho các hệ thống lớn là một vấn đề.

„ 4GT + dùng thành phần là hướng phát triển rất mạnh hiện

Qui trình RUP

„ Qui trình phát triển phần mềm thống nhất RUP (Rational

Unified Process) là một trong những mô hình phát triển dựa trên thành phần dùng Ngôn ngữ mô hình thống nhất (UML-Unified modeling language)

„ RUP là qui trình do hãng Rational phát triển

Các vấn đề về phần mềm

Nguyên nhân

Qui trình RUP (Rational Unified Process)

Các giai đoạn RUP

• Khởi tạo.

• Hình thành.

• Xây dựng.

• Chuyển giao.

Phát triển lặp

Qui trình RUP

„ Xác định phạm vi dự án, yêu cầu người dùng và các ràng buộc

„ Xác định Yêu cầu nghiệp vụ, phân tích rủi ro, lập kế hoạch

dự án (phân công, chi phí)

„ Thiết kế kiến trúc hệ thống (quan tâm đến chi phí, lịch biểu, tài nguyên)

„ Cấu hình môi trường làm việc, công cụ

Qui trình RUP

„ Tinh chỉnh tài liệu

„ Hoạch định những bước lặp

„ Kế hoạch phát triển: qui trình, công cụ CASE

„ Tinh chỉnh kiến trúc và chọn thành phần (component)

Qui trình RUP

„ Quản lý tiến trình tạo sản phẩm: tăng năng suất, đảm bảo chất lượng

„ Tạo sản phẩm (alpha, beta, các phiên bản test khác)

„ Kế hoạch triển khai ứng dụng: chuẩn bị phần mềm, huấn luyện người sử dụng, các biện pháp hỗ trợ…

Qui trình RUP

„ Giai đoạn 4 (Transition): Chuyển giao

„ Tạo sản phẩm xuất xưởng

„ Kiểm tra sản phẩm, thu thập thông tin phản hồi

UP Work Products

Incept ion phase

Elaborat ion phase

Const ruct ion phase

Transit ion phase

V ision document

Init ial use-case model

Init ial project glossary

Init ial business case

Init ial risk assessment

A naly sis model Sof t ware archit ect ure Descript ion.

Execut able archit ect ural prot ot y pe.

Preliminary design model Rev ised risk list

Project plan including

it erat ion plan adapt ed workf lows milest ones

t echnical work product s Preliminary user manual

Design model Sof t ware component s Int egrat ed sof t ware increment

Test plan and procedure Test cases

Support document at ion user manuals

inst allat ion manuals descript ion of current increment

Deliv e re d sof t ware increment Bet a t est report s

General user f eedback

PHƯƠNG PHÁP PHÁT TRIỂN PHẦN MỀM LINH HOẠT

PPPTPMLH (Agile software development)

„ Khác biệt dễ nhận thấy của PPPTPMLH đó là lượng giấy tờ tài liệu ít hơn và có thể nói là tập trung vào việc lập trình

hơn Nhưng ẩn đằng sau đó là hai khác biệt nền tảng quan trọng: “thích ứng thay vì dự đoán” và “hướng đến con người thay vì qui trình”

„ PPPTPMLH đề cao tính chủ động và sáng tạo của các cá

nhân tham gia, và đặc biệt là việc trao đổi thông tin giữa các thành viên

PPPTPMLH không khước từ sự tổ chức nhưng nó cố gắng

Phương pháp Agile: Scrum

„ Schwaber và Beedle

„ Đặc trưng

„ Chia công việc thành những packet.

„ Test và tư liệu khi sản phẩm đang được xây dựng.

„ “product backlog” và “sprint backlog”.

„ Gặp gỡ ngắn.

„ “demo” được chuyển tới khách hàng.

Scrum

Extreme Programming (XP)

„ Là qui trình Agile được dùng rộng rãi nhất (Kent Beck)

„ XP Planning:

„ Tạo “user stories”.

„ Đánh giá câu chuyện và gán một chi phí.

„ Gom các câu chuyện thành một phần gia tăng có thể chuyển giao (deliverable increment).

„ Một cam kết về thời gian chuyển giao

„ Xác định thời gian cho các phần gia tăng khác.

Extreme Programming

„ XP Design:

„ Nguyên lý KIS (Keep It Simple).

„ Dùng thẻ CRC (Class Responsibility Collaborator).

„ Nếu gặp trở ngại về thiết kế dùng nguyên mẫu (prototype).

„ Phân tách lại (refactoring).

Class-Responsibility-collaborator (CRC)