software eng

1. 1
Software Engineering
The term is made of two words, software and engineering.
“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.
“Engineering” on the other hand, is all about developing products, using
well-defined, scientific principles and methods.

2. 2

3. 3
Well defined Definition : Software engineering is an engineering branch
associated with development of software product using well-defined scientific
principles, methods and procedures.
Note : The outcome of software engineering is an efficient and reliable
software product.
THE EVOLVING ROLE OF SOFTWARE
1.Today, software takes on a dual role. It is a product and, at the same time,
the vehicle for delivering a product.
2. As a product, it delivers the computing potential embodied by computer
hardware or, more broadly, a network of computers that are accessible by
local hardware. Whether it resides within a cellular phone or operates inside
a mainframe computer,
3. software is an information transformer—producing, managing, acquiring,
modifying, displaying, or transmitting information that can be as simple as a
single bit or as complex as a multimedia presentation.

4. 4
4. As the vehicle used to deliver the product, software acts as the basis for
the control of the computer (operating systems), the communication of
information (networks), and the creation and control of other programs
(software tools and environments).
5.Software transforms personal data (e.g., an individual’s financial
transactions) so that the data can be more useful in a local context; it
manages business information to enhance competitiveness; it provides a
gateway to worldwide information networks (e.g., Internet) and provides
the means for acquiring information in all of its forms.
6. The role of computer software has undergone significant change
over a time span of little more than 50 years. Dramatic improvements
in hardware performance, profound changes in computing architectures,
vast increases in memory and storage capacity, and a wide variety of
exotic input and output options have all precipitated more sophisticated
and complex computer-based systems.

5. 5
Note :
The lone programmer of an earlier era has been replaced by a team of
software specialists, each focusing on one part of the technology required
to deliver a complex application.
Importance of evolution
* Organizations have huge investments in their software systems - they are
critical business assets.
* To maintain the value of these assets to the business, they must be
changed and updated.
* The majority of the software budget in large companies is devoted to
changing and evolving existing software rather than developing new
software.

6. 6
A spiral model of development and evolution

7. 7
software characteristics
To gain an understanding of software it is important to examine the
characteristics of software that make it different from other things that
human build.
The Following are the few characteristics of Software
1. Software is engineered or developed, not manufactured in the
traditional sense.
2. Software does not wear out in the same sense as hardware

8. 8
3. In theory, software does not wear out at all
4. But what happens when changes are requested in the software
5. Most software is custom built, rather being assembled from
existing components

9. 9
What is software myth in software engineering?
* The development of software requires dedication and understanding on the
developers’ part.
* Many software problems arise due to myths that are formed during the initial
stages of software development. Unlike ancient folklore that often provides
valuable lessons, software myths propagate false beliefs and confusion in the
minds of management, users and developers.
* Managers, who own software development responsibility, are often under
strain and pressure to maintain a software budget, time constraints, improved
quality, and many other considerations.

10. 10
Management Myths
The members of an organization can acquire all-the
information, they require from a manual, which contains
standards, procedures, and principles;
Standards are often incomplete, in adaptable, and
outdated.
Developers are often unaware of all the established
standards.
Developers rarely follow all the known standards because
not all the standards tend to decrease the delivery time of
software while maintaining its quality.
If the project is behind schedule, increasing the number
of programmers can reduce the time gap.
Adding more manpower to the project, which is already
behind schedule, further delays the project.
New workers take longer to learn about the project as
compared to those already working on the project.
If the project is outsourced to a third party, the
management can relax and let the other firm develop
software for them.
Outsourcing software to a third party does not help the
organization, which is incompetent in managing and
controlling the software project internally. The
organization invariably suffers when it out sources the
software project.

11. 11
In most cases, users tend to believe myths about the software because software managers and developers do not try to
correct the false beliefs. These myths lead to false expectations and ultimately develop dissatisfaction among the users.
Common user myths are listed in the below.
User Myths :
Brief requirement stated in the initial process is
enough to start development; detailed requirements
can be added at the later stages.
Starting development with incomplete and ambiguous
requirements often lead to software failure. Instead, a
complete and formal description of requirements is essential
before starting development.
Adding requirements at a later stage often requires
repeating the entire development process.
Software is flexible; hence software requirement changes
can be added during any phase of the development
process.
Incorporating change requests earlier in the development
process costs lesser than those that occurs at later stages.
This is because incorporating changes later may require
redesigning and extra resources

12. 12
In the early days of software development, programming was viewed as an art, but now software development has
gradually become an engineering discipline. However, developers still believe in some myths-. Some of the common
developer myths are mentioned below.
Software development is considered complete when the
code is delivered.
50% to 70% of all the efforts are expended after the software is
delivered to the user.
The success of a software project depends on the quality of
the product produced.
The quality of programs is not the only factor that makes the
project successful instead the documentation and software
configuration also play a crucial role.
Software engineering requires unnecessary documentation,
which slows down the project.
Software engineering is about creating quality at every level of
the software project. Proper documentation enhances quality
which results in reducing the amount of rework.
The only product that is delivered after the completion of a
project is the working program(s).
The deliverables of a successful project includes not only the
working program but also the documentation to guide the users
for using the software.
Software quality can be assessed only after the program is
executed.
The quality of software can be measured during any phase of
development process by applying some quality assurance
mechanism. One such mechanism is formal technical review
that can be effectively used during each phase of development
to uncover certain errors

13. 13
Software Crisis is a term used in the early days of computing science for
difficulty of writing useful and efficient computer programs in the required
time.
Causes of Software Crisis
* Project running over budget
* Project running over time
* Software was very inefficient
* Software was of low Quality
* Software often didn’t meet requirement
* Project were unmanageable and code difficult to maintain
* Software was never delivered
Important Note : Edsger Dijkstra's 1972 “Turing Award Lecture” makes
reference to this same problem: The major cause of the software crisis is
that the machines have become several orders of magnitude more
powerful. Software often did not meet requirements. Projects were
unmanageable and code difficult to maintain.

14. 14
By the end of the 1960s, hardware costs had fallen exponentially, and were
continuing to do so, while the cost of software development was rising at a
similar rate. (See below Figure)

15. 15

16. 16
Important Note : Solution of Software Crisis is Software Engineering
IEEE definition of software engineering is “the systematic application of
scientific and technological knowledge,methods, and experience to the
design, implementation, testing, and documentation of software”
* As a solution to software crisis , we must apply a disciplinary art; using
tools that help us manage this complexity.
* It is believed that the only satisfactory solution to the present software
crisis can possibly come from a spread of software engineering practices
among the engineers, coupled with further advancements to the software
engineering discipline itself.

17. 17
Software Development is a Layered Technology
Software development is totally a layered technology. Therefore, to develop
software one will have to go from one layer to another. The layers are
related and each layer demands the fulfilment of the previous layer.
Layers of Software Development
1. Quality Focus
2. Process
3. Methods
4. Tools

18. 18
Quality Focus
1. Software engineering must part of organizational commitment to
Quality.
2. Total quality management and similar philosophies foster a continuous
process improvement culture, and this culture ultimately leads to the
development of increasingly more mature approaches to software
engineering.
3. The bedrock that supports software engineering is a quality focus.

19. 19
Process
1. The foundation for software engineering is the process layer.
2. Process defines a framework for a set of Key Process Areas (KPAs) that
must be established for effective delivery of software engineering technology.
3. Consequently, this establishes the context in which technical methods are
applied, work products such as models, documents, data, reports, forms, etc.
are produced, milestones are established, quality is ensured, and change is
properly managed.

20. 20
Methods :
Software engineering methods provide the technical idea for building software.
Methods will include requirements analysis, design, program construction,
testing, and support.
This relies on a set of basic principles that govern each area of the technology
and include modelling activities and other descriptive techniques.
Tools :
Software engineering tools provide automated or semi-automated support for
the process and the methods.
When tools are integrated so that information created by one tool can be used
by another, a system for the support of software development, called computer-
aided software engineering is established.

21. 21
Software process
Software Process is a set of required activities and the outcome of the activities with a target to produce a
software product.
A software process is a flowchart of developing a software product, which includes gathering requirements,
analysing those requirements, scheduling development phases, checking the developments, implementing
changes etc. and this can be till the delivery of the final software product.

22. 22
An SRS should have enough information for developers to complete
the software described. It not only lays out the description of the
software under development but also the purpose it will serve: what
the software is supposed to do and how it should perform.
SRS document typically includes these elements:
* The purpose of the software being developed
* An overall description of the software
* The functionality of the software or what it is supposed to do
* Performance of the software in a production situation
* Non-functional requirements
* External interfaces or how the software will interact with hardware or other
software it must connect to
* Design constraints or the limitations of the environment that the software
will run in

23. 23
Linear Sequential Model
* The waterfall model is a linear, sequential approach to the software
development life cycle (SDLC).
* It is popular in software engineering and product development.
* The waterfall model emphasizes a logical progression of steps. Similar to
the direction water flows over the edge of a drop, distinct endpoints or goals
are set for each phase of development and cannot be revisited after
completion.
The waterfall methodology is composed of seven non-overlapping stages

24. 24

25. 25
Requirements: Potential requirements, deadlines and guidelines for the
project are analysed and placed into a functional specification. This stage
handles the defining and planning of the project without mentioning specific
processes.
Analysis: The system specifications are analyzed to generate product models
and business logic that will guide production. This is also when financial and
technical resources are audited for feasibility.
Design: A design specification document is created to outline technical design
requirements such as programming language, hardware, data sources,
architecture and services.
Coding/Implementation: The source code is developed using the models,
logic and requirements designated in the prior stages. Typically, the system is
designed in smaller components, or units, before being implemented together.
Testing: This is when quality assurance, unit, system and beta tests take
place to report issues that may need to be resolved. This may cause a forced
repeat of the coding stage for debugging. If the system passes the tests, the
waterfall continues forward.

26. 26
Operation/Deployment: The product or application is deemed fully
functional and is deployed to a live environment.
Maintenance: Corrective, adaptive and perfective maintenance is carried
out indefinitely to improve, update and enhance the final product. This could
include releasing patch updates or releasing new versions.
Important Note :
The waterfall approach is ideal for projects that have specific
documentation, fixed requirements, ample resources, an established
timeline and well-understood technology.
Alternatives to the waterfall model include joint application development
(JAD), rapid application development (RAD), sync-and-stabilize, Agile
project management (APM) and the spiral model.

27. 27
Advantages of the waterfall model
* Is simple to understand, follow and arrange tasks.
* Clearly defines milestones and deadlines.
Disadvantages of the waterfall model
* Design is not adaptive; often when a defect is found, the entire process
needs to start over.
* Ignores the potential to receive mid-process user or client feedback and
make changes based on results.
* Delays testing until the end of the development life cycle.
* Not ideal for complex, high risk, ongoing or object-oriented projects

28. 28
Prototyping model
The prototyping model is a systems development method in which a prototype is built, tested and then reworked as
necessary until an acceptable outcome is achieved from which the complete system or product can be developed.
Purpose of Prototype Model :
A prototype is an early sample, model, or release of a product built to test a concept or process.
What is Prototype Model ?
Ans: Prototyping is an experimental process where design teams implement ideas into tangible forms from paper to
digital. Teams build prototypes of varying degrees of quality to capture design concepts and test on users. With
prototypes, you can refine and validate your designs so your brand can release the right products.

29. 29
Steps of Prototype Model :
1. Requirement Gathering and Analyst
2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product

30. 30
Advantage of Prototype Model
1. Reduce the risk of incorrect user requirement
2. Good where requirement are changing/uncommitted
3. Support early product marketing
4. Reduce Maintenance cost.
5. Errors can be detected much earlier as the system is made side by side.
Disadvantage of Prototype Model
1. Prototyping tools are expensive.
2. Special tools & techniques are required to build a prototype.
3. It is a time-consuming process.
4. Require extensive customer collaboration

31. 31
Spiral Model
The spiral model is a systems development lifecycle (SDLC) method used
for risk management that combines the iterative development process
model with elements of the Waterfall model.
The spiral model is used by software engineers and is favored for
large, expensive and complicated projects.
1. The new system requirements are
defined in as much detail as possible.
2.A preliminary design is created for the
new system.
3. A first prototype of the new system is
constructed from the preliminary design.
4. Second prototype build based on
previous one with addition of new
requirements.
5.The entire project can be aborted if the
risk is deemed too great. Risk factors
might involve development cost overruns,
operating-cost miscalculation and other
factors that could result in a less-than-
satisfactory final product.

32. 32
1. The spiral model looks like a coil with many loops.
2. The number of loops varies based on each project and is often
designated by the project manager.
3. Each loop of the spiral is a phase in the software development
Process.
4. The spiral model enables gradual releases and refinement of a
product through each phase of the spiral as well as the ability to build
prototypes at each phase.
5. The most important feature of the model is its ability to manage
unknown risks after the project has commenced; creating a prototype
makes this feasible.

33. 33
Uses of the spiral model
1. The spiral model is best used in large, expensive and complicated projects
2. Projects in which frequent releases are necessary
3. Projects in which changes may be required at any time
4. Long term projects that are not feasible due to altered economic priorities
5. Medium to high risk projects
6. Projects in which cost and risk analysis is important
7. Projects that would benefit from the creation of a prototype
8. Projects with unclear or complex requirements.
9. The Flexibility, Customer satisfaction and Risk handling are other benefits of
Spiral Model

34. 34
Important Note : The progressive nature of the model allows developers to
break a big project into smaller pieces and tackle one feature at a time,
ensuring nothing is missed. Furthermore, since the prototype building is done
progressively, the cost estimation of the whole project can sometimes be
easier.
Limitations :
1. High cost - The spiral model is expensive and, therefore, is not suitable for small
projects.
2. Dependence on risk analysis - Since successful completion of the project
depends on effective risk handling, then it is necessary for involved personnel to
have expertise in risk assessment.
3. Complexity - The spiral model is more complex than other SDLC options. For it to
operate efficiently, protocols must be followed closely. Furthermore, there is
increased documentation since the model involves intermediate phases.
4. Hard to manage time - Going into the project, the number of required phases is
often unknown, making time management almost impossible. Therefore, there is
always a risk for falling behind schedule or going over budget.

35. 35
RAD Model [Rapid Application Development]
* RAD Model or Rapid Application Development model is a software
development process based on prototyping without any specific planning.
* In RAD model, there is less attention paid to the planning and more priority
is given to the development tasks.
* It targets at developing software in a short span of time.
SDLC RAD modelling has following phases
1. Business Modelling
2. Data Modelling
3. Process Modelling
4. Application Generation
5. Testing and Turnover

36. 36
Business Modelling :
The business model for the product
under development is designed in terms
of flow of information and the distribution
of information between various business
channels.
Data Modelling :
The information gathered in the
Business Modelling phase is reviewed
and analysed to form sets of data
objects vital for the business.
The attributes of all data sets is identified
and defined. The relation between these
data objects are established and defined
in detail in relevance to the business
model.

37. 37
Process Modelling :
The data object sets defined in the Data Modelling phase are converted to
establish the business information flow needed to achieve specific business
objectives as per the business model.
The process model for any changes or enhancements to the data object
sets is defined in this phase.
Process descriptions for adding, deleting, retrieving or modifying a data
object are given.
Application Generation :
The actual system is built and coding is done by using automation tools to
convert process and data models into actual prototypes.

38. 38
Testing and Turnover :
The overall testing time is reduced in the RAD model as the prototypes are
independently tested during every iteration.
However, the data flow and the interfaces between all the components need to
be thoroughly tested with complete test coverage.
Since most of the programming components have already been tested, it
reduces the risk of any major issues.

39. 39
When to use RAD Methodology?
* When a system needs to be produced in a short span of time (2-3 months)
* When the requirements are known
* When the user will be involved all through the life cycle
* When technical risk is less
* When there is a necessity to create a system that can be modularized in 2-3
months of time
* When a budget is high enough to afford designers for modelling along with the
cost of automated tools for code generation

40. 40
Advantages and Disadvantages
Advantages Disadvantages
Flexible and adaptable to changes It can’t be used for smaller projects
It is useful when you have to reduce
the overall project risk
Not all application is compatible with
RAD
It is easier to transfer deliverables as
scripts, high-level abstractions and
intermediate codes are used
If developers are not committed to
delivering software on time, RAD
projects can fail
Due to prototyping in nature, there is
a possibility of lesser defects
Reduced scalability occurs because
a RAD developed application begins
as a prototype and evolves into a
finished application
With less people, productivity can be
increased in short time
Requires highly skilled designers or
developers