1CNPM/NN

CÔNG NGHỆ PHẦN MỀM

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

MÔN HỌC

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCM

2CNPM/NN

Chương 2 : Qui trình phát triển phần mềm1. Qui trình (process).2. Mô hình phát triển phần mềm.

1. Mô hình thác nước.2. Mô hình phát triển gia tăng.3. Mô hình RAD.4. Mô hình bản mẫu.5. Mô hình xoắn ốc.

3. Một số vấn đề khác.1. Phát triển dựa vào thành phần.2. Kỹ thuật thế hệ thứ 4.3. Qui trình RUP.4. Phương pháp phát triển phần mềm linh hoạt (PTPMLH - Agile

software development).

3CNPM/NN

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.

4CNPM/NN

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

Software Engineering

a “quality” focus

process model

methods

tools

5CNPM/NN

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”).

6CNPM/NN

Khung tiến trình (Process framework)

Process frameworkFramework activities

work taskswork productsmilestones & deliverablesQA checkpoints

Umbrella Activities

7CNPM/NN

Khung tiến trình

Truyền thôngLập kế hoạchMô hình hóaXây dựngTriển khai

CommunicationPlanningModeling

Analysis of requirementsDesign

ConstructionCode generationTesting

Deployment

8CNPM/NN

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

Liên quan đếnCông việc (Work tasks)Sản phẩm (Work products)Mốc thời gian và thành quả chuyển giao (Milestones & deliverables)Thời điểm kiểm tra chất lượng (QA checkpoints)

9CNPM/NN

Hoạt động hỗ trợQuản lý dự án.Kiểm tra kỹ thuật hình thức.Bảo đảm chất lượng phần mềm.Quản lý cấu hình phần mềm.Tạo và chuẩn bị những sản phẩm công tác.Quản lý sử dụng lại.Đo lường.Quản lý rủi ro.

Software project managementFormal technical reviewsSoftware quality assuranceSoftware configuration managementWork product preparation and productionReusability managementMeasurementRisk management

10CNPM/NN

2. Mô hình phát triển phần mềm

Mô hình phát triển phần mềm là một thể hiện trừu tượng của quy trình phần mềm. Nó biểu diễn các đặc tả về quy trình từ những khía cạnh cụ thể, do đó, nó chỉ cung cấp một phần thông tin về quy trình phần mềm.

11CNPM/NN

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.Nhận thức rủi ro.Sự hiểu biết và kỹ năng của các kỹ sư.Kiến thức miền ứng dụng của người phát triển.

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.

12CNPM/NN

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 tăng dần (Incremental Model).Mô hình RAD (Rapid Application Development Model).

Mô hình Qui trình tiến hóa (Evolutionary Process models).Mô hình Tạo bản mẫu (Prototyping Model).Mô hình Xoắn ốc (Spiral Model).

13CNPM/NN

Không có qui trình?

Inputs Outputs

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ứcKhô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

14CNPM/NN

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.

15CNPM/NN

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

16CNPM/NN

Mô hình thác nướcPhá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í

17CNPM/NN

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ế.

18CNPM/NN

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

19CNPM/NN

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

20CNPM/NN

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.Các yêu cầu và kiến trúc của toàn bộ hệ thống sẽ được điều chỉnh dựa vào những sản phẩm phát hành theo từng vòng.

21CNPM/NN

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.

22CNPM/NN

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.

23CNPM/NN

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.

24CNPM/NN

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.

25CNPM/NN

Mô hình RAD

26CNPM/NN

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.

27CNPM/NN

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)…

28CNPM/NN

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

listento

customerbuild

mock-up (mẫu)

customertest-drivesmock-up

Prototyping

29CNPM/NN

Mô hình tạo bản mẫuMô 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)

30CNPM/NN

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ờ.

31CNPM/NN

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.

32CNPM/NN

Mô hình Tạo bản mẫu – khi nào sử dụngKhi 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. first-of-a-kind products.decision support systems…

33

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

34CNPM/NN

Mô hình xoắn ốc…

Riskanalys is

Riskanalys is

Riskanalys is

Riskanalysis Proto-

ty pe 1Prototyp e

2Prototype

3Opera-tionalprotoyp e

Concept o fOperation

Simulations, models, b ench marks

S/Wrequi rements

Requirementvalid ation

DesignV&V

Prod uctdesign Detailed

design

CodeUni t tes t

Integr ationtestAccep tance

testServ ice

Integrationand test p lan

Develop mentplan

Requirements planLife-cycle plan

REVIEW

Progress through steps

Commulative Cost

Determine Objectives, alternatives, constraints

Evaluate alternatives, Identify, resolve risks

Develop, verify next-level product

Plan next phases

Commitment Ratio

35CNPM/NN

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.

36CNPM/NN

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.

37CNPM/NN

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í.

38CNPM/NN

Kỹ thuật thế hệ thứ 44GT (fourth generation technique) là kỹ thuật dựa vào công cụ phần mềm, có thể đặc tả phần mềm ở mức khái niệm cao theo một cách thức định trước công cụ sẽ tự động sinh mã.4GT thích hợp cho ứng dụng vừa và nhỏ.4GT tăng năng suất đáng kể.Một số ý kiến cho rằng:

Một số công cụ khó sử dụng.Chương trình tạo ra cồng kềnh.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 nay.

39CNPM/NN

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.

40CNPM/NN

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

41CNPM/NN

Nguyên nhân

42CNPM/NN

Qui trình RUP (Rational Unified Process)

Giải quyếtPhát triển theo vòng lặp.Quản lý yêu cầu.Sử dụng thành phần.Mô hình trực quan.Thẩm định chất lượng.Kiểm soát thay đổi.

43CNPM/NN

Các giai đoạn RUP

• Khởi tạo.• Hình thành.• Xây dựng.• Chuyển giao.

44CNPM/NN

Phát triển lặp

45CNPM/NN

Qui trình RUP

Giai đoạn 1 (Inception): khởi tạo.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ụ.

46CNPM/NN

Qui trình RUP

Giai đoạn 2 (Elaboration): Hình thành.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).

47CNPM/NN

Qui trình RUP

Giai đoạn 3 (Construction): Xây dựng.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ợ…

48CNPM/NN

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.

49CNPM/NN

UP Work ProductsIncept ion phase

Elaborat ion phase

Const ruct ion phase

Transit ion phase

V ision documentInit ial use-case modelInit ial project g lossaryInit ial business caseInit ial risk assessment .Pro ject plan,

phases and it erat ions.Business model,

if necessary .One or more prot ot y pesI nce pt i on

Use-case modelSupplement ary requirement s

including non-funct ionalAnaly sis modelSof t ware arch it ect ure

Descrip t ion.Execut able arch it ect ural

prot ot y pe.Pre liminary design modelRev ised risk listPro ject p lan including

it erat ion planadapt ed workf lowsmilest onest echnical work product s

Pre liminary user manual

Design modelSof t ware component sInt egrat ed sof t ware

incrementTest plan and procedureTest casesSupport document at ion

user manualsinst allat ion manualsdescrip t ion of current

increment

Deliv ered sof t ware incrementBet a t est report sGeneral user feedback

50CNPM/NN

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 cân bằng giữa sự tổ chức và sự linh hoạt, cân bằng giữa việc không có qui trình nào cả và qui trình quá chi li và cứng nhắc.

51CNPM/NN

Phương pháp Agile: ScrumSchwaber 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.

52CNPM/NN

Scrum

53CNPM/NN

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.

54CNPM/NN

Extreme ProgrammingXP 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).

XP Coding:Xây dựng kiểm thử đơn vị trước.Lập trình “pair programming”.

XP Testing:Tất cả các đơn vị được kiểm thử hàng ngày, tích hợp liên tục.Thực hiện kiểm thử chấp nhận (Acceptance tests).

55CNPM/NN

Class-Responsibility-collaborator (CRC)