Software Crisis

Software Crisis refers to the challenges and problems faced during the development, maintenance,
and management of software systems, especially as the complexity and scale of software projects
grew. This term was first used in the 1960s when software projects frequently failed to meet
deadlines, budgets, or performance expectations.

Causes of Software Crisis

1. Increasing Complexity: Software systems became more complex, making them harder to
design, develop, and maintain.

2. Lack of Proper Planning: Inadequate project planning and unrealistic deadlines led to
project failures.

3. Inadequate Requirements Gathering: Poor understanding of client requirements resulted in

4. Rapid Technology Changes: The fast evolution of technology made existing knowledge and
skills obsolete quickly.

5. Poor Design Practices: Inexperienced developers and lack of standard design practices led to
poorly structured code.

6. Insufficient Testing: Limited testing resulted in bugs and errors in the final product.

7. Lack of Skilled Professionals: Shortage of trained software engineers affected project

Solutions to Software Crisis

1. Adopting Software Engineering Practices: Following systematic and disciplined approaches

2. Proper Project Management: Utilizing techniques like Agile, Scrum, or Waterfall models for
better project control.

3. Effective Requirement Analysis: Ensuring clear and complete understanding of user

4. Design Patterns and Architecture: Using standard design patterns and maintaining clear
architecture.

5. Code Quality Standards: Implementing best practices like code reviews, pair programming,
and clean code principles.

6. Thorough Testing: Conducting rigorous testing, including unit, integration, and system
testing.

7. Continuous Skill Improvement: Regular training of software professionals in new

Would you like me to give you a very concise one-page note for your exam in a well-organized
format?

Let me know. 🙂
You said:

yes please

ChatGPT said:

Software Crisis - Exam Notes

Software Crisis - Exam Notes

Definition:

Software Crisis refers to the set of problems encountered during the development, maintenance,
and management of software systems, particularly due to their increasing complexity and size.

Causes of Software Crisis:

1. Increasing Complexity: Complex software systems are difficult to manage.

2. Lack of Proper Planning: Poor project management and unrealistic timelines.

3. Inadequate Requirements Gathering: Misunderstanding of user requirements.

4. Rapid Technology Changes: Fast-evolving technology making existing skills obsolete.

5. Poor Design Practices: Use of inefficient or unstructured coding techniques.

6. Insufficient Testing: Lack of proper testing leads to buggy software.

7. Lack of Skilled Professionals: Shortage of experienced software engineers.

Solutions to Software Crisis:

1. Software Engineering Practices: Implementing systematic software development

2. Effective Project Management: Using Agile, Scrum, or Waterfall models.

3. Clear Requirement Analysis: Ensuring a complete understanding of user needs.

4. Standard Design Practices: Adopting design patterns and proper architecture.

5. Code Quality Standards: Using code reviews, pair programming, and clean code principles.

6. Comprehensive Testing: Conducting unit, integration, and system testing.

7. Continuous Skill Development: Regular training of software professionals.

Key Points to Remember:

 Software Crisis is primarily caused by mismanagement, complexity, and lack of standard

 The best solution is adopting software engineering principles and continuous improvement.

I have created a well-organized one-page note on "Software Crisis" for your exam.

You can review it here:

Let me know if you want any improvements. 🙂

You said:

Explain SDLC. Also discuss various activities during SDLC.what is the need of sdlc

ChatGPT said:

Software Development Life Cycle (SDLC)

SDLC (Software Development Life Cycle) is a systematic process used for designing, developing,
testing, and deploying software systems. It provides a structured approach to ensure software
quality, cost control, and project management.

Phases of SDLC and their Activities

1. Requirement Gathering and Analysis:

o Collecting and analyzing user requirements.

o Documenting requirements (Software Requirement Specification - SRS).

o Validating requirements with stakeholders.

2. System Design:

o Designing the architecture of the software (High-level design).

o Creating detailed design (Low-level design) for each module.

o Selecting technology stack and tools.

3. Implementation (Coding):

o Writing code as per design specifications.

o Dividing the project into modules and assigning them to developers.

o Adhering to coding standards and best practices.

4. Testing:

o Performing various tests (Unit testing, Integration testing, System testing, User
Acceptance Testing).

o Identifying and fixing bugs.

o Ensuring the software meets the requirements.

5. Deployment:

o Releasing the software to the production environment.

o Setting up user environments and configurations.

o Providing initial training and user documentation.

o Monitoring software performance.

o Fixing any bugs or errors reported.

o Upgrading software with new features or enhancements.

Need for SDLC

 Structured Approach: Ensures a systematic and step-by-step process for software

 Quality Control: Provides a framework to maintain quality at every stage.

 Risk Management: Identifies and mitigates risks early in the process.

 Cost Management: Helps in estimating costs and maintaining the budget.

 Timely Delivery: Provides clear milestones and timelines for project completion.

 Continuous Improvement: Allows feedback and updates to enhance software over time.

Software Engineering as Layered Technology

Software Engineering is considered a layered technology because it is built on a solid foundation

Four Layers of Software Engineering:

1. Quality Focus (Foundation Layer):

o Ensures the quality of the software product.

o Involves setting standards, quality assurance, and continuous improvement.

o Techniques: Code reviews, testing, and quality metrics.

2. Process Layer:

o Defines the software development process and workflow.

o Provides a framework for planning, monitoring, and controlling projects.

o Examples: Agile, Waterfall, Spiral, and V-Model.

3. Methods Layer:
 o Specifies the techniques and practices used for software analysis, design, coding,
testing, and maintenance.

o Examples: Object-oriented design, Data flow diagrams, UML diagrams.

4. Tools Layer:

o Provides automated or semi-automated support for software development.

o Includes IDEs, code editors, testing tools, version control systems, and project
management tools.

o Examples: Visual Studio Code, Git, JIRA, Selenium.

Why Software Engineering is Layered Technology:

 Organized Approach: It allows a systematic approach by categorizing activities.

 Quality Control: Each layer contributes to ensuring high-quality software.

 Flexibility: Changes in one layer (like switching methods) do not directly impact others.

 Enhanced Management: Processes and tools ensure efficient project management.

Diagram:

lua

CopyEdit

+--------------------+

| Tools |

+--------------------+

| Methods |

+--------------------+

| Process |

+--------------------+

| Quality Focus |

+--------------------+
1. TESTING SHOWS THE PRESENCE OF BUGS

Testing an application can only reveal that one or more defects exist in the application,

however, testing alone cannot prove that the application is error free. Therefore, it is

important to design test cases which find as many defects as possible.

2. EXHAUSTIVE TESTING IS IMPOSSIBLE

Unless the application under test has a very simple logical structure and limited input, it

is not possible to test all possible combinations of data and scenarios. For this reason, risk

and priorities are used to concentrate on the most important aspects to test.

3. EARLY TESTING

The sooner we start the testing activities the better we can utilize the available time. As

soon as the initial products, such the requirement or design documents are available, we

can start testing. It is common for the testing phase to get squeezed at the end of the

development lifecycle, i.e. when development has finished, so by starting testing early, we

can prepare testing for each level of the development lifecycle.

Another important point about early testing is that when defects are found earlier in the

lifecycle, they are much easier and cheaper to fix. It is much cheaper to change an

incorrect requirement than having to change a functionality in a large system that is not

working as requested or as designed!

4. DEFECT CLUSTERING

During testing, it can be observed that most of the reported defects are related to small number

of modules within a system. i.e. small number of modules contain most of the defects in the

system. This is the application of the Pareto Principle to software testing: approximately 80% of

the problems are found in 20% of the modules.

5. THE PESTICIDE PARADOX

If you keep running the same set of tests over and over again, chances are no more new defects

will be discovered by those test cases. Because as the system evolves, many of the previously

reported defects will have been fixed and the old test cases do not apply anymore. Anytime a

fault is fixed or a new functionality added, we need to do regression testing to make sure the new

changed software has not broken any other part of the software. However, those regression test

cases also need to change to reflect the changes made in the software to be applicable and
hopefully fine new defects.

6. TESTING IS CONTEXT DEPENDENT

Different methodologies, techniques and types of testing is related to the type and nature of the

application. For example, a software application in a medical device needs more testing than a

games software. More importantly a medical device software requires risk based testing, be

compliant with medical industry regulators and possibly specific test design techniques. By the

same token, a very popular website, needs to go through rigorous performance testing as well as

functionality testing to make sure the performance is not affected by the load on the servers.

7. ABSENCE OF ERRORS FALLACY

Just because testing didn’t find any defects in the software, it doesn’t mean that the software is

ready to be shipped. Were the executed tests really designed to catch the most defects? or where

they designed to see if the software matched the user’s requirements? There are many other

factors to be considered before making a decision to ship the software.

If the system built is unusable and does not fulfil the user’s needs and expectations then finding and

fixing defects does not help.

Other principles to note are:

Testing must be done by an independent party.

Testing should not be performed by the person or team that

developed the software since they tend to defend the correctness

of the program.

Assign best personnel to the task.

the best personnel must be assigned to design, implement, and

analyze test cases, test data and test results.

Test for invalid and unexpected input conditions as well as valid

conditions.

The program should generate correct messages when an invalid

test is encountered and should generate correct results when the

test is valid.

Keep software static during test.

The program must not be modified during the implementation of

the set of designed test cases.

Provide expected test results if possible.

A necessary part of test documentation is the specification of

expected results, even if providing such results is impractical