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.
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.
Student)- studentID: int, - name: string)+ 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.
Power On -> Circle labeled IDLE_STATEIDLE_STATE -> Arrow labeled Insert Coin -> Circle labeled VENDING_STATEComparison 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. |
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. |
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
Draw(). Draw arrows pointing from Draw() to three different outputs: a Circle, a Square, and a Triangle, showing one method acting differently.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:
Open this section to load past papers