Vorgehensmodelle — worksheet (Block 4) 8 questions From Course Content

Assume a project is run strictly phase-by-phase in fixed order (plan-driven), so e.g. design must be fully complete before implementation begins and finished phases cannot be changed. What advantages and disadvantages arise from deviating to a flexible/agile approach, and would a project manager, a customer, and a developer each prefer the plan-driven or the flexible variant — and why?

Unchecked
Answer
  • Agile gains: accommodate changing requirements, earlier feedback/working software, overlap phases instead of 100% completion gates.
  • Plan-driven gains: plannability, predictability, clear phase separation, traceability, fewer surprises.
  • Project manager weighs plannability/budget control vs. flexibility; customer values early feedback and adaptability; developer values freedom and avoiding costly early-phase mistakes.
1/8

In a flexible/agile process model, must requirements at project start be documented and elaborated more, less, or equally precisely than in a plan-driven model? If less, how are traceability and sufficient precision still achieved — and can you name requirements that must nevertheless be worked out precisely before the project begins?

Unchecked
Answer
  • Agile: initially less up-front documentation (working software over comprehensive documentation; welcome changing requirements).
  • Precision/traceability achieved continuously and iteratively (e.g. backlog refinement, user stories, ongoing customer collaboration, acceptance tests).
  • Some requirements must still be fixed early: e.g. safety-/security-critical or architecture-defining requirements.
2/8

You invite a long-standing customer to try the current, still incomplete prototype next week to get early feedback, instead of only handing over the finished product. Is this a good idea? What advantages and disadvantages do you see?

Unchecked
Answer
  • Advantage: early feedback prevents surprising rejection at final acceptance; aligns expectations; matches agile customer collaboration / responding to change.
  • Disadvantage/risk: customer may judge an unfinished UI as the final quality, expect features prematurely, or lose confidence; needs clear framing that it is a prototype.
3/8

For each project, decide whether to use a plan-driven (e.g. waterfall) or a more flexible/agile (e.g. Scrum) model and justify it with the Boehm/Turner factors, then name a concrete model: digital surgery software; a webshop; rocket-control software; self-driving-car control software; a computer game; a backend log-storage service; and an experimental "blue-light" project by Siemens AG with 4 staff.

Unchecked
Answer
  • Apply the five Boehm/Turner factors (personnel, dynamism, culture, size, criticality) to each project.
  • Life-/safety-critical (surgery, rockets, self-driving cars): plan-driven, e.g. V-Model.
  • Low-criticality, fast-changing, small-team (webshop, game, experimental 4-person Siemens project): agile, e.g. Scrum/XP/Kanban.
  • Justify each choice via the dominant factor(s).
4/8

What advantages generally arise in software projects from using a standardized process model?

Unchecked
Answer
  • Communication (common basis), plannability/predictability (known steps, checklists).
  • Tool support, reuse of documented experience, customer/legal requirements.
  • Statistically higher success probability (~6x).
5/8

A 3-person-day Excel prototype is to be rolled out department-wide with database integration; the boss budgets one work-week but it took ten person-weeks. Explain why a developer would call this course of events normal rather than unusual.

Unchecked
Answer
  • Productizing a prototype adds integration (databases), multi-user use, robustness, and quality work absent from the throwaway version.
  • Prototype effort is not a valid basis for estimating production effort.
6/8

A project leader estimates effort linearly (cumulative effort rising evenly from 0% at start to 100% at end). Why can discrepancies arise between this linear estimate and the real effort, and is comparing linear estimates against real effort a sensible way to monitor cost development?

Unchecked
Answer
  • Effort does not accrue linearly: phases differ; rework, integration, and late changes shift effort.
  • A purely linear estimate is of limited value for cost-development monitoring.
7/8

Design a task and schedule plan from a list of estimated work packages with a fixed delivery date and a fixed number of full-time staff, and explain how losing one developer to another project would affect the schedule.

Unchecked
Answer
  • Define work packages, estimate effort, determine total duration and critical dependencies (critical path).
  • Total duration is bounded by dependent chains and available parallel capacity, not the raw sum of efforts.
  • Losing a developer reduces capacity and lengthens the schedule where it sat on the critical path.
8/8
Vorgehensmodelle — lecture slides (Block 4) 18 questions From LLM

In the V-Model, what is the difference between validation and verification?

Unchecked
Answer
  • Validation: are we building the right product for the intended purpose?
  • Verification: are we building the product correctly according to the previous phases' specifications?
1/18

What are the three roles in Scrum and what is each responsible for?

Unchecked
Answer
  • Product Owner: owns and prioritizes the Product/Release Backlog, represents the customer, shields the team.
  • Scrum Team: implements the Sprint Backlog and reaches the Sprint Goal.
  • Scrum Master: enforces Scrum's rules and shields the team from external influences.
3/18

What is a Vorgehensmodell (process model), and what does it typically span?

Unchecked
Answer
  • A concrete strategy for the controlled execution of a specific project, tailored to the project's criteria and often adapted per project.
  • Its focus is usually the technical side: it begins with the definition of requirements and ends with deployment at the customer.
4/18

How are the process models presented in the lecture classified, and which models fall into each class?

Unchecked
Answer
  • Traditional / plan-driven approaches: Waterfall model, V-Model, Spiral model, and RUP.
  • Agile approaches: Agile Manifesto, Scrum, eXtreme Programming (XP), and Kanban.
5/18

Name key advantages and disadvantages of the waterfall model and the conditions under which it is appropriate.

Unchecked
Answer
  • Advantages: risk minimization by closing each phase before the next, strict phase separation improves plannability, wide adoption/familiarity, usable by small teams, many extensions (e.g. backtracking).
  • Disadvantages: all tasks of a phase must finish before the next (no cross-phase parallelism); early-phase errors strongly affect the project; changing requirements are costly.
  • Appropriate when requirements are well-known, clearly defined and complete (No-Surprise Software).
6/18

How does the basic V-Model structure its phases, and what are correlating phases?

Unchecked
Answer
  • It separates the specifying (constructive) phases on the left from the realizing/checking phases on the right, but is otherwise sequential like the waterfall.
  • Correlating phases: each constructive phase on the left is paired with a checking phase on the right, and each artifact gets a verification method (e.g. code ↔ unit test). It was the first model to integrate test stages.
7/18

Name the four phases of the Rational Unified Process (RUP) in order and what each produces.

Unchecked
Answer
  • Inception (preparation): the project vision and a first risk assessment.
  • Elaboration: detailed requirements, a prototypical architecture, tested possible solutions.
  • Construction: a runnable, tested system.
  • Transition: transfer of the system to the client.
8/18

What are the core elements of Kanban, and how does it differ from Scrum?

Unchecked
Answer
  • Kanban limits parallel work items (Work-In-Progress/WiP limit) on a Kanban board to shorten lead times and make problems visible; it has no roles and no meetings.
  • Difference: Scrum is team-centred, whereas Kanban optimizes value generation along the value-creation chain; Scrum can be seen as one possible implementation of Kanban.
10/18

Why do software projects use process models, and what concrete benefits does a standardized model provide?

Unchecked
Answer
  • They give a controlled project strategy from requirements to deployment, reduce uncontrolled improvisation, and make technical work plannable.
  • Standardized models improve communication, predictability, tool/checklist support, reuse of experience, and compliance with customer/legal expectations.
11/18

What makes the Spiral model iterative and risk-oriented, and why is full upfront planning difficult in it?

Unchecked
Answer
  • The project repeatedly runs through cycles whose number emerges during the project; each cycle is guided by the risks found.
  • Distance from the centre represents increasing effort/cost/duration, so more iterations mean longer development and make deterministic full-duration planning difficult.
12/18

How is RUP structured across disciplines and phases, and why is it described as iterative?

Unchecked
Answer
  • RUP distinguishes disciplines such as requirements, analysis/design, implementation, test, deployment, configuration/change management, project management, and environment.
  • Its phases are Inception, Elaboration, Construction, and Transition, but work is iterative inside and across them rather than a single strict waterfall pass.
13/18

What is Scrum's development philosophy, and which basic artifacts/events make it work?

Unchecked
Answer
  • Scrum is iterative, incremental, transparent, inspect-and-adapt work, organized around short sprints and close feedback.
  • Core elements include Product Backlog, Sprint Backlog, Increment, Sprint Planning, Daily Scrum, Review, Retrospective, and the Scrum roles.
14/18

Name the XP techniques and XP roles presented in the lecture, and explain what kind of development style they support.

Unchecked
Answer
  • Recall techniques such as small releases, planning game, metaphor, simple design, testing, refactoring, pair programming, collective ownership, continuous integration, 40-hour week, on-site customer, and coding standards.
  • They support rapid feedback, simplicity, communication, and continuous quality control in an agile setting.
15/18

How do you read the Boehm/Turner decision diagram when choosing between agile and plan-driven work?

Unchecked
Answer
  • Read the five factors together: personnel, dynamism, culture, size, and criticality.
  • Agile fits smaller, skilled, change-friendly, low-criticality environments; plan-driven fits larger, more critical, more stable or documentation-heavy environments.
16/18

What key principles summarize how process models should be used in real projects?

Unchecked
Answer
  • Use a model as a project strategy, not as a blind ritual; adapt it to project criteria.
  • Match the model to criticality, size, dynamism, culture and personnel; combine traditional and agile elements when the project needs it.
  • Keep requirements, validation and feedback aligned so the model supports the project instead of dominating it.
17/18

Why do process models matter for a software project beyond just naming phases?

Unchecked
Answer
  • They protect the investment by making the technical work controlled, communicable, and repeatable.
  • They support cost control by improving planning, feedback, traceability, and risk handling from requirements to deployment.
18/18
Implementierung — worksheet (Block 4) 25 questions From Course Content

Why does quickly written bad code create large long-term extra effort?

Unchecked
Answer
  • Bad code makes changes hard to understand, test and localize, so small fixes can take disproportionate effort.
  • Bad code collapses productivity over time and raises pressure/chaos; good code up front avoids the later rescue rewrite.
1/25

How does the saying "if all you have is a hammer, everything looks like a nail" relate to software development?

Unchecked
Answer
  • Over-applying one familiar tool/technology/pattern/language to every problem regardless of fit.
  • Remedy: know several approaches and choose per problem (cf. selecting language/framework/process model).
2/25

Why are chained null checks not a sufficient general strategy for avoiding NullPointerExceptions?

Unchecked
Answer
  • Chained null checks are verbose and do not fully prevent NPEs (e.g. registry.getItem(...) may still return null).
  • Never give null a meaning; Java-8 Optional addresses missing returns but avoid where it bloats code.
  • Prefer default values/helper methods and empty collections (Collections.emptyList()).
3/25

Why is throwing an exception for every ordinary validation failure usually a bad validation strategy?

Unchecked
Answer
  • Exceptions are for exceptional failure, not normal validation/control flow.
  • Use the Notification Pattern to collect all validation errors and report them together.
4/25

Why does code improve when YAGNI, KISS and DRY are respected?

Unchecked
Answer
  • KISS = keep it simple; DRY = no redundancy (once and only once); YAGNI = build only what is needed now.
  • The speculative interface violates YAGNI (and KISS): introduce an interface only when ≥2 types implement it now, not on suspicion.
5/25

What rule of thumb governs variable-name length?

Unchecked
Answer
  • Rule of thumb: the longer the scope/body, the longer the name; short i/j only for tiny scopes.
  • Deeply nested or long loops need meaningful index names and named constants for unexplained literal values.
6/25

Which implementation weaknesses often appear in over-parameterized methods?

Unchecked
Answer
  • Too many or same-typed parameters make call order error-prone; introduce a parameter object or builder.
  • A boolean flag parameter often means the method does two things; split the behavior into clearer methods.
7/25

When is static appropriate and when is it problematic?

Unchecked
Answer
  • static belongs to the class, not an instance; a static method uses no instance state.
  • Good for pure stateless helpers (like functional, side-effect-free functions); problematic when it hides global state or hinders testing/DI/polymorphism.
8/25

Why are magic numbers and magic strings a maintainability problem?

Unchecked
Answer
  • Magic numbers are unclear and scattered, so their meaning and change points are hidden; name them as constants.
  • Magic strings are the non-number analogue; fixed sets of magic constants are best replaced by enums.
9/25

How does Command-Query Separation support the "no surprises" principle?

Unchecked
Answer
  • A method should do exactly what its name says, with no hidden side effects.
  • A query should not secretly perform a state-changing command; separating commands from queries makes behavior predictable.
10/25

What advantages do Java enums bring compared with named constants?

Unchecked
Answer
  • Before enums: named int/String constants — not type-safe; enums are type-safe, named, exhaustively checkable.
  • Enums can also hold fields and per-constant behavior while keeping the value set explicit.
11/25

What problem does aspect-oriented programming address?

Unchecked
Answer
  • AOP extracts cross-cutting concerns (logging, timing, transactions, security, caching); benefit: single-concern methods; cost: added indirection/magic, harder to follow.
12/25

What is toString() typically used for?

Unchecked
Answer
  • toString() is for debugging/logging, not user-facing UI output (poor localization support).
  • Consumers (logs, tests, other code) may depend on its format, so changing it can silently break them.
13/25

Why is implementing Comparable often advised in Java?

Unchecked
Answer
  • Comparable.compareTo defines natural ordering used by the Collections Framework (sorting, sorted sets/maps); keep consistent with equals.
14/25

What is the difference between interfaces and abstract classes?

Unchecked
Answer
  • Interface = pure contract, multiple implementation; abstract class = shared state/partial implementation, single inheritance.
15/25

What drawback do telescoping constructors have?

Unchecked
Answer
  • Telescoping constructors: many hard-to-read overloads, order-dependent, easy to mismatch same-typed args.
  • Builder/Fluent Interface sets named parameters via chained calls, readable and order-safe, keeping the object immutable.
16/25

Why does Dependency Injection increase flexibility and ease testing?

Unchecked
Answer
  • DI decouples a class from constructing its dependencies → reusable and independently testable (inject mocks).
17/25

Why should composition usually be favored over inheritance?

Unchecked
Answer
  • Inheritance couples to superclass internals/breaks encapsulation; composition delegates via the public interface.
18/25

What is the Law of Demeter?

Unchecked
Answer
  • Only call methods of K, of parameters, of K's instance variables, of locals in m, and of static fields — 'talk to friends only'.
  • Following it reduces coupling and hidden dependencies by avoiding long chains through other objects.
19/25

What is the difference between static and dynamic typing?

Unchecked
Answer
  • Static = compile-time type checks (Java); dynamic = runtime checks.
  • Static catches errors early and aids tooling/maintainability (large systems); dynamic is more flexible/concise for quick scripting.
20/25

What are the two legitimate jobs of code comments?

Unchecked
Answer
  • Comments are not a substitute for bad code, but explaining WHY/intent and contracts is a legitimate job → not merely an admission of failure.
  • Useful method comments document expected inputs, returns, thrown exceptions, dependencies, and non-obvious behavior.
21/25

What are linters used for?

Unchecked
Answer
  • Linters statically analyse source for bugs/style/improvement potential.
  • Pros: fast, consistent, cheap, run on every commit; Cons: only detectable patterns, false positives, cannot judge design intent → complement, not replace, human review.
22/25

Why did distributed source-code management become dominant?

Unchecked
Answer
  • Distributed SCM: offline-capable, fast local ops, resilient, easy branching; before: email/FTP/shared folders → chaos, overwrites, no traceability.
24/25

What drawback can automatic memory management still have?

Unchecked
Answer
  • Drawbacks: less control over timing, GC overhead; memory still reachable is not freed.
25/25
Implementierung — lecture slides (Block 4) 24 questions From LLM

What is the difference between a framework and a library?

Unchecked
Answer
  • Library: you call its reusable functionality (you control when).
  • Framework: reusable behavior that calls your code (Inversion of Control); frameworks may include libraries.
1/24

What is Inversion of Control?

Unchecked
Answer
  • 'Don't call us, we call you' — the framework decides when your code runs.
  • Pros: modularization, Open-Closed, little configuration; Con: less abstraction (enforced structure/conventions → effort to extend or switch).
2/24

When do you use checked vs. unchecked exceptions in Java?

Unchecked
Answer
  • Checked (extends Exception): errors unavoidable by correct programming (e.g. wrong password from server); force handling.
  • Unchecked (extends RuntimeException): errors avoidable by correct programming (e.g. bad list index); handling optional.
3/24

In Design by Contract, what are preconditions, postconditions and invariants?

Unchecked
Answer
  • Precondition: required state at/before a call (valid inputs).
  • Postcondition: state at method end (valid return/object state).
  • Invariant: stable object state between method runs and after construction (e.g. 0 <= top <= list.size()).
4/24

What are the standard logging levels used in the lecture?

Unchecked
Answer
  • DEBUG: execution detail; INFO: essential events; WARNING: unexpected but compensated; ERROR: an error occurred (pass the exception object).
5/24

What is Implementierung?

Unchecked
Answer
  • Implementierung is translating a design into hardware/software components and the resulting realization.
6/24

How do macro-architecture and micro-architecture differ?

Unchecked
Answer
  • Macro-architecture is the overall component structure defined before implementation; micro-architecture is the detailed internal design of components refined by programmers during implementation.
7/24

Which programming paradigms must you distinguish?

Unchecked
Answer
  • By paradigm: non-structured, structured, imperative, procedural, object-oriented, declarative, functional, logic-based, and multi-paradigm.
8/24

Which criteria influence programming-language choice?

Unchecked
Answer
  • Criteria include team experience, domain fit, tools/frameworks/libraries, customer requirements, adoption/documentation/help, and developer availability.
9/24

What makes framework choice risky?

Unchecked
Answer
  • A later framework swap can be close to a rewrite, so fit, maintenance, license, architecture integration, and abstraction decisions matter early.
10/24

How do whitebox and blackbox frameworks differ?

Unchecked
Answer
  • Whitebox frameworks require internal knowledge and inheritance/method hooks; blackbox frameworks use ready components and composition; hot spots are adaptation points.
11/24

What does build management automate during implementation?

Unchecked
Answer
  • Build management automates compiling, testing, packaging and deployment; dependency management controls external libraries, versions, compatibility, updates, and transitive dependencies.
12/24

What are preconditions, postconditions, and invariants in Design by Contract?

Unchecked
Answer
  • Preconditions define required state before a call; postconditions define guaranteed state after a call; invariants define stable object state between calls and after construction.
16/24

Why should UI text be separated from source code for localization?

Unchecked
Answer
  • Separate texts from source code into resource files and use meaningful IDs by use area.
17/24

Which implementation goals should be checked before coding starts?

Unchecked
Answer
  • Goals: realize architecture, implement customer requirements, integrate and document components, deliver on time, and make software validatable and maintainable.
18/24

What is a programming language?

Unchecked
Answer
  • A programming language is a formal language for describing data structures and algorithms.
19/24

Why is Inversion of Control the core boundary between frameworks and libraries?

Unchecked
Answer
  • With a library your code calls reusable functions; with a framework, the framework decides when your code runs.
20/24

What do IDEs contribute during implementation?

Unchecked
Answer
  • IDEs bundle coding/navigation/refactoring/debugging/build/test/version-control support; changing them late costs time.
21/24

What concrete conditions should be ready before implementation begins?

Unchecked
Answer
  • The architecture should exist in enough detail, the team should be defined and familiar with the process, language/tool support should be chosen, and a rough schedule should exist.
  • Late switches of IDE/tools or too-tight schedules create avoidable delays and costs.
22/24

Distinguish centralized and decentralized version-management systems.

Unchecked
Answer
  • Centralized systems have one central repository that clients depend on.
  • Decentralized systems give every developer a full repository copy, enabling local history and distributed work.
23/24
Qualitätssicherung — worksheet (Block 5) 16 questions From Course Content

What efforts arise when testing? If you want minimal test effort yet still find crash-causing problems, how would you proceed (hint: fuzzing)? How can one know a software is "sufficiently" tested and how does that relate to test coverage, and who is responsible for quality?

Unchecked
Answer
  • Testing costs effort (creating/maintaining manual/automatic tests); good and bad quality both cost.
  • Low-effort crash finding: fuzzing; 'enough testing' relates to coverage (e.g. ~80%) but coverage is necessary not sufficient.
  • Quality is everyone's responsibility, not only a separate test team.
1/16

What is the difference between verification and validation, which can be achieved with technical measures and which not (or only partly), and why? Which of the three given definitions of "testing" do you agree with?

Unchecked
Answer
  • Verification: built right (against spec); Validation: right product (against customer needs).
  • Technical measures mainly achieve verification; validation needs customer involvement.
  • Prefer the error-finding and neutral-evaluation definitions over the 'show it works' one.
2/16

Complete the residual-defect table and interpret it (why don't planes constantly crash?). What is the difference between error/cause (Irrtum), fault/defect, and failure (Fehlverhalten), why distinguish them, which are easier/harder to fix, and give an example of each (hint: Y2K)?

Unchecked
Answer
  • Flight-control severe residual ~200, nuclear residual ~3000 / severe ~300 (≈5% residual, ≈0.4% severe).
  • Error/Irrtum = human cause; fault/defect = embedded code problem; failure = observed deviation; a fault must be triggered to fail.
  • Y2K: error = two-digit-year assumption, fault = date code, failure = wrong date at year 2000.
3/16

As project leader behind schedule with several minor defects, three severe defects and a missing feature, which of the four given courses of action would you choose and why?

Unchecked
Answer
  • Fix the severe defects and missing feature first (latency cost grows exponentially; building on broken code multiplies rework).
  • Parallelize low-risk preparatory work on areas with only minor issues to recover schedule (option 4 / prioritized).
4/16

What are black-box, gray-box and white-box tests and what view does each take? Why are black-box tests often seen as insufficient (give a practical example, e.g. QuickSort vs InsertionSort), and how does that relate to test coverage?

Unchecked
Answer
  • Black = user view, no internal knowledge; white = internal structure/code; gray = partial (docs + external effects).
  • Black-box can miss internal edge cases (QuickSort vs InsertionSort behave the same externally); coverage of internal logic stays low.
5/16

For the given code (e.g. calcDiscount, comeOnTestMe, processInput) define the minimal test cases for full C0, C1, and C2/C3 coverage, and explain how loops, try/catch, if-without-else and switch/case affect path coverage (C4). What is the trick in the short-circuit example?

Unchecked
Answer
  • C0 = every statement once; C1 = every branch (if-without-else still 2 edges); C2 = each atomic condition both truth values; C3 = all composite combinations (2^n).
  • Short-circuit (||/&&) can leave a sub-condition unevaluated despite 100% C2; C4 path count explodes with loops/branches.
6/16

Does test coverage give a sensible statement about whether a project is tested enough? Using "a good test finds errors with high probability", how could you judge test sufficiency better than coverage alone (recall the triangle test and the "tester in a bar")?

Unchecked
Answer
  • Coverage is necessary but not sufficient — high coverage can still miss whole input/scenario classes.
  • Judge by detected (real/mutated) defects, not coverage alone; enumerating all relevant cases is hard (triangle test).
7/16

What steps do you take to form equivalence classes, how do valid and invalid classes differ, and what lesson do equivalence classes give when combined with coverage? Form the classes for the Media-Markt staged-discount spec (int rabatt(boolean customerCard, int price)).

Unchecked
Answer
  • Partition inputs/outputs into classes of equivalent (mis)behavior; test one representative per class; cover valid and invalid.
  • Discount thresholds 1/51/201/501€ give valid classes plus an invalid <1€ class; +3% with customer card; pick a representative per class.
8/16

For boolean shouldCool(int currentTemp) with a target range of 5–10°C, identify the equivalence classes and the boundary values you would use as test data, and explain why boundary-value analysis focuses on class edges.

Unchecked
Answer
  • Classes: below range, in range, above range; boundaries around 5 and 10 (e.g. 4/5, 10/11) plus the boundary values themselves.
  • Most errors (off-by-one, >/≥) occur at class boundaries.
9/16

What are mocks, fakes, stubs and dummies, how do they differ, implement each for a database-access interface (dummy → mock), how would you swap test and real implementations (DI), and how does a test driver differ from these?

Unchecked
Answer
  • Dummy: interface only; Fake: simplified working impl (HashMap DB); Stub: returns fixed data/ignores changes; Mock: records and verifies calls/order/params.
  • Use Dependency Injection to swap real vs double; a test driver calls and controls the component under test (a layer), not a replacement.
10/16

What steps does TDD follow (when are tests, skeleton and real logic written), what do Think → Red → Green → Refactor mean and why this order, and what theoretical and practical advantages does TDD bring? Implement an Account class (getAmount/deposit/withdraw/transfer) test-first.

Unchecked
Answer
  • Tests first (Red, failing), skeleton during Think, real logic in Green, clean up in Refactor keeping green.
  • Order gives immediate feedback, early problem/side-effect detection, requirement plausibility; practice: higher satisfaction, fewer reported errors, shorter test phase.
11/16

Explain pre-conditions, post-conditions and invariants with code examples and their link to encapsulation. What is weak vs strong, and negotiating with a customer would you prefer strong or weak pre-/post-conditions? Must they be asserts, and how do asserts relate to unit tests? Annotate the Stack pop() with one of each.

Unchecked
Answer
  • Pre = state before call, post = state at end, invariant = stable state between calls (Stack: pre top>0, post top decreased, invariant 0<=top<=cap).
  • Implementer wants strong pre + weak post (less work); caller wants the opposite; asserts not mandatory; asserts are always-on contract checks, unit tests are external targeted cases — complementary.
12/16

What is fuzzing and how does it work, what steps does a fuzzer run, which errors can it find easily, what must be given to use it for regression tests, and what are its limits (why not replace manual unit tests)?

Unchecked
Answer
  • A fuzzer feeds generated/mutated inputs watching for crashes; finds crash/robustness defects easily.
  • For regression it needs a recorded expected baseline (oracle); limits: mostly crashes, no functional oracle → cannot replace targeted unit tests.
13/16

Explain how the given Gherkin/Cucumber example works and what advantages Cucumber brings over classic unit tests (keyword: data-driven test), considering different stakeholders.

Unchecked
Answer
  • Given/When/Then steps map to step definitions; the Examples table makes it data-driven (one scenario, many rows).
  • Readable by non-technical stakeholders → bridges requirements and tests while reusing one scenario across data.
14/16

Compute the cyclomatic complexity of the sqrt(float) method (M = E − N + 2), what measure reduces it, and what value range is desirable?

Unchecked
Answer
  • Build the control-flow graph, count edges E and nodes N, apply M = E − N + 2.
  • Reduce by extracting methods / removing branches; keep complexity low.
15/16

Describe the code-review types and the effect of "very formal" vs "little formal", name advantages/disadvantages of reviews, and explain why they should be combined with technical QA measures.

Unchecked
Answer
  • Formal (inspection) = strict roles/process, thorough but costly; informal (walkthrough) = lighter, faster, less thorough.
  • Pros: early, applicable to any artefact, shorten latency, knowledge transfer; con: author-as-accused; combine with tests because each finds different defects.
16/16
Qualitätssicherung — lecture slides (Block 5) 20 questions From LLM

State the seven ISTQB testing principles.

Unchecked
Answer
  • Testing shows presence not absence of errors; exhaustive testing impossible; start early; defect clustering; repetition ineffective; context-dependent; absence-of-errors fallacy.
1/20

Compare the big-bang, top-down, bottom-up and vertical integration strategies.

Unchecked
Answer
  • Big-bang: all at once, hard localization; top-down: UI first, many stubs; bottom-up: persistence first, only drivers; vertical: function across all layers, no simulation, preferred for testing.
2/20

Define statement (C0), branch (C1), condition (C2/C3) and path (C4) coverage and their hierarchy.

Unchecked
Answer
  • C0 every statement; C1 every branch (C1⇒C0); C2 each atomic condition both values; C3 all combinations; C4 all paths (explodes).
3/20

What is the acceptance test, who performs it, and what are alpha vs beta tests?

Unchecked
Answer
  • Proves the agreed deliverables were met (not error-finding), done by customer/users.
  • Alpha at the manufacturer site, beta/field at the customer site.
4/20

List the steps of a typical defect-management process.

Unchecked
Answer
  • Report → assess/classify → assign → fix → deliver correction → re-test → close.
5/20

Name the object-oriented software metrics CBO, DIT, RFC, WMC and LCOM and what each measures.

Unchecked
Answer
  • CBO coupling between objects; DIT depth of inheritance tree; RFC response for a class; WMC weighted methods per class; LCOM lack of cohesion in methods (ideally 1).
6/20

Why is QA necessary, which quality factors are used, and how does the QA method taxonomy split measures?

Unchecked
Answer
  • QA is necessary because software is never error-free, fault counts scale with size, and errors arise from requirements, communication, design, coding, and guideline problems.
  • Quality factors: functionality, reliability, usability, efficiency, changeability, and portability.
  • Taxonomy: static analytical QA, dynamic analytical QA, and organizational QA.
7/20

What does the residual-defect table demonstrate, and why do critical systems still usually not fail catastrophically?

Unchecked
Answer
  • Bug finding is never complete: residual defects and severe residual defects remain at delivery, roughly scaling with application size.
  • Many faults are never triggered, redundancy/processes catch others, and severe residual defects are only a small fraction.
8/20

What are static analysis, software metrics, and reviews used for in static QA?

Unchecked
Answer
  • Static analysis checks artefacts without executing them, early enough to improve internal quality before integration.
  • Metrics quantify process/product properties such as size, logical structure, cyclomatic complexity, and OO relationships.
  • Reviews formally inspect artefacts against criteria/checklists with roles and phases to reduce error latency.
9/20

Which test levels/types and integration strategies should you distinguish?

Unchecked
Answer
  • Levels/types include component/unit, integration, system, acceptance, functional and non-functional tests, with different responsibilities and scopes.
  • Integration strategies include top-down, bottom-up, big-bang, and mixed approaches, using drivers/stubs/doubles where needed.
10/20

What makes tests data-driven, readable, documented, and useful for later repetition?

Unchecked
Answer
  • Data-driven tests separate reusable test cases from concrete test data; positive tests check valid input, negative tests check problem detection/handling.
  • Readable tests use descriptive names or Given/When/Then scenarios; documentation records ID, type, preconditions, inputs, description, expected/actual result, and decision.
  • Tests should be small, reproducible, isolated, side-effect-free, framework-supported, and kept green.
11/20

How does TDD differ from traditional late testing, and why can it pay off despite initial extra effort?

Unchecked
Answer
  • Traditional testing finds errors late in an existing solution; TDD specifies tests before or alongside implementation and designs behavior through tests.
  • TDD gives immediate feedback, detects side effects early, checks requirements plausibility, can reduce customer-reported errors, and shortens the later test phase.
12/20

Name the test-process phases, the defect-management flow, and the main tradeoff of test automation.

Unchecked
Answer
  • Test process: planning/control, analysis/design, realization/execution, evaluation/report, and closure.
  • Defect management: report, assess, assign, fix, deliver correction, re-test, close.
  • Automation is expensive to prepare but cheap and repeatable to run, especially for regression/CI; GUI and non-functional tests need special care.
13/20

What do organizational QA, quality standards, and formal verification contribute?

Unchecked
Answer
  • Organizational QA provides knowledge/configuration management, templates, and checklists.
  • Standards such as ISO 9001, CMM/CMMI, SPICE and testing standards improve process consistency, coordination and customer trust.
  • Formal verification translates code/properties into SAT/SMT-style formulas to prove limited critical behavior, but is very costly.
14/20

Name the six software quality factors from the lecture and what each roughly means.

Unchecked
Answer
  • Functionality: functions with defined properties; Reliability: stable performance under given conditions over time.
  • Usability: effort needed by users; Efficiency: performance relative to resources.
  • Changeability: effort needed for changes; Portability: ease of migration to another environment.
15/20

What is static QA/static analysis, and which analysis forms does it include?

Unchecked
Answer
  • Static QA checks a test object without executing it, so it can be applied very early and improve internal quality.
  • It includes structure analysis, error-pattern analysis, and tool checks for development-guideline compliance.
16/20

What are the main benefits, costs, and target areas of automated and non-functional testing?

Unchecked
Answer
  • Automation is systematic, repeatable, traceable and cheap to rerun, but expensive to prepare and dependent on suitable frameworks.
  • It is especially useful for regression and CI; GUI automation can use capture/replay or scripting.
  • Non-functional tests cover performance, usability and security and usually need specialized expertise.
17/20

Which organizational QA measures lower the error rate before analytical testing even starts?

Unchecked
Answer
  • Knowledge management improves organizational learning and deliberate handling of knowledge.
  • Configuration management controls specifications, documentation and source across versions, change states and releases.
  • Templates and checklists standardize documents and guide yes/no weakness checks.
18/20

Why is systematic quality assurance unavoidable in modern software?

Unchecked
Answer
  • Software is never error-free, large systems contain many chances for faults, and famous failures show the consequences.
  • Errors arise from faulty requirements, communication misunderstandings, design errors, coding errors, wrong test data, and ignored standards/guidelines.
19/20

What are test data, data-driven tests, positive tests, and negative tests?

Unchecked
Answer
  • Test data configure the target system, doubles and drivers, and drive execution.
  • Data-driven tests separate reusable test cases from concrete data, allowing one case to run with many data sets.
  • Positive tests check valid input produces correct behavior; negative tests check problems are detected and handled as expected.
20/20
Security — worksheet (Block 5) 6 questions From Course Content

A company designed its own "especially secure and efficient" encryption algorithm and then decided to keep the algorithm secret to hinder attackers. Assess both decisions from a security viewpoint with reasons.

Unchecked
Answer
  • Don't invent your own crypto — secure crypto needs deep expertise and public scrutiny; self-made ciphers are almost certainly weak.
  • Keeping the algorithm secret is security by obscurity and violates Kerckhoffs' principle (security must rest only on the key); secrets leak.
1/6

Explain the practical lessons behind Least Privilege, Input Validation, and the storage of encryption keys, with examples of how each goes wrong.

Unchecked
Answer
  • Least privilege: minimal rights, deny by default (Apache-as-admin gave full access).
  • Input validation: always whitelist untrusted input early to stop injection/DoS.
  • Key storage: never plaintext/DB-readable (ELBA); use OS key stores, salted hashes, BCrypt/PBKDF2, clear from memory.
2/6

Where are the security problems hidden in the comparePasswords code that compares the supplied and expected password via Objects.equals (String.equals)?

Unchecked
Answer
  • Timing side-channel: String.equals returns on the first mismatching character, leaking match progress → use constant-time comparison.
  • Plaintext password handling (should be salted hashes) and information leakage via distinct exceptions/messages.
3/6

What is the difference between MAC-then-Encrypt, Encrypt-and-MAC and Encrypt-then-MAC? Does the choice matter, what are the pros/cons, and what can happen if a developer chooses the "wrong" one?

Unchecked
Answer
  • MAC-then-Encrypt (TLS): verify only after decryption; Encrypt-and-MAC (SSH): MAC over plaintext can leak, verified after decryption; Encrypt-then-MAC: verify ciphertext first, reject before decrypting — generally most secure.
  • The order matters; a wrong choice can silently weaken security (padding-oracle-style) — hence don't invent crypto.
4/6

Why is Java's built-in serialization called "a horrible mistake" with "no reason to use it in any new system", and what disadvantages does it bring?

Unchecked
Answer
  • Deserializing untrusted data can instantiate arbitrary objects/gadget chains, cause side effects and DoS, even via unused library classes.
  • Large hard-to-control attack surface; prefer XML/JSON, whitelist classes (look-ahead), never deserialize untrusted data.
5/6

What are trust boundaries, why do Google/iCloud push two-factor authentication (and what does that imply for software engineering), what are the drawbacks of all-or-nothing authentication, how do you build a trust basis with a server, and what is the purpose of the obfuscated %TEMP%/%ProgramFiles% command string?

Unchecked
Answer
  • Trust boundary: where data crosses into a more-trusted zone — validate/authorize everything crossing inward.
  • 2FA = layered defense (don't rely on one safeguard); all-or-nothing is bad (one compromise grants all) → graded least privilege.
  • Trust via encryption + verified certificates (PKI/pinning) and data validation; the obfuscated string is an evasive shell command → blacklist filtering fails, whitelist/validate (Code Obfuscation, cf. SQL injection).
6/6
Sicherheit — lecture slides (Block 5) 25 questions From LLM

Explain how SQL injection works, including tautology attacks and UNION attacks, and give the recommended countermeasures.

Unchecked
Answer
  • Dynamic SQL built from user input lets attackers alter the statement (' or '1'='1, UNION, subqueries) to read/change/delete data.
  • Countermeasures: validate input, escape/whitelist, prepared statements with placeholders, restrict DB privileges, use an OR-mapper.
1/25

State Kerckhoffs' principle and why it matters.

Unchecked
Answer
  • Security of encryption rests only on the secrecy of the key, not the algorithm; secret algorithms leak (no security by obscurity).
3/25

Name the design principles for a secure architecture.

Unchecked
Answer
  • Simplicity (KISS), restrict permissions/default deny + whitelist validation, complete mediation (central checks), open design (no obscurity/Kerckhoffs), layering, least privilege, minimize dependencies, and the social/usability component.
4/25

What is a man-in-the-middle attack (e.g. ARP spoofing) and what countermeasures exist?

Unchecked
Answer
  • Intercepting traffic via a third party; ARP spoofing poisons the ARP cache with forged IP/MAC mappings.
  • Countermeasures: encryption (HTTPS), PKI, certificate pinning, don't disable cert validation.
5/25

Why is relying solely on penetration testing ('penetrate and patch') insufficient?

Unchecked
Answer
  • Overlooks vulnerabilities; unfound ones stay unfixed; patches fix symptoms not root causes; systems stay vulnerable until deployed; published patches reveal holes in unpatched systems.
6/25

What is a vulnerability (Schwachstelle), and in which phases do vulnerabilities typically arise?

Unchecked
Answer
  • A flaw or weakness in a system that could be exploited to violate its security policy (RFC 4949).
  • They arise in the design phase (faulty architecture assumptions), implementation (insecure practice), and assembly/configuration (config errors or wrong defaults); today often a subtle combination of several small problems.
7/25

Outline the typical phases of a planned attack.

Unchecked
Answer
  • Reconnaissance of the target; analyse it for known vulnerabilities/conceptual gaps; identify and exploit vulnerabilities (privilege escalation, session hijacking, SQL injection).
  • Establish permanent access (own user, installed software, even patching the hole); cover tracks (e.g. delete logs); repeat, working further into the IT landscape.
8/25

What is the onion-shell (Zwiebelschalenmodell) wrapper model, and what problem does it solve?

Unchecked
Answer
  • A wrapper placed around a legacy system's interfaces that validates incoming/outgoing data and integrates new security concepts (e.g. encryption) without changing the legacy software itself.
  • It addresses legacy systems that lack open-interface design, rights management, sufficient patch levels, or input validation but must still be integrated.
9/25

Why is whitelisting preferred over blacklisting for input validation?

Unchecked
Answer
  • A whitelist defines exactly what is allowed (e.g. a credit-card-number format), so anything unexpected is rejected by default.
  • A blacklist only defines what is forbidden, fails against new/unknown attacks, and is hard to keep current.
10/25

Name the key secure-code rules regarding immutability, mutable values, and static fields in Java.

Unchecked
Answer
  • Define value types as immutable; return mutable values only as copies and copy mutable inputs before processing; expose explicit state-changing methods; make as many fields constant as possible.
  • Public mutable static fields are dangerous (identical across the whole JRE, attackable even with multiple ClassLoaders) — make public statics final and keep mutable statics non-public, encapsulating array access via copies (e.g. return data.clone()).
11/25

Why is deserializing untrusted Java objects dangerous, and how do you mitigate it?

Unchecked
Answer
  • Maliciously altered serialized structures can instantiate arbitrary objects and trigger side effects/gadget chains — even exploiting faults in unused classes that merely ship in a library — and enable DoS.
  • Mitigate by validating with a class whitelist (look-ahead ObjectInputStream), avoiding deserialization in general, never deserializing untrusted data, and preferring XML/JSON over serialized Java objects.
12/25

Why is IT security difficult, and what does "security is a process" imply for development?

Unchecked
Answer
  • Security is hard because systems are open, attacks evolve, developers misunderstand components, own code creates unique faults, functionality grows, and time/resources are limited.
  • Security must be considered in all phases, supported by management and users, based on risk/cost-benefit thinking, and addressed early because late fixes are expensive.
13/25

What must be done in the security analysis phase for requirements, risk, and threat documentation?

Unchecked
Answer
  • Elicit functional/non-functional security requirements from stakeholders, including implicit assumptions, certificates/standards, CIA goals, protection classes, and residual risk.
  • Use techniques such as CVE/CVSS, attack trees, misuse cases, and threat modeling with scenarios, data-flow diagrams, threat identification, risk assessment, and countermeasures.
14/25

Name the secure-design principles presented in the lecture, and explain why the architecture must support security before implementation begins.

Unchecked
Answer
  • Architecture is the basis for secure implementation; a small design gap can undo extensive work, so design uses patterns, attack patterns and modelling.
  • Principles: simplicity, restricted permissions/deny by default, complete mediation, open design/Kerckhoffs, layering/defense in depth, least privilege, minimal dependencies, and usable social components.
15/25

Which Java runtime-security mechanisms, Denial-of-Service prevention rules, and confidential-data handling rules matter for secure programming?

Unchecked
Answer
  • Java helps via runtime checks, bytecode verification, bounds checks, security APIs/tools, SecurityManager/AccessController policies, and ClassLoaders.
  • DoS prevention means releasing resources, avoiding dangerous parser/resource patterns, handling large/manipulated inputs, and planning for load/attacks.
  • Protect confidential data by avoiding leaks in exceptions/logs, not storing passwords/keys plaintext, and clearing sensitive memory promptly.
16/25

How do extensibility, security tests, and operation affect long-term security?

Unchecked
Answer
  • Extensibility and plug-ins need strict access rights, validation, and controlled extension points so added code cannot break assumptions.
  • Security tests include targeted negative/security-relevant tests and penetration-style checks; during operation, patching, monitoring, configuration and decommissioning continue the security process.
17/25

How do SQL injection attacks and man-in-the-middle attacks work at a high level, and which countermeasures address each one?

Unchecked
Answer
  • SQL injection manipulates untrusted input into commands; counter with prepared statements/parameter binding, validation, least privilege and no string-built SQL.
  • MitM intercepts or modifies communication between parties; counter with authenticated encryption/TLS, certificate checks, and not ignoring certificate warnings.
18/25

Distinguish exploitable and internal vulnerabilities, and give the consequence of each.

Unchecked
Answer
  • Exploitable vulnerabilities can be used directly to violate confidentiality, integrity or availability, e.g. privilege escalation through a buffer overflow.
  • Internal vulnerabilities are not directly exploitable but increase damage when combined with other vulnerabilities, e.g. insufficient rights restrictions.
19/25

How can secure architecture and secure implementation undermine each other, and which Denial-of-Service prevention rules follow for Java systems?

Unchecked
Answer
  • A secure architecture can be broken by implementation faults, and flawless code can still be weak if the architecture omits security.
  • For DoS, watch resource-heavy actions, release resources even on error paths, guard parsers and manipulated data, avoid integer-overflow resource checks, and test behavior under attack/load.
20/25

What must be controlled when software is extensible through plug-ins or external components?

Unchecked
Answer
  • Extension points must be explicit and controlled, because plug-ins or external components can bypass assumptions if they get too much access.
  • Use access rights, validation, minimal permissions and clearly restricted APIs so extensions cannot compromise core behavior.
21/25

Why do security problems arise even in ordinary software projects?

Unchecked
Answer
  • Security problems come from bugs, weak planning/code quality, open interfaces, false security understanding, component misunderstanding, own code, fast-evolving attacks, time/resource limits, and growing functionality.
  • They create financial damage through data theft, extortion, fines, image damage and operational compromise.
22/25

What must security design provide before secure implementation can succeed?

Unchecked
Answer
  • The architecture must support required security, because implementation cannot reliably compensate for an insecure design.
  • Use security patterns, attack patterns and modelling to identify template solutions, attack relations and architecture gaps.
23/25

Name the Java runtime-security mechanisms presented in the lecture and explain why they still need correct configuration.

Unchecked
Answer
  • Java provides runtime enforcement, security APIs/tools, automatic memory checks against buffer overflows, bytecode verification, SecurityManager/AccessController policies, and ClassLoader separation.
  • These mechanisms help but must be configured and not disabled.
24/25

What kinds of input or behavior create Denial-of-Service risk, and how should software defend itself?

Unchecked
Answer
  • Risks include CPU/memory-heavy computations, large binaries/images/compressed data, complex nested objects, manipulated ZIP/XML/regex/parser data, Java deserialization, integer overflows, endless loops, and forgotten resource release.
  • Defend with standard parsers/formats, resource limits, try-with-resources, configuration, and tests under attack and high load.
25/25
Inbetriebnahme, Rollout & Wartung — worksheet (Block 6) 9 questions From Course Content

During operation a contradiction often arises between the two requirements robustness and performance. What could cause this contradiction and how could it be resolved? Can you name a solution from the Java area for this problem (a suitable technique was already presented in Block 5)?

Unchecked
Answer
  • Cause: defensive checks, input validation and safe (intended) framework APIs cost speed, while raw-speed shortcuts sacrifice safety/robustness.
  • Resolution: only optimize where measurement proves a real bottleneck; keep robustness by default and trade it for speed selectively, with tests.
  • Java technique (Block 5): assertions/assert can be enabled during development/testing for robustness checks and disabled in production for performance.
1/9

Comment on the statement "Premature optimization is the root of all evil." What is the source probably trying to tell us, where could the problem with optimizations lie, and what is needed to carry out optimizations sensibly? Also: a framework-API functionality can be implemented either with the intended call or by an inventive combination of calls not meant for it that is ~20% faster — what speaks for and against using that optimization?

Unchecked
Answer
  • Message: don't optimize before you have measured where the real bottleneck is; optimization without data wastes effort and adds risk ('you can't control what you can't measure', 'without data you are just another person with an opinion').
  • Needed: systematic measurement (profiling, performance tests), but measuring is hard in practice (concurrency, JIT warm-up, caching, GC distort timings).
  • Faster workaround risks: breaks on framework updates, harder to understand/maintain, possible undocumented side effects; usually not worth it — prefer the intended API unless measurement proves the bottleneck matters.
2/9

Describe for each of the four enterprise-integration approaches (File Transfer, Shared Databases, Remote Procedure Invocation, Messaging) what characterizes it and what advantages/disadvantages it brings. What advantages/disadvantages do the upper two approaches show in particular compared to the lower two?

Unchecked
Answer
  • File Transfer: app A writes a file, copied and read by app B; simple/old, often batch → stale, coarse-grained data, needs shared drives, often manual and error-prone.
  • Shared Databases: apps share one (relational) DB; finer granularity, changes immediately visible on commit, but breaks encapsulation, creates hard-to-grasp dependencies, scales poorly.
  • Remote Procedure Invocation: call a method on a remote machine (RMI/CORBA); keeps encapsulation, efficient within a platform, problems across platform boundaries / for strong decoupling.
  • Messaging: data packed into messages on a message bus via a broker; loosest coupling, but complex (delivery/order/timing guarantees, connection quality), needs frameworks.
  • Upper two (File/Shared DB) are simpler but couple via shared files/data models, break encapsulation and scale poorly; lower two (RPI/Messaging) preserve encapsulation and decouple better, with Messaging loosest at the cost of complexity.
3/9

New versions typically pursue goals (e.g. more purchases) but it is often unclear in advance whether the new version meets the goal or even worsens it, and how versions can be introduced without downtime. Describe how each of Blue/Green deployment, A/B testing, and Canary releases works.

Unchecked
Answer
  • Blue/Green: two identical environments — Blue (current) live, Green (new) idle; deploy/test on Green, then switch all traffic at once; zero-downtime, instant rollback by switching back to Blue.
  • A/B testing: route different user groups to versions A vs B simultaneously and compare a target metric (e.g. purchases) to learn data-driven whether the new version is really an improvement.
  • Canary release: roll out to a small subset of users/servers first (the 'canary'), monitor, then gradually expand to everyone if it behaves well — limiting the blast radius of a bad release.
4/9

What benefit arises from versioning at all, and why did developers begin to lay down rules fixing exactly how version numbers are to be chosen? Explain a practical versioning scheme.

Unchecked
Answer
  • Benefit: a version number communicates what an update contains and how risky it is; rules (a scheme) make the number carry meaning instead of being arbitrary.
  • Semantic Versioning (MAJOR.MINOR.PATCH): MAJOR for incompatible/breaking API changes, MINOR for new backward-compatible functionality, PATCH for backward-compatible bug fixes.
  • Deprecation: before removing functionality (a breaking/major change), mark it deprecated in a release first so users get time to migrate and removal is no surprise.
5/9

Why should a new version be accompanied by a changelog? What is a changelog, which contents should it cover, can it be generated automatically from the source-code management, how is a typical changelog structured, and which best practices can you identify?

Unchecked
Answer
  • Why/what: it informs users and developers what is new, what changed, and which problems to expect on an update.
  • Structure/content: group changes by type (Added, Changed, Removed, etc.); always give date and version number; keep an Unreleased section updated during development so nothing is missed.
  • Auto-generation: possible from commits (even Conventional Commits) but tends to be too detailed and needs much manual finalization/control.
6/9

Lehman and Belady derived six laws from data on software maintenance (1976–1992), holding especially for large, continuously used software. Name the laws and consider briefly why each one would or would not apply.

Unchecked
Answer
  • Continuing change: software in use must continually adapt or it becomes less useful.
  • Increasing complexity: complexity grows unless effort is spent to reduce it.
  • Self-regulation / fundamental law of program evolution: evolution is a self-regulating process.
  • Conservation of organizational stability (invariance of work rate): average effort/activity stays roughly constant over a release's life.
  • Conservation of familiarity (invariance of release content): incremental growth/change per release stays roughly constant.
  • Continuing growth: functional content must keep growing to keep users satisfied.
7/9

Every library/framework you embed is a dependency you must update and adapt to. How does this relate to the lock-in effect, and how should you proceed optimally to keep the pain of updates as small as possible? Name the most important steps.

Unchecked
Answer
  • Lock-in: the more deeply your code depends on a framework's conventions/APIs, the harder and costlier it is to update or switch away (GitHub needed 1.5+ years for Rails 3.2 → 5.2).
  • Steps to minimize update pain: abstract from frameworks early and isolate third-party APIs behind your own interfaces; update in small steps (don't skip many versions); keep good automated/regression tests to catch breakage; weigh benefits (security, features, support) against migration cost.
8/9

Brooks found that successor systems (the 2.0 developed after the 1.0 release) carry an especially high risk of failing or being badly delayed. Think of a possible reason for this.

Unchecked
Answer
  • Second-system effect: emboldened by the first system's success and freed of its time pressure, developers over-engineer the successor — piling in all the features/refinements left out the first time — so it becomes bloated, over-ambitious and late.
  • Remedy: disciplined scope control and incremental delivery.
9/9
Inbetriebnahme, Rollout & Wartung — lecture slides (Block 6) 19 questions From LLM

Distinguish Continuous Integration, Continuous Delivery, and Continuous Deployment.

Unchecked
Answer
  • CI: commit to master as often as possible; each change is validated by automated build + tests.
  • Continuous Delivery: extends CI — build, test and deploy-to-staging + acceptance tests automated, but the deploy to production stays a manual (button) step.
  • Continuous Deployment: one step further — if all stages pass, every update goes to production automatically (deploy + smoke tests automated too).
1/19

What is the formal acceptance (Abnahme) of software and what legal/practical consequences does it have?

Unchecked
Answer
  • Acceptance is the customer's formal taking-over of the work, done on the basis of the specification and documented; complex systems need multi-stage acceptance by several stakeholders, traceable against a complete spec.
  • Consequences: final checks; payment becomes due; warranty obligations and the limitation period for defect claims begin; the burden of proof for defects shifts to the customer.
  • Levels: technical basis (developer/function tests), content level (black-box and user-acceptance tests), and integration tests.
2/19

Name and explain the four maintenance types and the two category axes they come from.

Unchecked
Answer
  • Axes: Correction vs Enhancement, and Reactive vs Proactive.
  • Corrective: correction + reactive — fixing faults, usually triggered by the customer.
  • Adaptive: enhancement + reactive — adapting to a changed environment (software/services/hardware).
  • Preventive: correction + proactive — preventing faults before they occur (e.g. Y2K preparation).
  • Perfective: enhancement + proactive — improvements (usability, performance, maintainability) on demand, needing reproducible measurement.
3/19

Compare the Cold-Turkey and Chicken-Little migration strategies, and explain forward vs. reverse migration.

Unchecked
Answer
  • Cold-Turkey (big bang): build the new system in parallel, then switch system + all data at once; time-consuming, hard to oversee, higher risk, but no gateways and simpler data handling.
  • Chicken-Little (incremental): migrate in many small, manageable steps until done; simpler/clearer, problems fixed or rolled back faster.
  • Forward migration: migrate the DB first, old apps use it via forward database gateways. Reverse migration: migrate the application first, it works on the old schema via reverse database gateways.
4/19

What are Service Level Agreements (SLAs) and according to which principle should they be defined?

Unchecked
Answer
  • SLAs fix criteria for non-functional requirements, set by stakeholders before development and met during operation or penalties apply (e.g. availability, response time under load, time to answer a maintenance request).
  • They should be defined per the SMART principle: Specific, Measurable, Achievable, Reasonable, Time-bound.
5/19

Which roles are involved in the operation of a system, and what are their responsibilities and rights?

Unchecked
Answer
  • Operators: ongoing monitoring, no infrastructure access (black box).
  • Administrators: network admin (network infrastructure), technical admin (individual systems like app/DB/server), functional admin (apps via own UI, usually no underlying-infrastructure access).
  • Support: contact point for users where error reports arrive, with First and Second Level support.
6/19

Why is user acceptance decisive for a successful commissioning, and which measures raise it?

Unchecked
Answer
  • Fear of change (making mistakes, work taking longer) otherwise causes resistance, so acceptance is decisive for success.
  • Measures: involve users early; adapt training material/user documentation to their needs; extensive training and a trial operation with feedback; show the new system's advantages; introduce the software gradually.
  • User documentation targets end users, is organized by application modules/functions (not technical structure), with examples and screenshots; it both introduces the feature scope and serves as a reference.
7/19

Name the maintenance processes (per the maintenance life cycle).

Unchecked
Answer
  • Process implementation: define all plans (incl. the maintenance plan) and procedures.
  • Problem and modification analysis: iterative at the start of each phase, triggered by a change request — analyse, develop and select change options.
  • Modification implementation: implement the selected change.
  • Maintenance review/acceptance: evaluate correctness / whether the problem is solved; completed changes go to production.
  • Migration: transfer the application to a changed environment. Retirement: all measures to stop operating an application (e.g. exporting data).
8/19

Define commissioning (Inbetriebnahme), operation (Betrieb), and maintenance (Wartung).

Unchecked
Answer
  • Commissioning: all measures necessary for the first functional take-over of components/systems at their final locations — including integration into an existing IT landscape and training the responsible staff.
  • Operation: the life-cycle period during which a product is used in its operational environment and continuously monitored/adapted.
  • Maintenance (IEEE STD 1219-1993): the modification of a software product after delivery to correct faults, improve performance/other attributes, or adapt it to a modified environment.
9/19

Define Inbetriebnahme (commissioning), Betrieb (operation), and Wartung (maintenance), and explain how application type and toolchain shape deployment and updates.

Unchecked
Answer
  • Inbetriebnahme introduces software into use, Betrieb keeps it running, and Wartung changes it after delivery for faults, adaptation or improvement.
  • Application types (web, desktop, mobile, embedded, etc.) differ in installation, update, rollback, metrics and distribution constraints.
  • Toolchains and development strategies support repeatable building, testing, deployment, operation and updates.
10/19

Distinguish Continuous Integration, Continuous Delivery, and Continuous Deployment in practice.

Unchecked
Answer
  • Continuous Integration frequently integrates and automatically builds/tests changes.
  • Continuous Delivery keeps the software releasable, but release to production remains a deliberate decision.
  • Continuous Deployment automatically releases every suitable change to production after passing the pipeline.
11/19

What must be clarified for user acceptance, commissioning, formal acceptance, and module integration?

Unchecked
Answer
  • User acceptance needs training, documentation, support, and feedback opportunities so users can actually adopt the system.
  • Commissioning clarifies where the app runs, boundaries/interfaces, responsibilities, integration tests, documentation, support, operation start and trial operation.
  • Formal acceptance clarifies who accepts what, how, with what test-system/specification, against which target state, and when.
  • Good integration proceeds systematically from modules/components with clear interfaces and tests rather than late big-bang surprise.
12/19

Why do enterprise integration patterns matter, and which integration problem do they address?

Unchecked
Answer
  • Enterprise systems must connect heterogeneous applications, data sources and processes without making every system directly depend on every other.
  • Integration patterns provide reusable communication/data-exchange structures so systems can cooperate while remaining manageable.
13/19

What does operation require regarding ITIL/roles, SLAs, monitoring, optimization, and the operation checklist?

Unchecked
Answer
  • Operation keeps services available with defined roles/processes, stability, security, recovery, documentation, staff and independence requirements.
  • SLAs define measurable non-functional commitments using SMART-style criteria.
  • Monitoring measures reachability, availability, response times and SLA fulfilment; optimization uses measured unused capacity carefully and only after tests.
  • The checklist asks about response times, availability, expected behavior, SLAs, backup/recovery, redundancy/load balancing, staffing, machine failure and single points of failure.
14/19

What motivates migration, which migration types exist, and how do Cold-Turkey and Chicken-Little differ?

Unchecked
Answer
  • Migration is needed because software/hardware age and apps must adapt to changed legal/market/technical needs without disturbing operation.
  • Types: software, data, hardware and application migration; software migration often includes data migration.
  • Cold-Turkey switches everything at once after full parallel development; Chicken-Little migrates incrementally in manageable steps, using forward or reverse gateways.
15/19

What are the four maintenance types and the maintenance-process steps?

Unchecked
Answer
  • Types: corrective (fault correction/reactive), adaptive (environment adaptation/reactive), preventive (fault prevention/proactive), and perfective (improvement/proactive).
  • Process steps: process implementation; problem/modification analysis; modification implementation; maintenance review/acceptance; migration; retirement.
16/19

How do application types and the toolchain influence rollout, updates and operations?

Unchecked
Answer
  • Different application types have different deployment/update channels, rollback options, user-installation risks, monitoring possibilities and store/server constraints.
  • A toolchain makes build, test, delivery/deployment and operation repeatable and supports CI/CD-style automation.
17/19

What makes module/component integration manageable during commissioning?

Unchecked
Answer
  • Clarify interfaces and dependencies, integrate systematically instead of as a late surprise, and test integrated parts at each step.
  • A good approach keeps operation/acceptance goals visible and avoids discovering incompatibilities only at final handover.
18/19

Why does deployment/operation need a toolchain instead of manual ad-hoc steps?

Unchecked
Answer
  • A toolchain makes building, testing, releasing, deploying, monitoring and operating repeatable and traceable.
  • It supports CI/CD-style automation and reduces manual mistakes during frequent updates.
19/19
SE1 2025S Final Exam (previous exam — redacted scan) 11 questions From Course Content

Why does composition ease maintenance compared with inheritance?

Unchecked
Answer
  • Composition encapsulates only the needed collaborator behavior instead of inheriting a whole superclass API.
  • Dependencies, side effects and later changes stay more local, and the delegated mechanism can be swapped more freely.
1/11

Which implementation practices prevent avoidable string-handling and null bugs in Java?

Unchecked
Answer
  • Define the null contract explicitly instead of letting callers discover a NullPointerException.
  • Use StringBuilder for repeated string construction, because Strings are immutable.
  • Initialize values to meaningful defaults instead of relying on null as a temporary value.
2/11

Why should toString() not be used as a stable functional interface?

Unchecked
Answer
  • toString() is a human-readable debug/log representation, not a stable functional contract.
  • If code depends on its format, later formatting or localization changes can compile successfully but break behavior at runtime.
3/11

(2025S Final, Q4 — Block 5) Mark whether statements about QA and security are mostly true (W) or false (F). [The concrete statements are redacted in the scan and cannot be reconstructed — the answer lists the typical true/false traps from Block 5 for study use.]

Unchecked
Answer
  • Testing can show faults and raise confidence but normally cannot prove fault-freeness; 100% coverage does not imply good tests.
  • Static QA does not execute the code; dynamic QA executes code/tests. Black-box = user/spec view, white-box = code/structure knowledge, gray-box = partial.
  • C1 implies C0 but C0 does not imply C1; C4/path coverage explodes with loops/branches. Regression tests check that changes didn't break working functionality.
  • Stubs fit top-down integration, test drivers fit bottom-up. Security is not just encryption — auth, authorization, validation, rights, logging and operation all belong to it.
4/11

(2025S Final, Q5 — Block 5) For the alternateCaps listing: give parameter values for the necessary tests per coverage type (C0 statement, C1 edge, C2/3 condition, C4 path) with reasoning, and write a data-driven positive JUnit test. [Some sub-selections are redacted in the scan.]

Unchecked
Answer
  • C0 (statements): one valid string of ≥2 chars, e.g. 'ab', exercises init, loop, charAt, odd-index branch, '+=' and return (and reveals the 'nullaB' bug if asserted).
  • C1 vs condition: 'ab' can also cover the loop and `i % 2 == 1` true/false; for condition coverage of the compound loop condition add the empty string '' (covers !text.isEmpty() = false). For C2/3: '"" | "ab"'.
  • C4 (path): full path coverage is not finitely reachable because of the loop; representative paths: '' (zero iterations), 'a' (one), 'ab' (even+odd); null is a negative error case (NPE before the loop).
  • Data-driven positive test: @ParameterizedTest + @CsvSource({'ab,aB','abc,aBc','hello,hElLo'}) asserting the exact expected output — finds the result=null bug.
5/11

(2025S Final, Q6 — Block 5) Unit tests cost effort but give clearly visible benefit only at one specific moment — when exactly? And: a positive path-finding test asserts only `assertNotNull(move)` and `assertTrue(EMove.values() contains move)` — are these asserts sufficient? [Selection redacted in scan.]

Unchecked
Answer
  • The concrete benefit appears when the test is executed and either exposes a fault/regression or, after a change, quickly confirms the checked behaviour still holds.
  • No, the asserts are too weak: they only check that some valid EMove is returned, not that it is the functionally correct move for a concrete situation. Improve: arrange a defined map/state, act move = nextMove(...), assert the exact expected move (and side conditions).
6/11

(2025S Final, Q7 — Block 6) A fully automated build pipeline corresponds most closely to which stage? [Options redacted.] And: explain one best practice a 'staging' system must fulfil.

Unchecked
Answer
  • If it only builds/tests automatically without productive deployment, the best fit is Continuous Integration (frequent integration with automated build and tests). Stronger options would be Continuous Delivery (release-ready, manual release decision) or Continuous Deployment (successful changes auto-rolled to production).
  • Staging best practice: it should resemble production as closely as possible — same configuration, DB/service structure, deployment path and relevant load/permission assumptions — otherwise you test an artificial environment, not the real release conditions.
7/11

(2025S Final, Q8 — Block 6) The four integration approaches (FT = File Transfer, SD = Shared Databases, RPI = Remote Procedure Invocation, M = Messaging) split into two groups by a fundamental difference. Explain the difference (keywords), and say concretely when/why it matters with an example. [Assignment sub-part redacted.]

Unchecked
Answer
  • Fundamental difference: data/state integration (FT, SD share data/state via files or DB/schema — simple but can break encapsulation, give stale data, create strong dependencies) vs. behaviour/communication integration (RPI, Messaging communicate via calls/messages — internal data stays encapsulated; Messaging decouples more strongly).
  • Why it matters (examples): two same-vendor ERP systems → SD plausible; a growing landscape (accounting/HR/payroll) → Messaging so new systems are added without coupling each to each; old mainframes → RPI when little should change; X-ray images → FT since artefacts are naturally files.
8/11

(2025S Final, Q9 — Block 6) During maintenance the customer wants to optimize colours and controls for maximum user engagement. Which update/release strategy fits, and why are the others unsuitable? [Selection redacted.]

Unchecked
Answer
  • A/B testing fits: variants are shown to real users and compared by behaviour/metrics, which is exactly engagement tuning.
  • Canary suits risk-limited technical roll-out, not variant evaluation; Blue/Green suits instant switch/rollback but does not by itself measure which UI variant performs better.
9/11

(2025S Final, Q10 — Block 6) Updating Java from 1.8.0 to the direct successor marks Observable/Observer as deprecated (assume this is the only change and Java used SemVer). Which SemVer category fits, and why are the others unsuitable? [Selection redacted.]

Unchecked
Answer
  • Deprecated-but-not-yet-removed is a backward-compatible API change → MINOR (e.g. 1.8.0 → 1.9.0) when it is the only change.
  • MAJOR would fit only if the types were removed or incompatibly changed; PATCH is only for backward-compatible bug fixes without new/deprecated API meaning.
10/11

(2025S Final, Q11 — Block 6) Successor systems often fail for similar reasons that risk analysis must watch for. Which reasons, and why?

Unchecked
Answer
  • Successor systems often fail because hidden requirements, grown special cases, user habits and old domain knowledge are underestimated.
  • Brooks' second-system effect: teams try to fix too many old burdens and wishlist features at once in the '2.0', making it bloated and late. Remedy: disciplined scope control and incremental delivery.
11/11
Moodle official exam-example questions & test-prep tips (final) 3 questions From Course Content

Why are free strings a smell for a closed set of known states?

Unchecked
Answer
  • Free strings allow typos and unknown values to surface only at runtime.
  • Use an enum for a known fixed value set so the compiler can guard invalid states and make missing cases easier to spot.
1/3

(Moodle E5 — Block 5) For an alternateCaps with an early `if (text==null) return null;` then a StringBuilder loop with `i % 2 == 0`: how many tests minimum for 100% C0? What is the absolute difference between the C2 and C3 test counts? How many for 100% C3? Estimate C4. Write a data-driven positive unit test.

Unchecked
Answer
  • C0: at least 2 tests — null (early return) and e.g. 'ab' (construction, loop, even branch, odd branch, setCharAt, final return).
  • Absolute difference C2 vs C3: 0 — the relevant conditions are atomic here, so without a compound condition there are no extra combinations.
  • C3: at least 2 tests — null makes text==null true; 'ab' makes it false and covers the loop condition true/false and i%2==0 true/false.
  • C4: full path coverage is not finitely reachable with an arbitrarily long loop; a defensible estimate is null, '', 'a', 'ab' (early exit, zero/one iteration, even/odd paths). Data-driven test: @ParameterizedTest + @CsvSource({'abc,AbC','hello,HeLlO','a,A'}) asserting the exact value (assertNotNull would be too weak).
2/3

(Moodle E6 — Block 6) A company's changelog says only "improvements to user experience" and "some bugs fixed". Is this sensible for a professional project? If not, how should it be changed?

Unchecked
Answer
  • No — it is too vague: 'improvements' and 'some bugs' don't say which users/functions are affected, whether compatibility is impacted, which version is meant, or whether known issues exist.
  • Better: give version and date, grouped concrete changes (Added/Changed/Fixed), the affected functions/users, compatibility/migration notes, known issues, and any security relevance.
3/3
Student study cards (final — community-made active-recall set) 28 questions From Course Content

The following shows two versions of the same class. Assume it is delivered by one of your libraries, and the library currently contains only this Event<T> class. The old version of the library was delivered as version 1.0.0. State how you would have to change the current library version number 1.0.0 so that the change made to the Event<T> class is visible to all library users. Give the new library version number.

Event<T> class in library version 1.0.0

public class Event<T> implements IPublishEvent<T> {
    private final Queue<IEventHandler<T>> globalQueue =
        new ConcurrentLinkedQueue<IEventHandler<T>>();

    public void publish(T value) {
        for (IEventHandler<T> eachListener : globalQueue) {
            eachListener.handle(value);
        }
    }
}

Event<T> class after the library change

public class Event<T> implements IPublishEvent<T> {
    private final Queue<IEventHandler<T>> globalQueue =
        new ConcurrentLinkedQueue<IEventHandler<T>>();

    public void publish(T value) {
        for (IEventHandler<T> eachListener : globalQueue) {
            if (eachListener == null) {
                continue;
            }

            eachListener.handle(value);
        }
    }
}
Unchecked
Answer
  • 1.0.1 — the change is backward-compatible and a small bug fix, so only the PATCH digit increases; existing code keeps compiling and working.
  • Source answer: 1.0.1. For this scenario it is sufficient to change the last digit; it signals small changes and bug fixes, and an implementation that worked before still works at runtime and compile time after the change.
1/28

In everyday software engineering you will encounter many problem situations and must decide how to handle them. Answer the following statement: Refactoring means improving the software structure and maintainability while preserving all interfaces.

Unchecked
Answer
  • False — refactoring preserves the observable program behaviour, but not necessarily all interfaces; if better maintainability/readability/extensibility requires an interface change, that can be part of the refactoring.
  • Source answer: No. Refactoring improves an existing implementation while preserving program behaviour, but not necessarily the interfaces; the goal is better documentation, maintainability, readability, understandability and extensibility.
2/28

In everyday software engineering you will encounter many problem situations and must decide how to handle them. A motivated new colleague joins your team and wants to revise the build system. They ask whether Continuous Integration, Continuous Deployment, or Continuous Delivery should be implemented. Which option must the colleague implement to achieve the maximum benefit for your team?

Unchecked
Answer
  • Continuous Deployment — highest automation: build, test and deployment all run automatically, so frequent manual work disappears and problems show up early after commits (rule of thumb: automate anything regularly taking more than ~30s).
  • Source answer: Continuous Deployment. It gives the maximum benefit because it provides the highest possible automation: building, testing, deployment to relevant hardware and updates of existing installations are handled automatically.
3/28

In everyday software engineering you will encounter many problem situations and must decide how to handle them. Assume you are looking for a developer to analyse an existing legacy software system in order to determine its requirements and internal design. Which of the following keywords should you most likely include in the job description: Reengineering, Reverse Engineering, or Refactoring?

Unchecked
Answer
  • Reverse Engineering — examining an existing solution to understand its structure, behaviour, requirements or internal design, especially when original documentation or source code is missing.
  • Source answer: Reverse Engineering. An existing solution is examined to determine its structures and internal construction, often when the implementation code is no longer available.
4/28

In everyday software engineering you will encounter many problem situations and must decide how to handle them. You are involved in developing a small cloud-based online shop. Marketing is preparing a new campaign that will hopefully go viral and strongly increase access counts. Which maintenance method is most suitable in this scenario: Corrective, Adaptive, Preventive, or Perfective maintenance?

Unchecked
Answer
  • Preventive maintenance — the higher load is foreseeable, so capacity can be raised in advance (like replacing a disk at 90% full) instead of reacting after an outage.
  • Source answer: Preventive maintenance. The expected traffic increase is announced in advance, so more capacity can be rented before the access count rises and service quality is good from the start.
5/28

Which of the following technical terms best fits the given scenario: Test drivers, Stubs, or Test drivers and stubs? In top-down tests, which artefacts from the list does the tester normally have to create?

Unchecked
Answer
  • Stubs — they replace not-yet-available or deliberately isolated downstream parts; top-down tests drive from upper layers while deeper components are stubbed.
  • Source answer: Stubs. They isolate a piece of code from its environment and other system parts by replacing a real implementation; in top-down testing, downstream parts such as backend code are replaced with stubs.
6/28

Your department normally uses integration tests, system tests, unit tests, and acceptance tests. Assume you have been hired as a tester and must create a test plan that specifies when which tests are performed. In which order must these test levels be planned or carried out?

Unchecked
Answer
  • Unit → Integration → System → Acceptance — from small to large: units, then their cooperation, then the whole system, then customer/stakeholder acceptance.
  • Source answer: Unit tests, integration tests, system tests, acceptance tests. Tests usually build on one another and gradually cover larger areas; acceptance testing with the customer comes at the end.
7/28

Which fundamental project-management style would you use to fulfil the stated requirements as completely as possible? Requirements: You are responsible as lead developer/manager for further development of military software. Because of a previous political dispute, you have been instructed to monitor development precisely. In particular, you must be able to make the most accurate possible estimate at any time of the used and still required cost frame.

Unchecked
Answer
  • Plan-driven, e.g. waterfall or V-model — they give exact cost/time estimation, clear phases and plannability (at the price of less flexibility).
  • Source answer: Plan-driven project management, for example waterfall or V-model. Plan-driven process models are suitable when precise cost and project-duration estimates are necessary because they make the current project position and remaining steps clear.
8/28

Does the given architecture violate one or more of the following principles? Assume that the types shown here are all types present in the code. Principles: YAGNI, KISS, and DRY.

Given architecture

  • Interface IPageable exposes UNKNOWN_N_OF_PAGES, getNumberOfPages(), getCurrentPageContent(), tryFlipToNextPage(), and tryFlipToPreviousPage().
  • BookService implements that interface and exposes curPage plus the same page-navigation and content methods.
Unchecked
Answer
  • YAGNI and KISS — an interface adds no value without a real abstraction need; it only multiplies types and harms understanding.
  • Source answer: The architecture violates YAGNI and KISS. The interface has no benefit when the diagram shows all existing types; it only increases the number of code lines and makes the code harder to read and understand.
9/28

The following Java example code checks whether a popular beverage component has reached a recommended drinking temperature. If this is the case, true is returned. Perform an equivalence-class analysis based on it. Into how many and which equivalence classes would you divide the definition of tests for this Java code example?

Java example code

boolean meetsC8H10N4O2Temp(int temp) {
    return !(temp < 48 || temp > 60);
}
Unchecked
Answer
  • 3 equivalence classes: temp < 48, 48 <= temp <= 60, temp > 60 — each is a range of equal expected behaviour, so test at least one representative value per class.
  • Source answer: 3 equivalence classes: temp < 48; 48 <= temp <= 60; temp > 60. Equivalence classes represent ranges of equal behaviour, and at least one set of parameter values from each class should be covered by tests.
10/28

The following Java example code checks whether a popular beverage component has reached a recommended drinking temperature. If this is the case, true is returned. The following equivalence classes were defined. Perform a boundary-value analysis for the equivalence classes by giving one boundary value for each.

Java example code and equivalence classes

  • temp < 48
  • 48 <= temp <= 60
  • temp > 60
boolean meetsC8H10N4O2Temp(int temp) {
    return !(temp < 48 || temp > 60);
}
Unchecked
Answer
  • temp<48: 47 (or Integer.MIN_VALUE); 48<=temp<=60: 48 or 60; temp>60: 61 (or Integer.MAX_VALUE). Boundaries are where faults cluster (e.g. < vs <=, off-by-one).
  • Source answer: temp < 48 => 47 or alternatively Integer.MIN_VALUE; 48 <= temp <= 60 => 48 or alternatively 60; temp > 60 => 61 or alternatively Integer.MAX_VALUE.
11/28

Analyse the following Java source code. It returns a different character depending on the values taken by the parameters. How many tests are needed at minimum to achieve 100% branch coverage?

Java source code

char foobar(boolean first, boolean second, boolean third, boolean fourth) {
    char result = 'S';
    if (first) {
        result = 'E';
    } else if (second) {
        result = '1';
    } else if (third) {
        if (fourth) {
            result = '!';
        }
    }
    return result;
}
Unchecked
Answer
  • 5 — every branch must be taken and not-taken: first=true; second=true; third=false; third=true & fourth=false; third=true & fourth=true.
  • Source answer: 5. Branch coverage refers to branches such as ifs and loops; each branch condition must be fulfilled once and not fulfilled once to obtain 100% branch coverage.
12/28

Which of the following technical terms best fits the given scenario: Software Validation, Software Debugging, or Software Testing? Scenario: Which term is concerned with proving the existence of defects or increasing the probability that none are present?

Unchecked
Answer
  • Software Testing — checks code against concrete expectations; it can demonstrate defects but normally cannot guarantee full defect-freeness.
  • Source answer: Software Testing. It checks whether a piece of code meets certain expectations; if an expectation is not fulfilled, a defect has been found, but complete defect-freeness usually cannot be guaranteed by such tests.
13/28

Which of the following technical terms best fits the given scenario: Integration Tests, Regression Tests, Smoke Tests, or Acceptance Tests? Scenario: To make sure that a software product still runs correctly after changes during maintenance, which test type from the list would you most likely create?

Unchecked
Answer
  • Regression tests — they check that changes didn't break already-working parts and that old faults don't reappear.
  • Source answer: Regression Tests. They focus on ensuring that code changes do not make already-functional program parts stop working as expected or reintroduce old defects.
14/28

Which of the following technical terms best fits the given scenario: White Box Testing, Silver Box Testing, or Black Box Testing? Scenario: To ensure that new tests check all algorithms newly added to a project, I use which testing type?

Unchecked
Answer
  • White Box Testing — it uses insight into code/documentation/changes, so coverage can show whether new algorithms are actually tested (black-box couldn't show this reliably).
  • Source answer: White Box Testing. It requires full insight into documentation, code and code changes, and coverage algorithms can determine whether and to what extent a code part is covered by tests.
15/28

Which of the following technical terms best fits the given scenario: Versioning and version history, Synchronisation, Syntax Highlighting, and Forks and Branches for projects. Scenario: Which function from the list is typically not necessarily provided by source-code management software?

Unchecked
Answer
  • SCM focuses on versions, history, synchronisation and variants such as branches/forks.
  • Syntax highlighting is usually an editor/IDE feature, not an SCM responsibility.
  • Source answer: Syntax Highlighting. It is usually not a feature of software for version management; such software normally focuses on managing arbitrary text files and their versions.
16/28

Analyse the following Java source code. It returns a different character depending on the values taken by the parameters. How many tests are needed at minimum to achieve 100% path coverage?

Java source code

char foobar(boolean first, boolean second, boolean third, boolean fourth) {
    char result = 'S';
    if (first) {
        result = 'E';
    } else if (second) {
        result = '1';
    } else if (third) {
        if (fourth) {
            result = '!';
        }
    }
    return result;
}
Unchecked
Answer
  • 5 — all feasible execution paths: all-false (result stays 'S'), first, second, third&!fourth, third&fourth.
  • Source answer: 5. Path coverage refers to the possible paths through a piece of code; only when all technically possible execution orders of statements are covered is 100% path coverage achieved.
17/28

Analyse the following Java source code. It returns a different character depending on the values taken by the parameters. How many tests are needed at minimum to achieve 100% statement coverage?

Java source code

char foobar(boolean first, boolean second, boolean third, boolean fourth) {
    char result = 'S';
    if (first) {
        result = 'E';
    } else if (second) {
        result = '1';
    } else if (third) {
        if (fourth) {
            result = '!';
        }
    }
    return result;
}
Unchecked
Answer
  • 3 — first=true; second=true; third=true & fourth=true execute every statement, even though not all branches/paths are covered.
  • Source answer: 3. Statement coverage requires every statement, roughly every Java line with a semicolon, to be covered; a statement is considered fully tested once it is executed at least once during tests.
18/28

Which of the following techniques would you use in the given scenario to support it optimally: Blue/Green deployment, A/B tests, or Canary releases? Scenario: You develop server software for storing, managing and monitoring cars rented over a very long period of time, with a permanent connection between car and server software. Because of COVID-19, your employer moves cars to new regions where rentals are possible again. This requires extensive server-software changes that would no longer support rentals created before the change.

Unchecked
Answer
  • Blue/Green deployment — old and new versions run in parallel; old persistent connections finish on the old version while new connections go only to the new version.
  • Source answer: Blue/Green deployment. Two solutions, old and new, run in parallel; old active connections can finish on the old version while new connections are built only to the new version.
19/28

During rollout of a new software solution, the question usually arises how existing legacy applications should be handled so they can be integrated as well as possible. Analyse the scenario and choose the most suitable integration strategy: File Transfer, Shared Databases, Remote Procedure Invocation, or Messaging. Scenario: In a dynamically growing and constantly extended software landscape of an airline, new HR-management software is to be created and integrated. It organizes COVID-19 short-time work and includes individual software for accounting, HR administration, and payroll. Implement the integration of these parts so that additional extensions can be added as easily as possible and can build on existing software.

Unchecked
Answer
  • Messaging — decouples applications via messages (often a message bus); senders/receivers don't depend directly on each other, so new applications integrate easily.
  • Source answer: Messaging. Individual self-contained messages are exchanged, often through a message bus; receivers and processing are not known or relevant to the sending applications, so new applications can be integrated dynamically.
20/28

During rollout of a new software solution, the question usually arises how existing legacy applications should be handled so they can be integrated as well as possible. Analyse the scenario and choose the most suitable integration strategy: File Transfer, Shared Databases, Remote Procedure Invocation, or Messaging. Scenario: Georg's Computer Club has bought the competing company Schurl's Computer Club. To simplify coordination between both companies, the Enterprise Resource Planning software used by both companies individually, and coming from the same vendor, is to be integrated in a first step.

Unchecked
Answer
  • Shared Databases — ERP systems are data-driven and a same-vendor system makes a compatible schema plausible; a shared DB gives transactions/locks and often needs little change to the applications.
  • Source answer: Shared Databases. ERP systems usually use databases; because both systems come from the same vendor, an identical schema is plausible, database locks and transactions handle concurrent writes, and changing the applications themselves is often unnecessary.
21/28

During rollout of a new software solution, the question usually arises how existing legacy applications should be handled so they can be integrated as well as possible. Analyse the scenario and choose the most suitable integration strategy: File Transfer, Shared Databases, Remote Procedure Invocation, or Messaging. Scenario: Two older mainframes that originally worked separately are to be integrated. Because many older developers still work on the relevant software, the integration should have as little effect as possible on the prevailing implementation style and given software architecture.

Unchecked
Answer
  • Remote Procedure Invocation — remote calls look like local method calls, so the calling code and existing structures barely change.
  • Source answer: Remote Procedure Invocation. The concrete implementation remains on the server while the client sees an interface representation; method calls transmit parameters and execute the matching server logic, so existing implementation style and architecture can largely remain unchanged.
22/28

During rollout of a new software solution, the question usually arises how existing legacy applications should be handled so they can be integrated as well as possible. Analyse the scenario and choose the most suitable integration strategy: File Transfer, Shared Databases, Remote Procedure Invocation, or Messaging. Scenario: New X-ray image analysis software has been created that can combine several X-ray images into three-dimensional representations. The remaining medical software and the X-ray devices are not replaced.

Unchecked
Answer
  • File Transfer — X-ray images are naturally files; file transfer is simple and integrates existing systems without heavily changing certified medical software.
  • Source answer: File Transfer. X-ray images are usually represented as individual files, and file transfer can be used without changing an existing implementation, which is especially relevant for certified medical software.
23/28

Which of the following error-handling strategies best fits the given scenario: Fail Hard, Fail Soft, Fail Ignore, or Fail Recover? Scenario: Connection to a public train-connection database of a navigation app fails for the first time because of network problems.

Unchecked
Answer
  • Fail Recover fits when the system can plausibly restore normal operation itself, for example by retrying or reconnecting.
  • Source answer: Fail Recover. The system tries to recover from the error and restore a functional state itself; network connections are a classic case because reconnecting or retrying is often reasonable.
24/28

Which of the following error-handling strategies best fits the given scenario: Fail Hard, Fail Soft, Fail Ignore, or Fail Recover? Scenario: An advertising display in a pedestrian zone notices that advertising videos read from an SD card are partly decoded incorrectly.

Unchecked
Answer
  • Fail Ignore fits when the failed function is non-essential and continuing with a minor defect is safer or less disruptive than stopping.
  • Source answer: Fail Ignore. Errors are ignored and system functions continue to be offered even if this can lead to corrupted data; here the advertising display can continue showing ads even if some video blocks are decoded incorrectly.
25/28

You should already know Dependency Injection (DI) from developing tests. Many frameworks such as Spring, Zend, and others also include DI. But why? Which properties are typically associated with DI?

Unchecked
Answer
  • DI reduces coupling between code parts (dependencies are passed in from outside, often via constructors) and can lead to more types, especially interfaces — which makes swapping implementations and using mocks/stubs in unit tests easier.
  • Source answer: DI makes it easier to reduce coupling between code parts and can lead to an increased number of types, especially interfaces. Dependencies used in a class can be passed into that class from outside, for example through a constructor.
26/28

Which of the following error-handling strategies best fits the given scenario: Fail Hard, Fail Soft, Fail Ignore, or Fail Recover? Scenario: While establishing an encrypted connection to a bank server, anomalies are detected that could indicate an attack.

Unchecked
Answer
  • Fail Hard fits when continuing could threaten security, safety, integrity or correctness, so the action must abort.
  • Source answer: Fail Hard. The error leads to aborting the action, in extreme cases even actively terminating the application; in security-critical applications even small deviations can create major weaknesses.
27/28

Which of the following error-handling strategies best fits the given scenario: Fail Hard, Fail Soft, Fail Ignore, or Fail Recover? Scenario: The control software of a pacemaker is partly faulty and notices that computed control signals cannot be plausible.

Unchecked
Answer
  • Fail Soft fits when a faulty function should be disabled while essential functions keep running in a limited safe mode.
  • Source answer: Fail Soft. Errors cause the system to try no longer offering faulty functions, while the rest of the system and essential functions continue to work.
28/28
Student study cards (final — community-made active-recall set) (german) 28 questions From Course Content

Im Folgenden werden zwei Versionen der gleichen Klasse angeführt. Nehmen Sie an, dass diese von einer Ihrer Bibliotheken ausgeliefert wird, letztere beinhaltet derzeit nur diese Event<T> Klasse. Die alte Version der Bibliothek wurde als Version 1.0.0 ausgeliefert. Geben Sie an, wie Sie die derzeitige Versionsnummer 1.0.0 der Bibliothek ändern müssten, um die durchgeführte Überarbeitung an der Event<T> Klasse mittels der Bibliothek-Versionsnummer für alle NutzerInnen der Bibliothek kenntlich zu machen. Geben Sie hierzu die neue Versionsnummer der Bibliothek an.

Event<T> Klasse der Bibliothek Version 1.0.0

public class Event<T> implements IPublishEvent<T> {
    private final Queue<IEventHandler<T>> globalQueue =
        new ConcurrentLinkedQueue<IEventHandler<T>>();

    public void publish(T value) {
        for (IEventHandler<T> eachListener : globalQueue) {
            eachListener.handle(value);
        }
    }
}

Event<T> Klasse nach der Überarbeitung der Bibliothek Version 1.0.0

public class Event<T> implements IPublishEvent<T> {
    private final Queue<IEventHandler<T>> globalQueue =
        new ConcurrentLinkedQueue<IEventHandler<T>>();

    public void publish(T value) {
        for (IEventHandler<T> eachListener : globalQueue) {
            if (eachListener == null) {
                continue;
            }

            eachListener.handle(value);
        }
    }
}
Unchecked
Answer
  • Antwort: 1.0.1.
  • Erklärung: Abhängig von der Art der Änderung sind andere Teile einer Versionsnummer zu ändern. Für das gegebene Szenario ist es ausreichend, die letzte Stelle zu ändern; mit dieser werden kleine Änderungen und Bugfixes signalisiert. Eine bestehende Implementierung, die zuvor problemlos funktioniert hat, funktioniert zur Laufzeit und Übersetzungszeit auch nach diesen Änderungen noch korrekt wie zuvor.
1/28

Im Alltag eines Software Engineers werden Ihnen zahlreiche Problemstellungen begegnen und Sie werden entscheiden müssen, wie Sie damit umgehen. Beantworten Sie das folgende Statement: Unter Refaktorisierung versteht man den Prozess der Verbesserung der Softwarestruktur und der Wartbarkeit unter Beibehaltung aller Schnittstellen.

Unchecked
Answer
  • Antwort: Nein.
  • Erklärung: Refaktorisierung verbessert eine bestehende Implementierung. Hierbei wird das Programmverhalten beibehalten, aber nicht notwendigerweise die Schnittstellen. Angestrebt wird eine Verbesserung der Dokumentation, Wartbarkeit, Lesbarkeit, Verständlichkeit und Erweiterbarkeit einer Implementierung.
2/28

Im Alltag eines Software Engineers werden Ihnen zahlreiche Problemstellungen begegnen und Sie werden entscheiden müssen, wie Sie damit umgehen. Ein motivierter neuer Kollege stößt zu Ihrem Team und möchte das Build System überarbeiten. Er fragt, ob Continuous Integration, Continuous Deployment oder Continuous Delivery realisiert werden soll. Welche dieser Optionen muss der Kollege umsetzen, um maximalen Nutzen für Ihr Team zu erreichen?

Unchecked
Answer
  • Antwort: Continuous Deployment.
  • Erklärung: Continuous Deployment bedeutet maximalen Nutzen durch höchstmögliche Automatisierung. Bauen, Testen und Deployment auf relevanter Hardware samt Updates bestehender Installationen werden vollautomatisch erledigt. Regelmäßig oft durchzuführende Teile wie Bauen und Testen können dadurch z. B. bei jedem Commit geschehen. Grundregel: Alles, was mehr als 30 Sekunden dauert, sollte automatisiert werden.
3/28

Im Alltag eines Software Engineers werden Ihnen zahlreiche Problemstellungen begegnen und Sie werden entscheiden müssen, wie Sie damit umgehen. Nehmen Sie an, dass Sie eine Entwicklerin suchen, welche ein bestehendes Legacy-Softwaresystem analysiert mit dem Ziel, dessen Anforderungen und internes Design zu ermitteln. Welches der folgenden Schlüsselwörter müssten Sie dazu am ehesten in die Stellenbeschreibung aufnehmen: Reengineering, Reverse Engineering oder Refaktorisierung?

Unchecked
Answer
  • Antwort: Reverse Engineering.
  • Erklärung: Reverse Engineering untersucht eine bestehende Lösung, um deren Strukturen und internen Aufbau zu ermitteln. Das ist oft notwendig, wenn beispielsweise der Code einer Implementierung nicht mehr vorhanden ist.
4/28

Im Alltag eines Software Engineers werden Ihnen zahlreiche Problemstellungen begegnen und Sie werden entscheiden müssen, wie Sie damit umgehen. Sie sind an der Entwicklung einer kleinen cloudbasierten Onlineshop-Lösung beteiligt. Die Marketingabteilung bereitet eine neue Kampagne vor, welche hoffentlich viral geht und hierdurch zu deutlichen Steigerungen bei den Zugriffszahlen führen soll. Welche Wartungsmethode ist in diesem Szenario am meisten geeignet: Korrektive Wartung, Adaptive Wartung, Präventive Wartung oder Perfektive Wartung?

Unchecked
Answer
  • Antwort: Präventive Wartung.
  • Erklärung: Präventive Wartung ist Wartung, bevor es zu einem Problem kommt. Hier ist sie geeignet, da sich die erhöhte Anzahl erwarteter Zugriffe ankündigt; es kann also im Voraus mehr Kapazität angemietet werden, damit von Anfang an eine gute Servicequalität garantiert ist.
5/28

Welcher der folgenden Fachbegriffe passt am besten zum gegebenen Szenario: Test Treiber, Stubs oder Test Treiber und Stubs? Bei Top-down-Tests muss der Tester normalerweise welche Artefakte aus der Liste der Fachbegriffe erstellen?

Unchecked
Answer
  • Antwort: Stubs.
  • Erklärung: Stubs dienen dazu, ein Stück Code von dessen Umgebung und anderen Systemteilen zu isolieren, indem sie eine echte Implementierung ersetzen. Bei Top-down-Tests werden nachgelagerte Teile, etwa Backend-Funktionen, durch Stubs ersetzt.
6/28

In Ihrer Abteilung werden in der Regel Integrationstests, Systemtests, Unit-Tests und Akzeptanztests eingesetzt. Nehmen Sie an, dass Sie als Tester eingestellt wurden und es Ihre Aufgabe ist, einen Testplan zu erstellen, der festlegt, wann welche Tests durchgeführt werden. In welcher Reihenfolge müssen Sie diese Teststufen einplanen bzw. durchführen?

Unchecked
Answer
  • Antwort: 1. Unit-Tests; 2. Integrationstests; 3. Systemtests; 4. Akzeptanztests.
  • Erklärung: Tests bauen in der Regel aufeinander auf und decken Schritt für Schritt größere Bereiche ab. Feingranulare Tests prüfen zuerst kleine Teile, danach wird deren Zusammenarbeit, dann das Gesamtsystem und am Ende die Akzeptanz durch den Kunden geprüft.
7/28

Auf welchen grundlegenden Projektmanagement-Stil würden Sie setzen, um die genannten Anforderungen möglichst vollständig erfüllen zu können? Anforderungen: Sie sind für die Weiterentwicklung einer militärischen Software als leitender Entwickler/Manager verantwortlich. Aufgrund eines vorangegangenen politischen Schlagabtauschs wurde Ihnen aufgetragen, die Entwicklung genau zu überwachen. Insbesondere müssen Sie jederzeit eine möglichst genaue Abschätzung über den ausgenutzten und noch benötigten Kostenrahmen erstellen können.

Unchecked
Answer
  • Antwort: Plangetriebenes Projektmanagement, z. B. Wasserfallmodell oder V-Modell.
  • Erklärung: Plangetriebene Vorgehensmodelle eignen sich insbesondere dann, wenn genaue Kosten- und Projektlaufzeitabschätzungen notwendig sind. Sie ermöglichen jederzeit festzulegen, an welcher Stelle im Projekt man sich befindet und welche Schritte noch folgen, jedoch zum Preis deutlich geringerer Flexibilität.
8/28

Verstößt die gegebene Architektur gegen eines oder sogar mehrere der folgenden Prinzipien? Nehmen Sie bei Ihrer Antwort an, dass die hier angezeigten Typen alle im Code vorhandenen darstellen. Prinzipien: YAGNI, KISS und DRY.

Gegebene Architektur

  • Interface IPageable enthält UNKNOWN_N_OF_PAGES, getNumberOfPages(), getCurrentPageContent(), tryFlipToNextPage() und tryFlipToPreviousPage().
  • BookService implementiert dieses Interface und enthält curPage sowie dieselben Navigations- und Inhaltsmethoden.
Unchecked
Answer
  • Antwort: Die gegebene Architektur verstößt gegen YAGNI und KISS.
  • Erklärung: KISS: Interfaces sind sinnvoll, wenn mehrere Implementierungen mit derselben abstrakten Schnittstelle versehen werden sollen. Da hier alle vorhandenen Typen gezeigt sind, bringt das Interface keinen Nutzen und erschwert nur das Lesen und Verstehen. YAGNI: Ein zusätzliches Interface auf Verdacht einzuführen, um für zukünftige Abstraktionen gerüstet zu sein, ist in der Regel nicht sinnvoll.
9/28

Folgender Java-Beispielcode überprüft, ob ein beliebter Getränkebestandteil eine empfohlene Trinktemperatur erreicht hat. Ist dies der Fall, wird true retourniert. Führen Sie basierend darauf eine Äquivalenzklassenanalyse durch. In wie viele und welche Äquivalenzklassen würden Sie die Definition von Tests für dieses Java-Codebeispiel einteilen?

Java-Beispielcode

boolean meetsC8H10N4O2Temp(int temp) {
    return !(temp < 48 || temp > 60);
}
Unchecked
Answer
  • Antwort: 3 Äquivalenzklassen: temp < 48; 48 <= temp <= 60; temp > 60.
  • Erklärung: Äquivalenzklassen repräsentieren Bereiche gleichen Verhaltens für eine durchgehende Reihe von Parameterwerten. Beim Testen sollte aus jeder gefundenen Äquivalenzklasse zumindest ein Satz an Parameterwerten in zumindest einem Test abgebildet werden.
10/28

Folgender Java-Beispielcode überprüft, ob ein beliebter Getränkebestandteil eine empfohlene Trinktemperatur erreicht hat. Ist dies der Fall, wird true retourniert. Entsprechend wurden folgende Äquivalenzklassen festgelegt. Führen Sie basierend darauf eine Grenzwertanalyse durch. Nehmen Sie eine Grenzwertanalyse für die Äquivalenzklassen vor, indem Sie je einen Grenzwert angeben.

Java-Beispielcode und Äquivalenzklassen

  • temp < 48
  • 48 <= temp <= 60
  • temp > 60
boolean meetsC8H10N4O2Temp(int temp) {
    return !(temp < 48 || temp > 60);
}
Unchecked
Answer
  • Antwort: temp < 48 => 47 oder alternativ Integer.MIN_VALUE; 48 <= temp <= 60 => 48 oder alternativ 60; temp > 60 => 61 oder alternativ Integer.MAX_VALUE.
  • Erklärung: Grenzwertanalyse basiert auf der Beobachtung, dass Code oft an den Grenzen der relevanten Äquivalenzklassen Fehler aufweist, etwa durch Verwendung von < statt <=.
11/28

Analysieren Sie den folgenden Java Source Code. Dieser retourniert, je nachdem welche Werte die Parameter angenommen haben, ein unterschiedliches Zeichen. Wie viele Tests werden mindestens benötigt, um 100% Branch Coverage zu erreichen?

Java Source Code

char foobar(boolean first, boolean second, boolean third, boolean fourth) {
    char result = 'S';
    if (first) {
        result = 'E';
    } else if (second) {
        result = '1';
    } else if (third) {
        if (fourth) {
            result = '!';
        }
    }
    return result;
}
Unchecked
Answer
  • Antwort: 5.
  • Erklärung: Branch Coverage bezieht sich auf Verzweigungen, etwa ifs und Schleifen. Die Bedingungen jeder Verzweigung müssen einmal erfüllt und einmal nicht erfüllt sein, um 100% Branch Coverage zu erhalten.
12/28

Welcher der folgenden Fachbegriffe passt am besten zum gegebenen Szenario: Software Validation, Software Debugging und Software Testing? Szenario: Welcher der Fachbegriffe befasst sich mit dem Nachweisen der Existenz von Mängeln oder dem Erhöhen der Wahrscheinlichkeit, dass keine vorhanden sind?

Unchecked
Answer
  • Antwort: Software Testing.
  • Erklärung: Software Testing prüft, ob ein Stück Code gewissen Erwartungen entspricht. Ist eine Erwartung nicht erfüllt, wurde ein Mangel entdeckt; vollständige Mangelfreiheit kann über solche Tests in der Regel aber nicht garantiert werden.
13/28

Welcher der folgenden Fachbegriffe passt am besten zum gegebenen Szenario: Integration Tests, Regression Tests, Smoke Tests und Acceptance Tests? Szenario: Um sicherzugehen, dass ein Softwareprodukt nach den Änderungen während der Wartung korrekt läuft, erstelle ich am ehesten welche Testart?

Unchecked
Answer
  • Antwort: Regression Tests.
  • Erklärung: Regression Tests konzentrieren sich darauf sicherzugehen, dass Codeänderungen nicht dazu führen, dass bereits funktionsfähige Programmteile nicht mehr wie erwartet funktionieren oder alte Fehler wieder eingebaut werden.
14/28

Welcher der folgenden Fachbegriffe passt am besten zum gegebenen Szenario: White Box Testing, Silver Box Testing und Black Box Testing? Szenario: Um sicherzugehen, dass neue Tests alle neu in ein Projekt hinzugefügten Algorithmen überprüfen, verwende ich welche Testart?

Unchecked
Answer
  • Antwort: White Box Testing.
  • Erklärung: White Box Testing setzt voraus, dass dem Tester vollständiger Einblick in Dokumentation, Code und dessen Änderungen gegeben wird. Mittels Coverage-Algorithmen lässt sich ermitteln, ob und inwiefern ein Code-Teil von Tests erfasst wird.
15/28

Welcher der folgenden Fachbegriffe passt am besten zum gegebenen Szenario: Versionierung und Versionsgeschichte, Synchronisation, Syntax Highlighting und Forks und Branches für Projekte. Szenario: Von Quellcode-Verwaltungssoftware wird typischerweise welche Funktion nicht zwingend bereitgestellt?

Unchecked
Answer
  • Antwort: Syntax Highlighting.
  • Erklärung: Syntax Highlighting ist in der Regel kein Feature von Software, welche zur Versionsverwaltung dient. Diese Software ist in der Regel rein auf die Verwaltung von beliebigen Textdateien und deren Versionen konzentriert.
16/28

Analysieren Sie den folgenden Java Source Code. Dieser retourniert, je nachdem welche Werte die Parameter angenommen haben, ein unterschiedliches Zeichen. Wie viele Tests werden mindestens benötigt, um 100% Pfad Coverage zu erreichen?

Java Source Code

char foobar(boolean first, boolean second, boolean third, boolean fourth) {
    char result = 'S';
    if (first) {
        result = 'E';
    } else if (second) {
        result = '1';
    } else if (third) {
        if (fourth) {
            result = '!';
        }
    }
    return result;
}
Unchecked
Answer
  • Antwort: 5.
  • Erklärung: Pfad Coverage bezieht sich auf die möglichen Pfade, auf denen ein Stück Code durchlaufen werden kann. Erst wenn alle technisch möglichen Ausführungsreihenfolgen der Statements abgedeckt wurden, ist eine vollständige 100% Pfadabdeckung gegeben.
17/28

Analysieren Sie den folgenden Java Source Code. Dieser retourniert, je nachdem welche Werte die Parameter angenommen haben, ein unterschiedliches Zeichen. Wie viele Tests werden mindestens benötigt, um 100% Statement Coverage zu erreichen?

Java Source Code

char foobar(boolean first, boolean second, boolean third, boolean fourth) {
    char result = 'S';
    if (first) {
        result = 'E';
    } else if (second) {
        result = '1';
    } else if (third) {
        if (fourth) {
            result = '!';
        }
    }
    return result;
}
Unchecked
Answer
  • Antwort: 3.
  • Erklärung: Statement Coverage bedeutet, dass jedes Statement abgedeckt werden muss. Sobald bei einer Ausführung von Tests ein Statement mindestens einmal mit ausgeführt wird, gilt dieses als vollständig getestet.
18/28

Welche der folgenden Techniken setzen Sie im gegebenen Szenario ein, um dieses optimal zu unterstützen: Blau/Grün Bereitstellung, A/B Tests und Kanarienvogel (Canary releases)? Szenario: Sie entwickeln eine Serversoftware zur Speicherung und Verwaltung von über eine sehr lange Zeitdauer vermieteten Autos und deren Überwachung. Hierzu besteht eine permanente Verbindung zwischen Auto und Serversoftware. Aufgrund von COVID-19 sollen Autos in neue Regionen umgesiedelt werden, was umfassende Änderungen an der Serversoftware erfordert, welche zuvor erstellte Vermietungen anschließend nicht länger unterstützen würde.

Unchecked
Answer
  • Antwort: Blau/Grün Bereitstellung.
  • Erklärung: Bei Blau/Grün Bereitstellung werden alte und neue Version einer Anwendung parallel betrieben. Alte Verbindungen können auf der alten Version abgeschlossen werden, während neue Verbindungen nur zur neuen Version aufgebaut werden.
19/28

Im Rahmen der Rollout-Phase einer neuen Softwarelösung stellt sich in der Regel auch die Frage, wie mit bestehenden Legacy-Anwendungen umgegangen werden soll, um diese bestmöglich zu integrieren. Analysieren Sie das beschriebene Szenario und wählen Sie die am besten geeignete Integrationsstrategie: File Transfer, Shared Databases, Remote Procedure Invocation oder Messaging. Szenario: In einer dynamisch wachsenden und ständig erweiterten Softwarelandschaft eines Flugunternehmens soll eine neue Personalverwaltungssoftware erstellt und integriert werden. Sie dient dazu, Kurzarbeit zu organisieren, und umfasst individuelle Software für Buchhaltung, Personaladministration und Lohnverrechnung. Setzen Sie die Integration so um, dass zusätzliche Erweiterungen möglichst leicht hinzugefügt werden können.

Unchecked
Answer
  • Antwort: Messaging.
  • Erklärung: Messaging basiert auf dem Übertragen einzelner, für sich stehender Nachrichten, häufig über einen Message Bus. Wer diese Nachrichten empfängt und wie sie verarbeitet werden, ist für die Anwendungen nicht bekannt oder relevant; dadurch können neue Anwendungen leicht dynamisch integriert werden.
20/28

Im Rahmen der Rollout-Phase einer neuen Softwarelösung stellt sich in der Regel auch die Frage, wie mit bestehenden Legacy-Anwendungen umgegangen werden soll, um diese bestmöglich zu integrieren. Analysieren Sie das beschriebene Szenario und wählen Sie die am besten geeignete Integrationsstrategie: File Transfer, Shared Databases, Remote Procedure Invocation oder Messaging. Szenario: Georg's Computer Club hat das konkurrierende Unternehmen Schurl's Computer Club gekauft. Um die Abstimmung zwischen beiden Unternehmen zu erleichtern, soll in einem ersten Schritt die von beiden Unternehmen individuell genutzte Enterprise-Resource-Planning-Software integriert werden, die jeweils vom gleichen Hersteller stammt.

Unchecked
Answer
  • Antwort: Shared Databases.
  • Erklärung: ERP-Systeme verwenden in der Regel Datenbanken. Da beide Systeme vom gleichen Hersteller stammen, ist ein identisches Datenbankschema plausibel. Datenbanklösungen nutzen Locks und Transaktionen; Datenbankverbindungen lassen sich oft konfigurieren, ohne die Anwendungen selbst zu ändern.
21/28

Im Rahmen der Rollout-Phase einer neuen Softwarelösung stellt sich in der Regel auch die Frage, wie mit bestehenden Legacy-Anwendungen umgegangen werden soll, um diese bestmöglich zu integrieren. Analysieren Sie das beschriebene Szenario und wählen Sie die am besten geeignete Integrationsstrategie: File Transfer, Shared Databases, Remote Procedure Invocation oder Messaging. Szenario: Zwei ältere, ursprünglich getrennt arbeitende Mainframes sollen miteinander integriert werden. Da viele ältere Entwickler an der Weiterentwicklung beteiligt sind, soll diese Integration möglichst wenig Auswirkung auf den vorherrschenden Implementierungsstil und die gegebene Softwarearchitektur haben.

Unchecked
Answer
  • Antwort: Remote Procedure Invocation.
  • Erklärung: Bei Remote Procedure Invocation liegt die konkrete Implementierung am Server, während der Client eine Abbildung der Schnittstellen sieht. Methodenaufrufe am Client lösen im Hintergrund Serveraufrufe aus; dadurch können bestehende Implementierungs- und Architekturkonzepte weitgehend beibehalten werden.
22/28

Im Rahmen der Rollout-Phase einer neuen Softwarelösung stellt sich in der Regel auch die Frage, wie mit bestehenden Legacy-Anwendungen umgegangen werden soll, um diese bestmöglich zu integrieren. Analysieren Sie das beschriebene Szenario und wählen Sie die am besten geeignete Integrationsstrategie: File Transfer, Shared Databases, Remote Procedure Invocation oder Messaging. Szenario: Eine neue Röntgenbildanalysesoftware wurde erstellt, die mehrere Röntgenbilder zu dreidimensionalen Darstellungen kombinieren kann. Die restliche medizinische Software und die Röntgengeräte werden nicht ausgetauscht.

Unchecked
Answer
  • Antwort: File Transfer.
  • Erklärung: Beim File Transfer werden einzelne Dateien zwischen Systemen hin und her kopiert. Das passt hier, weil Röntgenbilder in der Regel als einzelne Dateien abgebildet werden und die bestehende, oft zertifizierte medizinische Software nicht verändert werden muss.
23/28

Welcher der folgenden Fehlerbehandlungen passt am besten zum gegebenen Szenario: Fail Hard, Fail Soft, Fail Ignore und Fail Recover? Szenario: Die Verbindung mit der öffentlichen Zugverbindungsdatenbank einer Navigations-App schlägt aufgrund von Netzwerkproblemen erstmalig fehl.

Unchecked
Answer
  • Antwort: Fail Recover.
  • Erklärung: Bei Fail Recover versucht das System, sich von Fehlern zu erholen und einen funktionsfähigen Zustand selbst wiederherzustellen. Netzwerkverbindungen sind eine klassische Anwendung, weil wiederholte Verbindungsversuche oder Reconnects sinnvoll sind.
24/28

Welcher der folgenden Fehlerbehandlungen passt am besten zum gegebenen Szenario: Fail Hard, Fail Soft, Fail Ignore und Fail Recover? Szenario: Eine Werbeanzeige in einer Fußgängerzone bemerkt, dass die von einer SD-Karte ausgelesenen Werbevideos teilweise fehlerhaft dekodiert werden.

Unchecked
Answer
  • Antwort: Fail Ignore.
  • Erklärung: Bei Fail Ignore werden Fehler ignoriert und Funktionen des Systems weiter angeboten, selbst wenn diese zu korrupten Daten führen können. Im Beispiel kann die Werbeanzeige weiter angeboten werden, auch wenn Videos teilweise falsch dekodierte Blöcke aufweisen.
25/28

Bereits aus dem Entwickeln von Tests sollte Ihnen Dependency Injection (DI) bekannt sein. Auch viele Frameworks wie Spring, Zend etc. bringen DI bereits mit. Aber warum eigentlich? Welche Eigenschaften werden typischerweise mit DI assoziiert?

Unchecked
Answer
  • Antwort: DI erleichtert es, die Kopplung zwischen Codeteilen zu verringern, und kann zu einer erhöhten Anzahl von Typen, insbesondere Interfaces, führen.
  • Erklärung: Dependency Injection ermöglicht es, in einer Klasse verwendete Abhängigkeiten von außen, z. B. über einen Konstruktor, an die Klasse zu übergeben. Das ist beim Erstellen von Unit Tests hilfreich, weil ein Test möglichst nur den zu testenden Code und nicht dessen Abhängigkeiten abdecken soll.
26/28

Welcher der folgenden Fehlerbehandlungen passt am besten zum gegebenen Szenario: Fail Hard, Fail Soft, Fail Ignore und Fail Recover? Szenario: Beim Aufbau einer verschlüsselten Verbindung zum Bankserver werden Anomalien festgestellt, die auf einen Angriff hinweisen könnten.

Unchecked
Answer
  • Antwort: Fail Hard.
  • Erklärung: Bei Fail Hard führt der Fehler zum Abbruch der Aktion, in Extremfällen bis hin zur aktiven Beendigung der Anwendung. In sicherheitskritischen Anwendungen ist das Standardverhalten, da kleinste Abweichungen große Schwächen in der Verschlüsselung verursachen können.
27/28

Welcher der folgenden Fehlerbehandlungen passt am besten zum gegebenen Szenario: Fail Hard, Fail Soft, Fail Ignore und Fail Recover? Szenario: Die Steuerungssoftware eines Herzschrittmachers ist teilweise fehlerhaft und bemerkt, dass errechnete Steuersignale nicht plausibel sein können.

Unchecked
Answer
  • Antwort: Fail Soft.
  • Erklärung: Bei Fail Soft führen Fehler dazu, dass das System versucht, fehlerhafte Funktionen nicht länger anzubieten. Der Rest des Systems und essenzielle Funktionen arbeiten weiter, gegebenenfalls in einem eingeschränkten Notfallmodus.
28/28