৪৯তম বিসিএস ⎯ কম্পিউটার সায়েন্স (CSE) [৯৭১]

Answer: B
Explanation:  Software engineering involves applying systematic, disciplined, and quantifiable approaches (engineering principles) to software development. This includes requirement analysis, design, coding, testing, maintenance, and management.
Incorrect options:
A) Writing code is just a part of software engineering.
C) Testing is only one phase.
D) Documentation is necessary but not the definition of software engineering.

Answer: D
Explanation: The Waterfall model is linear and sequential, meaning each phase must be completed before moving to the next. The Waterfall model progresses sequentially through requirements → design → implementation → testing → maintenance.

Spiral Model 
•    Focuses on risk-driven iterative development.
•    Software is developed in spirals (iterations), with repeated planning, risk analysis, engineering, and evaluation.
•    Not linear: Phases are repeated in cycles rather than sequential.
•    Advantage: Flexible and reduces risk.

 Agile Model 
•    Agile is iterative and incremental, focusing on collaboration, customer feedback, and adaptability.
•    Development occurs in sprints, with frequent delivery of working software.
•    Not linear: Agile embraces continuous iteration rather than a sequential flow.

 RAD (Rapid Application Development) Model
•    RAD focuses on rapid prototyping and user feedback to accelerate development.
•    Phases are overlapping, using reusable components and prototypes.
•    Not linear: Emphasizes speed and iterative prototyping rather than sequential flow.

Answer: B
Explanation: Project management ensures that software projects are completed on time, within budget, and with required quality.

Answer: B) Requirements elicitation
Explanation:

 Requirements Elicitation 

Definition: Requirements elicitation is the process of gathering information about what the system should do from stakeholders such as users, customers, domain experts, and other relevant parties.

Purpose: To understand business needs, user expectations, and constraints.

Methods: Interviews→ Questionnaires→  Workshops→  Observation Prototyping

Why it comes first:

You cannot validate, specify, or manage requirements before knowing what they are.

It forms the foundation for all subsequent requirements engineering activities.

Summary Flow of Requirements Engineering:

Requirements Elicitation: Gather needs →

Requirements Analysis: Resolve conflicts, prioritize →

Requirements Specification: Document requirements (SRS) →

Requirements Validation: Verify correctness, completeness →

Requirements Management: Track and control changes

Answer: C
Explanation: Software prototyping = early working model of the system → helps stakeholders visualize, refine, and validate requirements before investing in full development.

Final product delivery 

Final delivery happens after the entire software development life cycle (SDLC), not during prototyping.
Prototyping produces a model, not the finished system.
 
 Testing the software only

Testing validates correctness, performance, and reliability of developed software.
Prototyping is about exploring requirements and design ideas, not testing the final system.
 
 Documenting requirements 

Documentation (like SRS) is part of requirements specification.
Prototyping goes beyond d

Answer: A
Explanation:
    Spiral model is iterative and focuses on risk assessment at each cycle. It’s suitable for large, complex, and high-risk projects.
 Incorrect options:
   B) Waterfall is linear with little risk analysis.
   C) V-Model focuses on verification/validation.
   D) Incremental focuses on delivering functionality in incremen

Answer: D
Explanation:
           Verification ensures the software meets specifications (“Are we building it right?”).
Incorrect options:
  A) Validation ensures software meets user needs (“Are we building the right thing?”).
  B) Testing is part of verification and validation
  C) Maintenance occurs after deployment.

Answer: B
Explanation:
          Reliability is the probability that software will perform its intended function without failure in a specified environment.

  Incorrect options:
    A) Correctness is related but does not include probability over time.
    C) Maintainability is a separate quality metric.
    D) Cost efficiency is unrelated to reliability

Answer: A
Explanation:
                  Context diagrams represent the system as a single entity (process) and show how it interacts with external actors (users, other systems, devices). It provides a high-level view without internal detail.

 Incorrect options:
   B ) Internal data flow is shown in detailed DFDs, not context diagrams.
   C ) Algorithms are not part of system modeling.
   D ) Class hierarchy belongs to object modeling (UML), not context diagrams.

Answer D
Explanation:
              DFDs illustrate how data moves through a system, what transformations occur, and where data is stored. They help in understanding system functionality and information flow.

 Incorrect options:
     A) Class diagrams focus on objects, attributes, and relationships.
     B) Sequence diagrams focus on interaction order over time
     C) State diagrams focus on state changes of an object..

Answer: C
Explanation:
A data store (file or database) is shown as a double rectangle, indicating where data is held within the system.

 Incorrect options:
    A) Circle = process.
    B ) Arrow = data flow.
    D ) Triangle is not used in standard DFD notation

 Answer: B
Explanation:
         Behavioral models (like state diagrams) capture system responses to events, states, transitions, and triggers. They are essential for real-time and reactive systems.

Incorrect options:
 A ) Object relationships are static models (class diagrams).
 C ) UI design is part of interface design, not behavioral modeling.
 D ) Cost calculation is unrelated.

Answer: A
Explanation:
           State diagrams represent all possible states of a system or object and transitions due to events, showing dynamic behavior.

Incorrect options:
    B) Data flow is for DFDs.
    C) UI screens sequence is different from state transitions.
    D) Inheritance is part of class diagrams.

 Answer: B
Explanation:
      Object models define classes, objects, attributes, methods, and relationships (association, inheritance, aggregation), forming the static structure.
Incorrect options:
    a) Functional behavior is captured in use cases and behavioral models.
    c) Algorithm optimization is part of implementation.
    d) Data flow is DFD concern, not object modeling

Answer: C

Explanation:
Objects are concrete instances of classes, having attributes and behavior defined by the class.

Incorrect options:
      A) Processes are procedural elements, not objects.
      B) Data flows are not objects.
      D) State represents condition, not object

Answer: B
Explanation:
        Real-time and interactive systems require modeling of event-driven behavior to ensure correct responses under time constraints.

Incorrect options:
    A) Batch systems are less dynamic.
    C) Documentation is not the primary purpose.
    D) Database normalization is unrelated

Answer: D
Explanation:
               OOD aims to design software around objects, which encapsulate data (attributes) and behavior (methods). It supports modularity, reuse, and maintainability.

 Incorrect options:
    A) Speed is secondary; maintainability and clarity are primary.
    B) Testing is a separate phase and not the design focus.
    C) Data flow modeling is procedural, not object-oriented.
    

Answer: A
Explanation:
Encapsulation ensures that an object’s internal state is hidden and only accessible through public methods (interfaces). This improves modularity and protects against unintended interference.
 
 Incorrect options:
B) Inheritance is different; it’s about deriving properties from a parent.
C) Splitting into modules is modular design, not encapsulation.
D) Running speed is unrelated.

Answer: B
Explanation:
      Single Responsibility Principle (SRP) & Modularity

High Cohesion:

Cohesion = how closely related the tasks within a module/class are.
High cohesion = a class/module does one well-defined job (SRP ensures this).
Example: A User Manager class that only handles user-related operations, not payment or logging.
Low Coupling:

Coupling = how much one module depends on others.
Low coupling = minimal interdependencies, so a change in one module has little impact on others.
Achieved through modularity, interfaces, dependency inversion.

Incorrect options:
    A) Encapsulation and inheritance help design but don’t guarantee cohesion/coupling.
    C) Polymorphism helps flexibility but not cohesion directly.
    D) Functional decomposition splits functions, not always objects; cohesion/coupling may vary.

Answer: B
Explanation:
        Periodic tasks run at fixed intervals; aperiodic are irregular but scheduled; sporadic occur unpredictably.

Incorrect options:
    A) CPU/memory use is unrelated to timing classification.
    C) Synchronous/asynchronous is execution mode, not timing.
    D) Abstract/concrete is OOD classification.

Answer: A
Coupling (Correct Option)

        Coupling is the measure of how much one module/class depends on or interacts with another.
High Coupling:

Modules/classes are tightly linked.
A change in one module often forces changes in others.
Example: Class A directly accessing the internal data of Class B.
Low Coupling (preferred):

Modules/classes are more independent.
Communication is through well-defined interfaces.

  Incorrect options:
    B) Number of methods is class size.
    C) Reuse can be independent of coupling.
    D) Documentation is unrelated.

Answer: D
Explanation:
                 Real-time systems must satisfy all these challenges to ensure reliability, timeliness, and safety.•  

  A/B/C are correct individually but incomplete; the comprehensive challenge is all of the above

Answer: A
Explanation:
                   Reusing existing, tested components reduces development effort, cost, and likelihood of introducing defects.
Incorrect options:
    b) Good reuse reduces coupling.
    c) Testing is still necessary to ensure compatibility.
    d) Documentation remains important.

Answer: C
Explanation:
           Fault-tolerant systems detect and recover from faults to maintain operation without total failure.
 
Incorrect options:
   A) Testing is always required.
   B) Absolute failure-free operation is unrealistic.
   D) Speed is unrelated.

Answer: A
Explanation:
           Availability is influenced by reliability and maintainability; it represents the readiness of a system for use.

 Incorrect options:
   B) Speed is performance, not availability.
   C) User capacity may affect load, not availability metric directly.
   A) LOC is irrelevant.

Answer: B
Explanation:
            Failure rate is a key metric in reliability analysis; it quantifies how often failures occur.
   
Incorrect options:
    B) Speed is performance.
    C) Code size does not measure failures.
    D) Documentation is unrelated.

Answer: D
Explanation:
           Maintenance is the process of updating software after deployment, including corrective, adaptive, perfective, and preventive maintenance.
   
Incorrect options:
    A) Design is pre-deployment.
    B) Documentation supports maintenance but is not the main activity.
    C) Testing is part of maintenance but not the entire process.

Answer: A
Explanation:
         Preventive maintenance reduces likelihood of future faults by improving code structure, design, and maintainability.

Incorrect options:
    B) Corrective addresses current faults.
    C) Adding features is perfective.
    D) Documentation is supportive but not the primary goal

Answer: B
Explanation:
        In critical systems (avionics, medical devices), incorrect specifications can lead to system hazards, injury, or loss of life.

Incorrect options:
    A) Effects are usually severe, not minor.
    C) Coding speed is irrelevant.
    D) Errors complicate testing, not ease it

Answer : B
Explanation:
           Each development phase has a corresponding testing or validation phase, ensuring early detection of defects.

Incorrect options:
    A) Iterative prototyping is a different model.
    C) Coding alone ignores specification/testing.
    D) Testing is structured, not random

Answer: B
Explanation:
       Verification checks whether the software was implemented according to the design and specifications. It answers the question: “Are we building the system right?”

 Incorrect options:
    A) This is validation.
    C) Performance is separate.
    D) Verification reduces errors but cannot guarantee bug-free software.

Answer: A
Explanation:
            Unit tests verify that each component or function works correctly in isolation.

Incorrect options:
   B) Integration testing comes next.
   C) System testing is for the complete system.
   D) User acceptance testing is the final step.

Answer: D
Explanation:
             Acceptance testing is performed by the client or end-user to confirm that the delivered software meets their needs.
   
Incorrect options:
      A) All functional requirements are tested, not only critical components.
      B) Developers’ satisfaction is internal, not user acceptance.
      C) Syntax errors are too basic.

 Answer: B
Explanation:
                  Validation checks if the right product is built to meet user needs. It answers: “Are we building the right system?”

Incorrect options:
    a) Checking specifications is verification.
    c) Comments are unrelated.
    d) Reusability is a design goal, not validation.

Answer: A
Explanation:
           White-box testing (structural testing) verifies internal code paths, branches, loops, and logic.

Incorrect options:
   B) That is black-box testing.
    C/D) UI and deployment are unrelated.

Answer: C
Explanation:
           Alpha testing is a type of internal acceptance testing performed by the organization’s developers and testers before the software is released to external users.
When it happens: After system testing, but before beta testing.
Purpose:
To identify bugs internally before handing the software to real users.
To simulate user environment as closely as possible.
Characteristics:
Done by developers, testers, and sometimes in-house users.
Typically includes white-box + black-box testing.

Incorrect options:
     A)Alpha testing is pre-release, not post-deployment
     B) This actually describes Beta Testing 
     D) Alpha testing involves system-level evaluation.

 Answer: A
Explanation:
           Fault injection is a testing technique that deliberately introduces faults (hardware, software, network, environment, or timing faults) into a system to verify that the system detects them, tolerates them, recovers correctly, and fails safely when necessary.
 
Incorrect options:
   B) Faults are introduced intentionally.
   C) Speed measurement is separate.
   D) Fault injection is critical in real-time systems.

Answer: B) Verification is based on reviews/analysis, Validation requires execution

Explanation:

Verification = Static (review docs, design, code → no execution).

Validation = Dynamic (execute software, test against requirements).

Option A (Wrong): Reverse meaning → Verification ≠ execution.

Option C (Wrong): Only validation requires execution.

Answer: B ) Black-box testing

Explanation:

Login page test checks functionality as per requirements → user enters inputs, tester validates outputs. No internal code knowledge required.

White-box would require checking authentication function’s code paths.

Answer: A
Explanation:
         Cost estimation helps project managers plan resources, schedule, and budget, ensuring realistic expectations.

 Incorrect options:
   B) Estimation aims to predict, not inflate cost.
   C) Testing is independent; estimation does not avoid it.
   D) Coding complexity is not the primary goal; it may influence effort but is not the focus.

Answer: B) Constructive Cost Model

Explanation:

     COCOMO = Constructive Cost Model, introduced by Barry Boehm (1981). It is a mathematical model for estimating cost, effort, and time required to develop software.

Answer: D
Explanation:
         COCOMO uses lines of code (LOC) or function points and project type (organic, semi-detached, embedded) to predict effort in person-months, schedule, and staffing.
 
Incorrect Options:
    A) COCOMO is an estimation model, not a code generator.
    B) Execution speed is unrelated.
    C) Readability is subjective and not measured by COCOMO.

Answer: c) Lines of code (KLOC)

Explanation:

           Original COCOMO bases effort estimation on size of software in KLOC.

Option A/B (Wrong): Use case points and function points are alternative estimation methods (not original COCOMO).

Option D (Wrong): Cyclomatic complexity is for testing effort, not project effort estimation.

Answer: A
Explanation:
       SQA ensures software quality through defined processes, verification, validation, standards, and audits.
   
Incorrect options:
    B) Coding is only one activity in software lifecycle.
    C) Recruitment is HR, not SQA.
    D) Marketing is unrelated.

Answer: D) Marketing campaign

Explanation:

       Marketing is not part of Software Development Life Cycle (SDLC).

SDLC Phases: Requirement analysis → System design → Implementation (coding) → Testing → Deployment → Maintenance.

Answer: A) Unified Modeling Language

Explanation:

         UML = Unified Modeling Language, a standard visual modeling language for object-oriented system design.

Option B (Wrong): “Markup” relates to HTML/XML, not UML.

Option C (Wrong): Not “Method Language.”

Option D (Wrong): Misleading expansion.

Answer: C

Project Development Software

This refers to Computer-Aided Software Engineering (CASE) tools that support one or more phases of the software development life cycle (SDLC).
They help with:

Requirement analysis
System design
Documentation
Code generation
Testing support

Answer: C) Waterfall
Waterfall = simple, structured, works best when requirements are clear and unlikely to change.
Spiral/Agile/RAD = better for large or evolving projects.

Answer B) Requirement → Design → Coding → Testing → Deployment → Maintenance

Answer: D)  Maintenance testing

Regression Testing is the process of re-testing existing software after changes (like bug fixes, enhancements, or updates) to ensure previously working features still function correctly.

Why it’s maintenance-related:

After software is deployed, it may require modifications or enhancements.

Regression testing ensures maintenance changes do not break existing functionality.

Maintenance phase includes corrective, adaptive, perfective, and preventive changes, all of which can trigger regression testing.