Một lỗi nhỏ nếu lọt qua kiểm tra để tung ra sản phẩm, sẽ tốn kém rất nhiều tiền để sửa chữa — hơn hẳn việc bắt kịp nó từ sớm. Đó là lý do chúng ta không chỉ bắt đầu gõ mã. Chúng ta tuân theo…
English narration · English + 中文 subtitles burned in · Giọng đọc tiếng Anh · phụ đề tiếng Anh + 中文 được ghi trực tiếp
12.1
Program development life cycle · Chu kỳ phát triển phần mềm
Syllabus · Chương trình
English
Candidates should be able to:
Notes and guidance
Show understanding of the purpose of a development life cycle
Show understanding of the need for different development life cycles depending on the program being developed
Including: waterfall, iterative, rapid application development (RAD)
Describe the principles, benefits and drawbacks of each type of life cycle
Show understanding of the analysis, design, coding, testing and maintenance stages in the program development life cycle
Tiếng Việt
Thí sinh cần có thể:
Ghi chú và hướng dẫn
Thể hiện sự hiểu biết về mục đích của vòng đời phát triển
Thể hiện sự hiểu biết về nhu cầu về các vòng đời phát triển khác nhau tùy thuộc vào chương trình đang được phát triển
Bao gồm: waterfall, lặp lại, **phát triển ứng dụng nhanh chóng (RAD)
Mô tả nguyên tắc, lợi ích và nhược điểm của từng loại vòng đời
Thể hiện sự hiểu biết về các giai đoạn phân tích, thiết kế, viết code, kiểm thử và bảo trì trong vòng đời phát triển chương trình
Source: Cambridge International syllabus · Nguồn: Chương trình Cambridge International
English
A development life cycle 开发生命周期 is the set of stages from idea to finished, maintained software. It exists to plan, manage and control a project — to build the right product, on time, with good quality.
Why a life cycle is needed
The examiner's list for "the purpose of a development life cycle": it breaks a large project into stages that can be planned and managed; it makes sure the requirements are found and agreed before design and coding begin; it builds in testing and documentation rather than leaving them to the end; it lets the team track progress against milestones and manage risk; and it gives the customer defined points at which to review the work. Without one, a team codes first and discovers late that it built the wrong thing.
Why there are different ones
No single life cycle fits every project, so several development life cycles exist. The choice depends on the size and complexity, how clear the requirements 需求 are at the start, how much change is expected, the risk level, the team, and the deadline.
Common models
Waterfall 瀑布模型 — a linear sequence (Analysis → Design → Coding → Testing → Maintenance), each stage finished before the next. Clear and well-documented; good for stable requirements, but poor at coping with mid-project change, and the customer sees nothing working until the end.
Iterative model 迭代模型 — repeated passes, each producing a partial version that is reviewed and refined. Catches problems earlier; good when requirements are discovered over time, but harder to estimate.
Rapid Application Development 快速应用开发 (RAD) — heavy use of a prototype 原型 and user feedback. Very fast first delivery; good for changing requirements, but depends on user availability and suits smaller systems.
Agile 敏捷 — short iterations ("sprints"), constant collaboration and testing. Flexible and adaptive, but needs a committed customer and a skilled team.
Principles, benefits and drawbacks — as the mark scheme lists them.
Model
Principle
Benefits
Drawbacks
waterfall
the stages run in a fixed order, each completed and signed off before the next starts; going back means restarting the sequence
simple to manage; every stage is fully documented; requirements are fixed early, so costs and dates can be estimated
inflexible once a stage is finished; no working software until late; a mistake in analysis is expensive to fix later; the customer cannot see progress
iterative
a small working version is built first, then repeatedly improved through further versions until complete
working software early and often; problems found in early versions; the customer's feedback shapes each version; requirements can change
hard to estimate the total time and cost; repeated testing costs effort; needs the customer to be available; can drift if versions are not planned
RAD
prototypes of parts of the system are built quickly and refined with the user until accepted, often in parallel by several teams
very fast delivery of a first version; the user is involved throughout, so the product fits their needs; changes are easy to absorb
needs skilled developers and committed users; documentation is weak; less suited to large or safety-critical systems
Worked example. A company must be the first to launch a website for a new games console, and the design will change as the console's features are announced. Name the most suitable life cycle and justify it.
RAD. A prototype of the site can be built and shown to the users within days, and refined as the requirements change; the site is small enough for a prototype-driven approach, and speed of delivery is the main requirement. Waterfall would fix the requirements before any page was built and deliver nothing until the end.
The standard stages
Each stage has a purpose, an output and typical activities — a "describe the … stage" question wants two or three of these.
analysis — find out what the program must do. Activities: interviews, questionnaires and observation of the current system; a feasibility study; agreeing the requirements specification, which every later stage is checked against.
design — decide how it will do it. Outputs: the structure chart (modules and parameters), flowcharts or pseudocode for each module, identifier tables and data structures, screen and file layouts, and the test plan written now, from the specification, before any code exists.
coding (implementation 实现) — write the program in a high-level language, module by module, following the design; each module is tested as it is written.
testing — run the program against the test plan (normal, abnormal, extreme and boundary data) and correct the errors found; integration, alpha, beta and acceptance testing follow.
maintenance 维护 — after release, correct faults, adapt the program to new hardware, software or law, and improve it (see below).
Worked example. Complete the waterfall diagram Analysis → ? → ? → ? → Maintenance and describe what happens at the design stage.
The missing stages are Design, Coding, Testing. At the design stage the requirements are turned into a plan for the program: the problem is decomposed into modules (a structure chart), the algorithm for each module is written as pseudocode or a flowchart, the data structures and identifiers are chosen, the screens and files are laid out, and the test plan is written from the specification.
Tiếng Việt
Chu kỳ phát triển là tập hợp các giai đoạn từ ý tưởng đến sản phẩm phần mềm hoàn thiện và được bảo trì. Nó tồn tại để lập kế hoạch, quản lý và kiểm soát dự án — nhằm xây dựng đúng sản phẩm, đúng hạn, với chất lượng tốt.
Phần mềm được xây dựng bởi các đội ngũ tuân theo chu kỳ phát triển để duy trì sự phối hợp
*Sơ đồ luồng lên kế hoạch cho logic chương trình trong giai đoạn thiết kế của chu kỳ
Tại sao cần có chu kỳ
Danh mục của giám khảo cho "mục đích của chu kỳ phát triển": nó chia nhỏ dự án lớn thành các giai đoạn có thể lập kế hoạch và quản lý; đảm bảo yêu cầu được xác định và thống nhất trước khi thiết kế và mã hóa bắt đầu; tích hợp sẵn kiểm thử và tài liệu thay vì để lại đến cuối cùng; giúp đội ngũ theo dõi tiến độ dựa trên các cột mốc và quản lý rủi ro; đồng thời cung cấp cho khách hàng các mốc thời gian xác định để xem xét công việc. Nếu không có chu kỳ này, đội ngũ sẽ viết mã trước rồi mới nhận ra muộn rằng họ đã xây dựng sai thứ gì đó.
Tại sao có nhiều loại khác nhau
Không có chu kỳ nào phù hợp với mọi dự án, nên có nhiều chu kỳ phát triển khác nhau. Việc lựa chọn phụ thuộc vào quy mô và độ phức tạp, mức độ rõ ràng của yêu cầu ở giai đoạn đầu, mức độ thay đổi dự kiến, mức độ rủi ro, đội ngũ và thời hạn.
Các mô hình phổ biến
Waterfall (Thác nước) — một dãy tuyến tính (Phân tích → Thiết kế → Mã hóa → Kiểm thử → Bảo trì), mỗi giai đoạn phải hoàn tất trước khi sang giai đoạn tiếp theo. Rõ ràng và có tài liệu đầy đủ; phù hợp với yêu cầu ổn định, nhưng kém linh hoạt khi có thay đổi giữa chừng, và khách hàng chỉ thấy sản phẩm hoạt động được đến tận cuối.
Mô hình lặp (Iterative) — các vòng lặp lặp đi lặp lại, mỗi vòng tạo ra một phiên bản từng phần để xem xét và tinh chỉnh. Phát hiện vấn đề sớm hơn; phù hợp khi yêu cầu được phát hiện dần theo thời gian, nhưng khó ước tính hơn.
Phát triển ứng dụng nhanh (RAD) — sử dụng mạnh mẽ bản mẫu và phản hồi của người dùng. Giao bản đầu tiên rất nhanh; phù hợp với yêu cầu thay đổi liên tục, nhưng phụ thuộc vào sự có mặt của người dùng và thích hợp cho hệ thống quy mô nhỏ.
Agile: các vòng lặp ngắn ("sprints"), cộng tác và kiểm thử liên tục. Linh hoạt và thích nghi cao, nhưng đòi hỏi khách hàng cam kết và đội ngũ có kỹ năng.
*Mô hình thác nước: mỗi giai đoạn phải hoàn tất trước khi giai đoạn sau bắt đầu
*Mô hình lặp: các lần lặp lại giúp tinh chỉnh chương trình
*Phát triển ứng dụng nhanh: các đội làm việc trên các phần khác nhau song song
Nguyên tắc, lợi ích và nhược điểm — theo danh sách sơ đồ chấm điểm.
Mô hình
Nguyên tắc
Lợi ích
Nhược điểm
Thác nước
các giai đoạn diễn ra theo thứ tự cố định, mỗi giai đoạn phải hoàn tất và được ký duyệt trước khi giai đoạn sau bắt đầu; quay lại nghĩa là phải khởi động lại toàn bộ chuỗi
dễ quản lý; mọi giai đoạn đều có tài liệu đầy đủ; yêu cầu được cố định sớm, nên chi phí và thời gian có thể được ước tính
thiếu linh hoạt khi một giai đoạn đã hoàn tất; không có phần mềm hoạt động cho đến tận cuối; sai sót trong phân tích sẽ tốn kém để sửa chữa về sau; khách hàng không thể thấy được tiến độ
Lặp
một phiên bản hoạt động nhỏ được xây dựng trước, sau đó cải tiến liên tục qua các phiên bản tiếp theo cho đến khi hoàn thành
phần mềm hoạt động sớm và thường xuyên; vấn đề được phát hiện ở các phiên bản đầu; phản hồi của khách hàng định hình mỗi phiên bản; yêu cầu có thể thay đổi
khó ước tính tổng thời gian và chi phí; kiểm thử lặp lại tốn sức lực; đòi hỏi khách hàng phải có mặt; có thể lạc hướng nếu các phiên bản không được lên kế hoạch kỹ
RAD
các bản mẫu của các phần hệ thống được xây dựng nhanh chóng và tinh chỉnh với người dùng cho đến khi được chấp nhận, thường là song song bởi nhiều đội
giao bản đầu tiên cực kỳ nhanh; người dùng tham gia suốt quá trình, nên sản phẩm đáp ứng đúng nhu cầu của họ; thay đổi dễ dàng được hấp thụ
đòi hỏi lập trình viên có kỹ năng và người dùng cam kết; tài liệu yếu; ít phù hợp với hệ thống lớn hoặc hệ thống quan trọng đến an toàn
Ví dụ giải. Một công ty phải là đơn vị đầu tiên ra mắt trang web cho máy chơi game mới, và thiết kế sẽ thay đổi khi các tính năng của máy được công bố. Hãy nêu tên chu kỳ phát triển phù hợp nhất và giải thích lý do.
RAD. Một bản mẫu của trang web có thể được xây dựng và trưng bày cho người dùng trong vài ngày, và tinh chỉnh khi yêu cầu thay đổi; trang web đủ nhỏ để áp dụng phương pháp dựa trên bản mẫu, và tốc độ giao hàng là yêu cầu chính. Mô hình Thác nước sẽ cố định yêu cầu trước khi bất kỳ trang nào được xây dựng và không giao任何东西 cho đến tận cuối.
Các giai đoạn tiêu chuẩn
Mỗi giai đoạn có một mục đích, một sản phẩm đầu ra và các hoạt động điển hình — câu hỏi "mô tả … giai đoạn" yêu cầu liệt kê hai hoặc ba yếu tố trong số này.
phân tích — xác định điều gì chương trình cần làm. Các hoạt động: phỏng vấn, khảo sát và quan sát hệ thống hiện tại; nghiên cứu khả thi; thống nhất tài liệu yêu cầu, mà mọi giai đoạn sau này đều được kiểm tra dựa trên đó.
thiết kế — quyết định làm thế nào để thực hiện. Kết quả đầu ra: biểu đồ cấu trúc (các mô-đun và tham số), sơ đồ khối hoặc giả mã cho từng mô-đun, bảng định danh và cấu trúc dữ liệu, bố trí màn hình và tập tin, cùng kế hoạch thử nghiệm được viết ngay lúc này, từ tài liệu yêu cầu, trước khi có bất kỳ mã nguồn nào.
lập trình (triển khai) — viết chương trình bằng ngôn ngữ cấp cao, theo từng mô-đun, tuân theo thiết kế; mỗi mô-đun được thử nghiệm ngay khi viết xong.
kiểm thử — chạy chương trình đối chiếu với kế hoạch thử nghiệm (dữ liệu bình thường, bất thường, cực đoan và biên) và sửa các lỗi tìm thấy; tiếp theo là thử nghiệm tích hợp, alpha, beta và chấp nhận.
bảo trì — sau khi phát hành, sửa lỗi, điều chỉnh chương trình cho phần cứng, phần mềm hoặc luật pháp mới, và cải tiến nó (xem bên dưới).
Ví dụ minh họa. Hoàn thành sơ đồ thác nước Phân tích → ? → ? → ? → Bảo trì và mô tả những gì xảy ra ở giai đoạn Thiết kế.
Các giai đoạn bị thiếu là Thiết kế, Lập trình, Kiểm thử. Ở giai đoạn Thiết kế, các yêu cầu được chuyển đổi thành kế hoạch cho chương trình: bài toán được phân rã thành các mô-đun (biểu đồ cấu trúc), thuật toán cho mỗi mô-đun được viết dưới dạng giả mã hoặc sơ đồ khối, các cấu trúc dữ liệu và định danh được chọn, màn hình và tập tin được bố trí, và kế hoạch thử nghiệm được viết từ tài liệu yêu cầu.
Explore · Khám phá
The program development life cycle · Vòng đời phát triển phần mềm
Step through the stages every project passes through. Getting the requirements right in analysis matters most — a mistake caught in testing is far costlier to fix than one caught early. · Đi qua từng giai đoạn mà dự án nào cũng trải qua. Việc thu thập đúng yêu cầu trong phân tích là quan trọng nhất — một lỗi phát hiện ra trong kiểm thử sẽ tốn kém hơn nhiều để sửa chữa so với việc phát hiện sớm.
Explore · Khám phá
Software process lab · Phòng thí nghiệm quy trình phần mềm
Classify development examples by the stage or tool they belong to. · Phân loại các ví dụ phát triển theo giai đoạn hoặc công cụ chúng thuộc về.
Program design tools · Công cụ thiết kế chương trình
Syllabus · Chương trình
English
Candidates should be able to:
Notes and guidance
Use a structure chart to decompose a problem into sub-tasks and express the parameters passed between the various modules/procedures/functions which are part of the algorithm design
Describe the purpose of a structure chart Construct a structure chart for a given problem Derive equivalent pseudocode from a structure chart
Show understanding of the purpose of state-transition diagrams to document an algorithm
Tiếng Việt
Thí sinh cần có thể:
Ghi chú và hướng dẫn
Sử dụng biểu đồ cấu trúc để phân rã một bài toán thành các tác vụ con và biểu diễn các tham số được truyền giữa các mô-đun/procedure/hàm khác nhau, là một phần của thiết kế thuật toán
Mô tả mục đích của biểu đồ cấu trúc Xây dựng biểu đồ cấu trúc cho một bài toán đã cho Rút ra giả mã tương đương từ biểu đồ cấu trúc
Thể hiện sự hiểu biết về mục đích của sơ đồ chuyển trạng thái để tài liệu hóa một thuật toán
Source: Cambridge International syllabus · Nguồn: Chương trình Cambridge International
English
Structure chart
A structure chart 结构图 shows the hierarchical decomposition 分解 of a program into modules (subroutines 子程序) and the parameters 参数 passed between them. Each module is a rectangle; lines link caller (above) to callee (below); small arrows show data going down and results coming back up. The design can then be turned into equivalent pseudocode 伪代码.
It is a design-stage tool, and you can read the procedure signatures off it.
The symbols the examiner asks about. A box is a module; a line links a caller (above) to the modules it calls (below), read left to right in the order they are called. A small arrow with an open circle at its tail is a data couple — a parameter passed down into a module or a value returned up; an arrow with a filled circle is a control couple, a flag (usually BOOLEAN) that tells the caller what happened. A diamond at a branch means selection: only one of the modules below it is called, depending on a condition. A curved arrow sweeping across the links means iteration: the modules under it are called repeatedly in a loop.
Worked example. Four modules are defined as PROCEDURE Main(), PROCEDURE ReadData(BYREF Count : INTEGER), FUNCTION IsValid(Value : INTEGER) RETURNS BOOLEAN and PROCEDURE Report(Total : INTEGER, Count : INTEGER). Main calls ReadData, then calls IsValid once for each value read, then calls Report. Describe the structure chart.
Main at the top; ReadData, IsValid and Report in a row beneath it, left to right in calling order. On the ReadData link an upward data couple Count (a BYREF parameter comes back). On the IsValid link a downward data couple Value and an upward control couple (the BOOLEAN result), with a curved iteration arrow across that link because it is called for each value. On the Report link two downward data couples, Total and Count. Reading the other way, a function is any module that returns a value — its header needs RETURNS and the returned type.
State-transition diagram
A state-transition diagram 状态转换图 shows the states 状态 a system can be in and the events that move it between them — good for vending machines, traffic lights, user interfaces. State-transition diagrams are used to document the behaviour of an algorithm or system. Each state is a circle; each transition is an arrow labelled with the event.
It makes missing transitions easy to spot ("what if a second coin is inserted while awaiting selection?").
Reading and drawing one. Each transition is labelled input | output (or condition | action): what happened, then what the system does as it changes state. A question gives a table of current state, input, output, next state and asks for the diagram, or the reverse — every row of the table is exactly one arrow. Check that every state has an arrow leaving it for every input that can occur, including the ones that leave the state unchanged (an arrow that loops back to the same state).
Worked example. A pump controller has states pump off and pump on. In pump off, the input low level detected produces the output activate pump and moves to pump on; in pump on, normal level detected produces deactivate pump and moves to pump off. Any other input leaves the state unchanged. Draw the table.
Current state
Input
Output
Next state
pump off
low level detected
activate pump
pump on
pump off
normal level detected
—
pump off
pump on
normal level detected
deactivate pump
pump off
pump on
low level detected
—
pump on
The two "no change" rows become loop arrows on the diagram; leaving them out loses the mark for completeness.
Tiếng Việt
Biểu đồ cấu trúc
Một biểu đồ cấu trúc thể hiện sự phân rã theo cấp bậc của một chương trình thành các mô-đun (hàm con) và các tham số được truyền giữa chúng. Mỗi mô-đun là một hình chữ nhật; các đường nối gọi hàm (trên) đến hàm được gọi (dưới); các mũi tên nhỏ chỉ dữ liệu đi xuống và kết quả quay lên. Thiết kế sau đó có thể được chuyển thành giả mã tương đương.
Đây là công cụ ở giai đoạn Thiết kế, và bạn có thể đọc các ký hiệu thủ tục trực tiếp từ biểu đồ.
Biểu đồ cấu trúc: các mô-đun với các tham số được truyền giữa chúng
Các ký hiệu mà giám khảo hay hỏi. Một ô vuông là một mô-đun; một đường nối kết nối người gọi (trên) đến các mô-đun mà nó gọi (dưới), đọc từ trái sang phải theo thứ tự được gọi. Một mũi tên nhỏ có vòng tròn mở ở gốc là một cặp dữ liệu — một tham số được truyền xuống vào mô-đun hoặc giá trị được trả lên; một mũi tên có vòng tròn đặc là một cặp điều khiển, một cờ (thường là BOOLEAN) báo cho người gọi biết điều gì đã xảy ra. Một hình thoi tại nhánh có nghĩa là lựa chọn: chỉ một trong các mô-đun bên dưới nó được gọi, tùy thuộc vào điều kiện. Một mũi tên cong quét ngang qua các đường nối có nghĩa là lặp lại: các mô-đun nằm dưới nó được gọi nhiều lần trong vòng lặp.
Các ký hiệu biểu đồ cấu trúc: cặp dữ liệu và cặp điều khiển, hình thoi lựa chọn và mũi tên lặp lại
Ví dụ minh họa. Bốn mô-đun được định nghĩa là PROCEDURE Main(), PROCEDURE ReadData(BYREF Count : INTEGER), FUNCTION IsValid(Value : INTEGER) RETURNS BOOLEAN và PROCEDURE Report(Total : INTEGER, Count : INTEGER). Main gọi ReadData, sau đó gọi IsValid một lần cho mỗi giá trị được đọc, rồi gọi Report. Hãy mô tả biểu đồ cấu trúc.
Main ở trên cùng; ReadData, IsValid và Report nằm ngang phía dưới, sắp xếp từ trái sang phải theo thứ tự gọi. Trên đường nối ReadData có cặp dữ liệu đi lên Count (tham số BYREF quay trở lại). Trên đường nối IsValid có cặp dữ liệu đi xuống Value và cặp điều khiển đi lên (kết quả BOOLEAN), kèm theo mũi tên lặp lại cong trên đường nối này vì nó được gọi cho mỗi giá trị. Trên đường nối Report có hai cặp dữ liệu đi xuống,分别是Total và Count. Đọc theo chiều ngược lại, một hàm là bất kỳ mô-đun nào trả về giá trị — phần đầu của nó cần có RETURNS và kiểu dữ liệu trả về.
Sơ đồ chuyển trạng thái
Một sơ đồ chuyển trạng thái hiển thị các trạng thái mà hệ thống có thể ở và các sự kiện di chuyển hệ thống giữa chúng — rất phù hợp cho máy bán hàng tự động, đèn giao thông, giao diện người dùng. Sơ đồ chuyển trạng thái được sử dụng để ghi chép hành vi của thuật toán hoặc hệ thống. Mỗi trạng thái là một hình tròn; mỗi sự chuyển đổi là một mũi tên được gắn nhãn với sự kiện.
Nó giúp dễ dàng phát hiện các sự chuyển đổi bị thiếu ("nếu chèn đồng xu thứ hai trong khi đang chờ lựa chọn thì sao?").
Sơ đồ chuyển trạng thái cho khóa cửa với mã 259
Đọc và vẽ sơ đồ. Mỗi sự chuyển đổi được gắn nhãn đầu vào | đầu ra (hoặc điều kiện | hành động): những gì đã xảy ra, sau đó hệ thống làm gì khi thay đổi trạng thái. Câu hỏi đưa ra bảng trạng thái hiện tại, đầu vào, đầu ra, trạng thái tiếp theo và yêu cầu vẽ sơ đồ, hoặc ngược lại — mỗi hàng của bảng chính xác là một mũi tên. Kiểm tra xem mỗi trạng thái có mũi tên ra ngoài cho mọi đầu vào có thể xảy ra, bao gồm cả những trường hợp giữ nguyên trạng thái (mũi tên vòng ngược về chính trạng thái đó).
Ví dụ minh họa. Bộ điều khiển bơm có các trạng thái tắt bơm và bật bơm. Trong tắt bơm, đầu vào phát hiện mực nước thấp tạo ra đầu ra kích hoạt bơm và chuyển sang bật bơm; trong bật bơm, phát hiện mực nước bình thường tạo ra phiên bản tắt bơm và chuyển sang tắt bơm. Mọi đầu vào khác giữ nguyên trạng thái. Hãy vẽ bảng.
Trạng thái hiện tại
Đầu vào
Đầu ra
Trạng thái tiếp theo
Tắt bơm
Phát hiện mực nước thấp
Kích hoạt bơm
Bật bơm
bơm tắt
mức bình thường được phát hiện
—
bơm tắt
bơm bật
mức bình thường được phát hiện
vô hiệu hóa bơm
bơm tắt
bơm bật
mức thấp được phát hiện
—
bơm bật
Hai hàng "không thay đổi" trở thành các mũi tên vòng lặp trên sơ đồ; nếu bỏ qua sẽ bị mất điểm vì thiếu tính toàn vẹn.
Explore · Khám phá
Software process lab · Phòng thí nghiệm quy trình phần mềm
Classify development examples by the stage or tool they belong to. · Phân loại các ví dụ phát triển theo giai đoạn hoặc công cụ chúng thuộc về.
Show understanding of the need for a test strategy and test plan and their likely contents
Choose appropriate test data for a test plan
Including normal, abnormal and extreme/boundary
Show understanding of the need for continuing maintenance of a system and the differences between each type of maintenance
Including perfective, adaptive, corrective
Analyse an existing program and make amendments to enhance functionality
Tiếng Việt
Thí sinh cần có thể:
Ghi chú và hướng dẫn
Thể hiện sự hiểu biết về các phương pháp phát hiện và tránh lỗi trong chương trình
Xác định và nhận diện các loại lỗi khác nhau
• lỗi cú pháp • lỗi logic • lỗi khi chạy chương trình
Sửa chữa các lỗi đã xác định
Thể hiện sự hiểu biết về các phương pháp kiểm thử có sẵn và chọn dữ liệu phù hợp cho một phương pháp cụ thể
Bao gồm chạy thử khô, walkthrough, hộp trắng, hộp đen, tích hợp, alpha, beta, chấp nhận, mô phỏng (stub)
Thể hiện sự hiểu biết về nhu cầu đối với chiến lược kiểm thử và kế hoạch kiểm thử cũng như nội dung dự kiến của chúng
Chọn dữ liệu kiểm thử phù hợp cho một kế hoạch kiểm thử
Bao gồm bình thường, bất thường và cực đoan/biên
Thể hiện sự hiểu biết về nhu cầu bảo trì liên tục của một hệ thống và sự khác biệt giữa từng loại hình bảo trì
Bao gồm hoàn thiện, phù thích, sửa chữa
Phân tích một chương trình hiện có và đưa ra các điều chỉnh để nâng cao chức năng
Source: Cambridge International syllabus · Nguồn: Chương trình Cambridge International
English
syntax error 语法错误 — breaks the language's grammar (missing bracket, misspelled keyword). Caught at translation time; the program won't run until fixed.
run-time error 运行时错误 — happens while running (divide by zero, file not found, array index out of range). The program crashes or raises an exception; fix by adding checks.
logic error 逻辑错误 — the program runs but gives wrong results (using + for -, an off-by-one loop, conditions in the wrong order). The hardest to find; the only sign is wrong output, so use careful testing and tracing.
Exposing and avoiding faults. Faults are exposed by testing against a test plan, by a dry run or trace table, by a walkthrough with colleagues, and by the IDE's debugger (breakpoints, single stepping, watching variables). They are avoided by designing before coding (structure chart, pseudocode), by modular code with meaningful identifiers and comments, by validation of every input, by handling exceptions rather than letting a run-time error crash the program, and by the IDE's dynamic syntax checks as you type.
Worked example. State the type of error in each case and how it shows itself. (a) Result <- STR_TO_NUM(x) / STR_TO_NUM(y) is run with y = "0". (b) The same line is run with x = "12a". (c) A loop written as FOR i <- 1 TO 9 processes a ten-element array. (d) OUTPUT "Total: " Total is missing a comma.
(a) Run-time error — division by zero; the program crashes when this line is executed with that data. (b) Run-time error — the string cannot be converted to a number. (c) Logic error — the program runs but the tenth element is never processed, so the output is wrong. (d) Syntax error — the statement breaks the language's rules and is reported by the translator before the program runs.
Worked example. Correct the errors in this pseudocode, which should output the average of ten marks.
The division should be by 10, not 9 (a logic error); the output line needs a comma or an & between the string and the value (a syntax error); and Average is never declared as REAL (a syntax or run-time error, depending on the language). Say which line and what the corrected line is: Average <- Total / 10.
Tiếng Việt
lỗi cú pháp — vi phạm ngữ pháp của ngôn ngữ (thiếu dấu ngoặc, viết sai từ khóa). Bị bắt khi dịch mã; chương trình không thể chạy cho đến khi được sửa.
lỗi thời gian chạy — xảy ra trong quá trình thực thi (chia cho số 0, không tìm thấy tập tin, chỉ số mảng vượt quá giới hạn). Chương trình bị sập hoặc ném ngoại lệ; sửa bằng cách thêm các kiểm tra.
lỗi logic — chương trình chạy nhưng đưa ra kết quả sai (dùng + thay vì -, vòng lặp lệch một bước, điều kiện sắp xếp sai thứ tự). Khó tìm nhất; dấu hiệu duy nhất là đầu ra sai, nên hãy sử dụng kiểm tra và truy vết cẩn thận.
Thời điểm xuất hiện từng loại lỗi: lỗi cú pháp tại lúc dịch, lỗi thời gian chạy trong lúc thực thi, lỗi logic tại kết quả đầu ra
Phát hiện và tránh các lỗi. Các lỗi bị phát hiện thông qua việc thử nghiệm theo kế hoạch thử nghiệm, chạy thử hoặc bảng truy vết, thảo luận cùng đồng nghiệp, và bộ gỡ lỗi của IDE (ngắt chương trình, chạy từng bước, theo dõi biến). Chúng được tránh khỏi bằng cách thiết kế trước khi viết code (biểu đồ cấu trúc, mã giả), viết code mô-đun với tên biến có ý nghĩa và chú thích, xác minh mọi dữ liệu đầu vào, xử lý ngoại lệ thay để lỗi thời gian chạy làm sập chương trình, và các kiểm tra cú pháp động của IDE khi bạn đang gõ.
Ví dụ đã giải. Nêu loại lỗi trong mỗi trường hợp và cách nó biểu hiện. (a) Result <- STR_TO_NUM(x) / STR_TO_NUM(y) được chạy với y = "0". (b) Dòng tương tự được chạy với x = "12a". (c) Một vòng lặp được viết là FOR i <- 1 TO 9 xử lý mảng mười phần tử. (d) OUTPUT "Total: " Total thiếu dấu phẩy.
(a) Lỗi thời gian chạy — chia cho số 0; chương trình bị sập khi dòng này được thực thi với dữ liệu đó. (b) Lỗi thời gian chạy — chuỗi không thể chuyển đổi thành số. (c) Lỗi logic — chương trình chạy nhưng phần tử thứ mười chưa bao giờ được xử lý, nên kết quả đầu ra bị sai. (d) Lỗi cú pháp — câu lệnh vi phạm quy tắc của ngôn ngữ và bị báo cáo bởi trình dịch trước khi chương trình chạy.
Ví dụ đã giải. Sửa các lỗi trong mã giả sau, vốn phải xuất trung bình cộng của mười điểm số.
Total <- 0
FOR i <- 1 TO 10
INPUT Mark
Total <- Total + Mark
NEXT i
Average <- Total / 9
OUTPUT "Average" Average
Phép chia phải là 10 chứ không phải 9 (lỗi logic); dòng xuất cần dấu phẩy hoặc & giữa chuỗi và giá trị (lỗi cú pháp); và Average chưa bao giờ được khai báo là REAL (lỗi cú pháp hoặc thời gian chạy, tùy thuộc vào ngôn ngữ). Hãy nói rõ dòng nào và dòng đã sửa là gì: Average <- Total / 10.
dry run 手工跟踪 — trace the code on paper, writing each variable's value in a table.
walkthrough 走查 — a team review of the code.
white-box testing 白盒测试 — designed from the code's internal structure, covering every statement, branch and loop.
black-box testing 黑盒测试 — designed from the specification only: feed inputs, check outputs.
integration testing 集成测试 — combine modules and test the interfaces between them.
alpha testing α测试 — by the developers/in-house before release; beta testing β测试 — by a limited group of real users in their own environment.
acceptance testing 验收测试 — by the customer, to decide if the product is fit for purpose.
stub 桩 — a placeholder for a module that does not exist yet, so the structure can be tested top-down.
Which method, when. A dry run and a walkthrough need no computer — the dry run is you, tracing the algorithm with a trace table 跟踪表; the walkthrough is a meeting in which the author explains the code line by line and colleagues look for faults, so it also spreads knowledge of the code through the team and checks it against the design. White-box tests are written by someone who can see the code and aims to exercise every path; black-box tests are written from the specification and check only inputs against expected outputs, so a user or a separate tester can do them. Integration testing follows module testing: modules that pass alone can still fail when the data passed between them is the wrong type or in the wrong order. Alpha testing is in-house; beta testing gives a release candidate to a sample of real users, who report faults from real use; acceptance testing is the customer checking the finished product against the requirements before paying for it. A stub lets top-down testing start before every module exists.
Worked example. After the program passed its in-house tests it was given to a group of users to try before release. Name this type of testing, and state what happens next.
Beta testing — real users in their own environment, reporting faults the developers did not find. The faults are corrected, then the customer carries out acceptance testing against the requirements and the program is released; faults found in live use are then handled by corrective maintenance.
Worked example. Give three benefits of testing a program by walkthrough.
Errors are found by people who did not write the code and so read it without assumptions; the logic is checked against the design and specification, not only against test data; several people learn how the code works, which helps later maintenance; and no test data or working computer is needed, so it can be done early.
Tiếng Việt
chạy thử — truy vết code trên giấy, ghi lại giá trị của từng biến vào bảng.
thảo luận — buổi xem xét nhóm đối với code.
thử nghiệm hộp trắng — thiết kế dựa trên cấu trúc nội bộ của code, bao phủ mọi câu lệnh, nhánh và vòng lặp.
thử nghiệm hộp đen — thiết kế chỉ dựa trên tài liệu yêu cầu: cung cấp đầu vào, kiểm tra đầu ra.
thử nghiệm tích hợp — kết hợp các mô-đun và thử nghiệm các giao diện giữa chúng.
thử nghiệm alpha α — do nhà phát triển/người trong công ty tiến hành trước khi phát hành; thử nghiệm beta β — do một nhóm nhỏ người dùng thực tế trong môi trường riêng của họ tiến hành.
thử nghiệm chấp nhận — do khách hàng tiến hành, để quyết định sản phẩm có đáp ứng mục đích hay không.
mô phỏng (stub) — một chỗ trống cho một mô-đun chưa tồn tại, để cấu trúc có thể được thử nghiệm từ trên xuống.
Hộp đen thử nghiệm tài liệu yêu cầu; hộp trắng thử nghiệm các đường đi của code
Phương pháp nào, khi nào. Một chạy thử và một thảo luận không cần máy tính — chạy thử là bạn tự mình truy vết thuật toán bằng bảng truy vết; thảo luận là cuộc họp mà tác giả giải thích code từng dòng và đồng nghiệp tìm kiếm lỗi, vì vậy nó cũng lan truyền kiến thức về code trong nhóm và kiểm tra code so với thiết kế. Hộp trắng được viết bởi người có thể nhìn thấy code và nhằm mục đích kích hoạt mọi đường đi; hộp đen được viết từ tài liệu yêu cầu và chỉ kiểm tra đầu vào so với đầu ra dự kiến, nên người dùng hoặc người thử nghiệm độc lập có thể thực hiện chúng. Tích hợp thử nghiệm diễn ra sau thử nghiệm mô-đun: các mô-đun đạt yêu cầu khi chạy riêng vẫn có thể thất bại khi dữ liệu truyền giữa chúng không đúng kiểu hoặc sai thứ tự. Alpha thử nghiệm diễn ra trong nội bộ; beta thử nghiệm cung cấp bản ứng cử viên phát hành cho một mẫu người dùng thực tế, những người báo cáo lỗi từ việc sử dụng thực tế; chấp nhận thử nghiệm là khách hàng kiểm tra sản phẩm hoàn thiện so với các yêu cầu trước khi thanh toán. Một mô phỏng (stub) cho phép thử nghiệm từ trên xuống bắt đầu trước khi tất cả các mô-đun đều tồn tại.
Một stub đóng vai thay thế cho một mô-đun chưa được viết, để các mô-đun nằm phía trên có thể được thử nghiệm ngay bây giờ
Ví dụ đã giải. Sau khi chương trình vượt qua các thử nghiệm nội bộ, nó được giao cho một nhóm người dùng thử trước khi phát hành. Gọi tên loại thử nghiệm này và nêu những gì sẽ xảy ra tiếp theo.
Beta thử nghiệm — người dùng thực tế trong môi trường của họ, báo cáo các lỗi mà nhà phát triển không tìm thấy. Các lỗi được sửa chữa, sau đó khách hàng tiến hành thử nghiệm chấp nhận so với các yêu cầu và chương trình được phát hành; các lỗi được tìm thấy trong quá trình sử dụng thực tế sau đó được xử lý bởi bảo trì sửa chữa.
Ví dụ đã giải. Đưa ra ba lợi ích của việc thử nghiệm chương trình bằng phương pháp thảo luận.
Lỗi được phát hiện bởi những người không viết mã và do đó đọc nó mà không có giả định; logic được kiểm tra so với thiết kế và yêu cầu, không chỉ so với dữ liệu thử nghiệm; nhiều người học cách mã hoạt động, điều này giúp bảo trì sau này; và không cần dữ liệu thử nghiệm hoặc máy tính đang chạy, vì vậy có thể thực hiện ngay từ đầu.
Test strategy and test plan · Chiến lược thử nghiệm và kế hoạch thử nghiệm
English
A test strategy 测试策略 is the high-level approach — which kinds of testing, who does them, when, and the criteria to move on. A test plan 测试计划 is the detailed list of tests — each with input data, expected output, and a column for the actual output.
What each contains. A test strategy states which testing methods will be used at which stage (module testing by the programmer, then integration, alpha, beta, acceptance), who is responsible for each, what test data is required, and the criteria for passing to the next stage. A test plan lists the individual tests: for each, the module or feature under test, the input data, the reason the data was chosen (normal, abnormal, extreme, boundary), the expected result, a space for the actual result, and what to do if they differ. The plan is written at the design stage, from the specification, so that it tests what the program should do rather than what it happens to do.
Choosing test data
For each field or condition, include three kinds:
normal data 正常数据 — typical values inside the valid range (for marks 0–100: 50, 75).
abnormal data 异常数据 — values that should be rejected (-10, 200, "abc").
extreme data 极端数据 — the largest and smallest values still accepted (0 and 100).
boundary data 边界数据 — values at the edges, where off-by-one errors hide (each accepted extreme and the rejected value just outside it: 0/-1, 100/101).
Worked example. A field accepts an exam mark from 0 to 100. Give test data of each kind with its expected result. Normal: 50 - accepted, a typical value inside the range. Abnormal: -10, 200, "abc" - all rejected, being out of range or the wrong data type. Extreme: 0 and 100 - the largest and smallest values that are still accepted. Boundary: the pairs straddling each edge - -1 rejected alongside 0 accepted, and 100 accepted alongside 101 rejected. Every value must carry its expected result, or the test plan proves nothing. Extreme and boundary are the pair most often confused: an extreme value sits inside and is accepted, while a boundary test is always a pair either side of the edge - which is exactly where off-by-one errors hide.
Worked example. A component passes if its weight, measured to the nearest gram, is within 3 g of the target of 50 g, i.e. from 47 g to 53 g inclusive. Draw up the test-plan rows for the check.
Test data
Type
Reason
Expected result
50
normal
a typical value well inside the range
accepted
47, 53
extreme (boundary)
the smallest and largest values that must still be accepted
accepted
46, 54
boundary
the values just outside the range, where an off-by-one error would accept them
rejected
20, 90
abnormal
values far outside the range
rejected
"abc", −5
abnormal
the wrong type, a negative weight
rejected
Each row must say why the value was chosen and what should happen; a bare list of numbers earns nothing.
Tiếng Việt
Một chiến lược thử nghiệm là phương pháp tổng quát — các loại thử nghiệm nào, ai làm, khi nào, và tiêu chuẩn để chuyển sang giai đoạn tiếp theo. Một kế hoạch thử nghiệm là danh sách chi tiết các bài kiểm tra — mỗi bài bao gồm dữ liệu đầu vào, kết quả mong đợi, và một cột cho kết quả thực tế.
Mỗi phần chứa gì.Chiến lược thử nghiệm nêu rõ phương pháp thử nghiệm nào sẽ được sử dụng ở giai đoạn nào (thử nghiệm mô-đun bởi lập trình viên, sau đó là tích hợp, alpha, beta, chấp nhận), ai chịu trách nhiệm cho từng phần, dữ liệu thử nghiệm cần thiết là gì, và tiêu chuẩn để chuyển sang giai đoạn tiếp theo. Kế hoạch thử nghiệm liệt kê từng bài kiểm tra cụ thể: đối với mỗi bài, mô-đun hoặc tính năng đang được thử, dữ liệu đầu vào, lý do chọn dữ liệu đó (bình thường, bất thường, cực trị, biên), kết quả mong đợi, khoảng trống cho kết quả thực tế, và những gì nên làm nếu chúng khác nhau. Kế hoạch được viết ở giai đoạn thiết kế, dựa trên yêu cầu, để đảm bảo kiểm tra những gì chương trình nên làm thay vì những gì nó ngẫu nhiên làm.
Chọn dữ liệu thử nghiệm
Đối với mỗi trường hoặc điều kiện, hãy bao gồm ba loại:
dữ liệu bình thường — các giá trị điển hình nằm trong phạm vi hợp lệ (đối với điểm số 0–100: 50, 75).
dữ liệu bất thường — các giá trị nên bị từ chối (-10, 200, "abc").
dữ liệu cực trị — giá trị lớn nhất và nhỏ nhất vẫn được chấp nhận (0 và 100).
dữ liệu biên — các giá trị tại các cạnh, nơi ẩn chứa lỗi sai lệch một đơn vị (mỗi giá trị cực trị được chấp nhận và giá trị bị từ chối ngay bên ngoài nó: 0/-1, 100/101).
Dữ liệu thử nghiệm cho trường 0–100: bình thường bên trong, cực trị tại các biên, bất thường bên ngoài
Ví dụ giải. Một trường chấp nhận điểm thi từ 0 đến 100. Hãy đưa ra dữ liệu thử nghiệm của mỗi loại kèm kết quả dự kiến. Bình thường: 50 - được chấp nhận, là giá trị điển hình nằm trong khoảng. Bất thường: -10, 200, "abc" - tất cả bị từ chối, do nằm ngoài khoảng hoặc sai định dạng dữ liệu. Cực trị: 0 và 100 - giá trị lớn nhất và nhỏ nhất mà vẫn được chấp nhận. Biên giới: các cặp跨越 mỗi cạnh - -1 bị từ chối cùng với 0 được chấp nhận, và 100 được chấp nhận cùng với 101 bị từ chối. Mỗi giá trị đều phải có kết quả dự kiến, nếu không bản kiểm thử sẽ vô nghĩa. Cực trị và biên giới là cặp khái niệm dễ nhầm lẫn nhất: giá trị cực trị nằm bên trong và được chấp nhận, trong khi kiểm tra biên giới luôn là một cặp ở hai phía của cạnh -这正是 one-off errors ẩn náu之处。
Ví dụ minh họa. Một thành phần đạt yêu cầu nếu trọng lượng của nó, đo đến gần gram nhất, nằm trong khoảng 3 g so với mục tiêu 50 g, tức là từ 47 g đến 53 g bao gồm. Hãy lập các hàng trong kế hoạch thử nghiệm cho phép kiểm tra này.
Dữ liệu thử nghiệm
Loại
Lý do
Kết quả mong đợi
50
bình thường
một giá trị điển hình nằm sâu trong phạm vi
được chấp nhận
47, 53
cực trị (biên)
giá trị nhỏ nhất và lớn nhất vẫn phải được chấp nhận
được chấp nhận
46, 54
biên
các giá trị ngay bên ngoài phạm vi, nơi lỗi sai lệch một đơn vị sẽ chấp nhận chúng
bị từ chối
20, 90
bất thường
các giá trị nằm xa khỏi phạm vi
bị từ chối
"abc", −5
bất thường
sai kiểu, trọng lượng âm
bị từ chối
Mỗi hàng phải giải thích tại sao giá trị đó được chọn và sẽ xảy ra điều gì; chỉ liệt kê các con số thuần túy thì không đạt điểm.
12.3
Maintenance · Bảo trì
English
Most of a program's lifetime cost is in maintenance. Three kinds:
perfective maintenance 完善性维护 — improving performance or features even though it works (a faster query, a new option).
adaptive maintenance 适应性维护 — keeping it working in a changing environment (a new OS, a new API, a legal change).
corrective maintenance 纠正性维护 — fixing bugs found in use.
A program may need all three throughout its life.
Why each is needed — the reasons the mark scheme lists.Corrective: a fault is reported by a user after release, or an incorrect output is noticed in particular circumstances that testing did not cover. Adaptive: the operating system, hardware or browser is upgraded; a law or company rule changes (tax rates, data-protection requirements); the program must work with a new external system or file format. Perfective: users ask for extra features or a better interface; the program is made faster or made to use less memory; the code is tidied to make future changes easier.
Worked example. (a) A released program outputs a wrong value under certain circumstances. (b) The hardware that runs a program is replaced. (c) Customers ask for the coffee-shop loyalty program to send a message on a customer's birthday. Name the maintenance type in each case.
(a) Corrective — a fault in the delivered program is being fixed. (b) Adaptive — the program is changed to run in its new environment. (c) Perfective — a feature is added to a program that already works.
Tiếng Việt
Hầu hết chi phí vòng đời của một chương trình nằm ở việc bảo trì. Ba loại:
Ba loại bảo trì: hoàn thiện, thích nghi và sửa chữa
bảo trì hoàn thiện — cải thiện hiệu suất hoặc tính năng dù nó vẫn hoạt động tốt (truy vấn nhanh hơn, tùy chọn mới).
bảo trì thích nghi — duy trì hoạt động trong môi trường thay đổi (hệ điều hành mới, API mới, thay đổi pháp lý).
bảo trì sửa chữa — khắc phục các lỗi tìm thấy khi sử dụng.
Một chương trình có thể cần cả ba loại trong suốt vòng đời của nó.
Tại sao mỗi loại cần thiết — các lý do được liệt kê trong bảng chấm điểm.Sửa chữa: một lỗi được báo cáo bởi người dùng sau khi phát hành, hoặc kết quả sai được chú ý trong các tình huống cụ thể mà quá trình thử nghiệm chưa bao phủ. Thích nghi: hệ điều hành, phần cứng hoặc trình duyệt được nâng cấp; luật hoặc quy định công ty thay đổi (tỷ lệ thuế, yêu cầu bảo vệ dữ liệu); chương trình phải hoạt động với một hệ thống bên ngoài hoặc định dạng tệp mới. Hoàn thiện: người dùng yêu cầu thêm tính năng hoặc giao diện tốt hơn; chương trình được làm nhanh hơn hoặc sử dụng ít bộ nhớ hơn; mã được sắp xếp gọn gàng để việc thay đổi trong tương lai dễ dàng hơn.
Ví dụ minh họa. (a) Một chương trình đã phát hành xuất ra giá trị sai trong một số trường hợp. (b) Phần cứng chạy chương trình được thay thế. (c) Khách hàng yêu cầu chương trình_OCC loyalty của quán cà phê gửi tin nhắn vào ngày sinh nhật khách hàng. Hãy đặt tên loại bảo trì trong từng trường hợp.
(a) Sửa chữa — một lỗi trong chương trình được giao đang được khắc phục. (b) Thích nghi — chương trình được thay đổi để chạy trong môi trường mới. (c) Hoàn thiện — một tính năng được thêm vào một chương trình vốn đã hoạt động tốt.
Amending an existing program · Sửa đổi chương trình hiện có
English
When asked to add a feature or fix a bug:
read the existing code until you understand the algorithm and data flow.
find where the change goes — which subroutine, which lines.
make the change as small as possible — don't rewrite working code.
update related parts — every caller of a changed parameter list, every routine using a changed data structure.
test the new behaviour and the old (regression testing 回归测试 — check you broke nothing).
document the change.
Clear comments, meaningful names, decomposed subroutines and a structure chart make a program much easier to amend — which is why the design tools matter even after the first release.
Analysing a program you did not write. Start from the identifier table and the module headers: they tell you what each module receives and returns before you read a line of its body. Then trace the algorithm with a trace table for one small input, noting where each output value comes from. Only then decide where the enhancement goes — usually a new module called from the existing one, so the working code is disturbed as little as possible — and write the pseudocode for the change and the test data that proves it.
Tiếng Việt
Khi được yêu cầu thêm tính năng hoặc sửa lỗi:
đọc mã hiện có cho đến khi hiểu thuật toán và luồng dữ liệu.
tìm nơi thay đổi diễn ra — subroutine nào, dòng nào.
tạo thay đổi nhỏ nhất có thể — không viết lại mã đang hoạt động.
cập nhật các phần liên quan — mọi nơi gọi danh sách tham số đã thay đổi, mọi thủ tục sử dụng cấu trúc dữ liệu đã thay đổi.
kiểm thử hành vi mới và hành vi cũ (kiểm thử suy thoái — đảm bảo bạn không làm hỏng điều gì).
đocumented hóa sự thay đổi.
Bình luận rõ ràng, tên gọi có ý nghĩa, các thủ tục con được phân tách và biểu đồ cấu trúc giúp chương trình dễ chỉnh sửa hơn — đó là lý do các công cụ thiết kế vẫn quan trọng ngay cả sau lần phát hành đầu tiên.
Phân tích một chương trình bạn không tự viết. Bắt đầu từ bảng định danh và tiêu đề mô-đun: chúng cho biết mỗi mô-đun nhận và trả về cái gì trước khi đọc dòng nào của thân chương trình. Sau đó theo dõi thuật toán bằng bảng theo dõi với một đầu vào nhỏ, ghi chú xem mỗi giá trị đầu ra đến từ đâu. Chỉ sau đó mới quyết định vị trí cải tiến — thường là một mô-đun mới được gọi từ mô-đun hiện có, để mã đang hoạt động bị tác động ít nhất có thể — và viết mã giả cho sự thay đổi cùng dữ liệu kiểm thử chứng minh nó.
12.3
Definitions the examiner accepts · Các định nghĩa mà giám khảo chấp nhận
English
A definition question is marked against fixed wording. Learn these exactly, and give one answer only.
Term
Definition
development life cycle
the sequence of stages, from analysis to maintenance, followed to produce and support a program
waterfall model
a life cycle in which the stages are carried out in a fixed order, each completed before the next begins
iterative model
a life cycle in which a working version is produced and then repeatedly refined until it is complete
rapid application development
a life cycle that builds prototypes quickly, refining them with user feedback until they are accepted
structure chart
a diagram that shows how a program is decomposed into modules, the order in which they are called and the parameters passed between them
state-transition diagram
a diagram that shows the states a system can be in and the inputs that cause it to move between them
syntax error
an error in the way a statement is written, so it breaks the rules of the language and cannot be translated
logic error
an error in the algorithm, so the program runs but produces the wrong result
run-time error
an error that occurs while the program is running, such as division by zero, and stops it
dry run
working through the algorithm by hand, recording the values of the variables in a trace table
walkthrough
a review in which the author steps through the code with colleagues who look for errors
stub
a placeholder module with the correct header that returns a fixed value, used so the modules that call it can be tested
test plan
a list of the tests to be carried out, each with its test data, the reason for the data and the expected result
boundary data
values at each edge of the valid range, both the last value accepted and the first value rejected
corrective / adaptive / perfective maintenance
fixing faults found in use / changing the program to suit a changed environment / improving a program that already works
Tiếng Việt
Câu hỏi định nghĩa được chấm dựa trên văn phong cố định. Hãy học thuộc những định nghĩa này và chỉ đưa ra một đáp án duy nhất.
Thuật ngữ
Định nghĩa
vòng đời phát triển
chuỗi các giai đoạn, từ phân tích đến bảo trì, được tuân theo để tạo ra và hỗ trợ một chương trình
mô hình thác nước
một vòng đời trong đó các giai đoạn được thực hiện theo thứ tự cố định, mỗi giai đoạn hoàn tất trước khi giai đoạn tiếp theo bắt đầu
mô hình lặp
một vòng đời trong đó phiên bản hoạt động được sản xuất và sau đó liên tục tinh chỉnh cho đến khi hoàn thiện
phát triển ứng dụng nhanh chóng
một vòng đời xây dựng prototyp nhanh chóng, tinh chỉnh chúng với phản hồi của người dùng cho đến khi được chấp nhận
biểu đồ cấu trúc
sơ đồ hiển thị cách một chương trình được phân tách thành các mô-đun, thứ tự gọi chúng và các tham số truyền giữa chúng
biểu đồ chuyển trạng thái
sơ đồ hiển thị các trạng thái mà hệ thống có thể ở và các đầu vào khiến nó di chuyển giữa các trạng thái đó
lỗi cú pháp
lỗi trong cách viết câu lệnh, khiến nó vi phạm quy tắc của ngôn ngữ và không thể dịch được
lỗi logic
lỗi trong thuật toán, khiến chương trình chạy nhưng tạo ra kết quả sai
lỗi thời gian chạy
lỗi xảy ra khi chương trình đang chạy, chẳng hạn như chia cho số không, và làm dừng nó lại
chạy thử tay
thực thi thuật toán bằng tay, ghi lại các giá trị biến trong bảng theo dõi
duyệt qua
một cuộc xem xét trong đó tác giả đi qua từng bước mã cùng đồng nghiệp tìm kiếm lỗi
stub
mô-đun giữ chỗ với tiêu đề đúng trả về giá trị cố định, dùng để các mô-đun gọi nó có thể được kiểm thử
kế hoạch kiểm thử
danh sách các bài kiểm thử sẽ được thực hiện, mỗi bài kèm dữ liệu kiểm thử, lý do chọn dữ liệu và kết quả mong đợi
dữ liệu biên
các giá trị tại mỗi cạnh của khoảng hợp lệ, bao gồm cả giá trị cuối cùng được chấp nhận và giá trị đầu tiên bị từ chối
bảo trì sửa lỗi / thích ứng / hoàn thiện
sửa chữa lỗi tìm thấy khi sử dụng / thay đổi chương trình để phù hợp với môi trường thay đổi / cải thiện một chương trình đã hoạt động tốt
12.3
Exam tips · Mẹo làm bài thi
English
Compare development models (waterfall, iterative, RAD) by principle, benefit, drawback, and know the five stages of the program development life cycle and what each produces.
Distinguish syntax, logic and run-time errors by when each shows itself: at translation, in the output, during the run.
Choose test data of every kind — normal, abnormal, extreme and boundary — and give each value with its reason and expected result.
Distinguish the types of maintenance (corrective, adaptive, perfective) by why the change is being made.
On a structure chart, name every symbol: box, calling line, data couple, control couple, selection diamond, iteration arrow. Reading module headers off a chart, remember a function has RETURNS.
Common mistakes
Describing a life cycle stage by its name only ("in the design stage the program is designed"). Say what is produced: structure chart, pseudocode, test plan.
Calling a wrong output a "run-time error". If the program runs to the end, it is a logic error.
Giving boundary data as just the extremes. The mark needs the values on both sides of the edge.
Treating alpha and beta testing as the same. Alpha is in-house by the developers; beta is by real users outside.
Confusing adaptive and perfective maintenance. Adaptive responds to a change outside the program; perfective improves a program nobody had to change.
Drawing a structure chart with the modules in any order. They read left to right in the order they are called, and each parameter needs its arrow.
Tiếng Việt
So sánh các mô hình phát triển (thác nước, lặp, RAD) dựa trên nguyên tắc, lợi ích, nhược điểm, và nắm vững năm giai đoạn của vòng đời phát triển chương trình cũng như những gì mỗi giai đoạn tạo ra.
Phân biệt lỗi cú pháp, logic và thời gian chạy dựa trên khi nào chúng xuất hiện: lúc dịch, trong đầu ra, hoặc trong quá trình chạy.
Chọn dữ liệu kiểm thử mọi loại — bình thường, bất thường, cực đoan và biên — và cung cấp mỗi giá trị kèm lý do và kết quả mong đợi.
Phân biệt các loại bảo trì (sửa lỗi, thích ứng, hoàn thiện) dựa trên tại sao sự thay đổi đang được thực hiện.
Trên biểu đồ cấu trúc, đặt tên mọi ký hiệu: ô vuông, đường gọi, cặp dữ liệu, cặp điều khiển, kim cương lựa chọn, mũi tên lặp. Khi đọc tiêu đề mô-đun từ biểu đồ, hãy nhớ một hàm có RETURNS.
Lỗi thường gặp
Mô tả một giai đoạn vòng đời chỉ bằng tên gọi ("ở giai đoạn thiết kế thì chương trình được thiết kế"). Hãy nói rõ sản phẩm tạo ra: biểu đồ cấu trúc, mã giả, kế hoạch kiểm thử.
Gọi sai đầu ra là "lỗi thời gian chạy". Nếu chương trình chạy đến hết, đó là lỗi logic.
Cung cấp dữ liệu biên chỉ là các giá trị cực trị. Điểm cần phải có các giá trị ở cả hai phía của biên.
Coi kiểm thử alpha và beta là giống nhau. Alpha là nội bộ do nhà phát triển thực hiện; beta là do người dùng thật bên ngoài thực hiện.
Nhầm lẫn bảo trì thích ứng và hoàn thiện. Thích ứng phản ứng với sự thay đổi bên ngoài chương trình; hoàn thiện cải thiện một chương trình không ai buộc phải thay đổi.
Vẽ biểu đồ cấu trúc với các mô-đun theo bất kỳ thứ tự nào. Chúng được đọc từ trái sang phải theo thứ tự gọi, và mỗi tham số cần có mũi tên tương ứng.
Interactive lessons on this topic · Bài học tương tác về chủ đề này
Work through it step by step, with instant-check exercises. · Làm theo từng bước, kèm theo bài tập kiểm tra ngay lập tức.
More topics in A-Level Computer Science · Khoa học máy tính A-Level · Nhiều chủ đề hơn trong A-Level Computer Science · Khoa học máy tính A-Level
Pick one and the site follows you — notes, papers, videos and practice all open on it. · Chọn một môn và trang sẽ điều hướng theo — ghi chú, tài liệu, video và bài tập đều mở ở đó.
Type to search notes, lessons, code, vocabulary and past-paper questions across every subject. · Nhập để tìm ghi chú, bài học, mã, từ vựng và câu hỏi đề thi cũ trên mọi môn học.
*Sơ đồ luồng lên kế hoạch cho logic chương trình trong giai đoạn thiết kế của chu kỳ
*Mô hình thác nước: mỗi giai đoạn phải hoàn tất trước khi giai đoạn sau bắt đầu
*Mô hình lặp: các lần lặp lại giúp tinh chỉnh chương trình
*Phát triển ứng dụng nhanh: các đội làm việc trên các phần khác nhau song song
