1. Trang chủ
  2. » Giáo Dục - Đào Tạo

ĐHBK HCM KHOA CNTT-BÀI GIẢNG CÔNG NGHỆ PHẦN MỀM Software Engineering

259 357 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 259
Dung lượng 2,13 MB

Nội dung

•• Nhu Nhu cầu cầu sử sử dụng dụng phần phần mềm mềm là là rất rất lớn lớn – Nhiều ngành nghề cần dùng phần mềm máy tính – Mỗi ngành nghề cần nhiều loại phần mềm khác nhau – Mội loại phầ

Trang 1

Bài Bài Giả Giả Bài

Bài Giảng Giảng

Công

Công Nghệ Nghệ Phần Phần Mềm Mềm

Software Engineering

Trang 2

Giáo viên & Giao tiếp giảng dạy p g p g g ạy g ạy

ThS Nguyễn Cao Trí – caotri@hcmut.edu.vn http://www.cse.hcmut.edu.vn/~caotri

Room 109 A5 – Trung tâm Kỹ thuật Điện toán Tel: 8647256 – 5370 Mobile: 091 391 6290 Hobbies: Automation , Flying Model

http://www.rc-easy.net

•• Tài Tài liệu liệu download download trên trên website website file file:: TailieudientuCNPM PrintableVersion

TailieudientuCNPM PrintableVersion ppt ppt

•• Học Học thế thế nào? nào? Î Î Hỏi Hỏi ngay ngay trên trên lớp lớp

•• Học Học thế thế nào? nào? Î Î Hỏi Hỏi ngay ngay trên trên lớp lớp

•• Bảng Bảng mã mã sử sử dụng dụng là là Unicode Unicode dựng dựng sẵn sẵn

•• Các Các bài bài tập tập nộp nộp bằng bằng email, email, dạng dạng file file ** ZIP ZIP

•• Email Email phải phải ghi ghi rõ rõ nội nội dung dung file file đính đính kèm kèm là là gì gì bằng bằng tiếng tiếng Việt Việt

•• Email Email phải phải ghi ghi rõ rõ nội nội dung dung file file đính đính kèm kèm là là gì gì bằng bằng tiếng tiếng Việt Việt

Trang 3

Giới thiệu môn học ệ ệ ọ ọ

•• Nội Nội dung dung môn môn học học

– Giới thiệu các khái niệm cơ bản về công nghệ phần mềm

– Mục tiêu của sản xuất phần mềm và công nghệ phần mềm

– Các mô hình sản xuất phần mềm

– Quy trình sản xuất và quản lý dự án phần mềm

•• Tài Tài liệu liệu tham tham khảo khảo

– Introduction to Software Engineering – Ronald J Leach – CRC Press ess (Thư viện A2 MS: 9075802004) ( ư v ệ S: 907580 00 )

– Software Engineering – Ian Sommerville – Fifth edition (Thư viện A3 MS: 200032)

•• Hình Hình thức Hình Hình thức thức kiểm thức kiểm kiểm tra kiểm tra tra tra

– Giữa kỳ + Cuối kỳ + Bài tập

Trang 4

•• CôngCông nghiệpnghiệp phầnphần mềmmềm && cáccác côngcông nghiệpnghiệp kháckhác

•• CôngCông nghiệpnghiệp phầnphần mềmmềm && cáccác côngcông nghiệpnghiệp kháckhác

– Giống

– Khác

Có hayhay khôngkhông (những)(những) côngcông nghệnghệ chocho sảnsản xuấtxuất phầnphần

•• CóCó hayhay khôngkhông (những)(những) côngcông nghệnghệ chocho sảnsản xuấtxuất phầnphầnmềm?

•• CóCó cầncần thiếtthiết phảiphải cócó côngcông nghệnghệ chocho sảnsản xuấtxuất phầnphần mềmmềm

ôô ảả ấấ ầầ ềề àà ộộ ảả ấấ ặặ

không,

không, khikhi sảnsản xuấtxuất phầnphần mềmmềm làlà hoạthoạt độngđộng sảnsản xuấtxuất ““đặc biệt”” vìvì khôngkhông thểthể nóinói làmlàm mộtmột phầnphần mềmmềm nhưnhư sảnsản xuấtxuấtmột

một lonlon cocacoca

Trang 5

Đặc tính của sản phẩm phần mềm ặ ặ p p p p

•• SoftwareSoftware == ProgramProgram

•• SoftwareSoftware productSoftwareSoftware productproduct =product = ProgramProgram +ProgramProgram ++ Document+ DocumentDocument +Document ++ Support+ SupportSupportSupport

•• CácCác đặcđặc tínhtính quanquan trọngtrọng củacủa sảnsản phẩmphẩm phầnphần mềmmềm

– Maintainability: phần mềm có thể thay đổi thuận tiện theo yêu cầu của

người dùng

– Dependability: tính ổn định, bảo mật và an toàn của phần mềm Không

gây tổn hại về vật chất hay kinh thế cho hệ thống

gây tổn hại về vật chất hay kinh thế cho hệ thống.

– Efficiency: Sử dụng hiệu quả tài nguyên của hệ thống cho công việc

Trang 6

Software

•• PhầnPhần mềmmềm đượcđược viếtviết ngayngay từtừ khikhi cócó nhữngnhững máymáy tínhtính

ầầ êê ââ àà áá ềề ừừ ấấprogramable

programable đầuđầu tiêntiên ĐượcĐược quanquan tâmtâm vàvà phátphát triềntriền từtừ rấtrấtsớm

•• CóCó rấtrất nhiềunhiều phầnphần mềmmềm đãđã đượcđược viếtviết

•• CóCó rấtrất nhiềunhiều phầnphần mềmmềm đãđã đượcđược viếtviết

Î

Î Không Không thiếu thiếu phần phần mềm mềm

•• ThựcThực tếự tế việcviệc sảnệệ sản xuấtxuất phầnphần mềmpp mềm khôngkhông đápgg đáp ứngpp ứng kịpgg ịpkịp yêuịp yyyêucầu

cầu củacủa ngườingười sửsử dụngdụng::

Trang 7

Nguyên nhân khách quan g y g y q q

•• Số Số lượng lượng phần phần mềm mềm phải phải được được hiểu hiểu là là số số đầu/loại đầu/loại phần phần mềm mềm được được sử sử dụng

dụng cho cho từng từng mục mục tiêu tiêu ứng ứng dụng dụng

dụng

dụng cho cho từng từng mục mục tiêu tiêu ứng ứng dụng dụng

•• Nhu Nhu cầu cầu sử sử dụng dụng phần phần mềm mềm là là rất rất lớn lớn

– Nhiều ngành nghề cần dùng phần mềm máy tính

– Mỗi ngành nghề cần nhiều loại phần mềm khác nhau

– Mội loại phần mềm cần nhiều cấp độ khác nhau theo trình độ người dùng

•• Chất Chất lượng lượng phần phần mềm mềm cũng cũng chưa chưa đáp đáp ứng ứng tốt tốt hoàn hoàn toàn toàn người người sử sử dụng

dụng::

– Tính customize rất cao của sản phẩm phần mềm.

– Trình độ sử dụng khác nhau và điều kiện hạ tầng ứng dụng khác nhau

•• Nhu Nhu cầu cầu phần phần mềm mềm thường thường rất rất cấp cấp bách bách

Trang 8

Nguyên nhân chủ quan g y g y q q

•• TínhTính chuyênchuyên nghiệpnghiệp trongtrong sảnsản xuấtxuất phầnphần mềmmềm chưachưa caocao

Các

Các dữ dữ liệu liệu quan quan sát sát được được

– Cứ 6 đề án triển khai thì có 2 bị huỷ bỏ

Trung bình thời gian thực hiện thực tế bị kéo dài 50 % (cá biệt

– Trung bình thời gian thực hiện thực tế bị kéo dài 50 % (cá biệt 300%)

200-– Các đề án lớn dễ thất bại

3/4 á hệ thố lớ ó lỗi khi th thi

– 3/4 các hệ thống lớn có lỗi khi thực thi

– Quá trình phân tích yêu cầu (5 % công sức): để lại 55 % lỗi, có 18 % phát hiện được

Trang 9

Nguyên nhân chủ quan (tt) g y g y q q ( ) ( )

– Quy trình phát triển phần mềm chưa được thống nhất

Phải iết l i / ỗi khi ó th đổi ề ô ữ h/ h ặ /

– Phải viết lại s/w mỗi khi có sự thay đổi về ngôn ngữ, h/w hoặc o/s

– Chưa đạt được 1 chuẩn cho việc đo lường hiệu suất và sản phẩm

– Độ phức tạp của phần mềm quá cao đối với 1 “kiến trúc sư”

– Kỹ thuật đặc tả để lại sự nhập nhằng trong các yêu cầu phần mềm

– Làm việc nhóm không đúng kỷ luật gây ra các lỗi

Trang 10

hiệu quảệệ qqquả vàvà tintin cậycậy trênậy trên cáccác máymáy tínhyy tính

•• Công Công nghệ nghệ phần phần mềm mềm làlà mộtmột quyquy trìnhtrình cócó hệhệ thốngthốngđược

được sửsử dụngdụng trongtrong quáquá trìnhtrình phânphân tích,tích, thiếtthiết kế,kế, hiệnhiệnthực,

thực, kiểmkiểm tratra vàvà bảobảo trìtrì đểđể bảobảo đảmđảm cáccác sảnsản phẩmphẩm phầnphầnmềm

mềm đượcđược sảnsản xuấtxuất vàvà hoạthoạt độngđộng:: hiệuhiệu quả,quả, tintin cậy,cậy, hữuhữumềm

mềm đượcđược sảnsản xuấtxuất vàvà hoạthoạt độngđộng:: hiệuhiệu quả,quả, tintin cậy,cậy, hữuhữudụng,

dụng, nângnâng cấpcấp dễdễ dàngdàng (modificable),(modificable), khảkhả chuyểnchuyển(portable),

(portable), khảkhả kiểmkiểm tratra (testable),(testable), cộngcộng táctác đượcđược vớivới cáccáchệ

hệ thốngthống kháckhác (interoperable)(interoperable) vàvà vậnvận hànhhành đúngđúng (correct)(correct)hệ

hệ thốngthống kháckhác (interoperable)(interoperable) vàvà vậnvận hànhhành đúngđúng (correct)(correct)

Trang 11

Cụ thể ụ

•• Efficiency Efficiency:: Phần Phần mềm mềm được được sản sản xuất xuất trong trong thời thời gian gian và và điều điều kiện kiện vừa vừa phải phải Phần Phần mềm

mềm vận vận hành hành đúng đúng mức mức độ độ yêu yêu cầu cầu về về công công việc việc và và thời thời gian gian

•• Reliablity Reliablity:: Phần Phần mềm mềm vận vận hành hành ổn ổn định định và và tương tương tác tác được được với với các các hệ hệ thống thống ứng ứng dụng

•• Usability Usability:: Phần Phần mềm mềm có có thể thể dùng dùng được được bởi bởi người người sử sử dụng dụng và và với với môi môi trường trường mà mà

•• Usability Usability:: Phần Phần mềm mềm có có thể thể dùng dùng được được bởi bởi người người sử sử dụng dụng và và với với môi môi trường trường mà mà người

người sử sử dụng dụng đang đang có có Chú Chú ýý tới tới giao giao diện, diện, điều điều kiện kiện hệ hệ thống, thống,… …

•• Modifiability Modifiability:: Phần Phần mềm mềm có có thể thể được được thay thay đổi đổi dể dể dàng, dàng, nhanh nhanh chóng chóng khi khi yêu yêu cầu cầu của

của người người sử sử dụng dụng thay thay đổi đổi

của

của người người sử sử dụng dụng thay thay đổi đổi

•• Portability Portability:: Phần Phần mềm mềm có có thể thể chuyển chuyển đổi đổi dễ dễ dàng dàng sang sang các các hệ hệ thống thống khác khác mà mà không không cần

cần phải phải điều điều chỉnh chỉnh lớn lớn Chỉ Chỉ cần cần recompile recompile nều nều cần cần thiết thiết là là tốt tốt nhất nhất

Testability

Testability:: Phầ ề ề ó ó thể thể dd00ượ ượ kiể kiể tt dễ dễ dà dà Tốt Tốt hất hất là là đượ đượ d l d l hó hó

•• Testability Testability:: Phần Phần mềmcó mềmcó thể thể dd00ược ược kiểm kiểm tra tra dễ dễ dàng dàng Tốt Tốt nhất nhất là là được được modul modul hóa hóa

Trang 12

Cụ thể (tt) ụ ụ ( ) ( )

•• Maintainability Maintainability:: thiết thiết kế kế của của phần phần mềm mềm có có thể thể được được hiểu hiểu dễ dễ dàng dàng cũng cũng như như chuyển chuyển

ii th ậ th ậ tiệ tiệ hh ười ười khá khá tt áá t ì h t ì h điề điề hỉ h ââ ấấ hh th đổi đổi th th

giao

giao thuận thuận tiện tiện cho cho người người khác khác trong trong quá quá trình trình điều điều chỉnh, chỉnh, nâng nâng cấp cấp hay hay thay thay đổi đổi theo theo yêu

yêu cầu cầu

•• Interoperability Interoperability:: Phần Phần mềm mềm vận vận hành hành ổn ổn định định và và đúng đúng như như mong mong đợi đợi Trên Trên hệ hệ thống

thống nhiều nhiều người người dùng dùng (multi (multi users) users) phần phần mềm mềm vẫn vẫn hoạt hoạt động động được được với với các các vận vận hành hành thống

thống nhiều nhiều người người dùng dùng (multi (multi users) users) phần phần mềm mềm vẫn vẫn hoạt hoạt động động được được với với các các vận vận hành hành khác

mục tiêu tiêu ứng ứng dụng dụng của của người người dùng dùng

•• CácCác yêuyêu cầucầu kháckhác::

Đúng tiến độ

– Đúng tiến độ

– Sử dụng hợp lý nguồn nhân lực phát triển

– Chi phí phát triển thấp nhất

Trang 13

Nội dung công việc của Software Engineering ộ ộ g g g ệ g ệ g g g g

Công việc của software engineering bao gồm:

•• PhânPhân tíchtích hệhệ thống/vấnthống/vấn đềđề

•• XácXác địnhđịnh cáccác yêuyêu cầucầu •• Quản•• HuấnQuản lýHuấn luyệnluyệnlý chấtchất lượnglượng

•• ThiếtThiết kếkế phầnphần mềmmềm

•• ViếtViết phầnphần mềmmềm (coding)(coding)

•• KiểmKiểm tratra vàvà tíchtích hợphợp hệhệ

Trang 14

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

•• CNPMCNPM làlà cáccác quyquy trìnhtrình đúngđúng kỷkỷ luậtluật vàvà cócó địnhđịnh lượnglượng đượcđược

áá áá ểể àà ảả ìì áá ệệáp

áp dụngdụng chocho sựsự phátphát triển,triển, thựcthực thithi vàvà bảobảo trìtrì cáccác hệhệthống

thống thiênthiên vềvề phầnphần mềmmềm

•• TậpTập trungtrung vàovào quyquy trìnhtrình sựsự đođo lườnglường sảnsản phẩmphẩm tínhtính

•• TậpTập trungtrung vàovào quyquy trìnhtrình,, sựsự đođo lườnglường,, sảnsản phẩmphẩm,, tínhtínhđúng

đúng thờithời giangian vàvà chấtchất lượnglượng

Trang 15

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

Các

Các côngcông đoạnđoạn chínhchính tổngtổng quátquát baobao gồmgồm 44 giaigiai đoạnđoạn

•• GiaiGiai đoạnđoạn đặcđặc tảtả:: xácxác địnhđịnh cáccác tínhtính năngnăng vàvà điềuđiều kiệnkiện hoạthoạtđộng

động củacủa hệhệ thốngthống (thu(thu thậpthập yêuyêu cầucầu vàvà phânphân tích)tích)

động

động củacủa hệhệ thốngthống (thu(thu thậpthập yêuyêu cầucầu vàvà phânphân tích)tích)

•• GiaiGiai đoạnđoạn phátphát triểntriển:: ThiếtThiết kếkế phầnphần mềmmềm (software(softwaredesign),

design), viếtg ), viết codecode (code(code generation(( generationgg

•• GiaiGiai đoạnđoạn kiểmkiểm tratra:: kiểmkiểm tratra phầnphần mềmmềm (software(software testing),testing),kiểm

kiểm tratra tínhtính hợphợp lýlý củacủa phầnphần mềmmềm

đđ bả ìì ửử lỗlỗ (( )) hh đổ ôô ờờ

•• GiaiGiai đoạnđoạn bảobảo trìtrì:: SửaSửa lỗilỗi (correction),(correction), thaythay đổiđổi môimôi trườngtrường

Trang 16

sản xuấtxuất kháckhác nhaunhau

•• MôMô hìnhhình tuầntuần tựtự tuyếntuyến tínhtính waterfallwaterfall

•• MôMô hìnhhình PrototypingPrototyping EvolutionaryEvolutionary DevelopmentDevelopment

•• MôMô hìnhhình PrototypingPrototyping EvolutionaryEvolutionary DevelopmentDevelopment

•• MôMô hìnhhình xoắnxoắn ốcốc –– Boehm’sBoehm’s SpiralSpiral ModelModel

•• MôMô hìnhMôMô hìnhhình RADhình RADRAD –– RapidRAD RapidRapid ApplicationRapid ApplicationApplication DevelopmentApplication DevelopmentDevelopmentDevelopment

MÔ HÌNH NÀO TỐT HƠN

Trang 17

Mô hình WaterFall

•• Mô Mô hình hình phát phát triển triển phần phần mềm mềm đầu đầu tiên tiên

•• Các Các công công việc việc tiếp tiếp nối nối nhau nhau một một cách cách tuần tuần tự tự

•• Đặt Đặt nền nền móng móng cho cho các các phương phương pháp pháp phân phân tích, tích, thiết thiết kế, kế, kiểm kiểm tra

Tí h hợ à kiể Tích hợp và kiểm tra tổng thể

Trang 18

lại chứchứ khôngkhông phảiphải tuầntuần tựtự

•• CácCác bướcbước thựcthực chấtự chất khôngkhông táchgg tách biệtbiệt hoànệệ hoàn toàntoàn màmà cócóchồng

chồng lấnlấn vàvà thamtham khảokhảo lạilại

•• BắtBắt buộcbuộc kháchkhách hànghàng đặcđặc tảtả tấttất cảcả yêuyêu cầucầu mộtmột cáchcách chínhchínhxác

xác vàvà đầyđầy đủđủ ngayngay từtừ banban đầuđầu

xác

xác vàvà đầyđầy đủđủ ngayngay từtừ banban đầuđầu

•• KháchKhách hànghàng thườngthường phảiphải chờchờ đợiđợi rấtrất lâulâu đểđể thấythấy đượcđượcphiên

phiên bảnbản đầuđầu tiêntiên củacủa sảnsản phẩmphẩm

Trang 20

Mô Hình Prototype

•• Prototype Prototype như như là là một một cơ cơ chế chế để để nhận nhận diện diện chính chính xác xác yêu yêu cầu cầu của của khách

Khách hàng chưa hiểu rõ khả năng hổ trợ của hệ thống máy tính

– Khách hàng chưa hiểu rõ khả năng hổ trợ của hệ thống máy tính

•• Kích Kích thích thích sự sự thích thích thú thú của của người người dùng dùng với với dự dự án án

•• Prototype Prototype có có thể thể bị bị “throw “throw away” away” > > Lãng Lãng phí phí

•• Các Các process process không không được được phân phân định định rõ rõ ràng ràng

•• Hệ Hệ thống ệệ thống thông gg thông thường gg thường có gg có cấu cấu trúc trúc lỏng lỏng lẻo gg lẻo

•• Cần Cần có có những những kỹ kỹ năng năng đăc đăc biệt biệt trong trong quản quản lý lý và và phát phát triển triển

•• Khách Khách hàng hàng hối hối thúc thúc nhà nhà phát phát triển triển hoàn hoàn thành thành sản sản phẩm phẩm một một khi khi thấy

thấy được được các các prototype prototype đầu đầu tiên tiên

thấy

thấy được được các các prototype prototype đầu đầu tiên tiên

Trang 21

thực hiệhiệ prototypeprototype

•• CầnCần sựsự cấpự cấp báchpp bách vềvề thờithời giangian triểngg triển khaikhai ngắnngắn Hệgg Hệ thốngệệ thốngggcần

cần đượcđược đưađưa vàovào ứngứng dụngdụng từngtừng phầnphần trongtrong khoảngkhoảng thờithờigian

gian nhấtnhất địnhđịnh

Trong

Trong trườngtrường hợphợp nhữngnhững hệhệ thốngthống màmà việcviệc đặcđặc tảtả cáccác yêuyêu

•• TrongTrong trườngtrường hợphợp nhữngnhững hệhệ thốngthống màmà việcviệc đặcđặc tảtả cáccác yêuyêu

Trang 22

Xác định công việc

•• ĐượcĐược thựcthực hiệnhiện theotheo mộtmột chuỗichuỗi lặplặp kiểukiểu xoắnxoắn ốc,ốc, mỗimỗi lầnlầnlặp

lặp cảicải thiệnthiện sảnsản phẩmphẩm

•• CóCó phươngphương pháppháp đánhđánh giágiá rủirủi roro

•• CóCó phươngphương pháppháp đánhđánh giágiá rủirủi roro

•• CóCó thểthể ápáp dụngdụng prototypeprototype

•• MỗiMỗi lầnMỗiMỗi lầnlần lặplần lặplặp đượclặp đượcđược cảiđược cảicải thiệncải thiệnthiện chothiện chocho thíchcho thíchthích nghithích nghinghi vớinghi vớivới bảnvới bảnbản chấtbản chấtchất củachất củacủacủa

Trang 24

Các tiêu chuẩn dùng trong CNpPM g g g g p p

•• The The capability capability Maturity Maturity Model Model (CMM) (CMM) của của Software Software Engineering Engineering Institue Institue (SEI) (SEI) Đại

Đại học học Carnegie Carnegie Mellon Mellon

Đại

Đại học học Carnegie Carnegie Mellon Mellon

– Chú trọng đến tính hệ thống và khả năng quản trị của các công ty phần mềm

hơn là một quy trình (process) cụ thể.

•• The The process process Improvement Improvement Paradigm Paradigm (PIP) (PIP) của của Software Software Engineering Engineering

•• The The process process Improvement Improvement Paradigm Paradigm (PIP) (PIP) của của Software Software Engineering Engineering Laboratory

Laboratory (SEL) (SEL) –– NASA’s NASA’s Goddard Goddard Space Space Flight Flight Center Center

– Tương tự như CMM, chú trọng đến tính hệ thống và những hướng dẫn để

tăng cường tính năng của các quá trình quản lý.

•• Các Các chuẩn chuẩn khác khác của của Department Department of of Defense Defense

– MIL – STD 2167A ; MIL-STD 1574A ; MIL-STD 882C

•• The The electronic The The electronic electronic Industries electronic Industries Industries Association Industries Association Association (EIA) Association (EIA) (EIA) chuẩn (EIA) chuẩn chuẩn SEB chuẩn SEB SEB 66 AA SEB 66 AA

•• The The European European ESPRIT ESPRIT project project

•• International International Standards Standards Organisation Organisation ISO ISO 9001 9001

Trang 25

Chuẩn CMM

Optimized

•Continuous Improvement

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

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

Managed

(Level 5)

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

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

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

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

Trang 27

Tại sao cần Project management

† Phát triển phần mềm hiện đại làm theo teamworks

† Cần quản lý và kiểm soát được rủi ro (Risk) trong quá trình sản

† Phải bảo đảm tính chuyên nghiệp trong phát triển dự án phần

mềm:

„ Bảo đảm lịch trình của dự án

„ Điều phối và khai thác tối đa nguồn nhân lực hiện có

„ Điều phối và khai thác tối đa nguồn nhân lực hiện có

„ Bảo đảm chất lượng của sản phNm

Trang 28

SUB-Team trong software engineering

Team 5

Team 6

Team 4

là một nhóm người mà có thể

là 1 người

„ Các sub-team không nhất thiết

tồn tại suốt quá trình của một Project 3

Trang 29

† Delivery & Installation Team

Trang 30

Vai trò & nhiệm vụ các Sub-Team

• Phân tích chi phí (Cost analysis)

• Dự đoán lợi nhận (Estimate revenues)

Tiên liệ các khó khăn ề kỹ th ật

† Implementation Team

† Tesing & Intergration Team

† Training Team

† Delivery & Installation Team

• Tiên liệu các khó khăn về kỹ thuật

† Metrics Team

† Documentation Team

† System Administration Team

† Reuse & Reengineering Team

Prototype/Spiral model thì tính tương tác và feedback là rất quan trọng kể

cả với các nhóm khác.

Trang 31

† Delivery & Installation Team

và bảo đảm các tiến trình diển ra đúng tiến độ đã định

•Xây dựng các kế hoạch thực hiện

•Lập các time frame cho các tiến trình

† Delivery & Installation Team

† Metrics Team

† Documentation Team

Trang 32

•Nếu không có khách hàng, có thể tiếp xúc với các user tiềm năng

† Delivery & Installation Team

Nếu dự án được phát triển theo mô

† Metrics Team

† Documentation Team

† System Administration Team

† Reuse & Reengineering Team

Nếu dự án được phát triển theo mô hình tương tác cao như Prototype/Spiral model thì tính tương tác và feedback là rất quan trọng kể

Trang 33

System Design Team

Xây dựng thiết kế chi tiết của hệ thống sau khi các yêu cầu đã được xác định.

Nếu sử dụng mô hình Waterfall

† Implementation Team

† Tesing & Intergration Team

† Training Team

† Delivery & Installation Team

Nếu sử dụng mô hình Waterfall, nhóm này phải feedback cho nhóm Requirement những khó khăn nếu có.

Sau khi hoàn chỉnh thiết kế nhóm

† Delivery & Installation Team

Nếu dự án được phát triển theo

† Metrics Team

† Documentation Team Nếu dự án được phát triển theomô hình tương tác cao như

Trang 34

† Delivery & Installation Team

• Kiểm tra cấp Module Sau khi hoàn tất chương trình, nhóm này sẽ cộng tác với nhóm Tesing & Integration để kiểm tra

mô hình tương tác cao như Prototype/Spiral model thì tính

á à f db k là ấ

† Metrics Team

† Documentation Team

† System Administration Team

† Reuse & Reengineering Team

tương tác và feedback là rất quan trọng kể cả với các nhóm khác

Trang 35

Testing & Integration Team

Xây dựng thiết kế chi tiết của hệ thống sau khi các yêu cầu đã được xác định.

Nếu sử dụng mô hình Waterfall, nhóm này phải feedback cho nhóm Requirement

Nhóm này có thể tiếp nhận các module rời

† Delivery & Installation Team

† Maintenance Team

† Quality Assurance Team

† Metrics Team

ó ày có t ể t ếp ậ các odu e ờ rạc và kiểm tra sau đó tích hợp thành hệ thống hoàn chỉnh.

Nếu dự án được phát triển theo mô hình tương tác cao như Prototype/Spiral model thì tính tương tác và feedback là rất quan

† Metrics Team

† Documentation Team thì tính tương tác và feedback là rất quantrọng kể cả với các nhóm khác

Trang 36

† System Administration Team

† Reuse & Reengineering Team g g

Trang 37

† Metrics Team

† Documentation Team cho khách hàng và các hỗ trợkỹ thuật trong cài đặt vận hành

Trang 38

Bảo trì hệ thống sau khi chuyển

† Delivery & Installation Team

† Maintenance Team

† Quality Assurance Team

† Metrics Team

g giao và cài đặt

•Cập nhật sửa chữa

•Nâng cấp mở rộng Cộng tác chặt chẻ với nhóm

† Metrics Team

† Documentation Team

† System Administration Team

† Reuse & Reengineering Team

Cộng tác chặt chẻ với nhóm implementation để thực hiện việc maintenance

Trang 39

† Implementation Team

† Tesing & Intergration Team

† Training Team

† Delivery & Installation Team

chuẩn thực hiện của sản phẩm phần mềm

2 Cung cấp các cơ chế kiểm tra, kiểm soát nhằm đánh giá khả năng thỏa mãn các tiêu chuẩn

† Delivery & Installation Team

và không chia sẻ với khách hàng.

Các tiêu chuẩn có thể được công bố

† Metrics Team

† Documentation Team Các tiêu chuẩn có thể được công bốkhi cần thiết, vì vậy cần được lưu

Trang 40

† Delivery & Installation Team

† Maintenance Team

† Quality Assurance Team

† Metrics Team

maintenance

•Số dòng code được viết

•Thời gian thực hiện từng công việc

Nhóm này làm việc với hầu hết

† Metrics Team

† Documentation Team

† System Administration Team

† Reuse & Reengineering Team

Nhóm này làm việc với hầu hết các nhóm để cung cấp báo cáo về chất lượng, hiệu quả, đồng thời feedback cho các nhóm đó về hiệu quả công việc.

g g hiệu quả công việc.

Ngày đăng: 03/05/2015, 17:43

TỪ KHÓA LIÊN QUAN

w