SYBCA Semester III

Software Engineering
Unit 1 – Introduction to Software Engineering
Prepared By
Dr. Shriprakash Soni
Contents of the Unit
Total 6 Lectures

1. Software and Software Engineering,

2. Evolution of Software, Software Characteristics,

3. Software Applications,

4. Software Myths,

5. Software Process,
6. Software Development Life Cycle (SDLC)
Meaning of Software Myths
✓ Software myths are false beliefs or misconceptions about software
development that can negatively affect a project's cost, quality, and
schedule.
✓ According to Roger S. Pressman, these myths are common among
customers, managers, and developers, and often lead to poor decisions
and project failures.
✓ Rajib Mall also emphasizes that successful software development
requires realistic planning, clear communication, and systematic
engineering practices.
Meaning of Software Myths
✓ In short, software myths are false beliefs that lead to project failure.
✓ Software myths are false beliefs held by managers, developers, and
customers that mislead projects.
Roger S. Pressman categorises software myths into:
1. Customer Myths
2. Management Myths
3. Practitioner (Developer) Myths
Reference: Roger S. Pressman, Software Engineering: A Practitioner's
Approach, 7th Edition
1. Customer Myths
Myth 1:
✓ “I only have a general idea. Developers can fill in the details later.”
✓ Reality:
A clear and complete understanding of the requirements is essential before
software development begins. If requirements are incomplete or unclear,
developers may build the wrong system, resulting in rework, increased costs, and
project delays.
Myth 2:
✓ “Changes are easy because software is flexible.”
✓ Reality:
Although software can be modified, changes made after design, coding, or testing
require significant effort. Late changes often affect multiple parts of the system,
increasing development time, cost, and testing effort.
1. Customer Myths
Corporate Example
 An e-commerce company decides to change its payment process after
the software has been fully tested. The developers must redesign the
user interface, update database tables, modify APIs, and repeat testing,
causing additional cost and delaying the software release.
 An API, or Application Programming Interface, is a set of rules and tools
that lets different software programs talk to each other. In an e-
commerce system, it allows the user interface to send payment data to
the database and payment bank.
2. Management Myths
Myth 1:
✓ “If the project is late, add more programmers.”
✓ Reality:
Adding more developers to a delayed project does not always solve the problem.
New team members require training and coordination, which increases
communication effort and may delay the project even further. This concept is
known as Brooks’s Law (It was coined by Fred Brooks in 1975).
✓ Corporate Example
A software company is developing a Mobile Banking Application for a bank. When the
project falls behind schedule, the project manager hires 10 additional developers during
the final development phase. The new developers require time to familiarise themselves
with the project, attend meetings, and become familiar with the existing code. Instead of
speeding up development, communication becomes more complex, integration issues
increase, and the project is delayed further. This is an example of Brooks's Law.
2. Management Myths
Myth 2:
✓ “Our standards book is enough.”
✓ Reality:
Having documented standards alone does not guarantee project success. Effective
software development also requires proper planning, continuous monitoring,
technical reviews, quality assurance, and active project management throughout the
software life cycle.
✓ Corporate Example
An IT company has a detailed Software Development Standards Manual, but project
managers do not conduct regular code reviews, quality audits, or progress meetings.
As a result, several software defects remain undetected until the final testing phase,
causing costly rework and delaying the product launch. This shows that standards
alone are not enough; active project management and quality assurance are equally
important.
3. Practitioners (Developer) Myths
Myth 1:
✓ “Once the program works, my job is finished.”
✓ Reality:
Developing working software is only one part of the software engineering process.
Developers must also perform testing, prepare documentation, fix defects, support
users, and maintain the software after it has been deployed.
✓ Corporate Example
A developer completes an Online Hospital Management System and hands it
over to the client without providing user documentation or post-deployment
support. After implementation, hospital staff face difficulties using several
features, and newly discovered bugs require immediate fixes. The developer must
continue maintaining and updating the software, showing that software
engineering continues even after the program is working.
3. Practitioners (Developer) Myths
Myth 2:
✓ “The only deliverable is working code.”
✓ Reality:
Working source code is important, but it is not the only deliverable of a software
project. Design documents, test reports, user manuals, deployment plans,
maintenance documents, and technical documentation are equally important for the
successful use and maintenance of the software.
✓ Corporate Example
A software company develops an ERP System for a manufacturing company and
delivers only the source code. Since there are no design documents, user manuals,
installation guides, or test reports, the client’s IT team struggles to install, maintain,
and upgrade the system. The company later spends additional time creating
documentation, demonstrating that successful software projects require much more
than just working code.
Examples of Myths

These examples relate to industries that you are familiar with

 Software Myths
[Link]
 Software Myths (Hindi)
[Link]
 Activity: “Myth Or Reality? – Corporate Software
Decision Challenge”
Scenario 1
A customer tells the software company: “I don’t know all my requirements now. Just start
developing the software. I’ll tell you the remaining features later.”
Students identify:
✓ Myth
✓ Reality
✓ Possible project impact
Scenario 2
A mobile banking application is running behind schedule.
The project manager says, “Let’s recruit 10 more programmers. The project will finish
faster.”
Students identify:
✓ Myth
✓ Reality
✓ Name of the software engineering principle involved
 Activity: “Myth Or Reality? – Corporate Software
Decision Challenge”
Scenario 3
A developer completes coding and says:
“The software is working perfectly. My job is finished.”
Students identify:
✓ Myth
✓ Reality
✓ Remaining software engineering activities
Scenario 4
An ERP software company delivers only the source code to the client without any
user manuals or documentation.
Students identify:
✓ Myth
✓ Reality
✓ Problems the client may face
 Activity: “Myth Or Reality? – Corporate Software
Decision Challenge”
Scenario Myth Category Correct Reality
Customer gives incomplete Customer Myth Complete requirements are
requirements necessary before
development begins.
Add more programmers to Management More developers may
a late project Myth increase communication
overhead (Brooks’s Law).
Developer says job is Practitioner Myth Testing, documentation,
finished after coding maintenance, and support
are still required.
MCQs

[Link]