Software Engineering 2024

Section II (Short Answer)

Q.2. i. What is mean by software scope? Software scope defines the exact boundaries of a project by outlining what the software will do and, equally importantly, what it will not do. It establishes the specific features, functions, performance constraints, and interfaces required for the final product. For example, the scope of a library management system would include issuing books and tracking inventory, but it would explicitly exclude managing the payroll for library staff.

Q.2. ii. What is feasibility study? A feasibility study is a preliminary assessment conducted before committing to a project to determine if it is practical and worth the investment. It evaluates the project across several dimensions, primarily focusing on Technical feasibility (do we have the right technology?), Economic feasibility (is it within budget?), and Operational feasibility (will it solve the user's problem?).

Q.2. iii. What is modularization? Modularization is the software design technique of breaking down a large, complex system into smaller, manageable, and independent components known as modules. This approach simplifies the development process because individual modules can be developed, tested, and updated independently, making the overall software much easier to maintain and understand.

Q.2. iv. Differentiate between coupling and cohesion. Coupling refers to the degree of interdependence between different modules; good software design requires low coupling so that changes in one module do not break others. Cohesion refers to how strongly related and focused the internal responsibilities of a single module are; good design requires high cohesion, meaning a module should perform one specific, well-defined task.

Q.2. v. Why Linear Sequential Model is also called Water Fall Model? The Linear Sequential Model is called the Waterfall Model because the project lifecycle flows steadily downwards through distinct phases: Requirements, Design, Implementation, Testing, and Maintenance. Just as water flows strictly downward over a cliff, this model assumes you must fully complete one phase before moving to the next, with little to no room for flowing backward to revise previous steps.

Q.2. vi. Define the term Metrics? Discuss Size Oriented Metrics. Software Metrics are quantitative measurements used to assess the quality, efficiency, or cost of the software development process and the software product itself. Size Oriented Metrics measure the software based on its physical size or volume, most commonly utilizing Lines of Code (LOC) or Thousands of Lines of Code (KLOC). Developers use these size metrics to calculate error rates (e.g., errors per KLOC) or estimate project costs (e.g., cost per LOC).

Q.2. vii. In which situation, prototype model is preferred? The prototype model is highly preferred in situations where the customer's exact requirements are ambiguous, unclear, or likely to change frequently. By quickly building a working, simplified version of the software (a prototype), developers can let the client interact with it directly, gather immediate feedback, and solidify the actual requirements before building the final, robust product.

Q.2. viii. Differentiate between white box testing and black box testing. In Black Box Testing, the tester treats the software as a closed box, focusing only on inputs and expected outputs without looking at the internal source code. In contrast, White Box Testing (or glass box testing) requires the tester to have full knowledge of the internal code, structure, and logic, allowing them to test specific programming paths, loops, and conditional statements.

Q.2. ix. Describe Software Quality Assurance. Software Quality Assurance (SQA) is an umbrella activity applied throughout the entire software development lifecycle to ensure that the final product meets specified quality standards and user requirements. It involves a planned and systematic set of actions—like audits, code reviews, and process monitoring—designed to prevent defects from occurring, rather than simply hunting for bugs at the very end of development.

Q.2. x. What is Incremental Process Model? The Incremental Process Model involves developing and delivering the software in manageable chunks, or "increments." The first increment delivers the core functionality of the system, and subsequent increments sequentially add new features or expand upon existing ones. For instance, an increment 1 word processor might only allow basic typing, while increment 2 adds spell-checking capabilities.

Q.2. xi. What is CMM? CMM stands for Capability Maturity Model. It is an industry-standard framework used to assess and improve the maturity and capability of a software development organization's internal processes. The model classifies organizations into five distinct maturity levels—Initial, Repeatable, Defined, Managed, and Optimizing—helping them transition from chaotic coding environments to highly disciplined and continuous improvement-focused operations.

---

Section III (Essay Type)

Q. #.3. Differentiate between structural Model and Behavioral Model with the help of diagrams

Introduction In software engineering, modeling is crucial for visualizing system architecture before writing code. The two primary categories of system modeling in UML (Unified Modeling Language) are Structural Models and Behavioral Models. They view the system from completely different perspectives.

Structural Model A structural model represents the static framework of a software system. It illustrates the physical and logical components of the system and how they are connected or related to one another, independent of time.

• Focus: It answers the question "What are the parts of the system?"
• Common Diagrams: Class Diagrams, Component Diagrams, Object Diagrams.
• Diagram Concept (Class Diagram representation for exam): Draw three boxes connected by lines.
• Box 1 (Top): Class Name (e.g., Student)
• Box 2 (Middle): Attributes (e.g., - studentID: int, - name: string)
• Box 3 (Bottom): Methods (e.g., + registerCourse(), + viewGrades())

Behavioral Model A behavioral model represents the dynamic behavior of the system. It illustrates how the system's components interact over time, how they respond to internal or external events, and how data flows through the system.

• Focus: It answers the question "What does the system do and how does it react?"
• Common Diagrams: Use Case Diagrams, State Machine Diagrams, Sequence Diagrams.
• Diagram Concept (State Diagram representation for exam): Draw circles (states) connected by arrows (transitions/events).
• Solid Dot -> Arrow labeled Power On -> Circle labeled IDLE_STATE
• Circle IDLE_STATE -> Arrow labeled Insert Coin -> Circle labeled VENDING_STATE

Comparison Table

Feature	Structural Model	Behavioral Model
Primary Focus	Static architecture and component relationships.	Dynamic interactions, workflows, and state changes.
Perspective	Represents the "Noun" aspect of a system.	Represents the "Verb" aspect of a system.
Time Dependency	Time-independent; shows the system at rest.	Time-dependent; shows the system in action.
Key UML Diagrams	Class, Object, Component, Deployment diagrams.	Use Case, Sequence, Activity, State diagrams.

---

Q. #.4. Compare and Contrast Water Fall Model and Prototype Model

The Waterfall Model The Waterfall Model is a traditional, linear-sequential approach to software development. It relies on heavy upfront planning, strict documentation, and completing one phase of development entirely before proceeding to the next. The standard phases are Communication, Planning, Modeling (Design), Construction (Code/Test), and Deployment.

The Prototype Model The Prototype Model is an iterative and evolutionary approach. Instead of finalizing all requirements upfront, developers quickly build a simplified, working version of the software (a prototype). This prototype is shared with the customer to gather feedback, which is then used to refine requirements and build a better version, repeating the cycle until the final product is approved.

Comparison and Contrast Table

Aspect	Waterfall Model	Prototype Model
Requirement Clarity	All requirements must be perfectly clear and frozen before development begins.	Best when requirements are vague, unknown, or expected to change.
Flexibility	Highly rigid; extremely difficult to accommodate changes once a phase is passed.	Highly flexible; accommodates changes easily through continuous iterations.
User Involvement	High at the beginning and end, but practically zero during the actual coding phase.	High throughout the entire lifecycle; relies heavily on continuous user feedback.
Delivery of Product	The user only sees working software at the very end of the project lifecycle.	The user interacts with working (though incomplete) software very early in the project.
Risk Management	High risk; if an initial requirement was wrong, it is discovered too late and is costly to fix.	Low risk; errors in requirements are caught early during prototype evaluations.
Documentation	Extensive and mandatory at every single phase.	Minimal during the initial iterations to speed up prototype creation.

---

Q. #.5. Why we use object oriented approach? Discuss different characteristics of object oriented approach with diagrams

Why We Use the Object-Oriented (OO) Approach The Object-Oriented approach is widely used because it maps software concepts directly to real-world entities, making complex systems easier to conceptualize and build. It promotes modularity by breaking systems down into self-contained objects. It enables high reusability through inheritance, allowing developers to use existing code for new projects. Finally, it drastically improves maintainability, as localized changes to one object rarely break the entire system.

Characteristics of Object-Oriented Approach

1. Classes and Objects: A Class is a blueprint or template defining the data and behaviors of an entity. An Object is a physical instance of that class.

• Diagram Concept: Draw a blueprint labeled "Class: Car". Draw arrows pointing to three physical cars labeled "Object 1: Civic", "Object 2: Corolla", "Object 3: Mustang".

2. Encapsulation: This is the practice of bundling data (variables) and the methods (functions) that operate on that data into a single unit (an object), while restricting direct external access to some of the object's components.

• Diagram Concept: Draw a capsule/pill shape. Inside the capsule, write "Data" and "Methods" to show they are locked together securely from the outside.

3. Inheritance: This allows a new class (child/subclass) to inherit the properties and methods of an existing class (parent/superclass), promoting code reusability.

• Diagram Concept: Draw a box labeled "Vehicle (Parent Class)" at the top. Draw arrows pointing down to two new boxes: "Car (Child Class)" and "Motorcycle (Child Class)".

4. Polymorphism: Meaning "many forms," this concept allows methods to perform different tasks based on the object invoking them. A single function name can be reused to perform different actions.

• Diagram Concept: Draw a box representing an action called Draw(). Draw arrows pointing from Draw() to three different outputs: a Circle, a Square, and a Triangle, showing one method acting differently.

---

Q. #.6. Define the term Software Quality, discuss tasks of SQA

Defining Software Quality Software Quality is defined as the degree to which a software product meets the needs of its users. Technically, it is the conformance to explicitly stated functional and performance requirements, adherence to explicitly documented development standards, and the presence of implicit characteristics that are expected of all professionally developed software (such as reliability, usability, and maintainability).

Tasks of Software Quality Assurance (SQA) SQA involves a series of proactive tasks applied throughout the software lifecycle to guarantee high-quality output. The primary tasks include:

• Preparing an SQA Plan: Before the project begins, SQA engineers create a plan identifying the quality evaluations to be performed, the standards to be applied, the error tracking procedures, and the specific documents to be produced.
• Participating in the Development of Project Software Process Description: The SQA team reviews the process description for the project to ensure it aligns with overall organizational policies and quality standards.
• Conducting Formal Technical Reviews (FTR): SQA members participate in technical reviews of code, designs, and requirements to uncover errors as early as possible in the development lifecycle.
• Auditing Software Processes and Products: SQA personnel independently audit designated software products and the development process itself to verify compliance with the defined standards and procedures.
• Testing Oversight: While SQA does not always perform the actual testing, they ensure that the testing strategy is sound, that test cases are comprehensive, and that testing is executed correctly.
• Recording and Tracking Deviations (Defect Management): SQA tracks all identified bugs, errors, and deviations from the standard, ensuring that they are documented, assigned, and resolved before final deployment.
• Reporting to Senior Management: SQA provides detailed reports to management highlighting non-compliance issues, project quality metrics, and risks, ensuring management has an objective view of the software's health.