Q.2. i) According to you which SDLC model is the best? There is no single "best" SDLC model; the ideal choice depends entirely on the specific context of the project. If the requirements are perfectly clear, stable, and well-documented from the beginning, the Waterfall Model might be best. However, for modern, dynamic projects where requirements are expected to change or are initially unclear, an Agile Model or Prototype Model is far superior due to their flexibility and iterative feedback loops.
Q.2. ii) Who is software project manager and what is his/her role? A software project manager is the professional responsible for the planning, execution, monitoring, and closure of a software development project. Their primary role revolves around managing the "4Ps": organizing the People (team members), defining the Product scope, selecting the right software development Process, and tracking the Project schedule, budget, and risks to ensure successful delivery.
Q.2. iii) What is mean by software scope? Software scope clearly 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, ensuring that the development team and the client agree on the deliverables before coding begins.
Q.2. iv) What is feasibility study? A feasibility study is a preliminary assessment conducted before committing resources to a project to determine if it is practical and worth the investment. It evaluates the project across several key dimensions: Technical feasibility (do we have the capability to build it?), Economic feasibility (can we afford it and will it make a profit?), and Operational feasibility (will the end-users actually adopt it?).
Q.2. v) What are functional and non-functional requirements?
Q.2. vi) What is modularization? Modularization is the software engineering practice of breaking down a large, complex system into smaller, manageable, and independent components known as modules. This approach simplifies development, allows different team members to work on different parts of the system simultaneously, and makes the final software much easier to test and maintain.
Q.2. vii) Differentiate between coupling and cohesion. Coupling refers to the degree of interdependence between different modules; good software design requires low coupling so that a change in one module does not unexpectedly break another. 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 exactly one well-defined task.
Q.2. viii) Discuss level 0 Data flow diagram? A Level-0 Data Flow Diagram (DFD), also known as a Context Diagram, provides the highest-level, bird's-eye view of a system. It represents the entire software system as a single process (usually drawn as one main circle) and illustrates how it interacts with external entities (drawn as rectangles) through the flow of data (drawn as labeled arrows) entering and exiting the system.
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 (Requirements Design Implementation Testing Deployment).
The Prototype Model The Prototype Model is an iterative approach. Instead of finalizing all requirements upfront, developers quickly build a simplified, working version of the software (a prototype). This is shared with the customer to gather immediate feedback, which is 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 | Best when requirements are perfectly clear and frozen before development begins. | Best when requirements are vague, unknown, or expected to change frequently. |
| Flexibility to Change | Highly rigid; extremely difficult and costly to accommodate changes once a phase is passed. | Highly flexible; accommodates changes easily through continuous iterations. |
| User Involvement | High at the beginning (planning) and end, but practically zero during the coding phase. | High throughout the entire lifecycle; relies heavily on continuous user feedback. |
| Product Delivery | The user only sees working software at the very end of the project lifecycle. | The user interacts with a working (though incomplete) software prototype very early. |
| Risk Factor | High risk; if an initial requirement was misunderstood, it is discovered too late to fix cheaply. | Low risk; errors in requirements or design are caught early during prototype evaluations. |
Defining Metrics In software engineering, Metrics are quantifiable, numerical measurements used to assess the quality, efficiency, cost, and progress of the software development process and the software product itself. They help managers make data-driven decisions rather than relying on guesswork.
1. Size-Oriented Metrics Size-oriented metrics measure the software based on its physical size or volume.
2. Function-Oriented Metrics Function-oriented metrics attempt to measure the software based on the actual "functionality" or utility delivered to the end-user, rather than the physical size of the code.
Why We Use the Object-Oriented (OO) Approach The Object-Oriented approach is widely used because it maps complex software concepts directly to real-world entities, making systems easier to conceptualize. It promotes modularity by breaking systems down into self-contained objects, enables high reusability (saving time and money) by allowing developers to use existing code for new projects, and drastically improves maintainability, as localized changes to one object rarely crash the entire system.
Characteristics of Object-Oriented Approach
1. Classes and Objects A Class is a logical blueprint or template defining the data and behaviors of an entity. An Object is a physical, memory-allocated instance of that class.
2. Encapsulation Encapsulation is the practice of bundling data (variables) and the methods (functions) that manipulate that data into a single, secure unit (the object). It hides the internal state of the object from the outside world, requiring other objects to interact with it only through strictly defined public methods.
3. Inheritance Inheritance allows a new class (child/subclass) to automatically acquire the properties and methods of an existing class (parent/superclass). This is the primary driver of code reusability.
4. Polymorphism Meaning "many forms," polymorphism allows different objects to respond to the exact same method call in their own unique way.
Draw(). Draw arrows pointing from Draw() to three different geometric shapes: a Circle, a Square, and a Triangle.Introduction to SDLC The System Development Life Cycle (SDLC) is a structured, standard framework that defines the necessary phases involved in developing a software application. Its purpose is to provide a logical, systematic plan to design, build, test, and deliver high-quality software that meets customer expectations while adhering to time and budget constraints.
Core Phases of the SDLC
Open this section to load past papers