Câu hỏi ôn tập nhập môn công nghệ phần mềm ppt

Câu hỏi ôn tập nhập môn công nghệ phần
mềm
Câu 1:
Để xem xét một dự án tin học có khả thi hay không thì cần phương pháp luận để đánh giá.
Với giả thiết không yêu cầu cài đặt đặc biệt nào cả, ứng dụng tự nó phải là nhân tố cơ bản để
quyết định phương pháp luận.
+ trong mt kinh doanh, các quy luật cơ bản để lựa chọn phương pháp luận nhằm đánh giá sự
phức tạp của ứng dụng 1 cách tốt nhất.
+ Nếu sự phức tạp trong thủ tục, 1 pp hướng xử lý là tốt nhất.
+ Nếu sự phức tạp trong liên kết dữ liệu, 1 pp luận hướng dữ liệu là tốt nhất.
+ Nếu bài toán dễ dàng chia nhỏ ra thành một chuỗi các bài toán nhỏ, mộ pp đối tượng sẽ là tốt
nhất.
+ Nếu dự án là nhằm xử lý trí tuệ nhân tạo hoặc bao gồm suy diễn, 1 pp luận ngữ nghĩa là tốt
nhất.
Câu 2:
* Phần mềm Rational rose:
- Rational Rose là một công cụ lập mô hình trực quan mạnh trợ giúp bạn phân tích và thiết kế các hệ
thống phần mềm hướng đối tượng. Nó được dùng để lập mô hình hệ thống trước khi bạn viết mã
(code). Dùng mô hình, bạn có thể bắt kịp những thiếu sót về thiết kế, trong khi việc chỉnh sửa chúng
vẫn chưa tốn kém. − Mô hình Rose là bức tranh về một hệ thống từ nhiều góc nhìn khác nhau. Nó
bao gồm tất cả các sơ đồ UML, các actor, các use case, các đối tượng, các lớp, các thành phần… Nó
mô tả chi tiết nội dung mà hệ thống sẽ gộp và cách nó sẽ làm việc.
Câu 3:
Mô tả mô hình 3 tầng của công nghệ phần mềm:
Mô hình 3 tầng hay còn gọi là mô hình 3-tiers: là một kiến trúc kiểu client/server mà trong đó giao
diện người dùng (UI-user interface), các quy tắc xử lý(BR-business rule hay BL-business logic), và
việc lưu trữ dữ liệu được phát triển như những module độc lập, và hầu hết là được duy trì trên các
nền tảng độc lập, và mô hình 3 tầng (3-tiers) được coi là một kiến trúc phần mềm và là một mẫu thiết
kế.
Như vậy, ta có thể mô hình này phân tách ứng dụng ra làm 3 module riêng biệt, bao gồm:
- Tầng Presentation: tầng này làm nhiệm vụ giao tiếp với người dùng cuối để thu thập dữ liệu và

hiển thị kết quả/dữ liệu thông qua các thành phần trong giao diện người sử dụng. tầng này sẽ sử
dụng các dịch vụ do lớp Business Logic cung cấp. Trong .NET thì bạn có thể dùng Windows
Forms, ASP.NET hay Mobile Forms để hiện thực tầng này. Trong lớp này có 2 thành phần chính
là User Interface Components và User Interface Process Components.
- Tầng Business Logic: tầng này thực hiện các nghiệp vụ chính của hệ thống, sử dụng các dịch vụ do
tầng Data Access cung cấp, và cung cấp các dịch vụ cho tầng Presentation. Tầng này cũng có thể sử
dụng các dịch vụ của các nhà cung cấp thứ 3 (3rd parties) để thực hiện công việc của mình(ví dụ như
sử dụng dịch vụ của các cổng thanh tóan trực tuyến như VeriSign, Paypal…). Trong lớp này có các
thành phần chính là Business Components, Business Entities và Service Interface.
- Tầng Data: Tầng này thực hiện các nghiệp vụ liên quan đến lưu trữ và truy xuất dữ liệu của ứng
dụng. Thường tầng này sẽ sử dụng các dịch vụ của các hệ quản trị cơ sở dữ liệu như SQL Server,
Oracle,… để thực hiện nhiệm vụ của mình. Trong tầng này có các thành phần chính là Data Access
Logic, Data Sources, Servive Agents).
3-tiers là một kiến trúc phần mềm, có nghĩa là bạn có thể dùng nó để xây dựng nên bộ khung tổng
thể của ứng dụng. Tuy nhiên bạn cần chú ý những ưu và nhược điểm sau đây để áp dụng nó một
cách đúng đắn.
Ưu điểm:
- Dễ dàng mở rộng, thay đổi quy mô của hệ thống: Khi cần tải lớn, người quản trị có thể dễ dàng
thêm các máy chủ vào nhóm, hoặc lấy bớt ra trong trường hợp ngược lại.
Nhược điểm:
- Việc truyền dữ liệu giữa các tầng sẽ chậm hơn vì phải truyền giữa các tiến trình khác nhau (IPC),
dữ liệu cần phải được đóng gói -> truyền đi -> mở gói trước khi có thể dùng được.
- Việc phát triển ứng dụng phức tạp hơn.
Trong 3-tiers, quá trình đi theo chiều dọc, bắt đầu từ Presentation, sang BL, rồi tới Data, và từ Data,
chạy ngược lại BL rồi quay ra lại Presentation.
Câu 4:
*Mô tả mô hình đài phun nước:
- Đây là mô hình của cách tiếp cận hướng đối tượng, hệ thống được xem là một hệ thống các thực
thể tác động qua lại để đạt được mục đích nào đó. Mô hình này tương ứng với mô hình thác nước
trong cách tiếp cận hướng thủ tục ở trên. Ở đây ta thấy trong có những phần lặp và giao nhau giữa

các bước phân tích, thiết kế và cài đặt.
Các điểm chính của mô hình được tóm tắt như sau(học vở)
*Mô hình phát triển dựa trên thành phần:
Xuất phát từ quan điểm: “Buy do not build”, tư tưởng của phát triển dựa trên thành phần là lắp ráp
hệ thống dựa trên những thành phần đã có. Do vậy, kiến trúc phần mềm của hệ thống dựa vào kiến
trúc phần mềm của các thành phần phần mềm tiêu chuẩn nên hệ thống đạt chất lượng cao hơn.
Phương pháp phát triển thành phần dựa trên thành phần tương tự như phương pháp phát triển hướng
đối tượng. Hoạt động công nghệ bắt đầu với sự chỉ ra các lớp tham dự để phát triển hệ thống.
Thành phần phần mềm được sử dụng lại có độ chính xác cao và có thể nói là không chứa lỗi.
Khi những thành phần sử dụng lai được ứng dụng thông qua tiến trình phần mềm, chúng ta tốn ít
thời gian để tạo ra kế hoạch, mô hình, tài liệu, mã và dữ liệu mà chúng ta cần thiết để tạo ra hệ
thống. Thêm vào, chức năng cùng mức được phân phối cho người sử dụng với đầu vào ít công sức
hơn, hiệu suất phần mềm được cải thiện.
Câu 5: Tính toàn vẹn của tiêu chuẩn phần mềm:
Sản phẩm phần mềm có tính toàn vẹn khi nó:
- Có cơ chế thâm nhập bất hợp pháp vào phần mềm hay dữ liệu và ngăn ngừa việc phát sinh ra
những đối tượng (dữ liệu, đơn thể…) sai wy cách hoặc mâu thuẫn với các đối tượng sẵn có.
- Không gây ra nhập nhằng trong thao tác, đảm bảo nhất quán về cú pháp.
- Có cơ chế phục hồi lại toàn bộ hoặc một phần những đối tượng thuộc toàn bộ hoặc một phần
những đối tượng thuộc diện quản lý của sản phẩm trong trường hợp có sự cố như hỏng máy,
mất điện đột ngột.
Câu 6:
Khác nhau:
Đặc tả phi hình thức Đặc tả hình thức
- Là đặc tả sử dụng ngôn ngữ tự nhiên
- Không chặt chẽ.
- Được nhiều người biết và để trao đổi zới
nhau làm chính xác các điểm chưa rõ,
chưa thống nhất giữa các bên phát triển
hệ thống.

- Chi phí thấp hơn đặc tả hình thức.
- Không thuận tiện cho các thiết kế viên
hoặc các hợp đồng giữa khách hàng và
cán bộ phát triển hệ thống.
- Là đặc tả mà ở đó các từ ngữ, cú pháp,
ngữ nghĩa được định nghĩa hình thức
dựa vào toán học.
- Chặt chẽ.
- Được coi là một phần của hoạt động đặc
tả phần mềm.
- Cho thấy được bản chất bên trong của
các yêu cầu > cách tốt để giảm các lỗi,
các thiếu sót có thể xảy ra, giúp công
việc thiết kế được thuận lợi.
- Khách hàng không thích đặc tả toán học
- Chi phí cao hơn các đặc ta khác
- Tính chắc chắn và đầy đủ của hệ thống
do dựa vào các công cụ toán học khi
phân tích.
- Giống nhau: đều là đặc tả yêu cầu. Các đặc tả này thường biểu diễn cùng với các mô hình hệ
thống được phát triển trong quá trình phân tích yêu cầu
Câu 7:
Kỹ thuật để thu thập dữ liệu nào mà thuận lợi cho người thu thập dữ liệu có 1 kỹ thuật. Đó là kỹ
thuật họp nhóm.
Giải thjx:
- Họp nhóm phù hợp với mọi kiểu dữ liệu do đó được thường xuyên use.
- Họp nhóm có thể vừa bổ sung vừa thay thế Phỏng vấn. Nó bổ sung phỏng vấn bằng cách cho
phép nhóm ktra lại kwa phỏng vấn cá nhân. Nó thay thể cho phỏng vấn bằng cách cung cấp 1
diễn đàn cho ng use cùng tìm ra các đòi hỏi và các ứng dụng.
- Họp nhóm có thể tạo ra quyết định, nhận được cả thông tin tổng hợp và chi tiết, là phương

pháp tốt cho các yêu cầu bên ngoài, tập hợp được nhiều người dùng lwan.
- Họp nhóm vấn có hạn chế đó là có thể làm lãng phí time. Nói chung nên họp nhóm ít. Từ 1- 5
người, không mời nhưng ng k thjx hợp tránh làm lãng phí time.
Câu 8: Độ phức tạp cảm nhận của vấn đề tổ hợp p và q là lớn hơn độ phức tạp cảm nhận được
khi tách biệt từng vấn đề p và q để xem xét vì:
- Phần mềm được chia thành các phần có tên riêng biệt và định địa chỉ được, gọi là các module.
Gọi C(x) là hàm xác định độ phức tạp cảm nhận được của vấn đề x, và E(x) là hàm xác định
nổ lực cần có để giải quyết vấn đề x. Với 2 vấn đề p, q ta có:
+ Nếu C(p)>C(q) thì tổng quát suy ra E(p)>E(q) vì phải mất nhiều nổ lực hơn để giải quyết
vấn đề khó hơn.
+ Một đặc trưng được chỉ wa thực nghiệm là: C(p+q)>C(p)+C(q)
Như thế độ cảm nhận of vấn đề tổ hợp p và q là lớn hơn độ phức tạp nhận được khi tách biệt
từng vấn đề p và q để xem xét.
- Kết hợp ta có E(p+q)>E(p)+E(q). Điều này dẫn đến kết luận chia để trị cho việc để giải quyết
các vấn đề phức tạp.
Câu 9: Sự khác nhau giữa thiết kế hướng chức năng và thiết kế hướng đối tượng
Thiết kế hướng chức năng Thiết kế hướng đối tượng
- Là 1 cách tiếp cận thiết kế phần mềm
trong đó bản thiết kế được phân giải
thành 1 bộ các đơn thể tác động lẫn
nhau, là 1 đơn thể có 1 chức năng xác
định rõ ràng. Các chức năng có các
trạng thái cục bộ, chia sẻ trạng thái hệ
thống.
- Chiến lược thiết kế chức năng dựa trên
phân giải hệ thống thành 1 bộ các chức
năng có tương tác nhau với trạng thái hệ
thống tập trung dùng chung cho các
chức năng đó.
- Thiết kế hướng chức năng gắn với các

chi tiết của một thuật toán của chức
- Dựa trến việc che dấu thông tin. Các đối
tượng này có 1 trạng thái được che dấu
và các phép toán trên các trạng thái đó.
Thiết kế biểu thị các dịch vụ được yêu
cầu và được cung cấp bởi các đối tượng
có tương tác với nó.
- Các đối tượng liên lạc với nhau bằng
cách trao đổi thông báo chứ không phải
bằng cách dùng biến chung.
- Có tính đóng gói và kế thừa.
- Có thể tái sử dụng các đối tượng đã
được thiết kế trong các bản thiết kế
trước.
- Vì có đối tượng có tính thừa kế độc lập
năng đó, thông tin trạng thái k bị che
dấu.
- Khó có thể dùng lại các đối tượng thiết
kế
- Chi phí sửa chữa lỗi lớn, tính mở của hệ
thống thấp
nên giảm chi phí và dễ bảo trì, hệ thống
có tính mở cao hơn.
- Có thể xd hệ thống lớn và phức tạp.
Câu 10: Mô tả hướng dẫn thiết kế giao diện:
• Hướng dẫn về tương tác chung: giao diện phải.
- Nhất quán
- Cho thông tin phản hồi có nghĩa.
- Yêu cầu kiểm chứng mọi hành động phá hủy không tầm thường.
- Cho phép dễ dàng lần ngược nhiều hành động.

- Tìm kiếm tính hiệu quả trong đối thoại, vận động và ý nghĩa, dung thứ cho sai lầm.
- Phân loại các hoạt động theo chức năng và tổ chức màn hình hài hòa theo vùng.
- Cung cấp tiện nghi trợ giúp làm ngữ cảnh.
- Dùng các động từ đơn giản hay các cụm từ ngắn để đặt tên chỉ lệnh.
• Hướng dẫn về hiện thị thông tin:
- Chỉ hiển thị thông tin lwan đến ngữ cảnh hiện tại.
- Đừng chôn vùi người dùng dưới dữ liệu, hãy dùng định dạng trình bày cho phép hấp thu
nhanh chóng thông tin.
- Dùng nhãn nhất quán, cách viết tắt chuẩn và màu sắc dự kiến trước được.
- Cho phép người dùng duy trì ngữ cảnh trực quan.
- Đưa ra các thông báo lỗi có nghĩa.
- Dùng chữ hoa chữ thường, thụt cấp và gộp nhóm văn bản để trợ giúp cho việc hiểu.
- Use cửa sổ để đóng khung các thông tin khác nhau.
- Dùng cách hiển thị “tương tự” để biểu diễn thông tin dễ được hấp thụ hơn với dạng biểu diễn
này.
- Xem xét vùng hiển thị có sẵn trên màn hình và dùng nó 1 cách có hiệu quả.
• Hướng dẫn về vào dữ liệu:
- Tối thiểu số hành động đưa vào mà người use thực hiện.
- Duy trì sự nhất quán giữa hiện thị thông tin và cái vào dữ liệu.
- Cho phép người dùng làm phù hợp cái vào.
- Tương tác nên mềm dẻo và hài hòa với mode đưa vào ưa thix.
- Khử kích hợp các lệnh không phù hợp hiện tại.
- Để cho người dùng kiểm soát luồng tương tác.
- Cung cấp trợ giúp cho mọi hành động đưa vào.
Câu 11:
Case có các loại ICASE, Upper CASE và lower CASE. ICASE nghĩa là “Intergrated” CASE hay là
CASE tích hợp, “Upper” nghĩa là công cụ ý tưởng hay chỉ là thiết kế logic, “Lower” nghĩa là công
cụ chỉ hỗ trợ lập trình.
Câu 12: Độ tin cậy của phần mềm:
- Là độ đo về mức độ tốt của các dịch vụ mả hệ cung cấp cho máy tính. Cần chú ý là người

dùng không xét rằng các dịch vụ là quan trong như nhau.
- Độ tin cậy là một đặc trưng động của hệ thống, nó là một hàm của số các thất bại phần mềm.
Một thất bại phần mềm là một sự kiện thi hành mà khi đó phần mềm hành xử không như
người ta mong đợi. Chú ý rằng một thất bại phần mềm khác với một hư hỏng phần mềm. Hư
hỏng phần mềm là một đặc trưng tĩnh, nó sẽ gây ra thất bại phần mềm khi mà mã lỗi được thi
hành với một tập hợp đặc biệt các thông tin vào. Các hư hỏng không phải luôn luôn xuất đầu
lộ diện, vì vậy độ tin cậy phụ thuộc vào việc sử dụng hệ thống như thế nào. Không thể đưa ra
1 phát biểu đơn giản và khái quát về độ tin cậy phần mềm.
- Các hư hỏng phần mềm không phải là các khuyết tật của chương trình. Một hành xử bất ngờ
có thể xảy ra khi mà phần mềm phù hợp với các yêu cầu của nó nhưng mà chính các yếu tố
đó lại không đầy đủ. Các sai sót trong các tư liệu phần mềm cũng có thể dẫn đến hành vi bất
ngờ dẫu rằng phần mềm không có khiếm khuyết.
- Có công trình nghiên cứu đã chỉ ra rằng có thể rút bỏ 60% các khiếm khuyết mà chỉ có thể cải
tạo được 3% độ tin cậy. Cũng có người cho rằng nhiều khiếm khuyết trong sản phẩm chỉ là
kết quả của hàng trăm hoặc hàng nghìn tháng use.
Câu 13:
Kiểm tra phát triển phần mềm gồm có 3 bước:
- Bước đầu tiên là xử lý kiểm tra, đầu vào kiểm tra, cấu hình và mã ứng dụng được đòi hỏi để
tạo các kiểm tra.
- Bước thứ hai là so sánh các kết quả kiểm tra với kết quả dự tính và định lượng sự khác biệt.
- Bước tiếp theo là loại trừ các lỗi, hoặc gỡ rối mã. Khi việc mã hóa lại hoàn thành, kiểm tra lại
được tiến hành.
Câu 14:
• Kiểm tra Black-box:
Kiểm tra hộp đen , black-box, coi xử lý kết quả như là minh chứng bởi dữ liệu. Khái niệm kiểm
tra là black-box không quan tâm logic. Khuynh hướng này hiệu quả đối với các modul chức năng
đơn và các hệ thống cấp cao. Ba phương pháp chính là:
- Phân hoạch cân bằng: tối thiểu các trường hợp kiểm tra cho trước, các mục dữ liệu vào được
chia thành các nhóm dữ liệu có vai trò cân bằng nhau, mỗi nhóm đại diện cho một tập dữ liệu.
Nguyen tắc là ktra triệt để 1 mục of mỗi tập hợp, chấp nhận all các mục tương đương khác

của tập hợp đó dũng sẽ được kiểm tra một cách kỹ càng.
- Phân tích cực biên: là 1 dạng nghiêm ngặt of phân hoạch cân bằng có use các giá trị biên hơn
bất cứ giá trị nào trong tập cân bằng.
- Đoán lỗi: dựa trên cơ sở trực giác và kinh nghiệm, các chuyên gia có thể dễ dàng kiểm tra các
điều kiện lỗi bằng cách đoán cái nào dễ xra nhất.
• Kiểm tra White-box:
Có 3 loại ktra hộp trằng là kiểm tra logic-logictest, chứng minh toán học – mathematical proof và
Cleanroom testing.
- Logic test:
+ Logic test có thể được chi tiết đến mức lệnh. Trong khi thực hiện of mọi lệnh là mục đích đáng
khen ngợi, có thể không kiểm tra tất cả các điều kiện thuộc chương trình.
+ Logic test nhìn vào mỗi quyết định trong module và san sinh các dữ liệu để tạo tất cả các kết quả
ra có thể. Có 1 vấn đề với logic test tại mức này là không test tình trạng của module đối với đặc tả.
Nếu ktra được phát triển dựa trên đặc tả mà đặc tả được dịch khác nhau bởi người lập trình thì ktra
sẽ k đúng. Giải pháp là đòi hỏi đặc tả chương trình đủ chi tiết và logic. Điều này có thể phù hợp với
ngôn ngữ thế hệ 1 và 2.
+ Các ktra nhiều điều kiện tạo mỗi kết quả ra cảu tiêu chuẩn đa quyết định và nhiều điểm vào
module. Khi được thiết kế phù hợp, test logic đa điều kiện có thể tối thiểu hóa các trương hợp ktra
nhiều nhất các điều kiện.
- Chứng minh bằng toán học: một phương pháp thep cách tiếp cận giảm thiếu sót về 0 là áp
dụng suy diễn toán học cho đòi hỏi logic, chứng minh tính đúng đắn của chương trình.
Phương pháp này đòi hỏi đặc tả ngôn ngữ dạng hình thức.
- Cleanroom testing: là mở rộng của pp cm bằng toán học. Lý thuyết của kỹ thuật này là ngăn
chặn các lỗi tại các đầu vào of quá trình xử lý, giá thành giảm, độ tin cậy lên và tiệm cận tới
không có lỗi. Cleanroom testing là KT ktra toán học hình thức và hội ý. Mục đích là phân tích
mọi module thành các chức năng và liên kết. Các phép ktra chức năng dùng kỹ thuật toán
học, các ktra lket use thuyết tập hợp.
Câu 15: Hoạt động của bảo trì phần mềm:
Gồm 4 hoạt động:
1. Bảo trì hiệu chỉnh:

Công việc bảo trì đầu tiên cần thực hiện là do việc kiểm tra chương trình không thể tránh được
một lỗi ẩn chứa bên trong một hệ phần mềm lớn. Trong khi sử dụng bất kỳ 1 chương trình lớn
nào, các lỗi sẽ được báo về lại cho người phát triển.
Bào trì hiệu chỉnh chính là quá trính phân tích và hiệu chỉnh một hay nhiều lỗi chương trình.
2. Bảo trì tiếp hợp:
Hoạt động thứ hai diễn ra bởi sự thay đổi thường xuyên môi trường. Bảo trì tiếp hợp là hoạt
động sửa đổi phần mềm để thích ứng được với những thay đổi môi trường.
3. Bảo trì hoàn thiện:
Hoạt động thứ ba diễn ra khi một phần mềm đã được hoàn tất thành công. Hoạt động này chiếm
hầu hết các công sức tiêu tốn cho việc bảo trì phần mềm. Để thỏa mãn những yêu cầu phát triển
của người sử dụng, ta tiến hành bảo trì hoàn thiện.
4. Bảo trì phòng ngừa:
Bảo trì phòng ngừa là bảo trì diễn ra khi phần mềm được thay đổi để cải thiện tính năng bảo trì
hay độ tin cậy trong tương lai hoặc để cung cấp một nền tảng tốt hơn cho những mở rộng sau
này.
Bảo trì phòng ngừa, hoạt động này vẫn còn nhiều xa lạ trong thế giới phần mềm hiện nay.
Trong thực tế của hoạt động bảo trì, các nhiệm vụ được làm như một phần của bảo trì tiếp hợp và
bảo trì hoàn thiện cũng giống như các nhiệm vụ cần làm trong giai đoạn phát triển của một chu
trình phần mềm. Để tiếp hợp hay hoàn thiện, chúng ta đều phải xác định yêu cầu, thiết kế lại, tạo
mã và kiểm tra phần mềm có được. Thông thường những nhiệm vụ đó đã được gọi là bảo trì rồi.
Câu 16: Khi bảo trì ,một số hiệu ứng lề xảy ra là:
1. Hiệu ứng lề của việc thay đổi mã nguồn:
Mặc dù tất cả thay đổi mã lệnh chương trình đều có thể tạo ra lỗi, nhưng tập hợp các thay đổi sau có
thể gây ra nhiều lỗi hơn:
- Một chương trình con bị xóa hay thay đổi
- Một dòng nhãn bị xóa hay thay đổi.
- Một biến bị xóa hay thay đổi.
- Các thay đổi để tăng khả năng thực hiện.
- Việc mở và đóng file bị thay đổi.
- Các phép toán logic bị thay đổi.

- Việc thay đổi thiết kế chuyển thành các thay đổi lớn về chương trình.
- Các thay đổi ảnh hưởng đến việc chạy thử các trường hợp biên.
2. Hiệu ứng lề của việc thay đổi dữ liệu:
Hiệu ứng lề của việc xảy ra như là kết quả của việc thay đổi cấu trúc dữ liệu. Các thay đổi dữ liệu
sau đây thường gây ra lỗi:
- Định nghĩa lại các hằng số cục bộ và hằng số địa phương.
- Định nghĩa lại cấu trúc bản ghi hay cấu trúc file.
- Tăng hay giảm kích thước một mảng.
- Thay đổi dữ liệu tổng thể.
- Định nghĩa lại các cớ điều khiển và các con trỏ.
- Xếp lại các tham số vào ra hay tham số của chương trình con.
3. Hiệu ứng lề của việc thay đổi tài liệu:
Bất cứ lúc nào có thay đổi về luồng dữ liệu, cấu trúc phần mềm, các thủ tục hay bất cứ cái gì có liên
quan, tài liệu kỹ thuật phải được cập nhật. Hiệu ứng lề xảy ra trong các lần bảo trì sau đó, khi việc
nghiên cứu không kỹ các tài liệu kỹ thuật, dẫn tới sự đánh giá sai về các đặc tính của phần mềm.
Các hiệu ứng lề trong tài liệu có thể được giảm về căn bản nếu toàn bộ cấu hình được xem xét trước
khi phát hành phiên bản phần mềm tiếp sau.