includes all software process models , SRS , its properties , characterstics of a good software product , agile model , software engineering

2. WHAT IS SOFTWARE ENGINEERING?
Software engineering is an engineering branch associated with
development of software product using well-defined scientific
principles, methods and procedures. The outcome of software
engineering is an efficient and reliable software product.
Software is more than just a program code. A program is an executable
code, which serves some computational purpose. Software is
considered to be collection of executable programming code,
associated libraries and documentations. Software, when made for a
specific requirement is called software product.

5. Software Design
Paradigm
This paradigm
is a part of
Software
Development
and includes
–
Design
Maintenance
Programming
Software Development
Paradigm
This Paradigm is known as
software engineering
paradigms where all the
engineering concepts
pertaining to the
development of software
are applied. It includes
various researches and
requirement gathering
which helps the software
product to build. It consists
of –
Requirement gathering
Software design
Programming
Programming
Paradigm
This paradigm is
related closely to
programming aspect
of software
development. This
includes –
Coding
Testing
Integration

6. Characteristics of good software
A software product can be judged by what it offers and how well it can be used.
This software must satisfy on the following grounds:
Operational
Transitional
Maintenance
Well-engineered and crafted software is expected to have the following
characteristics:
Operational
This tells us how well
software works in
operations. It can be
measured on:
Budget
Usability
Efficiency
Correctness
Functionality
Dependability
Security
Safety
Transitional
This aspect is
important when the
software is moved
from one platform to
another:
Portability
Interoperability
Reusability
Adaptability
Maintenance
This aspect briefs
about how well a
software has the
capabilities to
maintain itself in the
ever-changing
environment:
Modularity
Maintainability
Flexibility
Scalability

7. Components of Software:
There are three components of the software:
Program:
A computer program is a list of instructions that tell a computer what to do.
Documentation:
Source information about the product contained in design documents, detailed
code comments, etc.
Operating Procedures:
Set of step-by-step instructions compiled by an organization to help workers
carry out complex routine operations.
There are four basic key process activities:
Software Specifications:
In this process, detailed description of a software system to be developed with its
functional and non-functional requirements.
Software Development:
In this process, designing, programming, documenting, testing, and bug fixing is done.
Software Validation:
In this process, evaluation software product is done to ensure that the software meets the
business requirements as well as the end users needs.
Software Evolution:
It is a process of developing software initially, then timely updating it for various reasons.

8. SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
A software life cycle model (also termed process model) is a pictorial and
diagrammatic representation of the software life cycle. A life cycle
model represents all the methods required to make a software product
transit through its life cycle stages. It also captures the structure in
which these methods are to be undertaken.
In other words, a life cycle model maps the various activities performed on
a software product from its inception to retirement. Different life cycle
models may plan the necessary development activities to phases in
different ways

9. WATERFALL MODEL

10. INCREMENTAL AND ITERATIVE MODEL

12. . AGILE MODEL
By breaking the product into cycles, the Agile model quickly delivers a
working product and is considered a very realistic development
approach. The model produces ongoing releases, each with small,
incremental changes from the previous release. At each iteration, the
product is tested.
This model emphasizes interaction, as the customers, developers and
testers work together throughout the project. But since this model
depends heavily on customer interaction, the project can head the
wrong way if the customer is not clear on the direction he or she wants
to go.

13. AGILE PRINCIPLES
The highest priority of this process is to satisfy the customer.
Acceptance of changing requirement even late in development.
Frequently deliver a working software in small time span.
Throughout the project business people and developers work together on
daily basis.
Projects are created around motivated people if they are given the proper
environment and support.
Face to face interaction is the most efficient method of moving
information in the development team.
Primary measure of progress is a working software.
Agile process helps in sustainable development.
Continuous attention to technical excellence and good design increases
agility.
From self organizing teams the best architecture, design and
requirements are emerged.

14. SRS
The output of the requirements phase of the software development process
is Software Requirements Specification (SRS) (also known as
requirements document).
This document lays a foundation for software engineering activities and is
created when entire requirements are elicited and analyzed.
SRS is a formal document, which acts as a representation of software that
enables the users to review whether it (SRS) is according to their
requirements.
In addition, it includes user requirements for a system as well as detailed
specifications of the system requirements.

15. VARIOUS OTHER PURPOSES SERVED BY SRS ARE
LISTED BELOW.
Feedback: Provides a feedback, which ensures to the user that the
organization (which develops the software) understands the issues or
problems to be solved and the software behavior necessary to
address those problems.
Decompose problem into components: Organizes the information and
divides the problem into its component parts in an orderly manner.
Validation: Uses validation strategies applied to the requirements to
acknowledge that requirements are stated properly.
Input to design: Contains sufficient detail in the functional system
requirements to devise a design solution.
Basis for agreement between the user and the organization: Provides a
complete description of the functions to be performed by the system.
In addition, it helps the users to determine whether the specified
requirements are accomplished.
Reduce the development effort: Enables developers to consider user
requirements before the designing of the system commences. As a
result, 'rework' and inconsistencies in the later stages can be reduced.
Estimating costs and schedules: Determines the requirements of the

16. Correct: SRS is correct when all user requirements
are stated in the requirements document. The
stated requirements should be according to the
desired system.. Correctness ensures that all
specified requirements are performed correctly.
Unambiguous: SRS is unambiguous when every
stated requirement has only one interpretation.
This implies that each requirement is uniquely
interpreted. In case there is a term used with
multiple meanings, the requirements document
should specify the meanings in the SRS so that it
is clear and easy to understand.
Complete: SRS is complete when the requirements
clearly define what the software is required to do.
This includes all the requirements related to
performance, design and functionality.

17. Ranked for importance/stability: All requirements are not equally
important, hence each requirement is identified to make
differences among other requirements. For this, it is essential
to clearly identify each requirement.
Modifiable: The requirements of the user can change, hence
requirements document should be created in such a manner
that those changes can be modified easily, consistently
maintaining the structure and style of the SRS.
Traceable: SRS is traceable when the source of each requirement
is clear and facilitates the reference of each requirement in
future.
Verifiable: SRS is verifiable when the specified requirements can
be verified with a cost-effective process to check whether the
final software meets those requirements.
Consistent: SRS is consistent when the subsets of individual
requirements defined do not conflict with each other. For
example, there can be a case when different requirements can
use different terms to refer to the same object. For instance, a
requirement states that an event 'a' is to occur before another
event 'b'. But then another set of requirements states (directly
or indirectly by transitivity) that event 'b' should occur before

18. REQUIREMENTS MODELING
Requirements modeling in software engineering identifies the requirements
that a software application or system must meet in order to solve the
business problem. Requirements are divided into functional (what the
system will have to do) and non-functional (constraints within which the
system will have to perform).

19. Thank You