Software Crisis (Meaning)

When software demand, complexity, and challenges increase but we still use the same workforce, tools, and methods — it leads to serious problems like delays, poor quality, and unmanageable code. This is called a Software Crisis.

When It Happens

• Project takes too much time
• Project goes over budget
• Software is inefficient
• Poor quality software
• Doesn't meet requirements
• Code is hard to manage or maintain
• Software is never ready for delivery

Main Reasons

• Scaling problems
• High cost
• Late delivery
• Unreliable software
• Low productivity
• Poor understanding of the problem or environment
• Complex problems
• Duplicated effort due to lack of automation

Solution

The best approach is Software Engineering because it is:

• Systematic
• Disciplined
• Quantifiable

Guidelines to solve the crisis:

• Reduce budget overruns
• Improve software quality
• Save development time
• Use experienced teams

Generic Software Process Activities

1. Communication

   • Talk to customers, developers, and stakeholders
   • Gather requirements

2. Planning

   • Define tasks, schedule, resources, risks
   • Estimate and track project progress

3. Modeling

   • Create representations (like algorithms, flowcharts)
   • Analyze requirements and design the system

4. Construction

   • Code the software
   • Test the code to ensure correct output and logic

5. Deployment

   • Deliver the product to the customer
   • Take feedback and make corrections if needed

Software Life Cycle Models

They define phases and sequence to develop software. Popular SDLC models:

• Waterfall Model
• Iterative Waterfall Model
• Incremental Model
• Agile Model
• Spiral Model
• Prototype Model

Waterfall Model (Classic)

• First widely used model
• Linear & sequential — next phase starts only when previous is complete
• No feedback loops
• Easy to understand, good for small projects

Phases and Deliverables:

1. Requirement Analysis

   • Understand & validate requirements
   • Deliverable: RUD (Requirements Understanding Document)

2. System Design

   • Design system as per requirements
   • Deliverables: HLD (High Level), LLD (Low Level)

3. Implementation

   • Write and unit test code
   • Deliverable: Code + results

4. System Testing

   • Integrate and test system (functional + non-functional)
   • Deliverables: Test cases, reports, defect list

5. Deployment

   • Deploy to real environment, ensure setup works
   • Deliverables: User Manual, Environment Docs

6. Maintenance

   • Fix bugs, add new features
   • Deliverables: Production issues log, updated user manual

Advantages:

• Simple, structured
• Easy maintenance
• Works for small, fixed-scope projects
• Clear documentation

Disadvantages:

• No changes allowed in middle
• Late delivery (no prototypes shown)
• Poor for large or evolving projects
• Late testing = late risk discovery

Iterative Waterfall Model

• Same phases as Waterfall, but with feedback loops
• Can go back to previous phases to fix issues
• Errors caught early in the same phase

Advantages:

• Easier to fix mistakes
• Saves time and cost
• Better for large & complex projects

Limitations:

• Not good if requirements are unclear
• No customer preview/prototype
• Not ideal for short or frequently changing projects

Spiral Model (Meta Model)

• Combines iterative & waterfall approaches
• Each loop = development phase
• Risk analysis is key in every phase
• Radius = Cost, Angle = Progress

Phases in Each Loop

1. Planning
2. Risk Analysis
3. Development & Testing
4. Evaluation (customer feedback)

When to Use Spiral Model

• Large, complex projects
• Unclear or changing requirements
• High-risk projects
• Frequent releases needed

Advantages

• Handles risk very well
• Allows requirement changes
• Produces working software early
• High customer satisfaction
• Good for complex and critical systems

Disadvantages

• Not suitable for small or low-risk projects
• Costly & complex process
• Needs expertise in risk handling
• Time estimation is difficult
• May never end without clear limits
• Too much documentation

Win-Win Spiral Model

• Enhancement of Spiral with stakeholder negotiation
• Ensures both customer and developer goals are met

3 Anchor Points

1. LCO – Life Cycle Objectives
2. LCA – Life Cycle Architecture
3. IOC – Initial Operational Capability

7 Steps in Win-Win Spiral Model

1. Identify stakeholders
2. Identify their win conditions
3. Reconcile win conditions → set goals & constraints
4. Evaluate alternatives, manage risks
5. Define next level product/process, possibly split into subsystems
6. Validate product/process
7. Go to next loop with agreed goals

Agile Software Development

• Flexible, fast, and incremental approach
• Focuses more on working code than heavy documentation
• Uses Sprints (short, time-boxed iterations)
• Encourages team collaboration and customer feedback
• Adapts quickly to changing requirements

Agile Manifesto: 4 Core Values

1. Individuals and Interactions over processes/tools
2. Working Software over documentation
3. Customer Collaboration over contract negotiation
4. Responding to Change over following a plan

Agile Principles (Key Points)

• Early & continuous delivery
• Welcome change anytime in project
• Frequent delivery of working software
• Daily collaboration with business team
• Build around motivated individuals
• Prefer face-to-face communication
• Focus on working solutions, not effort
• Maintain constant pace
• Aim for technical excellence
• Keep it simple
• Use self-organizing teams
• Reflect & improve regularly

Advantages

• Fast deployment
• Quick response to change
• Customer feedback improves quality
• Better team communication
• Higher technical quality and transparency

Disadvantages

• Less documentation
• Needs active customer involvement
• Harder in large teams
• New developers may struggle (needs experience)

Purpose of PSP & TSP

Both help improve:

• Software quality
• Secure and disciplined processes
• Process management at personal and team level

TSP (Team Software Process)

• Developed by SEI, Carnegie Mellon
• Focus: Team productivity, planning, collaboration, and quality

Key Concepts

• Structured teamwork with defined roles (e.g., manager, developer)
• Iterative cycles with regular feedback
• Goal setting (quality, time, cost)
• Project planning with estimates, workload balance
• Metrics-driven decisions (defects, effort, productivity)
• Built-in quality via reviews, unit tests, tracking

TSP Phases

1. Launch – Define goals, assign roles, plan
2. Implementation – Coding, testing, reviews
3. Postmortem – Analyze results and improve for next time

TSP Benefits

• Higher productivity and quality
• Fewer defects
• Better scheduling & estimation
• Strong team coordination

PSP (Personal Software Process)

• Focus: Individual developer’s process improvement
• Promotes self-discipline, quality control, and time management

Key Concepts

• Self-improvement in habits and process
• Track defects and use reviews for early error detection
• Estimate task time and set personal goals
• Record time and effort data
• Analyze productivity and identify delays
• Improve personal process with data insights

PSP Phases

1. Planning – Task/time estimates
2. Design – Detailed design to avoid defects
3. Development – Code with time tracking
4. Testing – Unit testing and code reviews
5. Postmortem – Analyze and improve

Relationship Between PSP & TSP

• PSP = Individual level, forms the base of
• TSP = Team level, built on PSP discipline
• Both use data and metrics for continuous improvement
• PSP → TSP = Scalable from personal to team projects

Personal Software Process (PSP) – Example (John)

Scenario: John develops a product review feature for an e-commerce site.

1. Planning

   • Estimated: 10 hours
   • Tasks: DB design, UI, backend logic, unit testing

2. Time Tracking

   • Actual time: 12 hours
   • Breakdown: DB – 2h, UI – 3h, Backend – 4h, Testing – 2h

3. Defect Tracking

   • Backend caused 5 bugs
   • Fix time: +1 hour

4. Postmortem

   • Underestimated UI time
   • Backend needs better design to reduce bugs

5. Improvements

   • Next time: more design focus, better time estimates

Team Software Process (TSP) – Example (Team Project)

Scenario: John works in a team on a recommendation engine.

1. Team Roles

   • Team Leader, Developer (John), Quality Manager, Planning Manager

2. Planning

   • Tasks assigned:

     • Data: 20h (Data Engineer)
     • Backend: 15h (John)
     • UI: 10h (Frontend Dev)

3. Team Coordination

   • Everyone logs hours in shared system
   • Regular review meetings

4. Quality Control

   • Code reviewed by Quality Manager
   • Testing team runs integration/system tests

5. Metrics Tracking

   • Track:

     • Defect density
     • Team velocity

6. Postmortem

   • John’s backend = low defects (good reviews/testing)
   • Delay: 5h due to UI issues
   • Improvement: Better backend–frontend coordination next time

Goal:

Choose the best SDLC model based on project needs (size, complexity, budget, time, etc.)

Key Parameters for Model Selection

1. Requirements Characteristics

   • Are requirements clear and stable?
   • Will they change frequently?
   • Are they complex or numerous?
   • Can they be defined early?

2. Development Team

   • Team size
   • Developers’ experience in similar projects and technologies
   • Level of domain knowledge
   • Understanding of user requirements
   • Training availability

3. User Involvement

   • User’s expertise and experience
   • Will users be involved in all phases?

4. Project Type & Risk

   • Project size & duration
   • Budget stability
   • Resource availability
   • Schedule pressure
   • Complexity and risk level

Based on these factors, models like Agile (for changing requirements), Waterfall (for clear requirements), or Spiral (for high risk) can be selected.

Software Requirement

• A feature, function, or condition that the user needs
• Must satisfy contract, standard, or specification

Requirement Engineering

• Process of defining, documenting, and managing requirements
• Helps understand what customer wants, analyzes it, checks if it’s feasible, then clearly specifies and validates it

Requirement Engineering Process

1. Feasibility Study

   • Checks if project is practical and beneficial

   • Types:

     • Technical: Can tech meet needs?
     • Operational: Will it solve the problem?
     • Economic: Is it profitable?

2. Requirement Elicitation & Analysis

   • Gather needs from customers, users, stakeholders

   • Common issues:

     • Wrong people involved
     • Users unclear or change minds
     • Conflicting needs

3. Software Requirement Specification (SRS)

   • Analyst converts user requirements into technical document

   • Tools used:

     • DFD (Data Flow Diagram): shows data movement
     • Data Dictionary: defines terms clearly
     • E-R Diagram: shows entities, relationships, attributes

4. Requirement Validation

   • Check if requirements are:

     • Feasible, Correct, Complete, Clear

   • Techniques:

     • Reviews/Inspections
     • Prototyping
     • Test-case generation
     • Automated consistency checks

Fundamental Issues in Software Design

1. Meeting User Requirements

   • Understand what the user really needs
   • If needs are missed, software becomes useless

2. Maintaining Simplicity

   • Avoid unnecessary complexity
   • Simple UI = better usability and fewer errors

3. Scalability

   • Software should handle growth in users/data
   • Poor scalability = crashes or slowdowns

4. Performance

   • Must run fast and use resources efficiently
   • Slow software = frustrated users

5. Security

   • Protect against unauthorized access
   • Critical for sensitive domains like banking

6. Flexibility & Maintainability

   • Easy to update, add features, or fix bugs
   • Important for long-term software evolution

7. Handling Errors & Failures

   • Should show helpful error messages, not crash
   • Makes software reliable and user-friendly

8. Usability

   • Easy to learn and use
   • Better usability = fewer mistakes and higher productivity

9. Interoperability

   • Should work with other systems/software
   • Essential for data sharing and integration

10. Cost & Time Management

• Stay within budget and schedule
• Helps avoid delays and overspending

Cohesion

• Definition: How closely related and focused the functions inside a module/class are
• Goal: High Cohesion = each module does one specific task well

High Cohesion

• Parts inside the module are related and focused
• Easier to understand, maintain, and reuse
• Example: Separate modules for Product Management, Cart, Checkout in an e-commerce app

Low Cohesion

• Module handles unrelated tasks
• Leads to confusing and error-prone code
• Example: Cart module also handling user login or profile tasks

Coupling

• Definition: How much one module depends on another
• Goal: Low Coupling = modules are independent

Low Coupling

• Modules interact via well-defined interfaces
• You can change one module without affecting others
• Example: Payment system works independently from Cart or Product modules

High Coupling

• Modules are tightly connected
• Change in one requires changes in others
• Example: Cart logic directly accessing payment gateway internals

Cohesion vs Coupling

Combined Best Practice

• Aim for High Cohesion + Low Coupling

• Results in:

  • Easier maintenance
  • Higher flexibility & reuse
  • Better testing/debugging

Real Example: Amazon

• High Cohesion: Separate modules for product display, cart, payments, user accounts
• Low Coupling: Adding a new payment method doesn’t affect cart or product modules

Function-Oriented Design (FOD)

• Software is divided into functions performing specific tasks
• Follows top-down design using data flow
• Focus is on processes/actions, not objects (unlike OOP)

General Procedure

1. Start with what the system does
2. Break it into high-level → low-level functions

Key Concepts

• Functional decomposition
• Data flows between modules
• Top-down design
• Focus on input → process → output

Example: Online Library System

• Main function: LibrarySystem()
• Sub-functions: UserManagement(), BookManagement(), BorrowBooks()
• Further broken down into: registerUser(), addBook(), etc.

Advantages

• Easy to understand
• Good for small/medium projects
• Reusable functions

Disadvantages

• Hard to modify in large systems
• Poor security (data shared freely)
• Not suitable for complex applications

FOD Strategies

1. Data Flow Diagrams (DFD)

• Show how data moves through the system

• Types:

  • Logical DFD – Focus on process
  • Physical DFD – Focus on implementation

DFD Components:

DFD Levels:

• Level 0: Entire system as one process (Context Diagram)
• Level 1: Breaks Level 0 into basic modules
• Level 2: Further details each module from Level 1

DFD Rules:

1. Every process = 1 input, 1 output
2. Every data store = at least 1 input and 1 output
3. All flows must go to a process or store

2. Data Dictionary

• Stores metadata (data about data)
• Describes all elements used in DFDs

Example:

Types:

• Active: Auto-updated with DB changes
• Passive: Must be updated manually

Structured Analysis

• Focus: What the system should do
• Uses graphical tools to understand and define system requirements

Purpose

• Understand user needs clearly
• Break system into manageable parts
• Define logical relationships
• Ensure consistency, scalability, maintainability

Tools Used in Analysis Phase

Structured Design

• Focus: How the system will be built
• Converts analysis into a working modular design

Tools Used in Design Phase

Advantages of SAD

• Clear understanding with diagrams
• Easier maintenance & debugging
• Better communication with stakeholders
• Efficient resource usage
• System is scalable

Disadvantages of SAD

• Time-consuming due to detailed planning
• Rigid structure (hard to change once designed)
• Not ideal for agile or fast-changing projects

What is UML?

• Unified Modeling Language = standard visual language to design and understand software systems
• Not a programming language — it’s for visualizing system structure and behavior
• Helps developers, analysts, and non-technical stakeholders communicate clearly

Why UML is Needed

• Large systems involve multiple teams → need clear communication
• Helps non-programmers understand system functionality
• Saves time by visualizing structure, logic, and interactions

Major UML Diagram Types (With Examples)

Key Diagrams in Detail

1. Class Diagram

• Most used
• Shows static structure: classes, attributes, methods
• Displays relationships: inheritance, associations

2. Use Case Diagram

• Captures functional requirements
• Actors (users) interact with system functions

3. Sequence Diagram

• Shows step-by-step interactions among objects
• Focuses on order and timing of messages

4. Activity Diagram

• Describes control flow between activities
• Supports sequential & parallel flows

Object-Oriented Concepts in UML

UML Tools

• Lucidchart – Web-based, real-time collaboration
• Draw.io – Free, offline/online, cloud-integrated
• Visual Paradigm – Full suite, desktop + online
• StarUML – Open-source, extensible via plugins

Benefits of UML

• Improves clarity and communication
• Helps in planning, design, and requirement analysis
• Saves time and reduces misunderstandings

User Interface (UI) Design

• Process of designing the front-end interface where users interact with software

• A good UI is:

  • Attractive
  • Simple & Clear
  • Responsive (fast)
  • Consistent across all screens

UI Design Principles

User Interface Design Process

Phase 1: User, Task, and Environment Analysis

• Understand user types, skills, goals, and usage conditions
• Categorize users based on their profiles

Phase 2: Interface Design

• Identify tasks users will do
• Define objects and operations related to those tasks

Phase 3: Interface Construction

• Build a prototype
• Improve it iteratively based on feedback
• Simulate real-world use

Phase 4: Interface Validation

• Test if UI supports all user tasks and variations
• Final check before full deployment

Unified Design Process (UDP)

• A systematic approach to software design and development
• Ensures that software is planned, built, and delivered in stages
• Helps meet user needs, manage risks, and handle changing requirements

Phases of UDP

Key Concepts

1. Iteration and Incremental Development

   • System is built and improved in small, testable steps
   • Example: First release = booking; next = ratings, reminders

2. Use Cases

   • Describe user interactions with the system
   • Example: User searches, selects groomer, books appointment

3. Models and Diagrams

   • Show system structure, flow, and component interactions
   • Example: Diagram showing how bookings link to users & payments

Benefits of UDP

• Clarity: Clear goals for each phase
• Flexibility: Easy to update design mid-process
• Quality: Frequent testing = fewer bugs
• User-focused: Regular feedback and real user use-cases guide design

What is SCM?

• SCM = Managing changes in software systematically
• Ensures software components (code, docs, settings) are organized, trackable, and controlled
• Essential for teams working on large or collaborative software projects

Key SCM Processes

Advanced SCM Features

Why SCM is Important

• Collaboration: Prevents code overwrite
• Change Tracking: Know who did what and when
• Risk Management: Rollback to safe versions
• Efficiency: Automated builds & releases save time

Real-Life SCM Examples

• GitHub: Open-source code hosting with version control
• Mobile App Development: Tracks feature additions (e.g., step counter) while keeping app stable

What is Software Configuration Management (SCM)?

• SCM is the systematic process of identifying, organizing, and controlling changes to Software Configuration Items (SCIs) (code, documents, test cases, etc.)
• Ensures quality, consistency, and traceability across the software lifecycle

IEEE Definition

SCM is the process of identifying and defining the items in the system, controlling changes throughout their life cycle, tracking status, and verifying completeness and correctness of items.

SCM Objectives

• Control changes in SCIs
• Avoid errors and mismanagement
• Improve productivity and traceability
• Ensure the software release is stable and verified

Key Components of SCM

Examples of SCIs

• Entire documents (SRS, Design Spec)
• Code files or modules
• Test cases and plans
• Operational software or executables

Baselines (Per SDLC Phase)

Software Release Management

• Release = Delivery of software configuration items (code, docs, install files)

• Must define:

  • What’s new (version description document)
  • Known issues
  • Installation/upgrade instructions

SCM Plan (What It Contains)

1. Introduction: Scope, definitions
2. Management: Roles, responsibilities, baseline control
3. Activities: Identification, change control, status accounting, auditing
4. Tools & Techniques: CM tools and processes
5. Supplier Control: Vendor software coordination
6. Record Retention: Archiving logs, documents, approvals

Constraints on SCM

• Organizational policies
• Regulatory bodies (e.g., safety-critical software)
• Tools/lifecycle models used
• Industry standards and best practices

Organizational Context

• SCM roles may be shared by developers, QA, or a dedicated SCM team

• SCM interacts with:

  • Quality assurance (for non-conforming items, records)
  • Development & maintenance teams (for tool support and coordination)

1. What is Software Testing?

• Process of evaluating software to ensure it meets requirements and is defect-free

2. Why It’s Important

• Ensures quality, performance, and security
• Reduces later-stage costs
• Boosts user satisfaction
• Ensures business needs are met

3. Manual vs Automation Testing

4. STLC (Software Testing Life Cycle)

1. Requirement Analysis – Understand what to test
2. Test Planning – Define scope, strategy, budget
3. Test Case Design – Write test cases + expected results
4. Test Environment Setup – Prepare test system
5. Test Execution – Run tests, log bugs
6. Test Closure – Analyze results, prepare summary

5. Types of Testing

Functional Testing ("What system does")

• Unit Testing – Test individual functions
• Integration Testing – Test data flow between modules
• System Testing – End-to-end system test
• UAT (User Acceptance Testing) – Tested by end users

Non-Functional Testing ("How system performs")

• Performance Testing – Speed under load
• Security Testing – Prevent unauthorized access
• Usability Testing – Ease of use
• Compatibility Testing – Across devices/OS/browsers

Other Testing Types

• Regression – Check if updates break anything
• Smoke – Basic app functionalities
• Sanity – Quick check after a small fix
• Ad-hoc – Random testing without test cases

6. Common Testing Terms

7. Why Automation Testing?

• Saves time on repetitive tests
• Useful for large apps
• Ensures consistency & accuracy

Popular Tools

When to Use

• Manual: UI, Exploratory
• Automation: Regression, Performance

8. Interview Questions Quick Review