Chapter01 v02

Bài Giảng
Giả
Công Nghệ Phần Mềm
Software Engineering
Giới thiệu
ệ môn học
ọ
• Nội dung môn 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 liệu tham khảo
– Introduction to Software Engineering – Ronald J. Leach – CRC Press (Thư
viện A2 MS: 9075802004)
– Software Engineering
g g – Ian Sommerville – Fifth edition ((Thư viện
ệ A3 MS:
200032)
– Software Engineering – A Practitioner’s Approach – Roger S. Pressman –
Fifth Edition
• Hình
ì thức
ứ kiểm
ể tra
– Giữa kỳ (20%) + Cuối kỳ (60%) + Bài tập (20%)
– Hình thức kiểm tra: trắc nghiệm khách quan – open book
– Đánh giá kêt quả: tương đối - phi tuyến
Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn
2
???????? & !!!!!!!!
• Công Nghiệp & Công Nghệ
• Công
ô Nghiệp
ệ Phần
ầ Mềm
ề (CNpPM)
CNpPM)
• Công Nghệ Phần Mềm (CNPM)
• Công nghiệp phần mềm & các công nghiệp khác
– Giống
– Khác
• Có hay không (những
những)) công nghệ cho sản xuất phần
mềm??
mềm
• Có cần thiết phải có công nghệ cho sản xuất phần mềm
không,
không
ô , khi sản
ả xuất
ấ phần
ầ mềmề là
à hoạt động
ộ sản ấ “đặc
ả xuất ặ
biệt” vì không thể nói làm một phần mềm như sản xuất
một lon coca.
coca.
Trường Đại Học Bách Khoa - Khoa Công Nghệ Thông Tin
Copyright 2004 – Th.S Nguyễn Cao Trí – caotri@hcmut.edu.vn
3
Đặc
ặ tính của sản p
phẩm p
phần mềm
• Software = Program
• Software product = Program + Document + Support
• Loại sản phẩm phần mềm
– Generic Product: là sản phNm đóng gói và bán rộng rãi trên thị trường.
– Bespoke
B k PProduct:
d t là sảnả phNm
hN được
đ phát
hát triển
t iể theo
th yêuê cầuầ đặc
đặ thù củaủ
từng khách hàng.
• Các đặc tính quan trọng của sản phẩm phần mềm
– M
Maintainability:
i i bili phần hầ mềmề có ó thể
hể thay
h đổi thuận
h ậ tiện
iệ theo
h 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 tế cho hệ thống.
thống
– Efficiency: Sử dụng hiệu quả tài nguyên của hệ thống cho công việc
– Usability: giao diện và phương thức phải phù hợp với người dùng đồng
thời đáp ứng đúng yêu cầu của người dùng
Trường Đại Học Bách Khoa - Khoa Công N ghệ Thông Tin
Copyright 2004 – Th.S N guyễn Cao Trí – caotri@hcmut.edu.vn
4
Software - Đủ hayy Thiếu?
• Phần mềm được viết ngay từ khi có những máy tính
programable đầu
ầ tiên.
tiên
ê . Được quan tâm
â vàà phát
á triền
ề từ ừ rất
ấ
sớm
• Có rất nhiều phần mềm đã được viết
Î Không thiếu phần mềm
• Thực
ự tế việcệ sản xuất pphần mềm khôngg đáp
p ứngg kịp
ịp yyêu
cầu của người sử dụng
dụng::
– Không đủ về số lượng
– Thiếu về chất lượng
– Không kịp về thời gian
Î Phần mềm không đáp ứng đủ cho người dùng
5
Nguyên
g y nhân khách quan
q
• Số lượng phần mềm phải được hiểu là số đầu/loại phần mềm được sử
dụng cho từng mục tiêu ứng dụng
dụng..
• Nhu cầu sử dụng phần mềm là rất 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 lượng phần mềm cũng chưa đáp ứng tốt hoàn toàn người 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 cầu phần mềm thường rất cấp bách
– Tầm nhìn và chiến lược chưa đầy đủ của người sử dụng
– Không có kế hoạch lâu dài
– Phải thay đổi theo từng đối tượng người dùng
6
Nguyên
g y nhân chủ quan
q
• Tính chuyên nghiệp trong sản xuất phần mềm chưa cao
Các dữ liệu quan sát đượ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 200-
300%)
– Các đề án lớn dễ thất bại
– 3/4 các
á hệ thống
thố lớn
lớ có ó lỗi khi thực
th 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
– Quá trình thiết
ế kếế (25 % công sức): đểể lại 30 % lỗi,
ỗ có 10 % phát
hiện được
– Quá trình mã hoá, kiểm tra và bảo trì: để lại 15 % lỗi, có 72 % phát
hiện được
7
Nguyên
g y nhân chủ quan
q ((tt))
Lý do của những hệ quả trên
– Phát triển
ể phần ầ mềm ề giống ố như một ộ “nghệ thuật”, chưa được xem
như một ngành khoa học
– Quy trình phát triển phần mềm chưa được thống nhất
– Phải viết
iết lại
l i s/w
/ mỗi ỗi khi cóó sự thay
th đổi vềề ngôn
ô ngữ,
ữ h/w
h/ hoặc
h ặ 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ạii 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
Î CẦN
Ầ PHẢI
Ả CÓ
Ó MỘT/NHIỀU
Ộ Ề CHUẨN
Ẩ QUY TRÌNH
Ì TRONG SẢN
Ả
XUẤT PHẦN MỀM ĐỂ NÂNG CAO TÍNH CHUYÊN NGHIỆP CỦA
NỀN SẢN XUẤT ĐẶC BIỆT NÀY
Î CẦN CÔNG NGHỆ CHO CÔNG NGHIỆP PHẦN MỀM
8
Định
ị nghĩa
g “Công
g nghệ
g ệpphần mềm”
• Công Nghệ Phần Mềm là sự thiết lập và sử dụng các
nguyên
ê tắc
ắ khoa học nhằm ằ mục đích í tạo ra các
á phần
ầ
mềm một cách kinh tế mà các phần mềm đó hoạt động
hiệu
ệ qquả và tin cậy
ậy trên các máyy tính
tính..
• Công nghệ phần mềm là một quy trình có hệ thống

được sử dụng trong quá trình phân tích, thiết kế, hiện
thực, kiểm tra và bảo trì để bảo đảm các sản phẩm phần
mềm được sản xuất và hoạt độngđộng:: hiệu quả, tin cậy, hữu
dụng, nâng cấp dễ dàng (modificable), khả chuyển
(portable), khả kiểm tra (testable), cộng tác được với các
hệ thống khác (interoperable) và vận hành đúng (correct)
(correct)..
9
Cụ
ụ thể
• Efficiency:
Efficiency: Phần mềm được sản xuất trong thời gian và điều kiện vừa phải.
phải. Phần
mềm vận hành đúng mức độ yêu cầu về công việc và thời gian.
gian.
• Reliablity:
Reliablity: Phần mềm vận hành ổn định và tương tác được với các hệ thống ứng
dụng
• Usability
Usability:: Phần mềm có thể dùng được bởi người sử dụng và với môi trường mà
người sử dụng đang có.
có. Chú ý tới giao diện,
diện, điều kiện hệ thống
thống,,…
• Modifiability:
Modifiability: Phần mềm có thể được thay đổi dể dàng
dàng,, nhanh chóng khi yêu cầu
của người sử dụng thay đổi
đổi..
• Portability:
Portability: Phần mềm có thể chuyển đổi dễ dàng sang các hệ thống khác mà không
cần phải điều chỉnh lớn.
lớn. Chỉ cần recompile nều cần thiết là tốt nhất
nhất..
• Testability
Testability:: Phần
Phầ mềm
ề có
ó thể được
đượ kiểm
kiể tra
t dễ dàng
dà
dàng.. Tốt nhất
hất là được
đượ modul
d l hóa
hó .
hóa.
• Reusability:
Reusability: Phần mềm hay một phần có thể được tái sử dụng cho các ứng dụng
khác. Các modul có thiết kế tốt
khác. tốt,, độc lập và giao tiến đơn giản,
giản, cả về tình tương thích
công nghệ phát triển
10
Cụ
ụ thể ((tt))
• Maintainability:
Maintainability: thiết kế của phần mềm có thể được hiểu dễ dàng cũng như chuyển
giao
i thuận
th ậ tiện
tiệ cho
h người
ười khác
khá trong
t quá
á trình
t ì h điề
điều chỉnh,
hỉ h nâng
â cấp
ấ hay
h thay
th đổi theo
th
yêu cầu.
cầu.
• Interoperability:
Interoperability: Phần mềm vận hành ổn định và đúng như mong đợi
đợi.. Trên hệ
thống nhiều người dùng (multi users) phần mềm vẫn hoạt động được với các vận hành
khác của hệ thống
thống..
• Correctness:
Correctness: Phần mềm phải tính toán đúng và tạo ra kết quả đúng và đúng với
mục tiêu ứng dụng của người dùng
dùng..
• Các yêu cầu khác:

khác:
– Đú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
11
What is “Engineering”?
g g
• The profession in which
– a knowledge off the mathematical
h i l and naturall sciences
i gained
i by study,
experience, and practice
– is applied with judgment
– to develop
de elop ways
a s to utilize,
tili e economically,
economicall the materials and forces of nature
nat re
for the benefit of mankind
-- Accreditation Board for Engineering and Technology
Si
Science
12
ch0. Introduction
12
Engineers
g in Societyy
• ACM Code of Ethics and Professional Conduct
– 1.1 Contribute to society and human well-being.
– 1.2 Avoid harm to others.
– 1.3 Be honest and trustworthy.y
– 1.4 Be fair and take action not to discriminate.
– 1.5 Honor property rights including copyrights and patent.
– 1 6 Give proper credit for intellectual property.
1.6 property
– 1.7 Respect the privacy of others.
– 1.8 Honor confidentiality.
13
ch0. Introduction
13
Nội
ộ dung
g công
g việc
ệ của Software Engineering
g g
Công việc của software engineering bao gồm:
• Phân tích hệ thống/vấn đề • Quản lý chất lượng

• Xác định các yêu cầu • Huấn luyện
yệ
• Thiết kế phần mềm • Dự đoán tài nguyên
• Viết phần mềm (coding) • Quản trị dự án
• Kiểm tra và tích hợp hệ
thống
• Cài đặt và chuyển giao
phần
hầ mềm ề
• Lập tài liệu
• Bảo trì
14
Một
ộ định
ị nghĩa
g khác của CNPM
• CNPM là các quy trình đúng kỷ luật và có định lượng được
á dụng cho sự phát
áp á triển,
ể thực thi và à bảo
ả trìì các
á hệệ
thống thiên về phần mềm
• Tập trung vào quy trình
trình,, sự đo lường
lường,, sản phẩm
phẩm,, tính
đúng thời gian và chất lượng
Qui trình Đo lường Thời gian Chất lượng

Tiê chuẩn
Tiêu h ẩ Quản lý Dịch vụ
15
Mô hình p
phát triển p
phần mềm
Các công đoạn chính tổng quát bao gồm 4 giai đoạn
• Giai đoạn đặc tả

tả:: xác định các tính năng và điều kiện hoạt
động của hệ thống
thống.. (thu thập yêu cầu và phân tích)
• Giai đoạn phát triển triển:: Thiết kế phần mềm (software
design),
g ), viết code ((code g generation
• Giai đoạn kiểm tra:
tra: kiểm tra phần mềm (software testing),
kiểm tra tính hợp lý của phần mềm.mềm.
• Giai đoạn
đ bả trì
bảo trì:
ì: Sửa
ử lỗi
lỗ (correction),
( ) thay
h đổi
đổ môi
ô trường
ờ
thực thi (adaptation), tăng cường (enhancement)
16
Các mô hình sản xuất p
phần mềm
Tùy theo quy mô và công nghệ phát triển, có các mô hình
sản
ả xuất
ấ khác
á nhau
nhau..
• Mô hình tuần tự tuyến tính-
tính- waterfall
• Mô hình Prototyping - Evolutionary Development
• Mô hình xoắn ốc – Boehm’s Spiral Model
• Mô hình RAD – Rapid Application Development
MÔ HÌNH NÀO TỐT HƠN

Mỗi mô hình phù hợp với trình độ phát triển, quy mô sản
phẩm và yêu cầu ràng buộc cụ thể về thời gian và tính
chất của hệ thống
thống..
17
Mô hình WaterFall – Sequency
q y model
• Mô hình phát triển phần mềm đầu tiên
• Các công việc tiếp nối nhau một cách tuần tự
• Đặt nền móng cho các phương pháp phân tích, thiết kế, kiểm
tra…
tra …
Phân tích
yêu cầu
Thiết kế hệệ thống
g
& phần mềm
Hiện thức và
kiểm tra moduls
Tích
Tí h hợp
hợ vàà kiể
kiểm
tra tổng thể
Chuyển giao
và Bảo trì
18
Mô hình WaterFall – Sequency
q y model ((tt))
Bộc lộ một số khuyết điểm
• Bản
ả chấtấ của
ủ phát
á triển
ể phần
ầ mềmề là à quáá trình
ì lặp
ặ đi lặp
ặ
lại chứ không phải tuần tự
• Các bước thực ự chất không g tách biệt
ệ hoàn toàn mà có
chồng lấn và tham khảo lại
• Bắt buộc khách hàng đặc tả tất cả yêu cầu một cách chính
xác và đầy đủ ngay từ ban đầu
• Khách hàng thường phải chờ đợi rất lâu để thấy được
phiên bản đầu tiên của sản phẩm
• Tồn
ồ tại “delay”
“d l ” tích
í h lũy
lũ trong nhóm
hó làm là việc
ệ -> dự d án
á
thường bị trể
trể..
• Chỉ pphù hợp
ợp cho dựự án nhỏ,
nhỏ, đơn g
giản..
giản
19
Mô Hình Prototype
yp
Hoạt động sản xuất
Bản prototype
Đặc tả
Mô tả sơ lược Các bản trung

của
ủ khá
khách
h hà
hàng Phát triển gian
Kiểm thử
Bản cuối cùng
20
Mô Hình Prototype
yp – ưu & khuyết
y
• Prototype như là một cơ chế để nhận diện chính xác yêu cầu của
khách hàng
– Bản thân khách hàng chưa hiểu rõ yêu cầu của mình, cũng như các quy
trình chưa được xác lập rõ ràng.
– 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 thích sự thích thú của người dùng với dự án
• Prototype cóó thể

ể bị “throw
“throw--away” -> Lãng
ã phíí
• Các process không được phân định rõ ràng
• Hệệ thống
g thôngg thường g có cấu trúc lỏng
g lẻo
• Cần có những kỹ năng đăc biệt trong quản lý và phát triển
• 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 prototype đầu tiên
21
Mô Hình Prototype
yp – Ứng
g dụng
ụ g
• Dùng cho các hệ thống nhỏ.

nhỏ. Các chi phí khi thay đổi hệ
thống là không quá lớn khia cần phải thay đổi sau khi
thực hiện prototype
• Cần sựự cấpp bách về thời g
gian triển khai ngắn.
ngắn
g . Hệ ệ thống
g
cần được đưa vào ứng dụng từng phần trong khoảng thời
gian nhất định
định..
• Trong trường hợp những hệ thống mà việc đặc tả các yêu
cầu là rất khó và không rõ ràng ngay từ đầu
đầu..
22
Mô hình Xoắn Ốc - Boehm’s Spiral
p Model
Xác
á định công
ô việc
ệ Đánh giá rủi ro
Hoạch định đề tài Phát triển sản phẩm
• Được thực hiện theo một chuỗi ỗ lặp kiểu xoắn ốc

ốc,, mỗi
ỗ lần
lặp cải thiện sản phẩm
• Có phương pháp đánh giá rủi ro
• Có thể áp dụng prototype
• Mỗi lần lặp được cải thiện cho thích nghi với bản chất của
đề án
23
Mô hình RAD
Application Testing &
Business modeling Data Process modeling
generation Turnover
modeling
• Rapid Application Development là mô hình tuần tự tuyến

tính có thời gian phát triển rất ngắn
• Sử dụng các thành phần có sẵn càng nhiều càng tốt
• Sử dụng
ụ g công g cụ
ụ lập
ập trình ở dạng
ạ g tự
ự động
ộ g sinh mã chứ
không phải các ngôn ngữ truyền thống
• Phụ
Ph thuộc
h ộ vàoà công
ô nghệ hệ phát
há triển
iể có
ó tính
í h reusable
bl cao
cao..
• Pattern system development
24
Software Process Model
25
Các tiêu chuẩn dùngg trongg CNpPM
p
• The Capability Maturity Model (CMM) của Software Engineering Institue (SEI)
- Đại học 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 Process Improvement Paradigm (PIP) của Software Engineering
Laboratory (SEL) – NASA’s Goddard Space Flight 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ý.
26
Các tiêu chuẩn dùngg trongg CNpPM
p (tt
tt))
• Các chuẩn khác của Department of Defense
– MIL – STD
S 216 A ; MIL-STD
2167A S 1 4A ; MIL-STD
1574A S 882C
• The electronic Industries Association (EIA) chuẩn SEB-
SEB-6-A
• The European ESPRIT project
• International Standards Organisation - ISO 9001
• United Kingdom MOD 0055
27
Software Process Management
g
To Achieve Improvement
The Capability Maturity Model for Software (CMM) is a

five--level roadmap for improving the software process and
five
achieving improved quality results.
28
Software Process Management
g
Capability Maturity Model Overview
Optimizing
O ti i i - Process
P
refined constantly
Increasing
P
Process Managed - Process
Maturity measured/controlled
Defined - Process
institutionalized
Repeatable - Costs,
Costs
Schedules managed
Initial - Ad hoc;
unpredictable
29
The Capability Maturity Model
The CMM
Maturity Levels
Structure
30
The CMM
Maturity Levels
Structure
Process indicate
Capability
31
The Capability
p y Maturity
y Model
Maturityy Levels
A maturity level is a well-

well-defined evolutionary plateau on
the path toward becoming a mature software
organization..
organization
• each level is a layer in the foundation for continuous
process improvement
• there are five maturity levels in the CMM
Process capability describes the range of expected results

from following a process
process..
32
The Capability
p y Maturity
y Model
The Five Maturity Levels
Continuously
improving Optimizing
process (5)
Predictable Managed
process (4)
Standard,
consistent Defined
process (3)
Disciplined
Di i li d Repeatable
process (2)
Initial
(1)
33
The CMM
Maturity Levels
Structure
are composed of
Process indicate
d cate
K P
Key Process A
Areas
Capability
34
The Capability
p y Maturity
y Model
Keyy Process Areas
Key process areas are the major building blocks in

establishing
bl h the
h process capability
b l off an organization.
organization.
They are a cluster of related activities performed

collectively to achieve a set of goals
35
The Capability
p y Maturity
y Model
Focus of the Key Process Areas
Level Focus Key Process Area
Optimizing (5) Continuous Process Defect Prevention
Technology Change Management
improvement
Process Change Management
Quantitative process management
Managed (4) Product & process quality Software quality management
Organization process focus
Organization process definition
Training program
Defined (3) Engineering process Integrated software management
Software product engineering
Intergroup coordination
Peer Reviews
Requirements management
Software project planning
Repeatable (2) Project management Software project tracking & oversight
Software subcontract management
Software quality assurance
Software configuration management
Initial (1)
36
The Initial Maturityy Level
Understanding
g the Initial Maturityy Level
Performance driven by the competence and heroics of

the
h people
l doing
d the
h work
work.
k.
Consistency and compliance to standards driven by

management priorities - usually schedule is the top
priority..
priority
High quality and exceptional performance possible so

long as the best people can be hired
hired..
37
The Initial Maturityy Level
The Management
g View of the Software Process
at Level 1
In Out
Requirements flow in
in..
A software product is (usually) produced by some

amorphous process.
process.
Th product
The d t flows
fl outt and
d (hopefully)
(h f ll ) works.
works
k .
38
The Repeatable
p Maturity
y Level
Understanding
g the Repeatable
p Maturityy Level
The major problems in software development are

manageriall - not technical.
technical
h l.
Without management discipline,

discipline good software
engineering practices typically are abandoned in the
crunch..
crunch
39
The Repeatable
p Maturity
y Level
The Management
at Level 2
In Out
~
Requirements and resources flow in

in..
The production of the software product is visible at

defined points
points..
A tif t off the
Artifacts th process are controlled
controlled.
t ll d.
40
The Defined Maturityy Level
Understanding
g the Defined Maturityy Level
To control a process, it must be well understood

understood..
Identify the inputs, how they will affect the process, and
their readiness criteria
criteria..
Identify the outputs and the completion criteria for the

outputs..
outputs
Establish a shared understanding of how the process

works and the role of each participant
participant..
41
The Defined Maturityy Level
The Management
at Level 3
In Out
~ ~ ~
Roles and responsibilities in the process are understood

understood..
The production of the software product is visible

throughout the software process
process..
42
The Managed
g Maturity
y Level
Understanding
g the Managed
g Maturityy Level
Applying the principles of statistical process control,

address
dd speciall causes off process variation
variation..
Quantitatively address the organization’s

organization s, customer
customer’ss and
end user’s quality goals as part of a philosophy of quality
management..
management
43
The Managed
g Maturity
y Level
The Management
at Level 4
In Out
~ ~ ~ ~ ~ ~
The p
production of the software p
product is q
quantitativelyy
understood throughout the software process
process..
44
The Optimizing
p g Maturity
y Level
Understanding
g the Optimizing
p g Maturityy Level
Automation and trying new technologies
Identify and eliminate chronic causes of poor

performance
Continually improve the software process
45
The Optimizing
p g Maturity
y Level
The Management
at Level 5
In Out
~ ~ ~ ~ ~ ~
~
The software process is continuously improved in a
controlled manner
46
Chuẩn CMM ((tt
tt))
•Continuous Improvement
Optimized
•Các hệ thống quality control và qualify đã
được sử dụng hiệu quả
(Level 5)
•Có khả năng dự đoán (Predictability) Managed
•Các quy trình quản lý và tiêu chuẩn
Risk
đ
được chi
hi tiết
iế hóa
hó (Level 4)
Defined •Xác lập các tiêu chuẩn quản lý
•Các vấn đề documentation đã xác lập
(Level 3)
Competitiiveness
Repeatable
•Bắt
Bắt đầu có khả năng quản lý
(Level 2) •Quản lý dựa vào kinh nghiệm tương tự
Initial
•Largely Ad-hoc
(Level 1) •Phụ thuộc vào cá nhân
47
CMM
• Problem
– The KPAs focus mostly on activities and supporting artifacts
associated with a conventional waterfall process (requirements
specifications, documented plans, quality assurance audits)
– Very few of the KPAs address the evolving results (i.e., the software
product) and associated engineering artifacts (use-case models,
design models, source code, or executable code) that capture the real
target product.
– Most implementations of the CMM drive organizations to produce

more documents, more checkpoints, more artifacts, more
traceability, more reviews, and more plans
– CMMI
48
Tham khảo
• Chapter 01 in [Software Engineering]
• CMM vs.
vs. CMMI From Conventional to Modern Software
Management..pdf
Management
49

Chapter01 v02

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter01 v02

Uploaded by

Copyright:

Available Formats

Bài Giảng

• Công nghệ phần mềm là một quy trình có hệ thống

• Các yêu cầu khác:

-- Accreditation Board for Engineering and Technology

• Phân tích hệ thống/vấn đề • Quản lý chất lượng

Qui trình Đo lường Thời gian Chất lượng

• Giai đoạn đặc tả

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

Hoạt động sản xuất

Mô tả sơ lược Các bản trung

• Prototype cóó thể

• Dùng cho các hệ thống nhỏ.

Hoạch định đề tài Phát triển sản phẩm

• Được thực hiện theo một chuỗi ỗ lặp kiểu xoắn ốc

• Rapid Application Development là mô hình tuần tự tuyến

The Capability Maturity Model for Software (CMM) is a

A maturity level is a well-

Process capability describes the range of expected results

Keyy Process Areas

Key process areas are the major building blocks in

They are a cluster of related activities performed

Performance driven by the competence and heroics of

Consistency and compliance to standards driven by

High quality and exceptional performance possible so

A software product is (usually) produced by some

The major problems in software development are

Without management discipline,

Requirements and resources flow in

The production of the software product is visible at

To control a process, it must be well understood

Identify the outputs and the completion criteria for the

Establish a shared understanding of how the process

Roles and responsibilities in the process are understood

The production of the software product is visible

Applying the principles of statistical process control,

Quantitatively address the organization’s

Automation and trying new technologies

Identify and eliminate chronic causes of poor

Continually improve the software process

– Most implementations of the CMM drive organizations to produce

You might also like