SOFTWARE ENGINEERING

UNIT 2

Software Applications, Myths.

Software Engineering: Generic View.

Software Applications
Software is used in many fields to solve problems and
automate tasks. There are different types of software
applications based on their purpose and usage.
Types of Software Applications

Type Description Examples

●​ Manages hardware and basic system

System functions. Windows, Linux,
Software ●​ Runs in the background and supports macOS
other applications.

●​ Designed for end-users to complete

specific tasks. MS Word,
Application
●​ Used in offices, homes, and Photoshop,
Software
businesses Chrome

●​ Helps organizations manage

Business operations, finance, and customer Tally, SAP,
Software relations. QuickBooks

Engineering
Used for simulations, calculations, and MATLAB,
& Scientific
research. AutoCAD, SPSS
Software

1
SOFTWARE ENGINEERING

●​ Controls devices and appliances. Software in smart

Embedded
●​ Found in cars, medical equipment, TVs, medical
Software
ATMs, and smart devices. devices

●​ Runs on browsers without

Web-Based installation. Gmail, Facebook,
Software ●​ Used for communication, social Google Docs
networking, and collaboration.

Chatbots, Virtual
Assistants (Siri,
Artificial
Mimics human intelligence and automates Alexa)
Intelligence
tasks.
Software

Software Myths
There are several misconceptions about software development
that can cause problems in projects.

Software Myths:

Pressman (1997) describes a number of common beliefs or myths that

software managers, customers, and developers believe falsely. He describes
these myths as
``misleading attitudes that have caused serious problems.'' We look at these
myths to see why they are false, and why they lead to trouble.

2
SOFTWARE ENGINEERING

Three Types Of Software Myths

1.​ Management Myths

2.​ Customer Myths
3.​ Practitioners Myth

Management Myth
Myth 1: Manuals will have simple procedures, principles, and standards
that are required for developers to enquire about every piece of
information as they are necessary for software development.

Reality 1: Whereas, standards that are scripted in modules can be

outdated, inadaptable, and incomplete. Hence, developers are not aware
of every standard mentioned in the manual as it can reduce the delivery
time and enhance the quality.

3
SOFTWARE ENGINEERING

Myth 2: In the world of software development, there’s a popular belief

that if a project is running late, just adding more programmers to the
team will magically speed things up.

Reality 2: However, adding more people to delayed projects can

increase the issues. Hence, developers who work on projects have to
teach newcomers and this may delay the project. Also,
the newcomers are much less productive compared to the developers.
Therefore, they find it difficult to meet the deadline due to the extra time
spent on newcomers.

Myth 3: Outsourcing a project to a third party is helpful, but we can’t just

sit back and relax. We need to stay involved, communicate clearly, and
provide feedback to make sure the project goes well. Active engagement
is key to outsourcing success!
Reality 3: If a company can’t handle software projects well on its own, it
will still face problems when it outsources the project to others. The
issues they have internally can still affect the outsourced project, causing
trouble for the company.

Customer Myth
Customer myth occurs due to false expectations by customers and this
can lead customers to become dissatisfied with software developers.
Some of the customer myths are the following:
Myth 1: Not solely relying on specific requirements,
If software goals are unclear or vaguely defined, programming can still
begin.
🔹 Developers might start coding without a detailed plan, believing they
can adjust later.
🔹 However, this is a misconception (a software myth) because unclear
goals lead to errors, rework, and project failure..

4
SOFTWARE ENGINEERING

Reality 1: In the realm of software development, if the objectives set for

the software are ambiguous and lacking clarity, it is almost certain that
the end product will fail to meet the customer’s expectations. Launching
into software development without a complete and well- defined picture
in mind often leads to disastrous results and disappointment for both the
customers and developers involved.

Myth 2: Software is flexible, and developers can easily make changes to

accommodate newrequirements as they come up during development.
They can adapt quickly to meet the project’s needs.

Reality 2: As software development progresses over time, it becomes

increasingly challenging to accommodate changes. Making alterations at
later stages of development results in additional costs due to the need for
redesigning and requiring extra resources. The longer the project goes
on, the more significant the impact of changes on the overall process and
budget.

Practitioner Myth
Developers often have to work under pressure from their managers to
finish software projects quickly and with limited resources. Sometimes,
they believe in certain software myths that can impact how they
approach their work. Here are some common myths that practitioners
may fall for:
Myth 1: There is a misconception that once the software is developed or
the code is delivered to the customer, the developer’s job is finished.
However, the reality is that software development is an ongoing process
that involves maintenance, updates, bug fixes, and support even after
the initial delivery. Developers play a crucial role in ensuring the software
continues to function
properly and meets the customer’s evolving needs over time.
Reality 1: A substantial portion, approximately 50-60%, of developers’
efforts, is dedicated to post- delivery tasks once the software is provided

5
SOFTWARE ENGINEERING

to the customer. During this phase, developers encounter major missing

requirements, discover new bugs, and encounter various challenges.
Developers need to address these issues diligently, make necessary
updates, and ensure the software remains functional and up to the
customer’s expectations. This post-delivery phase is critical in the software
development process to ensure customer satisfaction and overall success.

Myth 2: Software testing becomes feasible only when the software

program is in operation and running. In essence, testing can only occur
when the software is actively functioning and performing its intended
tasks. Before this stage, comprehensive testing cannot take place, and
the software’s reliability and performance cannot be thoroughly
evaluated.

Reality 2: At any point during software development, the quality of the software
can be evaluated by applying a QA mechanism. Quality Assurance techniques
allow developers to measure the software’s performance and identify potential
issues, ensuring that the final product meets the desired standards. By
implementing QA processes throughout the development lifecycle, developers
can ensure that the software is of high quality and meets the expectations of the
end users.

Myth 3: An overflow of unnecessary documentation can act as a

roadblock to software development. When developers are burdened with
excessive paperwork, it diverts their attention from actual coding and
problem-solving tasks. Striking the right balance and focusing on
essential information in documentation can streamline the development
process, enabling developers to work more efficiently and effectively.

Reality 3: An overflow of unnecessary documentation can act as a

roadblock to software development. When developers are burdened
with excessive paperwork, it diverts their attention from actual coding
and problem-solving tasks. Striking the right balance and focusing on
essential information in documentation can streamline the

6
SOFTWARE ENGINEERING

development process, enabling developers to work more efficiently

and effectively.

Software Engineering: Generic View

The work associated with software engineering can be categorized into

three generic phases, regardless of application area, project size, or
complexity. Each phase addresses one or more of the questions noted
here.

1.​ Definition Phases:

The definition phase focuses on what.

That is, during definition, the software engineer attempts to identify

●​ what information is to be processed,

●​ what function and performance are desired,

7
SOFTWARE ENGINEERING

●​ what system behavior can be expected,

●​ what interfaces are to be established,
●​ what design constraints exist, and
●​ what validation criteria are required to define a successful
system.

The key requirements of the system and the software are identified.
Although the methods applied during the definition phase will vary
depending on the software engineering paradigm (or combination of
paradigms) that is applied, three major tasks will occur in some form:
system or information engineering, software project planning, and
requirements analysis.

2.​ Development Phase :

The development phase focuses on how.

That is, during development a software engineer attempts to define

●​ how data are to be structured,

●​ how function is to be implemented within a software architecture,
●​ how procedural details are to be implemented,
●​ how interfaces are to be characterized,
●​ how the design will be translated into a programming language (or
nonprocedural language), and
●​ how testing will be performed.

The methods applied during the development phase will vary, but three
specific technical tasks should always occur: software design, code
generation,and software testing.

3.​ Support Phase:

The support phase focuses on change associated with error correction,

adaptations required as the software's environment evolves, and
changes due to enhancements brought about by changing customer
requirements.

8
SOFTWARE ENGINEERING

The support phase reapplies the steps of the definition and development
phases but does so in the context of existing software.
Four types of change are encountered during the support phase:

a.​ Correction. Even with the best quality assurance activities, it is likely
that the customer will uncover defects in the software. Corrective
maintenance changes the software to correct defects.
b.​ Adaptation. Over time, the original environment (e.g., CPU,
operating system, business rules, external product characteristics) for
which the software was developed is likely to change. Adaptive
maintenance results in modification to the software to accommodate
changes to its external environment.
c.​ Enhancement. As software is used, the customer/user will recognize
additional functions that will provide benefit. Perfective maintenance
extends the software beyond its original functional requirements.
d.​ Prevention. Computer software deteriorates due to change, and
because of this, preventive maintenance, often called software
reengineering, must be conducted to enable the software to serve the
needs of its end users. In essence, preventive maintenance makes
changes to computer programs so that they can be more easily
corrected, adapted, and enhanced.