Unit1 - Subjective Questions

Definition:
According to IEEE Standard 610.12, Software Engineering is defined as:

"The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software."

Differences between Software Engineering and Computer Science:

The Software Crisis refers to a period in the late 1960s and 1970s characterized by difficulties in writing high-quality and efficient computer software within the allocated time and budget.

Contributing Factors:

• Projects over budget: Costs often spiraled out of control ().
• Projects running over time: Deadlines were frequently missed.
• Low Quality: Software was unreliable, inefficient, and bug-ridden.
• Unmaintainable Code: Lack of documentation and structure made modification impossible (Spaghetti code).
• Hardware Evolution: Hardware power increased rapidly (Moore's Law), but software techniques could not keep up with the complexity required to utilize that power.

Impact:
This crisis led to the 1968 NATO conference where the term "Software Engineering" was coined to introduce disciplined engineering approaches to software development.

The Software Development Life Cycle (SDLC) provides a framework for the software creation process. The generic phases include:

1. Requirement Gathering & Analysis:
   • Collecting inputs from stakeholders.
   • Defining functional and non-functional requirements.
   • Output: SRS (Software Requirement Specification).
2. Feasibility Study:
   • Analyzing technical, operational, and economic feasibility.
3. Design:
   • High-Level Design (HLD): Architecture, database design.
   • Low-Level Design (LLD): Algorithms, API definitions.
4. Implementation (Coding):
   • Writing the actual code using programming languages.
5. Testing:
   • Verifying that the software meets requirements and is bug-free (Unit, Integration, System testing).
6. Deployment:
   • Releasing the software to the production environment.
7. Maintenance:
   • Corrective (bug fixes), Adaptive (environment changes), and Perfective (enhancements) maintenance.

Waterfall Model:
It is a linear-sequential life cycle model where progress is seen as flowing steadily downwards (like a waterfall) through phases.

Process:
Requirements Analysis Design Coding Testing Maintenance.

Advantages:

• Simple to understand: Easy to manage due to the rigidity of the model.
• Milestones: Each phase has specific deliverables and a review process.
• Good for stable requirements: Works well when requirements are well-known and fixed.

Disadvantages:

• No Feedback Loop: It is difficult to go back and change something once a phase is finished.
• Late Testing: Testing is done only at the end. If a design error is found in the testing phase, the cost of fixing it is very high ().
• Not suitable for complex projects: Cannot handle changing requirements or high uncertainty.

Comparison:

Spiral Model:
The Spiral model combines elements of design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. It is visually represented as a spiral with many loops.

The Four Quadrants:

1. Objective Setting: Determine objectives, alternatives, and constraints.
2. Risk Analysis: Analyze alternatives and identify/resolve risks. Prototypes are often built here.
3. Development & Validation: Develop the product for this iteration (design, code, test).
4. Planning: Review results and plan for the next iteration (spiral).

Risk Handling:
It is the only traditional model driven by risk analysis. Before any coding takes place in a loop, risks (technical, schedule, cost) are assessed. If risks are too high, the project might be terminated.

Meta-Model:
It is called a Meta-Model because it subsumes other models. For example, a single loop might resemble the Waterfall model, while the risk analysis phase utilizes Prototyping.

V-Model:
An extension of the Waterfall model where process steps are bent upwards after the coding phase, forming a V shape. It emphasizes that for every development phase, there is a corresponding testing phase.

Mapping of Phases:

1. Requirement Analysis Acceptance Testing: Checks if the software meets customer needs.
2. System Design System Testing: Checks the entire system architecture and functionality.
3. Architectural Design Integration Testing: Checks if different modules work together.
4. Module Design Unit Testing: Checks individual components or functions.

Key Benefit: Testing planning begins early in the life cycle (during the design phase), not just after coding.

Agile Manifesto:
A declaration created in 2001 by software practitioners to improve software development processes. It prioritizes flexibility and customer satisfaction.

Four Core Values:

1. Individuals and interactions over processes and tools.
   • Significance: People drive development, not rigid rules.
2. Working software over comprehensive documentation.
   • Significance: Deliver functional code rather than extensive manuals.
3. Customer collaboration over contract negotiation.
   • Significance: Continuous feedback is better than fixed contracts.
4. Responding to change over following a plan.
   • Significance: Adaptability is crucial in dynamic environments.

Scrum:
A lightweight Agile framework for developing complex software systems using iterative and incremental practices.

1. Roles:

• Product Owner: Defines features, prioritizes the Product Backlog, represents stakeholders.
• Scrum Master: Facilitates the process, removes impediments, ensures Scrum rules are followed.
• Development Team: Cross-functional group that designs, builds, and tests the increment.

2. Artifacts:

• Product Backlog: Ordered list of everything that is known to be needed in the product.
• Sprint Backlog: List of tasks selected for the current Sprint.
• Increment: The sum of all Product Backlog items completed during a Sprint.

3. Events:

• Sprint: A time-boxed period (usually 2-4 weeks) to create an increment.
• Daily Stand-up: 15-minute meeting to synchronize activities.
• Sprint Review: Inspecting the outcome of the Sprint.
• Sprint Retrospective: Reviewing the process to improve for the next Sprint.

DevOps:
A set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality.

DevOps Lifecycle (Continuous Loop):

1. Plan: Define business value and requirements.
2. Code: Software construction and code review.
3. Build: Compiling code and packaging artifacts.
4. Test: Automated testing to ensure quality.
5. Release: Managing release coordination.
6. Deploy: Provisioning infrastructure and deploying code.
7. Operate: Managing the software in production.
8. Monitor: Collecting data on performance and user experience.

This is often represented as an infinity symbol indicating continuous integration and continuous deployment (CI/CD).

Comparison:

Functional Requirements (FR):
These define what the system should do. They describe the functions, behaviors, and services the system provides.

• Example 1: The system must allow a user to register with an email and password.
• Example 2: The system must calculate the total tax using the formula .

Non-Functional Requirements (NFR):
These define how the system performs. They are quality constraints or quality attributes.

• Example 1 (Performance): The system should load the dashboard in less than 2 seconds.
• Example 2 (Security): All user passwords must be encrypted using SHA-256.

Requirement elicitation is the process of seeking, uncovering, acquiring, and elaborating requirements for computer systems. Common techniques include:

1. Interviews:
   • One-on-one meetings with stakeholders. Can be structured (pre-planned questions) or unstructured (open-ended).
2. Brainstorming:
   • Group sessions to generate new ideas and solutions rapidly without immediate criticism.
3. Questionnaires/Surveys:
   • Useful for gathering data from a large number of users remotely. Good for statistical data.
4. Observation (Job Shadowing):
   • Observing the user in their actual work environment to understand their workflow and pain points.
5. Prototyping:
   • Building a mock-up to show users. Helps in clarifying vague requirements.
6. Use Cases / User Stories:
   • Describing scenarios of how the user will interact with the system.

Feasibility Study:
An analysis conducted to determine if a proposed project is worth undertaking. It happens during the early stages of the SDLC.

Types of Feasibility:

1. Technical Feasibility:
   • Can we build it? Does the necessary technology, hardware, and expertise exist?
2. Economic Feasibility:
   • Is it profitable? Cost-Benefit Analysis ().
3. Operational Feasibility:
   • Will it work in the organization? Will users accept it?
4. Legal Feasibility:
   • Does it comply with laws (e.g., GDPR, copyright)?
5. Schedule Feasibility:
   • Can it be completed within the required timeframe?

SRS Document:
A formal document that acts as a contract between the client and the developer. It completely describes the expected behavior of the software system.

Characteristics of a Good SRS:

1. Correct: Accurately reflects the user's needs.
2. Unambiguous: Every requirement has only one interpretation.
3. Complete: Contains all significant requirements and responses to all inputs.
4. Consistent: No conflicts between requirements (e.g., Req A says distinct inputs, Req B says overlapping inputs).
5. Verifiable: There exists a method (test case) to verify if the requirement is met.
6. Modifiable: Structure and style allow easy changes.
7. Traceable: Origin of each requirement is clear (Forward and Backward traceability).

The IEEE Std 830 recommends the following structure for an SRS:

1. Introduction

• 1.1 Purpose
• 1.2 Scope
• 1.3 Definitions, acronyms, and abbreviations
• 1.4 References
• 1.5 Overview

2. Overall Description

• 2.1 Product perspective
• 2.2 Product functions
• 2.3 User characteristics
• 2.4 Constraints
• 2.5 Assumptions and dependencies

3. Specific Requirements (The core section)

• 3.1 External interface requirements
• 3.2 Functional requirements
• 3.3 Performance requirements
• 3.4 Design constraints
• 3.5 Software system attributes (Security, Maintainability)

4. Appendices
5. Index

Requirement Validation:
The process of checking that the requirements defined in the SRS actually define the system that the customer wants. It ensures the requirements are complete, correct, and consistent.

Why is it necessary?
Errors in requirements are the most expensive to fix later in the lifecycle. Validation prevents "building the wrong product."

Techniques:

1. Requirements Reviews: A team (including customers) manually analyzes the requirements.
2. Prototyping: Demonstrating a model to the user for validation.
3. Test-Case Generation: If a test case is difficult to derive, the requirement might be ambiguous.
4. Automated Consistency Analysis: Using CASE tools to check for inconsistencies.

Hardware Failure (Bathtub Curve):
Hardware follows a "Bathtub" curve:

1. Infant Mortality: High failure rate initially due to manufacturing defects.
2. Useful Life: Failure rate drops and remains constant/low.
3. Wear Out: Failure rate rises sharply due to physical deterioration (rust, dust, heat).

Software Failure:
Software does not wear out. Its curve is different:

1. Initial Phase: High failure rate (bugs found during testing/early release).
2. Idealized Curve: Failure rate should drop to zero as bugs are fixed.
3. Actual Curve: When changes/upgrades are introduced, the failure rate spikes again due to side effects, then slowly lowers. It does not rise due to time/physics, but due to complexity and change.

Incremental Development:

• Concept: The system is broken down into small, manageable pieces (increments). Each increment delivers a portion of the functionality.
• Analogy: Building a house room by room. You finish the kitchen, then the bedroom.
• Goal: To deliver parts of the working software early.

Iterative Development:

• Concept: The system is developed through repeated cycles (iterations). In each iteration, the system is improved and refined.
• Analogy: Sketching a whole picture, then inking it, then coloring it. You work on the whole, improving quality/detail.
• Goal: To refine the system based on feedback.

Note: Agile/Scrum is usually both Iterative (repeating cycles) and Incremental (delivering chunks of value).

Requirement Analysis is often the most difficult phase. Challenges include:

1. Ambiguity: Stakeholders often speak in vague terms (e.g., "Make it user-friendly").
2. Changing Requirements: Business needs change during the analysis process (Volatility).
3. Communication Gap: Differences in vocabulary between technical developers and non-technical business users.
4. Conflicting Requirements: Different stakeholders (e.g., Sales vs. Security team) may have opposing needs.
5. Undocumented Processes: Users often rely on tacit knowledge that they forget to mention explicitly.
6. Scope Creep: Uncontrolled expansion of project scope without adjustments to time, cost, and resources.