Software
Computer software is the product
that software professionals build
and then support over the long
term. It encompasses programs that execute
within a computer of any size and architecture



Software is developed or engineered: it is
not manufactured in the classical sense.
Software doesn’t “wear out.”
most software continues to be custom
built, The reusable components have
been created so that the engineer can
concentrate on the truly innovative
elements of a design
Software Application Domains
System software - a collection of
programs written to service other
programs. Some system software (e.g., compilers,
editors, and file management utilities) processes
complex, but determinate, information structures.
Other systems applications (e.g., operating system
components, drivers, networking software,
telecommunications processors) process largely
indeterminate data.
Application software - stand-alone
programs that solve a specific business
need. Applications in this area process
business or technical data in a way that facilitates
business operations or management/technical
decision making.
Engineering/scientific software - has
been characterized by “number
crunching” algorithms. Applications
range from astronomy to volcanology, from
automotive stress analysis to space shuttle orbital
dynamics, and from molecular biology to
automated manufacturing.
Embedded software - resides within
a product or system and is used to
implement and control features and
functions for the end user and for the system itself.
Product-line software—designed to provide a
specific capability for use by many different
customers.
Web applications - called
“WebApps,” this network-centric
software category spans a wide
array of applications. In their
simplest form, WebApps can be little more than a
set of linked hypertext files that present
information using text and limited graphics.
Artificial intelligence software makes use of nonnumerical
algorithms to solve complex
problems that are not amenable to
computation or straightforward
analysis. Applications within this area include
robotics, expert systems, pattern recognition
(image and voice), artificial neural networks,
theorem proving, and game playing.
History
1945-1965: The Beginning


The term software engineering first
appeared in the late 1950s and early
1960s.
Programmers have always known about
civil, electrical, and computer engineering
and debated what engineering might
mean for software.
1965-1985: The Software Crisis




Some used the term software crisis to
refer to their inability to hire enough
qualified programmers
Cost and Budget Overruns: OS/360 was
one of the first large (1000 programmers)
software projects.
Property Damage: Software defects, Poor
software security allows hackers to steal
identities, costing time, money, and
reputations.
Life and Death: Some embedded systems
used in radiotherapy machines failed so
catastrophically that they administered
lethal doses of radiation to patients
1985-1989: Silver Bullets
To solve the software crisis





Tools: Especially emphasized were tools:
structured programming, object-oriented
programming, CASE tools, Ada,
documentation, and standards were
touted as silver bullets.
Discipline: Some pundits argued that the
software crisis was due to the lack of
discipline of programmers.
Formal methods: Some believed that if
formal engineering methodologies would
be applied to software development, then
production of software would become as
predictable an industry as other branches
of engineering. They advocated proving all
programs correct.
Process: Many advocated the use of
defined processes and methodologies like
the Capability Maturity Model. •
Professionalism: This led to work on a
code of ethics, licenses, and
professionalism
1990-1999: The Internet
Running on the HTML language
2000-Present: Lightweight Methodologies
The need for inexpensive software solutions led to
the growth of simpler, faster methodologies that
developed running software, from requirements to
deployment, quicker & easier. The use of rapidprototyping evolved to entire lightweight
methodologies, such as Extreme Programming
(XP), which attempted to simplify many areas of
software engineering, including requirements
gathering and reliability testing for the growing,
vast number of small software systems.
Software requirement analysis simply means
complete study, analyzing, describing software
requirements so that requirements that are
genuine and needed can be fulfilled to solve
problem.
ACTIVITIES INVOLVE IN ANALYZING SOFTWARE
REQUIREMENTS
1.
Problem Recognition
The main aim of requirement analysis is to fully
understand main objective of requirement that
includes why it is needed, does it add value to
product, will it be beneficial, does it increase
quality of the project, does it will have any other
effect. All these points are fully recognized in
problem recognition so that requirements that are
essential can be fulfilled to solve business
problems.
2.
Evaluation and Synthesis
Evaluation means judgement about something
whether it is worth or not and synthesis means to
create or form something. Here are some tasks are
given that is important in the evaluation and
synthesis of software requirement:
•

•
•
To define all functions of software that
necessary.
To define all data objects that are present
externally and are easily observable. To
evaluate that flow of data is worth or not.
To fully understand overall behavior of
system that means overall working of
system. • To identify and discover
constraints that are designed.
To define and establish character of
system interface to fully understand how
system interacts with two or more
components or with one another.
3. Modeling
Software requirement means requirement that is
needed by software to increase quality of software
product.
After complete gathering of information
from above tasks, functional and
behavioral models are established after
checking function and behavior of system
using a domain model that also known as
the conceptual model.
4. Specification:
•
Problem of Scope: The
requirements given are of
unnecessary detail, ill-defined,
or not possible to implement.
•
Problem of Understanding:
Not having a clear-cut
understanding between the
developer and customer when
putting out the requirements
needed. Sometimes the
customer might not know
what they want or the
developer might
misunderstand one
requirement for another.
•
Problem of Volatility:
Requirements changing over
time can cause difficulty in
leading a project. It can lead
to loss and wastage of
resources and time.
The software requirement specification
(SRS) which means to specify the
requirement whether it is functional or
non-functional should be developed.
5. Review:
After developing the SRS, it must be
reviewed to check whether it can be
improved or not and must be refined to
make it better and increase the quality.
Requirements Engineering Tasks:
The software requirements engineering
process includes the following steps of
activities:
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Requirements Management
1. Inception
•
•
•
•
This phase gives an outline of how to get
started on a project. In the inception
phase, all the basic questions are asked on
how to go about a task or the steps
required to accomplish a task.
Understanding of the problem.
The people who want a solution.
Nature of the solution.
Communication and collaboration
between the customer and developer
2. Elicitation
This phase focuses on gathering the
requirements from the stakeholders.
Understanding the kind of requirements
needed from the customer is very crucial
for a developer. The right people must be
involved in this phase.
The following problems can occur in the
elicitation phase:
3. Elaboration
require analysis process
result of the inception and elicitation
phase
The main task in this phase is to
indulge in modeling activities and
develop a prototype that elaborates
on the features and constraints using
the necessary tools and functions.
4. Negotiation
Negotiation is between the developer and
the customer and they dwell on how to go
about the project with limited business
resources. Customers are asked to
prioritize the requirements and make
guesstimates on the conflicts that may
arise along with it.
The following are discussed in the
negotiation phase:
• Availability of Resources.
• Delivery Time.
•
•
•
Scope of requirements.
Project Cost.
Estimations on development.
5. Specification
This final working product will be the basis
of any functions, features or constraints
to be observed. The models used in this
phase include ER (Entity Relationship)
diagrams, DFD (Data Flow Diagram), FDD
(Function Decomposition Diagrams), and
Data Dictionaries.
A software specification document is
submitted to the customer in a language
that he/she will understand, to give a
glimpse of the working model
6. Validation
Known as the formal technical review.
This phase focuses on checking for errors
and debugging.
Developer scans the specification
document and checks for the following:
• All the requirements have been stated
and met correctly
• Errors have been debugged and
corrected.
• Work product is built according to the
standards.
Validation techniques are the following:
• Requirements reviews/inspections. •
Prototyping.
• Test-case generation.
• Automated consistency analysis.
7. Requirements Management
A set of activities where the entire team
takes part in identifying, controlling,
tracking, and establishing the
requirements for the successful and
smooth implementation of the project.
The working model will be analyzed
carefully and ready to be delivered to the
customer.