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

Chia sẻ: Nguyễn Thị Phương Phương | Ngày: | Loại File: DOCX | Số trang:8

Thêm vào BST

Báo xấu

609
lượt xem 58
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Câu hỏi ôn tập nhập môn công nghệ phần mềm

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 - Là đặc tả mà ở đó các từ ngữ, cú pháp, - Không chặt chẽ. ngữ nghĩa được định nghĩa hình thức - Được nhiều người biết và để trao đổi dựa vào toán học. zới nhau làm chính xác các điểm chưa - Chặt chẽ. rõ, chưa thống nhất giữa các bên phát - Được coi là một phần của hoạt động triển hệ thống. đặc tả phần mềm. - Chi phí thấp hơn đặc tả hình thức. - Cho thấy được bản chất bên trong của - Không thuận tiện cho các thiết kế viên các yêu cầu.-> cách tốt để giảm các lỗi, hoặc các hợp đồng giữa khách hàng và các thiếu sót có thể xảy ra, giúp công cán bộ phát triển hệ thố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 - Dựa trến việc che dấu thông tin. Các trong đó bản thiết kế được phân giải đối tượng này có 1 trạng thái được che thành 1 bộ các đơn thể tác động lẫn dấu và các phép toán trên các trạng thái nhau, là 1 đơn thể có 1 chức năng xác đó. Thiết kế biểu thị các dịch vụ được định rõ ràng. Các chức năng có các trạng yêu cầu và được cung cấp bởi các đối thái cục bộ, chia sẻ trạng thái hệ thống. tượng có tương tác với nó. - Chiến lược thiết kế chức năng dựa trên - Các đối tượng liên lạc với nhau bằng phân giải hệ thống thành 1 bộ các chức cách trao đổi thông báo chứ không phải năng có tương tác nhau với trạng thái bằng cách dùng biến chung. hệ thống tập trung dùng chung cho các - Có tính đóng gói và kế thừa. chức năng đó. - Có thể tái sử dụng các đối tượng đã
- Thiết kế hướng chức năng gắn với các được thiết kế trong các bản thiết kế chi tiết của một thuật toán của chức trước. năng đó, thông tin trạng thái k bị che - Vì có đối tượng có tính thừa kế độc lập dấu. nên giảm chi phí và dễ bảo trì, hệ - Khó có thể dùng lại các đối tượng thiết thống có tính mở cao hơn. kế - Có thể xd hệ thống lớn và phức tạp. - Chi phí sửa chữa lỗi lớn, tính mở của hệ thống thấ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.