Question 1

Which systems conversion technique removes the old system entirely and activates the new system immediately in its place?

Accepted Answer

Introduction / Context: When implementing a new information system, teams must choose a conversion strategy balancing risk, cost, and speed. One aggressive option is to retire the old system completely and switch users to the new one at a defined moment. This direct approach is commonly called crash conversion or direct cutover (often informally the big bang). Given Data / Assumptions: A legacy system is being replaced by a new system. There is a specific go-live date and window. Rollback plans may be limited compared to safer strategies. Concept / Approach: Crash (direct) conversion involves shutting down the old system and making the new system live for all users at once. It reduces the overhead of dual running and speeds time to benefit but carries higher operational risk if defects surface post-cutover. It is chosen when parallel operation is impractical, when interfaces force a single switchover, or when business imperatives demand immediate change. Step-by-Step Solution: 1) Freeze legacy transactions and prepare a final data migration. 2) Execute cutover during a planned outage window. 3) Validate smoke tests and open support channels for hypercare. Verification / Alternative check: Compare with alternatives: pilot converts a subset of users; phased converts functions or sites incrementally; parallel runs both systems together. Only crash conversion retires the old system immediately for everyone. Why Other Options Are Wrong: Pilot limits exposure to a small group first. Phased spreads change over time by module or site. Parallel run keeps both systems operating simultaneously. Canary deployment is a software release tactic, not a full system conversion method in classic MIS terms. Common Pitfalls: Inadequate data reconciliation, missing rollback criteria, and weak hypercare staffing increase risk with direct cutover. Final Answer: Crash (direct) conversion.

Question 2

In systems analysis and design, when is a system design said to be functionally modular? (Choose the option that best captures the essence of modularity and independent development.)

Accepted Answer

Introduction / Context: Functional modularity is a core systems design principle. It means the overall system is decomposed into coherent, loosely coupled modules, each responsible for a clearly defined capability. This question checks whether you can distinguish true modularity from unrelated traits such as programming language choice or UI conveniences. Given Data / Assumptions: We are discussing design (not just coding style). Modules should encapsulate a single, clear responsibility. Low coupling and high cohesion are desirable to enable parallel work and easier maintenance. Concept / Approach: A functionally modular design is characterized by high cohesion within each module and minimal, well-defined interfaces between modules. This enables independent development, testing, and deployment of components and reduces the impact of changes in one area on the rest of the system. Step-by-Step Solution: 1) Identify the hallmark of modularity: single, specific responsibility per module. 2) Check for independence: teams can develop modules in parallel through stable interfaces. 3) Confirm that language or UI features (e.g., function keys) are not determinants of modularity. 4) Conclude that the option describing focused modules with relative independence is correct. Verification / Alternative check: Textbooks emphasize cohesion/coupling metrics, interface contracts, and separable build/test cycles as evidence of modularity. Why Other Options Are Wrong: Option A: Scope coverage says nothing about internal modular structure. Option C: UI affordances are orthogonal to modularity. Option D: Language or paradigm does not guarantee modular design. Option E: Incorrect because a correct statement is present. Common Pitfalls: Equating “lots of features” or “particular languages” with modularity. True modularity is about design structure and interfaces. Final Answer: Each module performs a specific function and can be developed relatively independently by programmers

Question 3

In data structures, what is the main characteristic of a 'ring' (circular linked) structure?

Accepted Answer

Introduction / Context: A “ring” in data structures typically refers to a circular linked structure (e.g., circular singly or doubly linked list) where traversal can continue indefinitely by looping back to the beginning. Recognizing this property is essential for designing round-robin schedulers, buffer rings, and cyclic traversals. Given Data / Assumptions: Nodes (records) are linked in a sequence. In a ring, the tail connects back to the head. Pointer semantics may vary (singly vs. doubly linked), but cyclic closure remains the key trait. Concept / Approach: The defining characteristic is cycle closure: next of the last node = first node (for singly circular), and in a doubly circular list, prev of the first = last and next of the last = first. This enables uniform traversal without null termination checks and supports cyclic algorithms. Step-by-Step Solution: 1) Identify the structure: “ring” implies circular linkage. 2) Determine the unique property: last node links back to first. 3) Eliminate alternatives that do not express cyclic closure. 4) Choose the option that explicitly states last → first linkage. Verification / Alternative check: Standard references define circular lists by last.next = head (and head.prev = last for doubly circular lists). Why Other Options Are Wrong: Option B: One-directional first→last without closure is not a ring. Option C: Describes a fan-in pointer pattern, not circularity. Option D: Cannot be all since B and C are not ring-defining traits. Common Pitfalls: Confusing circular lists with lists that merely have pointers to tail or head; the essence is the closed loop. Final Answer: The last record points to the first record, forming a closed loop

Question 4

In a data-flow diagram (DFD), an open-ended rectangle (open rectangle) symbolizes which element?

Accepted Answer

Introduction / Context: Data-flow diagrams use a small set of symbols to describe how data move and are stored. The open-ended rectangle (often drawn as two parallel lines or an open rectangle) denotes a data store, i.e., data at rest that can be read or written by processes. Given Data / Assumptions: Notation follows common DFD styles (e.g., Yourdon, Gane–Sarson). External entities are squares/rectangles; processes are circles or rounded rectangles; flows are arrows; stores are open rectangles/parallel lines. We are identifying the symbol “open rectangle”. Concept / Approach: The open-ended rectangle indicates persistence. Processes exchange data with stores via flows. Unlike external entities (outside the system boundary), stores are internal repositories—files, tables, or queues—that hold data between process executions. Step-by-Step Solution: 1) Map each DFD element to its standard symbol. 2) Recognize that the open rectangle corresponds to a store, not a process or external entity. 3) Confirm that arrows represent flows; circles represent processes; squares represent external entities. 4) Select the option describing a data store. Verification / Alternative check: Symbol tables in systems analysis references consistently show open rectangles (or parallel lines) for data stores. Why Other Options Are Wrong: Option A: External entities are closed squares/rectangles, not open-ended. Option B: Flows are arrows. Option C: Processes are circles/rounded rectangles. Option E: Not applicable because the correct symbol meaning is present. Common Pitfalls: Confusing external entities with stores; remember that stores imply persistence inside the system boundary. Final Answer: A data store—data at rest or a temporary repository

Question 5

Which of the following tools is NOT excluded when modeling a new system (i.e., which statement claiming “not used” is incorrect)? Identify the option that is NOT a correct exclusion.

Accepted Answer

Introduction / Context: When modeling a new system, analysts rely on standard artifacts: data-flow diagrams (DFDs) to depict movement and transformation of data, decision tables to capture complex business rules, and a data dictionary to standardize data definitions. The item asks which statement about tools “not being used” is correct—spoiler: all three are in fact used, so the exclusion claims are wrong. Given Data / Assumptions: We are in analysis and early design phases. Artifacts must clarify processes, data, and rules. Decision tables, DFDs, and data dictionaries are canonical tools. Concept / Approach: Each listed artifact serves a distinct purpose. Removing any one typically reduces clarity: DFDs map flows and processes, decision tables disambiguate rules, and a data dictionary governs semantics and metadata (names, formats, domains). Therefore, saying any of them is “not used” is false. Step-by-Step Solution: 1) Evaluate each claim of exclusion (A–C). 2) Recognize that all three are standard and useful. 3) Conclude that none of the exclusions are correct. 4) Select “None of the above.” Verification / Alternative check: Systems analysis texts list these tools among core modeling techniques. Why Other Options Are Wrong: Option A/B/C: Each wrongly asserts a useful artifact is not used. Option D: “All of the above” would mean every exclusion is correct, which is false. Common Pitfalls: Assuming one artifact can replace all others; in practice, they complement each other. Final Answer: None of the above

Question 6

Which control structure is present in every program, regardless of size or complexity?

Accepted Answer

Introduction / Context: Structured programming is built on three fundamental control structures: sequence, selection, and repetition. While many programs use conditional logic and loops, every program necessarily executes statements in some order—this ordering is the sequence structure. Given Data / Assumptions: Any non-empty program has at least one statement to execute. Statements execute in a defined order unless control transfers (e.g., jumps, calls) alter the flow. Selection and repetition are optional depending on requirements. Concept / Approach: Sequence represents straightforward execution from one statement to the next. Even a single function that performs a calculation with no branches or loops is an instance of sequence. Therefore, sequence is universal, while selection (if/else) and repetition (while/for) appear only when needed. Step-by-Step Solution: 1) Consider a minimal program with a single print or return—this is sequence. 2) Consider a numeric utility with no conditions—still sequence. 3) Recognize that selection and repetition are not mandatory in such cases. 4) Conclude that sequence is always present. Verification / Alternative check: Foundational CS literature defines these three as sufficient; of them, sequence is the irreducible baseline in any program execution. Why Other Options Are Wrong: Option A: Loops are optional. Option B: Conditionals are optional. Option D: “Switching” is a specific form of selection, not universally required. Option E: Not applicable since one correct structure exists. Common Pitfalls: Assuming that all control structures are always present. Many scripts are purely sequential. Final Answer: Sequence

Question 7

A programmer reviews the accuracy of an algorithm by _____ it (before executing code).

Accepted Answer

Introduction / Context: Before running a program, developers often verify logic manually to catch defects early. This practice—called desk-checking—uses pencil-and-paper (or a simple table) to simulate the algorithm with sample inputs and follow variable changes step by step. Given Data / Assumptions: No actual execution or debugger is required. Representative test cases are chosen, including edge cases. The goal is to validate control flow and state transitions. Concept / Approach: Desk-checking reduces costly rework by exposing logic gaps, off-by-one errors, and uninitialized variable usage before compiling or running code. It complements later dynamic testing and fits well in code reviews and pair programming sessions. Step-by-Step Solution: 1) Select input values (normal, boundary, invalid). 2) Walk through each algorithm step, recording variable updates. 3) Compare expected outcomes to the algorithm’s computed results. 4) Adjust algorithm where discrepancies appear. Verification / Alternative check: Software engineering guides recommend desk-checking and dry runs prior to unit tests to minimize trivial defects. Why Other Options Are Wrong: Option A/D: “Analyzing” and “planning” are general phases, not the specific manual simulation practice. Option B: Coding produces the artifact; it does not validate logic by itself. Option E: Not applicable because a standard practice exists. Common Pitfalls: Skipping desk-checks and relying solely on runtime tests; this often lengthens the debug cycle. Final Answer: Desk-checking

Question 8

In building a model base (e.g., for a Decision Support System), preparation cannot proceed until which prerequisites are met?

Accepted Answer

Introduction / Context: A model base houses analytical, statistical, and optimization models supporting managerial decisions. Standing up a model base requires foundational choices and people with the competencies to implement and maintain those models. This item asks which prerequisites are essential before preparation proceeds meaningfully. Given Data / Assumptions: We are at the stage of enabling model execution and integration. Platform compatibility and staff expertise are critical. Facilities (while useful) are less constraining than hardware and skilled personnel. Concept / Approach: Models depend on the computing environment (OS, libraries, performance characteristics) and on MIS/analytics staff to curate, validate, and operationalize them. Without a selected platform, technical architecture decisions are premature; without the right staff, models cannot be implemented or governed effectively. Step-by-Step Solution: 1) Identify critical path dependencies: platform and people. 2) Evaluate each option’s necessity at start-up. 3) Recognize that both hardware selection and staff organization are mandatory. 4) Choose the combined prerequisite (both a and b). Verification / Alternative check: DSS implementation references call out environment standardization and cross-functional MIS/analytics staffing as preconditions for effective model base deployment. Why Other Options Are Wrong: Option A or B alone is insufficient; both are required. Option C: Facilities are supportive but not the gating factor. Option E: Incorrect because there are prerequisites. Common Pitfalls: Attempting to prototype models before establishing platform/toolchain or assigning accountable owners; this leads to rework and inconsistency. Final Answer: Both (a) and (b)

Question 9

What is the graphic representation that shows the control logic and module relationships of a system's processing functions?

Accepted Answer

Introduction / Context: Different notations emphasize different views. A structured chart (structure chart) focuses on the architecture of modules—how they call one another, data passed, and control logic at the module level. It is distinct from narratives (Structured English) and end-to-end flow depictions (system flowcharts). Given Data / Assumptions: We need a diagram emphasizing module decomposition and invocation relationships. Granularity is at the component/procedure level, not just data movement. Control logic is summarized via hierarchy, sequencing, selection, and iteration at the module-call level. Concept / Approach: A structured chart is typically a top-down diagram showing major modules, their submodules, and interfaces. It communicates coupling, cohesion, and control flow among modules, aiding partitioning and team assignment. Step-by-Step Solution: 1) Map artifacts to viewpoints: data vs. control vs. narrative. 2) Identify the artifact that best reflects control and modular structure: structured chart. 3) Distinguish from system flowcharts (overall processing/data paths) and Structured English (textual algorithmic statements). 4) Select structured chart. Verification / Alternative check: Design methods present structure charts as the standard for depicting module hierarchies and interfaces. Why Other Options Are Wrong: Option A: “Structured analysis” is a methodology, not a specific diagram. Option C: Narrative form, not a graphic hierarchy. Option D: Emphasizes processes and data flows at a system level, not module call structure. Common Pitfalls: Confusing DFDs/system flowcharts with structure charts; the latter highlight module relationships and control. Final Answer: Structured chart

Question 10

In the Systems Development Life Cycle (SDLC), what is the first step?

Accepted Answer

Introduction / Context: The SDLC provides a structured approach to building information systems. It begins by understanding the problem space and feasibility before committing to design and construction. This initial step is commonly called preliminary investigation and analysis (or feasibility study and requirements analysis). Given Data / Assumptions: Project governance requires clarity of scope and business case. Stakeholders and constraints must be identified early. Feasibility (technical, economic, operational, schedule) is assessed upfront. Concept / Approach: Starting with investigation and analysis prevents building the wrong solution. It frames objectives, success metrics, risks, and high-level requirements that feed subsequent design. Only after this step should teams proceed to solution architecture and database design. Step-by-Step Solution: 1) Identify SDLC phases: investigation/analysis → design → implementation → testing → deployment → maintenance. 2) Confirm the first phase focuses on understanding needs and feasibility. 3) Eliminate later-phase activities (design, database design, GUI specifics). 4) Select preliminary investigation and analysis. Verification / Alternative check: Most SDLC variants (waterfall, V-model) begin with analysis/feasibility before design and build. Why Other Options Are Wrong: Option A/B/D: These belong to later phases after requirements are established. Option E: Not applicable since there is a standard first step. Common Pitfalls: Jumping into design or UI mockups prematurely without validated requirements increases rework. Final Answer: Preliminary investigation and analysis

Question 11

Which four icons are standard when building a Data Flow Diagram (DFD)?

Accepted Answer

Introduction / Context: A DFD communicates how information moves through a system, what transforms it, and where it rests. To keep diagrams consistent and readable, analysts use four standard icons: data flow, process, external entity (source/destination), and data store. Given Data / Assumptions: Notation aligns with common DFD conventions. Terminology: “source/destination” is synonymous with “external entity” or “source/sink.” Stores represent persistence; flows are arrows; processes are transformations. Concept / Approach: The essential elements are: Flow (arrow), Process (circle/rounded rectangle), Source/Destination (square/rectangle), and Store (open-ended rectangle/parallel lines). Grouping them correctly ensures complete coverage of the DFD vocabulary without redundancy. Step-by-Step Solution: 1) List the canonical four: Flow, Process, Source/Destination, Store. 2) Compare each option’s wording to include all four distinctly. 3) Select the option that explicitly names Source/Destination (external entities) instead of only “Source.” 4) Confirm no element is missing or duplicated. Verification / Alternative check: Standard symbol tables in analysis references enumerate these four icons as the foundation of DFDs. Why Other Options Are Wrong: Option A/B/D: Wording omits “Destination” explicitly or repeats terms in a way that is less precise; option C is the most accurate formulation. Option E: Not applicable since a correct grouping exists. Common Pitfalls: Confusing external entities with processes or misusing store symbols for temporary variables; DFDs model data movement/persistence, not code variables. Final Answer: Flow, Process, Source/Destination, Store

Question 12

In systems analysis, which of the following is NOT a standard component of a Data Flow Diagram (DFD)?

Accepted Answer

Introduction / Context: Data Flow Diagrams (DFDs) model how data moves through a system at a logical level. They purposely avoid implementation details (devices, programs) and instead emphasize processes, stores, flows, and external entities. Given Data / Assumptions: DFDs show processes (circles/bubbles), data stores (parallel lines or open-ended rectangles), data flows (arrows), and external entities (terminators). DFDs are technology-agnostic; they do not depict physical hardware like disks/printers. We are selecting the item that does not belong to a DFD notation set. Concept / Approach: Differentiate logical modeling symbols (process, flow, store, external entity) from physical/hardware symbols (e.g., disk pack). A disk icon is common in flowcharting or physical system diagrams, not in logical DFDs. Step-by-Step Solution: 1) List DFD primitives: process, data flow, data store, external entity.2) Compare each option against those primitives.3) Arrow, data store, and process bubble are core DFD symbols; external entity is also standard.4) A disk storage icon is a physical device representation, not part of logical DFD notation. Verification / Alternative check: DFD tutorials and textbooks consistently restrict symbols to the four logical primitives, reinforcing that device icons are excluded. Why Other Options Are Wrong: Arrow = data flow (correct DFD symbol). Data store = repository (correct). Process bubble = transformation (correct). External entity = source/sink (correct). Common Pitfalls: Mixing flowchart symbols (physical devices) with DFD symbols; attempting to show implementation specifics on a logical diagram. Final Answer: Disk storage symbol (physical device icon) is not a standard DFD component.

Question 13

Systems conversion strategies: the technique where the old system is removed and the new system is switched on immediately is called

Accepted Answer

Introduction / Context: Organizations adopt different go-live strategies when replacing systems. The riskiest but fastest is to replace the old system with the new one in a single step, often called crash or direct cutover conversion. Given Data / Assumptions: “Immediately implementing the new system” means no overlap or dual running. Risk tolerance is higher; there is no fallback after cutover except rollback plans. Other strategies (pilot, phased, parallel) reduce risk but increase effort/time. Concept / Approach: Map each conversion name to its behavior: direct (crash) = instant switch; phased = module by module; pilot = limited scope first; parallel = both systems run together. Step-by-Step Solution: 1) Identify the described pattern: immediate replacement.2) Match to terminology: direct cutover / crash conversion.3) Select the matching option. Verification / Alternative check: Implementation playbooks define direct cutover as the fastest path with highest operational risk. Why Other Options Are Wrong: Phased: gradual rollout. Pilot: trial subset first. Parallel: both systems run concurrently for a period. Shadowing: new system mirrors old without being authoritative. Common Pitfalls: Choosing parallel when the prompt clearly states “totally removing the existing system.” Final Answer: Crash (direct cutover) conversion.

Question 14

Databases and software: which term best describes the software that manages an integrated collection of data with minimal redundancy so multiple applications can use it?

Accepted Answer

Introduction / Context: In information systems, the database is the organized collection of data, and the Database Management System (DBMS) is the software layer that defines, stores, manipulates, and controls access to that data with minimal redundancy. Given Data / Assumptions: The question emphasizes “integrated collection of data” usable by different applications. We focus on the managing software component, not merely the logical definition or a single file. Minimal redundancy, integrity, and sharing imply centralized control and services. Concept / Approach: Differentiate the artifacts: a record is a row; a file is a collection of records; a schema is the structural blueprint; the DBMS is the software that provides definition (DDL), manipulation (DML), integrity, security, and concurrency services for the database. Step-by-Step Solution: 1) Identify the item that provides multi-application access and control.2) Recognize that schema and files do not offer services like transactions, security, or concurrency.3) Select DBMS as the managing software that fulfills these roles. Verification / Alternative check: Examples include PostgreSQL, MySQL, Oracle—software systems enabling shared, low-redundancy data access. Why Other Options Are Wrong: Record/file: data containers, not management software. Schema: design blueprint, not the executing system. Repository label: vague. Common Pitfalls: Confusing “database” (data) with “DBMS” (software). The prompt’s emphasis on enabling use by different applications points to DBMS capabilities. Final Answer: Database Management System (DBMS).

Question 15

Systems thinking: what does the black-box concept assume and emphasize when modeling a system?

Accepted Answer

Introduction / Context: The black-box concept is a fundamental abstraction in systems theory, engineering, and software testing. It focuses on externally observable behavior—what goes in and what comes out—without requiring knowledge of the internal mechanism. Given Data / Assumptions: We examine a system through input/output behavior. Internal details may be hidden, unavailable, or intentionally ignored. Environmental interactions can still affect inputs/outputs. Concept / Approach: A black box encapsulates internal complexity and exposes an interface. This allows specification and testing against contracts (preconditions, postconditions) and facilitates modular design. However, the abstraction does not presume environmental independence or stability of I/O; those are empirical concerns, not definitional assumptions. Step-by-Step Solution: 1) Identify the essential feature: observable input/output mapping.2) Recognize that independence from the environment is not guaranteed; the box may rely on inputs provided by the environment.3) Realize that inputs/outputs can vary with conditions; stability is not inherent.4) Select the option that matches the definition without adding unjustified assumptions. Verification / Alternative check: Black-box testing validates outputs for given inputs without reading internal code, confirming the concept’s emphasis on interfaces over implementation. Why Other Options Are Wrong: Independence (B) and I/O stability (C) are not required; they may or may not hold. “All of the above” (D) therefore cannot be correct. Common Pitfalls: Assuming the abstraction implies invariance of behavior under all contexts; in practice, environmental factors (timing, configuration) can change outcomes. Final Answer: Describe the system by its inputs and outputs while treating internal transformation as unknown.

Question 16

File organization methods: what does “sequential organization” of records mean in classical file systems?

Accepted Answer

Introduction / Context: Classical file organizations include sequential, indexed-sequential, random (hash), and others. Understanding these patterns helps match workloads (batch vs interactive) to storage structures. Given Data / Assumptions: Sequential organization emphasizes ordered storage by a key. Indexed-sequential adds an index for faster access. Random/hash places records non-contiguously based on a hash function. Concept / Approach: In pure sequential organization, records are arranged in order (e.g., ascending key). Access patterns are typically sequential scans, which work well for batch processing and range reports. Step-by-Step Solution: 1) Identify the defining property: sorted, contiguous/sequential record layout.2) Distinguish from indexed-sequential, which introduces auxiliary indexing.3) Distinguish from random/hash, which distributes records unpredictably for constant-time access.4) Choose the option describing ordered contiguous storage. Verification / Alternative check: Textbook definitions align sequential with ordered scans and high throughput for large, ordered reads. Why Other Options Are Wrong: (B) describes indexed-sequential, not pure sequential. (C) refers to multiple indexes design. (D)/(E) describe random/hash organizations. Common Pitfalls: Confusing sequential with indexed-sequential due to similar names; the index changes access characteristics. Final Answer: Storing records in key order in contiguous/sequential fashion.

Question 17

Database terminology: in data management, the term “schema” refers to

Accepted Answer

Introduction / Context: Precise terminology is essential in databases. “Schema” (often misspelled as “scheme”) is the formal description of how data is structured and related in a database. Given Data / Assumptions: We consider logical structures: tables, attributes, constraints, relationships, views. Schema is a blueprint, not data itself. Different levels exist (conceptual, logical, physical), but all are designs. Concept / Approach: The schema defines entities, attributes, keys, and relationships, plus integrity rules. It is the map used by the DBMS to validate and manage data. Step-by-Step Solution: 1) Recognize common use: “CREATE SCHEMA / CREATE TABLE” statements define structures.2) Distinguish schema (design) from instances (data content).3) Select the option that captures the “overall structure” meaning. Verification / Alternative check: Most DBMS documentation describes schema as the container/definition set for database objects. Why Other Options Are Wrong: They do not refer to structural design (service bureau, parent, generic table, routing plan). Common Pitfalls: Confusing schema with a specific table or with the data itself. Final Answer: The overall structural map (design) of a database.

Question 18

CASE environments: software designed to draw system diagrams, write process specifications, and maintain data dictionaries is called a

Accepted Answer

Introduction / Context: Analysts and designers use specialized software to model systems, document processes, and manage data dictionaries. Collectively, these belong to CASE (Computer-Aided Software/Systems Engineering) environments. Given Data / Assumptions: Tooling supports diagrams (DFD, ERD, UML), specifications, repositories. Goal: improve consistency, traceability, and productivity. We are naming the class of such software. Concept / Approach: CASE tools provide integrated repositories and generators/templates to keep artifacts aligned across the life cycle (analysis through design). SDLC is a process framework, not a tool. Step-by-Step Solution: 1) Identify the software category that supports diagrams/specifications/dictionaries.2) Map that to CASE.3) Eliminate non-tool options (frameworks, strategies). Verification / Alternative check: Examples include enterprise modeling suites that store diagrams and metadata centrally. Why Other Options Are Wrong: SDLC is a methodology; phased conversion and success factors are strategies or frameworks; “Move of the above” is invalid. Common Pitfalls: Assuming SDLC is a tool rather than a process. Final Answer: CASE tool (Computer-Aided Software/Systems Engineering).

Question 19

Structured design outcomes: well-structured programs produced by structured design are typically

Accepted Answer

Introduction / Context: Structured design emphasizes modularity, clear control flow, low coupling, and high cohesion. These principles are intended to yield code that is easier to reason about and adapt. Given Data / Assumptions: Use of sequence/selection/iteration rather than arbitrary jumps. Well-defined module boundaries and responsibilities. Readable naming and consistent interfaces. Concept / Approach: When modules have single, clear purposes (high cohesion) and limited, predictable dependencies (low coupling), a change in one area is less likely to ripple widely. Predictable control flow also aids comprehension, code review, and testing. Step-by-Step Solution: 1) Evaluate maintainability: modular design localizes change and supports refactoring.2) Evaluate understandability: clear flow and small, focused modules improve readability.3) Conclude both qualities are hallmarks of structured design outputs. Verification / Alternative check: Empirical studies and engineering practice find that cyclomatic complexity and coupling correlate with defect rates and maintenance costs; structured design aims to minimize those. Why Other Options Are Wrong: Heavy GOTO usage contradicts structured programming and increases testing complexity; “none” is false because structured design demonstrably improves maintainability and comprehension. Common Pitfalls: Mistaking design patterns or OOP features as substitutes for fundamental structure; the basics still matter. Final Answer: Both (a) and (b) — structured design produces programs that are easier to maintain and understand.

Question 20

Decision representations: what is the key difference between decision tables and decision trees?

Accepted Answer

Introduction / Context: Decision tables and decision trees are complementary ways to specify complex conditional logic. Both aim to make rules explicit and unambiguous. Given Data / Assumptions: Decision tables list conditions/actions in a matrix, enumerating combinations. Decision trees depict conditions as internal nodes and actions as leaves. Both communicate logic to analysts, developers, and testers. Concept / Approach: The essential distinction is visual and structural. Tables are compact for many conditions with mutually exclusive rules; trees are intuitive for hierarchical “if-then-else” branching and for explaining paths. Step-by-Step Solution: 1) Identify purpose overlap: both express logic.2) Identify structural difference: matrix vs graph.3) Conclude that representation form is the key difference. Verification / Alternative check: Modeling guides often recommend converting between the two to check completeness/consistency. Why Other Options Are Wrong: (A) End-user value is similar—clarity of rules. (C) Both show logic; “process flow” wording is misleading for trees, which still encode logic paths. Common Pitfalls: Assuming one is inherently superior; the choice depends on rule density and audience. Final Answer: Form of representation differs (tabular matrix vs branching graph).

System Analysis and Design Questions