Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

Software Maintenance > SOMA > Flashcards

SOMA Flashcards

1
Q

Program understanding - System Knowledge

A

problem domain

execution effects

cause and effect relation

product environment

decision support

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Tasks during Maintenance

A

1 change (changes are necessary)
2 Understanding the system
3 execute changes
4 Test and deploy

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Cause effect relation

A

1 Identify program parts

2 Establish relation between parts

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Process model for program understanding

A

Read about the program (Read data flow diagrams)
Read the source code (Read definitions and implementation modules)
Run the program (Get trace data
Dynamic analysis)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Strategy for program understanding

A

Strategy for program understanding

top-down: top levels of programs to the low-level details
bottom-up: From lower-level patterns to higher-level

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Top-Down Model

A

First, make hypotheses about coarse structure
Refine knowledge

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Procedure knowledge acquisition:

A

1 To raise basic knowledge

2 Create hypotheses about program behavior

3 Check hypotheses (correct, mental model correct, otherwise hypothesis must be
revised)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Composition VS Comprehension

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Influence factors on program understanding

A

1 Expertise (Domain, Programming)
2 Implementation issues (Naming, Comments, Nesting, Coding standards)
3 Doumentation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Characteristics of good software

A

Functionality
Flexibility
Availability
Correctness

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Test Pyramid

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Reuse

A

of: code, test data, architecture, algos
→ of knowledge: process, lessions learned, product

benefits: increase productivity, quality, portable code, less maintenance, better maintainability

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Approaches to Reuse

A

Composition-Based: Atomic building blocks (modules, functions, classes)

Generation-Based: Program that generates target systems (High-Level specification, e.g. compiler-generator)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Problems with Reuse Libraries

A

Granularity and size
Low granularity: few functions, easy to understand but limiting the reuse § High granularity: many functions, c confusing, bad for reuse

Search problem (find reusable comps)

Search problem

Specification and flexibility problem

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Factors influencing Reuse

A

Technical factors: programming languages, information presentation, availability of libs

Non-technical factors: money spent, not invented here, legal framework

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Software Lifecycle

A

Analysis

Design

Implementation

Test

Software Use

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Software Maintenance Framework

A

Organisational
vs User (requirements, additional functionality, non-programming support)
vs Operational (policies, market)
Environment (hardware, software)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Software Changes

A

Corrective changes (Design, logic, coding errors)

Adaptive changes (changed environment, new laws …)

Perfective changes (user requests, extending functionality, performance)

Preventive Changes (ease further maintenance)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Changes to a software often cannot be
realized because

A

Limitations of resources

poor quality of the existing system

Organizational strategy

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Solutions to Maintenance Problems

A

Budget and effort reallocation

replacement of existing system

Improve the existing system by preventive
maintenance.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

How to reduce maintenance costs?

A

Budget reallocations

replacing old software

Improving the existing software

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

knowledge is implicitly stored

A

Experiences

Management knowledge

Operational and functional information

Business rules and prozesse

23
Q

Waterfall model

A

Emphasis on phases (analysis, design, coding, testing, usage)
Disad: errors found in later stages are hard to correct

Assumption: All results of one phase are correct and
complete

24
Q

Spiral model

A

based on 4 tasks:

1 Analyis of goals, requirements, and alternatives
2 Evaluating alternatives considering risks
3 Start next iteration of program development and testing
4 Start planing the next iteration (phase)

25
Code-And-Fix
Coding phase: - Programming Fix phase: - Corrections - Extensions AD HOC Code remains faulty and maintainability decreases
26
Maintenance tasks
Operation Validation Software Maintenance Processes Idea Unterstand the system Implementation Testing Define objectives Analysis Specification Documentation Release new version Training
27
Quick-Fix Model
First responder approach 1. Find fault 2. Correct it Problems: - No detailed analyses - No documentation
28
Boehm‘s model
Cyclic model Based on economic models and principles Management decision is driver of the process
29
Osborne‘s model
Considers the real requirements of software maintenance Iterative loops to implement maintenance activities
30
Reverse Engineering - abstraction
From product/system to idea abstraction: extraction of knowledge at an appropriate level of understanding 3 types of abstraction: 1 Function abstraction (knowl. about how a procedure works) 2 Data abstraction (knowl. about data models without impl. details) 3 process abstraction (program flow without exact behav.)
31
Objectives of Reverse Engineering
Recovering **Lost Information** Support **migration** between different platforms Improving or restoring **documentation** Providing different **perspectives** on a program Extraction of **re-usable** components Support in dealing with **complexities** Detecting **side effects** Reduction of maintenance **costs**
32
Redocumentation
Goal: Creation of semantically equivalent documentation within the same level of abstraction. Creating alternative views Improving existing documentation documentation on modified program Techniques: CFG, Structograms, ERDs, Class diagrams
33
Different Levels of Reverse Engineering
34
Reverse Engineering - Design Recovery
Goal: Gain higher abstractions directly from the source code. Detection of control structures, data types, modules, class hierarchies Recognition of patterns Derivation of the architecture
35
Reverse Engineering - Specification Recovery
Goal: Obtaining specification knowledge from system information if: Design knowledge is often not sufficient OR Paradigm shift in design
36
Reverse Engineering - Specification Recovery
Goal: Obtaining specification knowledge from system information if: Design knowledge is often not sufficient OR Paradigm shift in design
37
When is reverse engineering necessary?
* **Missing or incomplete** design/specification * Insufficient **documentation** * **Poorly structured** source code * Program **transformation** * Ensuring program **compatibility** * **Migration** to other HW/SW platforms * Rising **error rate**
38
Restructuring of Source Codes
Control-flow-driven Efficiency-driven Adaption-driven
39
Software maintenance - definition
Software maintenance is the process of modifying a software system or component after delivery to correct faults, improve performances or other attributes, or adapt to a changed environment.
40
Reasons for the high costs of maintenance
- Insuffcient **knowledge** of the user domain - Insuffcient or obsolete **documentation** - **Complexity** of programs - **Programmer = maintenance** personnel - Employee responsible for the code **left the company** - Knowledge often only **implicitly** (in the program code) available
41
Maintenance process
1. Analyze the existing system 2. Analyze the necessary changes of the system 3. Prediction of potential impacts (ripple effects) 4. Determination of skills and knowledge required for the changes 5. Implementation of the changes
42
Restructuring
Creating a more maintainable system, changing the abstract representation of the system without changing its functionality.
43
Re-engineering
Enhancement of a system by using first reverse engineering to comprehend the system and then forward engineering to produce the new system.
44
Forward engineering
The traditional software development approach.
45
The aims of program comprehension
Problem domain Execution effect Cause-effect relation Product-environment relation Decision-support features
46
Principles which impact reusability
Generality (wide spectrum) Cohesion vs coupling (should be high vs low) Interaction (with user should be min.) Uniformity and standardization
47
Motivation Backward Slicing
Computation of Statements influencing the value of a variable Identification of faulty statements
48
Motivation Forward Slicing
Computation of statements influenced by a statement Effects of a statement on the rest of the program Find the variables that are influenced by a statement
49
Internal Factors Software-Maintenance
Software: Difficulty of aplication domain, Quality, Complexity Process: Capturing requirments, undocumented assumptions, variation in programming practice Personnel: Stuff turnover, Domain expertise
49
External Factors Software-Maintenance
Organisational: Change in policies, Competition in market place Operational: Hardware and software innovation User environment: User requirements
50
Purpose of software analysis
Unfolding of program structures Which statements influences a variable in a specific line Which statements have no influence on the result Is a specific line of code reachable
51
Forward (!) Slicing
start with all defs of statement gen(n) = def : if ref∧in or inSlice(n) inSlice if ref and out intersect inSlice if m is in INFL(n) and inSlice(n)
52
In Slice - Backward (!) Slicing
S0(n): if n is PRE(m) and Def(n) and R(m) intersect B(n): if one of INFL(n) in slice (create new slice for each n of B(n) in slice) S1: S0(n) + B(n) + slice(B(n) if n in slice)

Software Maintenance (1 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions