_SP01

Software engineering revisited

Xem xét lại kỹ thuật phần mềm
Covered topics
- Software engineering: kỹ thuật phần mềm
- Software quality: chất lượng phần mềm
SOFTWARE ENGINEERING: kỹ thuật phần mềm
1. FAQs: các câu hỏi thường gặp
1.1. What is software? Phần mềm là gì
- Software = computer programs + associated documentation (e.g.
requirements, design models and user manuals)
Phần mềm = các chương trình máy tính + tài liệu liên quan (ví dụ như là các
yêu cầu, các mô hình thiết kế và các hướng dẫn sử dụng)
- Software products may be: các sản phẩm phần mềm có thể:
o Generic – developed to be sold on open market to any customers:
được phát triển chung để bán trên thị trưởng mở cho bất kỳ khách
hàng nào
o Customized – developed for a particular customer according to their
specification: được phát triển một cách tùy chỉnh cho một khách hàng
cụ thể theo yêu cầu của họ
- New software can be created by: một phần mềm mới có thể được tạo ra bằng
cách
o Developing new programs: phát triển những chương trình mới
o Configuring generic software systems: cấu hình những hệ thống phần
mềm chung
o Reusing existing software: tái sử dụng một phần mềm hiện có
1.2. What is software engineering? Kỹ thuật phần mềm là gì
- Software: large/complex, given budget, given deadline, built by teams,
changeable, high quality
Phần mềm: lớn/phức tập, có chi phí nhất định, có thời hạn nhất định, được
xây dựng bởi các đội (team), có khả năng thay đổi, chất lượng cao
- Software engineering is concerned with all aspect of software production:
công nghệ phần mềm có liên quan đến tất cả các khía cạnh của việc sản xuất
phần mềm
o Technical processes of software development activities: các quy trình
kỹ thuật của hoạt động phát triển phần mềm
o Development tools, methods, and theories to support software
production: các công cụ, các phương pháp và các nguyên lý hỗ trợ
việc sản xuất phần mềm
1.3. What is a software process? Quy trình phần mềm là gì
- A set of activities whose goal is the development or evolution of software
Một tập hợp các hoạt động với mục tiêu là phát triển hoặc thay đổi phần
mềm
- Generic activities in all software processes are: các hoạt động thường có
trong tất cả các quy trình phần mềm là:
o Specification – what the system should do and its development
constraints: đặc tả: hệ thống nên làm gì và giới hạn phát triển của nó
o Development – production of the software system: phát triển: việc sản
xuất của hệ thống phần mềm
o Validation – checking that the software is what the customer wants
Xác nhận: kiểm tra xem đó có phải là phần mềm mà khách hàng mong
muốn hay không
o Evolution – changing the software in response to changing demands
Thay đổi: thay đổi phần mềm để đáp ứng được các nhu cầu thay đổi
1.4. What is a software process model? Mô hình quy trình phần mềm là gì
- A simplified representation of a software process, presented from a specific
perspective: một mô tả đơn giản của một quy trình phần mềm, trình bày từ
một quan điểm cụ thể
- Examples of process perspectives: ví dụ về một vài mô tả quy trình
o Workflow perspective: sequence of activities
Mô tả luồng công việc: thứ tự các hành động
o Data flow perspective: information flow
Mô tả luồng dữ liệu: theo nguồn thông tin
o Role/action perspective: who does what
Mô tả vai trò/hành động: ai làm gì
- Generic process models: một số quy trình phổ biến
o Waterfall: thác nước
 o Iterative development: phát triển lặp đi lặp lại (xoắn ốc)
o Component-based software engineering: công nghệ phần mềm dựa
trên thành phần
- E.g. the waterfall software lifecycle: Requirements analysis and
specification  Design and specification  Code and module testing 
Integration and system testing  Delivery and maintenance
Ví dụ: vòng đời của mô hình thác nước: phân tích các yêu cầu và đặc tả 
thiết kế và đặc tả thiết kế  lập trình và kiểm thử module  tích hợp và
kiểm thử hệ thống  chuyển giao vào bảo trì
1.5. What is the difference between SE and CS? Sự khác nhau giữa công
nghệ phần mềm và khoa học máy tính là gì?
- SE: Software Engineering: công nghệ phần mềm:
o SE is concerned with the practical problems of developing and
delivering useful software: công nghệ phần mềm được quan tâm cùng
với các vấn đề thực tiễn của việc phát triển và cung cấp các phần mềm
hữu ích
o SE is about more than just programming/coding: công nghệ phần
mềm không chỉ là việc lập trình/mã hóa
o The software engineer is interested in only those techniques that make
sound economic sense: kỹ sư phần mềm chỉ quan tâm đến các kỹ
thuật có ý nghĩa lớn về mặt kinh tế
- CS: Computer Science: khoa học máy tính
o CS is concerned with theory and fundamentals: khoa học máy tính có
liên quan đến các nguyên tắc, nguyên lý cơ bản
o CS theories are still insufficient to act as a complete underpinning for
software engineering: các nguyên lý khoa học máy tính vẫn chưa đủ
để hoạt động như một nền tảng hoàn hảo cho công nghệ phần mềm
o The computer scientist investigates a variety of ways to produce
software, some good and some bad: Các nhà khoa học máy tính
nghiên cứu nhiều cách khác nhau để sản xuất phần mềm, có một số
cách tốt và một số cách xấu
1.6. What are software engineering methods? Các phương pháp kỹ thuật
phần mềm là gì
- Structured approaches to software development which include system
models, notations, rules, design advice and process guidance: Phương pháp
 tiếp cận có cấu trúc để phát triển phần mềm trong đó bao gồm các mô hình
hệ thống, ký hiệu, quy tắc, tư vấn thiết kế và hướng dẫn quy trình
- Model descriptions: descriptions of graphical models which should be
produced. Mô tả mô hình: đưa ra mô tả cho các mô hình đồ họa
- Rules: constraints applied to system models
Các quy tắc: hạn chế áp dụng cho các mô hình hệ thống
- Recommendations: advice on good design practice
Khuyến cáo: tư vấn về thực hành thiết kế sản phẩm
- Process guidance: activities to follow
Quy trình hướng dẫn: các hoạt động tuân theo
1.7. What are the attributes of good software? Các thuộc tính của một phần
mềm tốt là gì?
- The software should deliver than the required functionalities and
performance to the user and should be maintainable, dependable and
acceptable.
Phần mềm phải được chuyển giao hơn là chỉ đưa ra các chức năng đã được
yêu cầu và hiệu quả cho người sử dụng và cần được bảo trì, đáng tin cậy và
có thể chấp nhận.
- Maintainability: software must evolve to meet changing needs
Khả năng bảo trì: phần mềm phải đáp ứng được nhu cầu thay đổi
- Dependability: software must be trustworthy
Khả năng tin cậy: phần mềm phải đáng tin cậy
- Efficiency: software should not make wasteful use of system resources
Hiệu quả: phần mềm không nên sử dụng lãng phí tài nguyên hệ thống
- Acceptability: software must accepted by the users for which it was
designed: it must be understandable, usable and compatible with other
systems
Sự chấp nhận: thiết kế của phần mềm phải được người sử dụng chấp nhận:
nó phải là điều dễ hiểu, có thể sử dụng và tương thích với các hệ thống khác
1.8. What are the key challenges facing software engineering? Công nghệ
phần mềm phải đối mặt với những thách thức chính là gì?
- Heterogeneity: developing techniques for building software that can cope
with heterogeneous platforms and execution environments
Tính không đồng nhất: phát triển kỹ thuật để xây dựng phần mềm có thể đối
phó với các nền tảng không đồng nhất và môi trường thực hiện
- Delivery: developing techniques that load to faster delivery of software
Bàn giao: phát triển các kỹ thuật để bàn giao phần mềm nhanh hơn
- Trust: developing techniques that demonstrate that software can be trusted
by its users
Tin tưởng: các kỹ thuật phát triển sẽ chứng minh phần mềm có thể được tin
cậy bởi người sử dụng
2. Deal with complexity & changes. Đối phó với sự phức tạp và các thay đổi
Approach tiếp cận
- Consider the software engineering as a problem solving activity: Xem công
nghệ phần mềm như là một hoạt động giải quyết vấn đề
o Analysis: understand the nature of the problem and break the problem
into pieces
Phân tích: hiểu được bản chất của vấn đề và chia vấn đề thành nhiều
mảnh
o Synthesis: put the pieces together into a large structure
Tổng hợp: đưa các mảnh hợp lại với nhau thành một cấu trúc lớn
- For solving a problem we use
Đối với việc giải quyết một vấn đề, chúng tôi sử dụng
o Techniques (methods): formal procedures for producing results using
some well-defined notation
Các kỹ thuật (phương pháp): các thủ tục hình thức thay cho các kết
quả sử dụng một số chú thích rõ ràng
o Methodologies: collection of techniques applied across software
development and unified by a philosophical approach
Phương pháp học: tập hợp các kỹ thuật đã áp dụng qua việc phát triển
phần mềm và thống nhất bằng một cách tiếp cận triết học
o Tools: instrument or automated systems to accomplish a technique
Công cụ: dụng cụ hoặc các hệ thống tự động để thực hiện một kỹ
thuật
2.1. Deal with complexity. Đối phó với vấn đề phức tạp:
- The problem here is the complexity
Vấn đề ở đây là sự phức tạp
- Many sources of complexity, but size is the key
Sự phức tạp có nhiều nguyên nhân, nhưng kích thước là chìa khóa
- This problem can be solved by: Vấn đề này có thể được giải quyết bằng cách
o Modeling: mô hình hóa
o Decomposition: phân chia
 o Abstraction : trừu tượng hóa
o Hierarchy: kế thừa
o Use patterns: sử dụng các mô hình
2.2. Deal with changes. Đối phó với các thay đổi
- Changes of project conditions: tailor the software lifecycle
Thay đổi về điều kiện dự án: điều chỉnh vòng đời phần mềm
- Changes of requirements or technology: use a nonlinear software lifecycle
Thay đổi về yêu cầu hoặc công nghệ: sử dụng một vòng đời phần mềm phi
tuyến
- Changes of entities: provide the configuration management
Thay đổi các thực thể: cung cấp việc quản lý cấu hình
3. Knowledge Area & Units. Diện tích kiến thức và các đơn vị
Software engineering: công nghệ phần mềm
- Computing essentials: yếu tố tính toán cần thiết
- Mathematical & engineering fundamentals: Nguyên tắc cơ bản về Toán học
& kỹ thuật
- Professional practice: Hành nghề
- Software modeling & analysis: mô hình hóa phần mềm và phân tích
- Software design: thiết kế phần mềm
- Software verification & validation: Xác minh Phần mềm & xác nhận
- Software evolution: Tiến hóa phần mềm
- Software process: quy trình phần mềm
- Software quality: chất lượng phần mềm
- Software management: quản lý phần mềm
SOFTWARE QUALITY: chất lượng phần mềm
Introduction: cơ bản:
- Software products are different from traditional types of products
Các sản phẩm phần mềm khác với các sản phẩm kiểu truyền thống
o Intangible: difficult to describe and evaluate
Phi vật thể: khó khăn để mô tả và đánh giá
o Malleable: tính mềm dẻo
o Human intensive: involves only trivial “manufacturing” process
Tập trung vào con người: chỉ liên quan đến quá trình “chế tạo” thông
thường
- Good software products require good programming, but … programming
quality is the means to the end, not the end itself.
Các sản phẩm phần mềm tốt đòi hỏi lập trình tốt, nhưng ... chất lượng lập
trình là tiềm lực để kết thúc, không phải là nó kết thúc.
1. Classification of software qualities. Phân loại chất lượng phần mềm
- Internal vs. external: bên trong và bên ngoài
o External  visible to users: bên ngoài  rõ ràng với người sử dụng
o Internal  concern developers: bên trong  mối quan tâm của các
lập trình viên
o Internal qualities affect external qualities:
Phẩm chất bên trong ảnh hưởng đến phẩm chất bên ngoài
- Product vs. process: sản phẩm và quy trình
o Our goal is to develop software products
Mục đích của chúng ta là phát triển các sản phẩm phần mềm
o The process is how we do it
Quy trình là chúng ta làm nó như thế nào
o Process quality affects product quality
Chất lượng của quy trình ảnh hưởng tới chất lượng của sản phẩm
2. Representative qualities. Các chất lượng tiêu biểu
- Common qualities: 11
11 chất lượng phổ biến
- Process – specific qualities: 3
3 chất lượng đặc tả quy trình
- Application – specific qualities
Các chất lượng đặc tả ứng dụng
2.1. Common qualities. Các chất lượng thông thường
2.1.1. Correctness. Tính đúng đắn
- Software is correct if it satisfies the functional requirements specifications:
assuming that specification exists!
Phần mềm là chính xác, nếu nó đáp ứng được các yêu cầu đặc tả chức năng
- If specifications are formal, since programs are formal objects, correctness
can be defined formally: It can be proven as a theorem or disproved by
counter examples (testing)
Nếu các đặc tả kỹ thuật là chính quy, thì chương trình là các đối tượng chính
quy, tính đúng đắn có thể được định nghĩa chính thức: Nó có thể được chứng
minh như là một nguyên lý hay bác bỏ bằng các ví dụ đối lập (kiểm thử)
- Limits: giới hạn
o It is an absolute (yes/no) quality:
Nó là một chất lượng chắc chắn (Có/ Không)
 There is no concept of “degree of correctness”
Không có khái niệm về "mức độ đúng đắn"
 There is no concept of severity of deviation
Không có khái niệm về mức độ nghiêm trọng của độ sai lệch
o What if specifications are wrong? (e.g. they derive from incorrect
requirements or errors in domain knowledge)
Điều gì xảy ra nếu đặc tả có vấn đề? (ví dụ: họ xuất phát từ yêu cầu
không chính xác hoặc sai sót trong một miền tri thức)
2.1.2. Reliability. độ tin cậy
- Informally, user can rely on it
Tin cậy, người dùng có thể dựa vào nó
- Can be defined mathematically as “probability of absence of failures for a
certain time period”
Có thể được định nghĩa bằng cách toán học như là "xác suất của sự vắng mặt
của những thất bại trong thời gian thời gian nhất định"
- If specifications are correct, all correct software is reliable, but not vice –
versa (in practice, however, specs can be incorrect …)
Nếu thông số kỹ thuật là chính xác, tất cả các phần mềm đúng là đáng tin
cậy, nhưng không phải ngược - lại (trong thực tế, tuy nhiên, thông số kỹ
thuật có thể không chính xác ...)
- Idealized situation: requirements are correct
Trạng thái lý tưởng: yêu cầu là chính xác
 2.1.3. Robustness. Tính linh hoạt
- Software behaves “reasonably” even in unforeseen circumstances (e.g.
incorrect input, hardware failure)
Phần mềm xử "hợp lý" ngay cả trong những tình huống không lường trước
(ví dụ, đầu vào không chính xác, lỗi phần cứng)
2.1.4. Performance. Hiệu suất
- Efficient use of resources: memory, processing time, communication
Sử dụng hiệu quả các nguồn tài nguyên: bộ nhớ, thời gian xử lý, thông tin
liên lạc
- Can be verified: Có thể được xác nhận
o Complexity analysis: Phân tích phức tạp
o Performance evaluation (on a model, via simulation)
Thực hiện đánh giá (trên một mô hình, thông qua mô phỏng)
- Performance can affect scalability: a solution that works on a small local
network may not work on a large intranet
Hiệu suất có thể ảnh hưởng đến khả năng mở rộng: một giải pháp mà các
công trình trên một mạng cục bộ nhỏ có thể không hoạt động trên một mạng
nội bộ lớn
2.1.5. Usability. Khả năng sử dụng
- Expected users find the system easy to use
 Người sử dụng dự kiến tìm thấy hệ thống dễ sử dụng
- Other term: user – friendliness
Thuật ngữ khác: thân thiện với người dùng
- Rather subjective, difficult to evaluate
So với tưởng tượng thì khó khăn để đánh giá
- Affected mostly by user interface: e.g. visual vs. textual
Bị ảnh hưởng chủ yếu bởi giao diện người dùng: ví dụ: văn bản so với thị
giác (giao diện đồ họa so với giao diện dòng lệnh)
- Why is usability important? Tại sao khả năng sử dụng lại quan trọng
o Users are able to achieve their tasks easily and efficiently, which has
public relations benefits for the organization – thereby increasing
uptake
Người dùng có thể để đạt được mục đích của mình một cách dễ dàng
và hiệu quả, trong đó có lợi ích quan hệ công khai cho việc tổ chức -
do đó làm tăng sự hấp thu
o Systems having poor usability levels can result in substantial
organizational costs
Hệ thống có mức độ khả năng sử dụng kém có thể dẫn đến chi phí tổ
chức lớn
o People avoid using the application if they find it difficult to use
Mọi người thường tránh sử dụng các ứng dụng nếu họ cảm thấy khó
khăn sử dụng
2.1.6. Verifiability. Tính kiểm chứng
- How easy it is to verify properties. Xác minh các tính chất dễ dàng như thế
nào?
o Mostly an internal quality: chủ yếu là chất lượng bên trong
o Can be external as well (e.g. security critical application)
Chất lượng bên ngoài có thể tốt (ví dụ, ứng dụng bảo mật)
2.1.7. Maintainability. Khả năng bảo trì
- Maintainability: ease of maintenance
Khả năng bảo trì: sự dễ dàng của việc bảo trì
- Maintenance: changes after release
Bảo trì: thay đổi sau khi đi vào sử dụng
o Maintenance costs exceed 60% of total cost of software
Chi phí bảo dưỡng vượt quá 60% tổng chi phí của phần mềm
o Three main categories of maintenance
 Có 3 loại bảo trì
 Corrective: removing residual errors (20%)
Khắc phục: loại bỏ các lỗi còn lại (20%)
 Adaptive: adjusting to environment changes (20%)
Thích nghi: điều chỉnh để thay đổi môi trường (20%)
 Perfective: quality improvements (>50%)
Hoàn hảo: cải tiến chất lượng (> 50%)
- Maintenability can be decomposed as
Khả năng bảo trì có thể được chia thành:
o Repairability: ability to correct defects in reasonable time
Khả năng sửa chữa: khả năng sửa chữa các nội dung thiếu chính xác
trong thời gian hợp lý
o Evolvability: ability to adapt software to environment changes and to
improve it in reasonable time
Khả năng phát triển: khả năng thích ứng với các thay đổi của môi
trường và cải thiện nó trong thời gian hợp lý
2.1.8. Reusability. Khả năng tái sử dụng
- Existing product (or components) used (which minor modifications) to build
another product: similar to evolvability
Sản phẩm hiện tại (hoặc các thành phần) được sử dụng (có thay đổi nhỏ) để
xây dựng một sản phẩm khác: tương tự như khả năng phát triển
- Also applies to process
Cũng áp dụng cho quy trình
- Reuse of standard parts measure of maturity of the field
Tái sử dụng các bộ phận tiêu chuẩn đo lường của sự trưởng thành của trường
2.1.9. Portability. Tính khả chuyển
- Software can run on different hardware platforms or software environments
Phần mềm có thể chạy trên các nền tảng phần cứng khác nhau hoặc các môi
trường phần mềm
- Remains relevant as new platforms and environments are introduced: e.g.
digital assistants
Có liên quan như là các nền tảng và môi trường mới được giới thiệu: ví dụ:
trợ lý kỹ thuật số
- Relevant when downloading software in a heterogeneous network
environment
Có liên quan khi tải phần mềm trong một môi trường mạng không đồng nhất
2.1.10. Understandability. Tính dễ hiểu
- Ease of understanding software
Dễ dàng để hiểu được phần mềm
- Program modification requires program understanding
Sửa đổi chương trình đòi hỏi sự hiểu biết chương trình
2.1.11. Interoperability. Khả năng tương thao tác
- Ability of a system to coexist and cooperate with other systems
Khả năng của một hệ thống để cùng tồn tại và hợp tác với các hệ thống khác
o Capable of exchange information with other systems
Có khả năng trao đổi thông tin với các hệ thống khác
o Capable of use the exchanged information
Có khả năng sử dụng các thông tin trao đổi
2.2. Typical process qualities. Đặc trưng của chất lượng quá trình
- Productivity: denotes its efficiency and performance
Năng suất: biểu thị hiệu quả và hiệu suất của nó
- Timeliness: ability to deliver a product on time
Kịp thời: khả năng cung cấp kết quả trong một thời gian nhất định
- Visibility: all of its steps and current status are documented clearly
Tầm nhìn: tất cả các bước của nó và tình trạng hiện tại được ghi chép rõ ràng
Timeliness: kịp thời
- Often the development process does not follow the evolution of user
requirements
Thường thì quá trình phát triển không theo kịp sự tiến hóa của các yêu cầu
người sử dụng
- A mismatch occurs between user requirements and status of the product
Sự không phù hợp xảy ra giữa yêu cầu của người sử dụng và tình trạng của
sản phẩm
 2.3. Application – specific qualities. Các chất lượng đặc tả ứng dụng
- Information systems: security, data availability …
Các hệ thống thông tin: bảo mật, dữ liệu sẵn có …
- Real-time systems: scheduling priority …
Các hệ thống thời gian thực: ưu tiên lập kế hoạch …
- Distributed systems: code mobility
Các hệ thống phân phối: Mã di động
3. Quality measurement. Đo lường chất lượng
- To measure the software quality indicators, we use:
Để đo lường các chỉ số chất lượng phần mềm, chúng tôi sử dụng
o Metrics: độ đo
o Methods: phương pháp đo
Measurement Plan: kế hoạch đo
- Name + description for each unique metric
Tên + mô tả cho mỗi độ đo duy nhất
- Classification for each metric
Phân loại cho mỗi độ đo
- Association point in product development that identifies when and how data
is to be collected
Tập hợp điểm trong phát triển sản phẩm để xác định dữ liệu được thu thập
khi nào và như thế nào
- Definitions of the data collection forms
Định nghĩa của các hình thức thu thập dữ liệu
- Data reporting, collection, and validation procedures
Báo cáo số liệu, tập trung dữ liệu, và các thủ tục xác nhận
CONCLUSION PHẦN KẾT LUẬN
- Key points: software engineering
Những điểm chính: công nghệ phần mềm
o Software engineering is an engineering discipline that is concerned
with all aspects of software production.
Công nghệ phần mềm là một ngành kỹ thuật có liên quan với tất cả
các khía cạnh của sản xuất phần mềm.
 o Software products consist of developed programs and associated
documentation. Essential product attributes are maintainability,
dependability, efficiency and usability
Sản phẩm phần mềm bao gồm các chương trình phát triển và tài liệu
liên quan. Thuộc tính thiết yếu của sản phẩm là bảo trì, độ tin cậy,
hiệu suất và khả năng sử dụng
o Software process consists of activities that are involved in developing
software products. Basic activities are software specification,
development, validation and evolution
Qui trình phần mềm bao gồm các hoạt động có liên quan đến việc
phát triển các sản phẩm phần mềm. Các hoạt động cơ bản là đặc tả
phần mềm, phát triển, xác nhận và tiến hóa
o Methods are organized ways of producing software. They include
suggestions for the process to be followed, the notations to be used,
rules governing the system
Phương pháp là cách tổ chức sản xuất phần mềm. Chúng bao gồm các
đề nghị cho quá trình này phải tuân theo, các ký hiệu được sử dụng,
quy tắc quản trị hệ thống
- Key points: software quality
Những điểm chính: chất lượng phần mềm
o Ensuring the mentioned qualities becomes the goals in the practice of
software engineering
Bảo đảm chất lượng đề cập trở thành mục tiêu trong việc thực hành
công nghệ phần mềm
o Many qualities are subjective to measure, but no standard metrics
defined for most qualities.
Nhiều phẩm chất này là chủ quan để đánh giá, nhưng không có chỉ số
tiêu chuẩn quy định cho hầu hết các phẩm chất.