1CNPM/NN

CÔNG NGHỆ PHẦN MỀM

Chương 2

Qui trQui trìình xây dnh xây dựựng phng phầần mn mềềmm

MÔN HỌC

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

2CNPM/NN

Chương Chương 2 : Qui tr2 : Qui trìình xây dnh xây dựựng phng phầần mn mềềmm

2.1 Qui trình (process)2.2 Một số qui trình xây dựng phần mềm

2.2.1 Mô hình thác nước2.2.2 Mô hình phát triển gia tăng2.2.3 Mô hình RAD2.2.4 Mô hình bản mẫu2.2.5 Mô hình xoắn ốc

2.3 Một số vấn đề khác2.3.1 Phát triển dựa vào thành phần2.3.2 Kỹ thuật thế hệ thứ 42.3.3 Qui trình RUP2.3.4 Phương pháp phát triển phần mềm linh hoạt (PTPMLH)

3CNPM/NN

Yêu cYêu cầầu u

Hiểu rõ một số qui trình phần mềm cơ bảnCần biết là trong thực tế người ta thường áp dụng những phương pháp tổng hợp, có thể kết hợp nhiều phương phápNhững phương pháp giới thiệu là những phương pháp cơ bản thường mang tính chặt chẻ cao, hiện nay người ta áp dụng những phương pháp mới nó có tính linh hoạt cao, tạo sự thoải mái và phát huy tính sáng tạo nhưng vẫn không từ bỏ tính kỷ luậtTất cả các qui trình đều có những bước 5 cơ sở: phân tích, thiết kế, hiện thực mã, kiểm thử, triển khai và bảo trì, tiến hóa

4CNPM/NN

2.1 Qui tr2.1 Qui trìình (process)nh (process)Qui trình (process) phần mềm 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 xác định ai làm gì, khi nào và bằng cách nào để đạt được một mục tiêu nào đóQuy trình phần mềm xác định một bộ khung và tiêu chuẩn để triển khai công nghệ phần mềmTrong công nghiệp để giải quyết những vấn đề thực tế, những kỹ sư hay một nhóm kỹ sư phần mềm phải cộng tác để đưa ra một chiến lược phát triển bao gồm qui trình (process), phương pháp (method) và công cụ (tool)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”)

5CNPM/NN

Qui trQui trìình phnh phầần mn mềềmmNhững loại hệ thống khác nhau sẽ cần những qui trình phát triển khác nhau

Hệ thống thời gian thực yêu cầu phải hoàn thành đặc tả hệthống trước khi chuyển sang giai đoạn xây dựng nó. Hệ thống thương mại điện tử, chúng ta có thể vừa đặc tảvừa xây dựng chương trình một cách đồng thời.

6CNPM/NN

Qui trQui trìình phnh pháát trit triểển phn phầần mn mềềm lm làà nnềền tn tảảng chong cho

Management Control of software projectsEstablishes the Control in which technical methods are appliedWork Products (models, documents, data, reports, forms etc.) are ProducedMilestones are establishedQuality is ensured andChange is properly managed

7CNPM/NN

CCáác tc tầầng trong công nghng trong công nghệệ phphầần mn mềềmm

Software Engineering

a a ““qualityquality”” focusfocus

process modelprocess model

methodsmethods

toolstools

8CNPM/NN

Khung tiKhung tiếến trn trìình (Process framework)nh (Process framework)

Process frameworkProcess frameworkFramework activitiesFramework activities

work taskswork taskswork productswork productsmilestones & deliverablesmilestones & deliverablesQA checkpointsQA checkpoints

Umbrella ActivitiesUmbrella Activities

9CNPM/NN

Khung tiKhung tiếến trn trììnhnh

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

CommunicationPlanningModeling

Analysis of requirementsDesign

ConstructionCode generationTesting

Deployment

10CNPM/NN

Framework activitiesFramework activities

work taskswork taskswork productswork productsmilestones & deliverablesmilestones & deliverablesQA checkpointsQA checkpoints

11CNPM/NN

HoHoạạt đt độộng hng hỗỗ trtrợợ (umbrella)(umbrella)Quản lý dự ánKiểm tra kỹ thuật hình thứcBảo đảm chất lượng phần mềmQuản lý cấu hình phần mềmTạo và chuẩn bị những sản phẩm công tácQuản lý sử dụng lạiĐo lườngQuản lý rủi ro

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

12CNPM/NN

HoHoạạt đt độộng hng hỗỗ trtrợợ (umbrella)(umbrella)

13CNPM/NN

2.1 Mô h2.1 Mô hìình phnh pháát trit triểển phn phầần mn mềềm m (Process Model) (Process Model)

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ềmTrong qui trình cần

Process needs to be controlledProgress needs to be monitored (giám sát)People and resources (tài nguyên) need to be allocated (chỉ định) at the right point in time

14CNPM/NN

LLựựa cha chọọn mô hn mô hìình phnh pháát trit triểểnn

The nature of the project and applicationRisk perception(nhận thức)Understanding and application skill of the software engineerDomain knowledge of the software developer

The methods and tools to be usedThe Controls and deliverables that are required.

15CNPM/NN

Năm mô hNăm mô hìình phnh pháát trit triểển phn phầần mn mềềmm

Mô hình Thác nước (Waterfall)Mô hình Tiến trình tăng dần (Incremental Process)

Mô hình tăng dần (Incremental)Mô hình RAD (Rapid Application Development)

Mô hình qui trình tiến hóa (Evolutionary Process)Mô hình Bản mẫu (Prototyping)Mô hình Xoắn ốc (Spiral)

16CNPM/NN

WhatWhat’’s s Wrong?Wrong?

Inputs Outputs

Không thể biết khi nào hoàn thành do không cóphân tích thiết kế chính thứcKhông có cách đánh giá yêu cầu và tiêu chuẩn chất lượng có được thỏa mãn hay không

17CNPM/NN

Mô hMô hìình thnh tháác nưc nướớc (Waterfall)c (Waterfall)

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 (framework) gồm những giai đoạn (phase) phát triển phần mềm dựa vào yêu cầu đã xác định và được tư liệu trong giai đoạn đầu

18CNPM/NN

Mô hMô hìình thnh tháác nưc nướớcc

Communicat ion Planning

ModelingConstruct ion

Deployment analysis design code

test

project init iat ion requirement gat hering estimating

scheduling tracking

delivery support f eedback

19CNPM/NN

Mô hMô hìình thnh tháác nưc nướớcc

Tiến triển theo trình tự các bướcGiai đoạn kế tiếp sẽ bắt đầu khi giai đoạn hiện hành được hoàn tấtMỗi giai đoạn xác định tiêu chuẩn vào và raViệ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ứcThỏa một kiểm tra xác định một sự đồng thuận giữa những thành viên dự án và khách hàng

20CNPM/NN

Mô hMô hìình thnh tháác nưc nướớc c -- ưu đi ưu điểểmmMô hình được này được những người dùng cuối và những khách hàng biết rõNó giải quyết những vấn đề phức tạp theo một cách có trình tự, thực hiện tốt cho những dự án được hiểu rõ nhưng vẫn còn phức tạpMô hình dễ thực hiện khi việc phát triển theo trình tựNó cung cấp một cấu trúc cho những nhân viên thiếu kinh nghiệm hay yếu về kỹ thuậtNó làm việc tốt 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íNó xác định những thủ tục kiểm soát chất lượng. Mỗi sản phẩm chuyển giao được kiểm tra khi nó được hoàn tấtDễ dàng lần vết diễn tiến của dự án bằng cách dùng biểu đồGantt

21CNPM/NN

Mô hMô hìình thnh tháác nưc nướớc c –– như nhượợc đic điểểmm

Phải đặc tả tất cả yêu cầu một cách chính xác và đầy đủ ngay từ ban đầuMô hình có tính tuần tự theo 5 giai đoạn nên khi muốn quay lui 2 hay nhiều giai đoạn để làm đúng một vấn đề hay một kết quả thiếu sót thì sẽ tốn kém nhiều chi phí và thời gianNó không xử lý vấn đề thực tế chứa đựng việc lặp đi lặp lại giữa các giai đoạnKhó đánh giá tình trạng của dự ánNhững vấn đề tích hợp được thực hiện ở giai đoạn cuối nên quá trễ khi gặp những vấn đề về tích hợpCần phải quản lý và kiểm soát chặt chẽ (do không quay lui)Khách hàng chí có thể thấy hệ thống ở giai đoạn cuốiTồn tại “delay” trong nhóm làm việc

22CNPM/NN

Khi nKhi nàào so sửử ddụụng mô hng mô hìình thnh tháác nưc nướớcc

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ể dùng thiết kế đã có có thể sử dụng mô hình thác nướcTạo một phiên bản mới của một sản phẩm tồn tại mànhững biến đổi (change) được xác định và điều khiển

23CNPM/NN

Mô hMô hìình tăng dnh tăng dầần (Incremental)n (Incremental)

This model combines elements of the linear sequential model with the iterative philosophy of prototypingInitial Software requirements are reasonably (hợp lý) well definedCompelling (thuyết phục) need to provide a limited set of software functionality to users quickly and then refine and expand on that functionality in later software releases

24CNPM/NN

Mô hMô hìình tăng dnh tăng dầầnn

25CNPM/NN

Mô hMô hìình tăng dnh tăng dầầnn

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 caoPhâ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ốngVò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ẩmMỗi chức năng cũng như hệ thống tích hợp phải được đánh giá theo từng giai đoạnCá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

26CNPM/NN

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

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 đươc hoàn thành phần cơ bản sớmSau 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, tách nhỏ công việc nhằm dễ quản lý hơn (The “divide and conquer” rule)Giảm rủi ro trong việc thất bại của toàn bộ dự án, rủi ro trải ra nhiều phần nhỏSử dụng nhân viên giới hạn, họ có thể thực hiện nhưng công việc tương tự ơ các vòng

27CNPM/NN

Mô hMô hìình tăng dnh tăng dầần n –– khuykhuyếết đit điểểmm

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ăngPhả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ềuViệc kiểm tra khó khăn hơn trên một hệ thống hoàn chỉnhKhá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

28CNPM/NN

Mô hMô hìình gia tăng nh gia tăng –– khi nkhi nàào so sửử ddụụngng

Khi tất cả yêu cầu được hiểu rõ nhưng mong muốn có sự tiến hóa dần của sản phẩmKhi 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

29CNPM/NN

Mô hMô hìình RAD (Rapid Application Development)nh RAD (Rapid Application Development)

Mô hình này được đưa ra bởi IBM vào những năm 1980, qua sách của James MartinRapid Application Development một mô hình tiến trình phần mềm gia tăng mà nhấn mạnh tới chu kỳ phát triển ngắn (60-90 ngày)Mô hình RAD là sự ráp nối tốc độ cao của mô hình Thác nước, xây dựng dựa vào thành phần và sử dụng các ứng dụng tạo mã tự động

30CNPM/NN

Mô hMô hìình RADnh RAD

Communicat ion

Planning

Mode lingbusiness modeling dat a modeling process modeling

Const ruct ioncomponent reuse aut omat ic code generat ion t est ing

De ployme nt

6 0 - 9 0 days

Team # 1

Modelingbusiness m odel ing dat a m odel ing process m odel ing

Co nst ruct io ncom ponent reuse aut om at ic code generat ion t est ing

M o d e lin gbusiness m odeling data m odeling process m odeling

Co n st ru ct io ncom ponent reuse autom at ic code generat ion test ing

Team # 2

Team # n

int egrat ion delivery feedback

31CNPM/NN

TTạạo mô ho mô hìình (Modeling)nh (Modeling)Business Modeling:

What information drives the business process?What information is generated?Who generates it?Where does the information goes?Who processes it?

Data Modeling: The characteristics of each object are identified and the relationships between these objects defined.Process Modeling: Processing descriptions are created for adding, modifying, deleting, or retrieving a data object

32CNPM/NN

Xây dXây dựựng (construction)ng (construction)

Application generation: kỹ thuật thế hệ thứ 4, thành phần (component) và công cụ tự động (tool)Testing and turnover: chú ý tới kiểm thử giao tiếp (interface)

33CNPM/NN

Mô hMô hìình RAD nh RAD –– đi điểểm mm mạạnhnh

Thời gian phát triển giảm nhờ dùng công cụChỉ cần ít người phát triển hơn, do họ thân thiện với vấn đềNhanh chóng cho phép hình dung ra sản phẩmDùng hiệu quả các framework và công cụ đóng gói (off-the-shelf tools and frameworks)Giảm rủi ro nhờ có sự tham gia của khách hàng

34CNPM/NN

Mô hMô hìình RAD nh RAD –– đi điểểm ym yếếuu

Thiếu sự tham gia tốt của người dùng trong chu kỳ sống của phần mềmNgườ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à thời gian phát triển nhanhHệ thống có khả năng phân tách moduleCần có đáp ứng về thành phần sử dụng lạiNgười phát triển và khách hàng phải nỗ lựcNgười quản lý phải làm việc tận tụy với nhóm phát triển và khách hàng để nhanh chóng đạt được các thỏa thuận

35CNPM/NN

Mô hMô hìình RAD nh RAD –– khi nkhi nàào so sửử ddụụngng

Hệ thống dễ dàng phân chia module và có thể mởrộngHệ thống mà những yêu cầu được biết rõ và hợp lý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, dưới 60 ngàyNhững thành phần sử dụng lại có sẵn trong kho phần mềmNhững hệ thống nhỏ, những hệ thống không có tính nghiêm ngặt (critical)…

36CNPM/NN

Mô hMô hìình tnh tạạo bo bảản mn mẫẫu (Prototyping)u (Prototyping)Bernard Boar: “a strategy for performing requirements determination wherein user needs are extracted, presented and developed by building a working model of the ultimate system - quickly and in context”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ẫu thử ban đầu có thể loại bỏ, mẫu thử chỉ có tác dụng để làm sáng tỏ yêu cầu của người sử dụng.

37CNPM/NN

PROTOTYPE MODELPROTOTYPE MODEL

listento

customerbuild/revise

mock-up

customertest-drivesmock-up

Prototyping

38CNPM/NN

PRO

TOTY

PE M

OD

ELPR

OTO

TYPE

MO

DEL

Requirements

Quick Design

Implement

Customer Evaluation

Design

Implementation & Unit Testing

Integration and System Testing

Operation & Maintenance

Refinements of Requirement as per suggestions

Not accepted by customer

Accepted by Customer

39CNPM/NN

Mô hMô hìình tnh tạạo bo bảản mn mẫẫu u –– ưu đi ưu điểểmm

Khách hàng tương tác sớm với hệ thốngKhách hàng và người phát triển làm việc với nhauNgười phát triển có thể xác định chính xác được yêu cầuCó 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 cho phép thiết kế và phát triển mếm dẽo qua nhiều vòng lặp

40CNPM/NN

NhưNhượợc đic điểểmmLà phương pháp Quick-and-dirtyNhững nguyên mẫu Quick-and-dirty thường gây ra khó khăn trong việc thiếu tư liệu hay tư liệu không phùhợpHệ 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 không tốt. Hệ thống sẽcó chất lượng thấp và khó bảo trì sau một thời gian dàiKhá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 prototype đầu tiênNgười phát triển có thể rơi vào chu kỳ code-and-fix

41CNPM/NN

Mô hMô hìình bnh bảản mn mẫẫu u –– khi nkhi nàào so sửử ddụụngng

Khi yêu cầu không được biết rõ, Khi yêu cầu không ổn định, việc thông tin không đáp ứng tốtMột vài phần của hệ thống lớn có thể được tạo theo mô hình bản mẫuKhi 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 là tối ưuTrên những hệ thống dựa vào phần mềm kỹ thuật cao mà những yêu cầu không được xác định rõPhù hợp với những hệ thống

user-interface intensive systemsinteractive online systems, first-of-a-kind products decision support systems…

42CNPM/NN

Mô hMô hìình xonh xoắắn n ốốc (Spiral Model)c (Spiral Model)

Đề nghị bởi Berry Boehm, 1988Qui trình được biểu diễn theo hình xoắn ốcMỗi vòng lặp (hay chu kỳ) trong hình xoắn ốc biểu diễn một giai đoạn trong qui trình. Vòng trong cùng tập trung vào tính khả thi của hệ thống, vòng kế tiếp xác định yêu cầu hệ thống, rồi vòng thiết kế…

43CNPM/NN

Spiral model of the software processSpiral model of the software process

Riskanalys is

Riskanalys is

Riskanalys is

Riskanalysis Proto-

type 1Prototyp e

2Prototype

3Opera-tionalprotoype

Concept o fOperation

Simulations, models, bench marks

S/Wrequirements

Requirementvalid ation

DesignV&V

Prod uctdesign Detailed

design

CodeUni t t es 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

44CNPM/NN

Mô hMô hìình xonh xoắắn n ốốcc

Mỗi chu kỳ có 4 tầng, mỗi tầng chiếm một cung ¼Đường kính và góc biểu diễn chi phí tích lũy và tiến triển của qui trìnhXác định những vấn đề rắc rối và phân loại rủi ro nhằm loại trừ những rủi ro cao trước khi nó đe dọa

45CNPM/NN

Mô hMô hìình xonh xoắắn n ốốcc

Mỗi giai đoạn được hoàn tất bằng một kiểm tra tất cảnhững sản phẩm có được bao gồm kế hoạch cho chu kỳ kế tiếpNhững kế hoạch này phải bao gồm những phần nhỏ, chi tiết hơn cho nhóm và những cá nhânMô 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

46CNPM/NN

Q1. determine Objectives, alternatives and constraintsQ1. determine Objectives, alternatives and constraints

Objectives: performance, functionality, ability to accommodate change, hardware/software interface, and critical success factorsAlternatives: xác định những sự lựa chọn (cost, schedule, interface, environmental limitations, etc.)

47CNPM/NN

Q2. Evaluate alternatives, identify and resolve risksQ2. Evaluate alternatives, identify and resolve risks

Đánh giá những lựa chọn và các ràng buộcNhận diện và giải quyết rủi ro: những rủi ro về quản lý, chiến lược lợi nhuận, đánh giá những rủi ro còn lại và quyết định dừng hay tiếp tục…

48CNPM/NN

Q3. Develop Next Level ProductQ3. Develop Next Level Product

Creation of a designReview of DesignDevelopment of codeInspection of CodeTesting and packaging of the product.

49CNPM/NN

Q4. Plan Next PhaseQ4. Plan Next PhaseProject PlanConfiguration Management planTest plan Installation plan

50CNPM/NN

Mô hMô hìình xonh xoắắn n ốốc c –– ưu đi ưu điểểmm

Mô hình cho phép tạo bản mẫu sớmNó cho những chỉ báo sớm những rủi ro không thểkhắc phục với phí tổn không caoNó cho phép người dùng tham gia vào các giai đoạnNó tách nhỏ những nỗ lực phát triển, ưu tiên cho những chức năng quan trọng thực hiện trước, với sựthuận lợi của việc phát hành tăng thêm, cho phép chọn lựa sự tiếp tục của dự án

51CNPM/NN

Mô hMô hìình xonh xoắắn n ốốc c –– ưu đi ưu điểểmm

Phản hồi từ người dùng sớm và liên tụcQua mỗi vòng lặp, việc đánh giá giúp cải thiện nhiều vấn đề của dự ánNó có thể cải thiện năng suất nhờ vào việc sử dụng

lạiTất cả tiền của dự án không cần phải phân phối trướcChi phí tích lũy (Cumulative) được đánh giá thường xuyên, giảm rủi ro về chi phí

52CNPM/NN

Mô hMô hìình xonh xoắắn n ốốc c –– như nhượợc đic điểểmm

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ụngCần kiến thức đánh giá rủi ro chuyên sâuKhó quản lý tiến trình và thuyết phục khách hàng

53CNPM/NN

Mô hMô hìình xonh xoắắn n ốốc c –– ssửử ddụụngng

Những dự án có rủi ro từ trung bình đến caoÁp dụng cho những dự án cần nhiều thời gian và cóthể gặp nhiều rủi roKhi cần tập trung vào những phần ổn định hay đã được biết rõ trong khi thu thập những kiến thức vềnhững phần khácKhi thực hiện dựa vào những kỹ thuật mới

54CNPM/NN

Mô hMô hìình xonh xoắắn n ốốc c (Spiral)(Spiral)Kết hợp giữa bản chất lặp của việc tạo bản mẫu (prototyping) và mô hình tuần tự Thác nướcLà mô hình tiến trình hướng rủi ro, luôn đánh giá rủi roÁp dụng qua toàn bộ đời sống phần mềmCác bước: phát triển khái niệm, phát triển sản phẩm, hoàn thiện sản phẩmQuá trình có thể tạm dừng, nhưng nó có thể bắt đầu tại điểm vào phùhợp (vd: hoàn thiện sản phẩm) Hướng cho việc phát triển những phần mềm lớn

55CNPM/NN

2.2 C2.2 Cáác vc vấấn đn đềề khkháác: dc: dùùng thng thàành phnh phầầnn

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í

56CNPM/NN

KKỹỹ thuthuậật tht thếế hhệệ ththứứ 444GT (fourth generation technique) là kỹ thuật dựa vào nhiều công cụphần mềm có đặc điểm : Dựa vào đặc tả phần mềm ở mức 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ụngChương trình tạo ra cồng kềnhViệ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

57CNPM/NN

Qui trQui trìình RUPnh 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

58CNPM/NN

CCáác vc vấấn đn đềề vvềề phphầần mn mềềmm

59CNPM/NN

Nguyên nhânNguyên nhân

60CNPM/NN

Qui trQui trìình RUP (Rational Unified Process)nh RUP (Rational Unified Process)

Giải quyếtPhát triển theo vòng lặpQuản lý yêu cầuSử dụng thành phầnMô hình trực quanThẩm định chất lượngKiểm soát thay đổi

61CNPM/NN

Qui trQui trìình RUPnh RUP

62CNPM/NN

CCáác giai đoc giai đoạạn RUPn RUP

63CNPM/NN

Unified Process (UP)Unified Process (UP)

s o f t w a r e in c r e m e n t

R e l e a s e

I n c e p t i o n

E l a b o r a t i o n

c o n s t r u c t i o n

t r a n s i t i o n

p r o d u c t i o n

64CNPM/NN

PhPháát trit triểển ln lặặpp

65CNPM/NN

UP Work ProductsUP Work ProductsIncept ion phase

Elaborat ion phase

Const ruct ion phase

Transit ion phase

Vision documentInit ial use-case modelInit ial project glossaryInit 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 archit ect ure

Descrip t ion.Execut able arch it ect ural

prot ot y pe.Preliminary design modelRev ised risk listProject p lan includ ing

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

Preliminary 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

66CNPM/NN

Qui trQui trìình RUPnh RUP

Giai đoạn 1 (Inception): khởi đầuPhạm vi dự án, yêu cầu người dùng và ràng buộcYêu cầu nghiệp vụ, rủi ro, kế hoạch dự án (phân công, chi phí)Thiết kế kiến trúc (chi phí, lịch, tài nguyên)Cấu hình môi trường làm việc, công cụ

67CNPM/NN

Qui trQui trìình RUPnh RUP

Giai đoạn 2 (Elaboration): Hình thànhTinh chỉnh tài liệuHoạch định những bước lặpKế hoạch phát triển: tiến trình, công cụ CASETinh chỉnh kiến trúc và chọn thành phần (component)

68CNPM/NN

Qui trQui trìình RUPnh RUP

Giai đoạn 3 (Construction): Xây dựngQuản lý tiến trình tạo sản phẩm: năng suất, đảm bảo chất lượngTạ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: phần mềm, người sửdụng, hỗ trợ…

69CNPM/NN

Qui trQui trìình RUPnh RUP

Giai đoạn 4 (Transition): Chuyển giaoTạo sản phẩm xuất xưởngKiểm tra sản phẩm, thu thập phản hồi

70CNPM/NN

PHƯƠNG PHPHƯƠNG PHÁÁP PHP PHÁÁT TRIT TRIỂỂN PHN PHẦẦN MN MỀỀM LINH HOM LINH HOẠẠTT

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.

71CNPM/NN

Phương phPhương phááp Agile: Scrump Agile: ScrumSchwaber và BeedleĐặc trưng

Chia công việc thành những packetTest và tư liệu khi sản phẩm đang được xây dựngPhần công việc trong “backlog” được chia xuất hiện trong “sprint”Gặp gỡ ngắn “demo” được chuyển tới khách hàng

72CNPM/NN

ScrumScrum

73CNPM/NN

Extreme Programming (XP)Extreme Programming (XP)

The most widely used agile process, originally proposed by Kent BeckXP Planning

Begins with the creation of “user stories”Agile team assesses each story and assigns a costStories are grouped to for a deliverable incrementA commitment is made on delivery dateAfter the first increment “project velocity” is used to help define subsequent delivery dates for other increments

74CNPM/NN

Extreme Extreme ProgrammingProgrammingXP Design

Follows the KIS principle (keep it simple)Encourage the use of CRC cards (see Chapter 8)For difficult design problems, suggests the creation of “spike solutions” - a design prototypeEncourages “refactoring” - an iterative refinement of the internal program design

XP CodingRecommends the construction of a unit test for a store beforecoding commencesEncourages “pair programming”

XP TestingAll unit tests are executed daily“Acceptance tests” are defined by the customer and excuted to assess customer visible functionality

75CNPM/NN

Extreme Extreme ProgrammingProgramming

unit t est cont inuous integrat ion

acceptance test ing

pair programming

Release

user stories values acceptance test crit eria it erat ion plan

simple design CRC cards

spike solut ions protot ypes

refactoring

software incrementproject velocity computed