0% found this document useful (0 votes)
38 views78 pages

SE Unit 1

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
38 views78 pages

SE Unit 1

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 78

Unit 1

Software
Engineering
Evolving Role of Software

• Due to
• Failure and over budget rates are High
• Success
• Cost of hardware and software is decreased by the time
• Manager and Technical Persons asked:
• Why are costs so high?
• Why can not we find all errors before release?
• Why do we have difficulty in measuring progress of software development?
Software Crisis: Problem encountered in the
development of software during 1960s.
1. Early software development was ‘personalized’.
2. As sophistication of application grew, programs grew in size
and complexity.
3. Maintenance became difficult.
4. Software projects were taking a lot longer than originally
calculated.
5. Software was costing a lot more to develop than initially
estimated.
6. Software was being delivered to the customer only to fail.
7. Error found by the customer were extremely difficult to
trace and fix.
Software
• It consists of programs, set of documentations and the procedures used to setup and
operate the software system
• Software = Programs + Documentation + Operating Procedures.

Programs

Documentation Operating
Procedures

Program is a subset of software.


Program = Source Code + Object Code
Documentation Manuals
Operating Procedures
Engineering

• Engineering is the processes of designing and building something that serves a


particular purpose and find a cost-effective solution to problems.
• Engineering is the science, skill, and profession of acquiring and applying
scientific, economic, social, and practical knowledge, in order to design and also
build structures, machines, devices, systems, materials and processes.
• Manufacturing is the production of goods for use or sale using labor and
machines, tools, chemical and biological processing, or formulation.
Software Engineering

• Software engineering is an engineering discipline which is concerned with


all aspects of software production
• Software engineers should
• adopt a systematic and organised approach to their work
• use appropriate tools and techniques depending on
• the problem to be solved,
• the development constraints and
• use the resources available
Software Engineering

According to IEEE -
The application of systematic, disciplined and quantifiable approach to the
development, operation, and maintenance of software; that is, the
application of engineering to software.
According to Boehm -
The practical application of scientific knowledge in the design and
construction of computer programs and the associated documentation
required to develop, operate, and maintain them.
Software Engineering

- Engineering uses methods, procedures, tools, and standards


- Methods give the different steps you have to take project planning and
estimation, Requirements analysis, Design, Algorithm development,
Coding, Testing, Maintenance.
- Tools provide automated support for the methods – CASE Tools, Coding
Tools, Testing Tools
- Procedure defines the sequence in which the methods are to be executed
Software Characteristics
1. Software does not wear out – Like hardware

Burn-In Wear Out Phase


Phase Useful Life Phase

Failure
Intensity

Time

Bathtub Curve
Software Characteristics
Software may be retired due to
environmental changes , new
requirements, new expectations

Failure
Intensity

Time

Software curve
Software Characteristics

2. Software is not manufactured – The life of a


software is from concept exploration to the
retirement of the software product. It is one time
development effort and continues maintenance effort
in order to keep it operational. However making 1000
copies is not an issue and it does not involve any cost.
In case of hardware products, every product costs us
due to raw material and other processing expenses.
Hence it is not manufactured in the classical sense.
Software Characteristics

3. Software is logical rather than physical.


4. Reusability of components.
5. Software is flexible.
6. Most software is custom built, rather than being assembled from
existing components.
Software Myths
Management Myths-
Myth – We already have a book that’s full of standards and procedures for
building software. Won’t that provide my people with everything they need to
know?
Reality – The very well exist,
• but is it used?
• Are the practitioners aware of its existence?
• Is it complete?
• Is it adaptable?
• In many cases the answer to all is no.
Software Myths
Myth – If we get behind schedule, we can add more programmers and catch up.
Reality – S/W development is not a mechanistic process like manufacturing.
• Adding people to a late s/w project makes it later .
• spend time educating the newcomers, there by reducing the amount of time spent on
productive development effort.
• People can be added but only in a planned and well coordinated manner.
Software Myths
Myth – If I decide to outsource the s/w project to a 3rd party, I can just relax
and let that firm build it.
Reality If an organization does not understand how to manage and control
software projects internally, it will invariably struggle when it outsource s/w
projects.
Software Myths
Customer myths –
Myth – A general statement of objectives is sufficient to begin writing
programs – we can fill in the details later.
• A formal and detailed description of the information domain, function,
behaviour, performance, interfaces, design constraints, and validation
criteria is essential.
• These characteristics can be determined only after thorough
communication between customer and developer.
Software Myths
Myth: Project requirements continually change, but change can be easily accommodated because
software is flexible.
• Reality: It is true that software requirements change, but the impact of change varies with the time at
which it is introduced.
• If serious attention is given to up-front definition, early requests for change can be accommodated
easily.
• The customer can review requirements and recommend modifications with relatively little impact on
cost.
• When changes are requested during software design, the cost impact grows rapidly. Resources have
been committed and a design framework has been established.
• Change can cause upheaval that requires additional resources and major design modification, that is,
additional cost.
• Changes in function, performance, interface, or other characteristics during implementation (code
and test) have a severe impact on cost.
• Change, when requested after software is in production, can be over an order of magnitude more
expensive than the same change requested earlier.
Software Myths
Practitioner’s Myth –
Myth – Once we write the program and get it to work, our job is done.
Reality – Someone once said that the sooner you begin writing code, the
longer it will take to get done.
• Industry data indicate that between 60 to 80% of all effort expended on
s/w will be expanded after it is delivered to the customer for the first
time.
Software Myths
Myth – Until I get the program running, I have no way of accessing its
quality
Reality - One of the most effective software quality assurance mechanisms
can be applied from the inception of a project—the formal technical review
Myth – The only deliverable work product for a successful project is the
working program.
Reality - working program is only one part of a software configuration that
includes many elements. Documentation provides a foundation for
successful engineering and, more important, guidance for software support.
Software Myths
Myth – SE will make us create voluminous and unnecessary documentation
and will invariably slows us down.
Reality – SE is not about creating documents. It is about crating quality.
Better quality leads to reduced rework. And reduced rework results in
faster delivery times.
Software Process
 (Webster) A system of operations in producing something; a series of actions, changes, or
functions that achieve an end or a result
 (IEEE) A sequence of steps performed for a given purpose
According to Pressman
 Software engineering process is the glue that holds the technology layers together and
enables rational and timely development of computer software.
 Process defines a framework for a set of key process areas that must be established for
effective delivery of software engineering technology.
 The key process areas form the basis for management control of software projects and
establish the context in which technical methods are applied, work product (models,
documents, data, reports, forms, etc.) are produced, milestones are established, quality
is ensured, and change is properly managed.
Software Process
• A common process framework is established by defining a small number of framework
activities that are applicable to all software projects, regardless of their size or
complexity.
• Several task sets—each a collection of software engineering
• work tasks,
• project milestones,
• work products, and
• quality assurance points—
• Enable the framework activities to be adapted to the characteristics of the software
project and the requirements of the project team.
• Umbrella activities—such as software quality assurance, software configuration
management, and measurement—overlap the process model. Umbrella activities are
independent of any one framework activity and occur throughout the process.
Difference between Software Engineering and
Traditional Engineering
 Software is intangible
 Software doesn’t degrade with time as hardware does. Software failures are
caused by design and implementation error, not by degradation over time
• In classical engineering disciplines, the engineer is equipped with tools and the
mathematical maturity to specify the properties of the product separately from
those of design. The typical software engineering relies much more on
experience and judgment rather than mathematical formula.
Difference between Software Engineering and
Traditional Engineering
Software quality
• Conformance to
• explicitly stated functional and

• performance requirements,

• explicitly documented development standards, and


• implicit characteristics

• that are expected of all professionally developed software.


McCall’s quality factors
• Two categories of software quality factors:
• Factors that can be directly measured (bugs or defects)
• Factors that can be measured only indirectly (usability or maintainability)
• Both sets can (and should) be measured
McCall’s quality factors
• McCall, Richards, and Walters group these factors into three
categories, focused on three aspects of a software product:
• Its operational characteristics
(PRODUCT OPERATION)
• Its ability to undergo change
(PRODUCT REVISION)
• Its adaptability to new environments
(PRODUCT TRANSITION)
McCall’s quality factors
Product Operation
• It includes five software quality factors, which are related with the
requirements that directly affect the operation of the software such as
operational performance, convenience, ease of usage and its correctness.
These factors help in providing a better user experience.
• Correctness:
• the extent to which a program satisfies its specifications and fulfills the customer’s
mission objectives
• Reliability:
• The extent to which a software performs its intended functions without failure.
• Usability:
• The extent of effort required to learn, operate and understand the functions of the
software.
Product Operation (cont.)
• Integrity:
• the extent to which access to software or data by unauthorized persons can
be controlled
• Efficiency:
• The amount of hardware resources and code the software, needs to perform
a function.
Product Revision
It includes three software quality factors, which are required for testing and
maintenance of the software. They provide ease of maintenance, flexibility
and testing effort to support the software to be functional according to the
needs and requirements of the user in the future.
• Maintainability:
• The effort required to detect and correct an error during maintenance phase.
• Flexibility:
• the effort required to modify an operational program
• Testability:
• The effort required to verify a software to ensure that it meets the specified
requirements.
Product Transition
• It includes three software quality factors, that allows the software to adapt
to the change of environments in the new platform or technology from the
previous.
• Portability:
• the effort required to transfer the program from one hardware and/or software
system to another
• Reusability:
• the extent to which a program (or parts or a program) can be reused in other
applications
• Interoperability:
• the effort required to couple one system to another
Activities undertaken during Requirement
Analysis and specification
• The aim of the requirements analysis and specification phase is to
understand the exact requirements of the customer and to document them
properly. This phase consists of two distinct activities, namely
i. Requirements gathering and analysis, and
ii. Requirements specification
• The goal of the requirements gathering activity is to collect all relevant
information from the customer regarding the product to be developed.
• This is done to clearly understand the customer requirements so that
incompleteness and inconsistencies are removed.
Activities undertaken during Requirement
Analysis and specification
• The requirements analysis activity is begun by collecting all relevant data
regarding the product to be developed from the users of the product and
from the customer through interviews and discussions.
• After all ambiguities, inconsistencies, and incompleteness have been
resolved and all the requirements properly understood, the requirements
specification activity can start. During this activity, the user requirements
are systematically organized into a Software Requirements Specification
(SRS) document.
Activities undertaken during Design
• The goal of the design phase is to transform the requirements specified in the
SRS document into a structure that is suitable for implementation in some
programming language.
• In technical terms, during the design phase the software architecture is derived
from the SRS document. Two distinctly different approaches are available: the
traditional design approach and the object-oriented design approach.
Activities undertaken during Coding and Unit
Testing
• The purpose of the coding and unit testing phase (sometimes called the
implementation phase) of software development is to translate the software
design into source code. Each component of the design is implemented as a
program module.
• The end-product of this phase is a set of program modules that have been
individually tested.
• During this phase, each module is unit tested to determine the correct working of
all the individual modules.
• It involves testing each module in isolation as this is the most efficient way to
debug the errors identified at this stage.
Activities undertaken during integration and
system testing
• Integration of different modules is undertaken once they have been coded and unit tested.
• During the integration and system testing phase, the modules are integrated in a planned
manner.
• The different modules making up a software product are almost never integrated in one
shot.
• Finally, when all the modules have been successfully integrated and tested, system
testing is carried out.
• The goal of system testing is to ensure that the developed system conforms to its
requirements laid out in the SRS document.
• System testing usually consists of three different kinds of testing activities:
• α – testing: It is the system testing performed by the development team.
• β – testing: It is the system testing performed by a friendly set of customers.
• acceptance testing: It is the system testing performed by the customer himself after
the product delivery to determine whether to accept or reject the delivered product.
Activities undertaken during Maintenance
• Maintenance involves performing any one or more of the following three kinds of
activities:
• Correcting errors that were not discovered during the product development phase.
This is called corrective maintenance.
• Improving the implementation of the system and enhancing the functionalities of the
system according to the customer’s requirements. This is called perfective
maintenance.
• Porting the software to work in a new environment. For example, porting may be
required to get the software to work on a new computer platform or with a new
operating system. This is called adaptive maintenance.
Waterfall Model Application
• Every software developed is different and requires a suitable SDLC approach to be
followed based on the internal and external factors. Some situations where the use
of Waterfall model is most appropriate are:

 Requirements are very well documented, clear and fixed.


 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.
Prototype Model
• The Prototyping model is suitable for projects, which either the customer requirements
or the technical solutions are not well understood.
• This risks must be identified before the project starts. This model is especially popular for
the development of the user interface part of the project.
• In this process model, the system is partially implemented before or during the analysis
phase thereby giving the customers an opportunity to see the product early in the life
cycle.
• The process starts by interviewing the customers and developing the incomplete high-
level paper model.
• This document is used to build the initial prototype supporting only the basic
functionality as desired by the customer.
• Once the customer figures out the problems, the prototype is further refined to
eliminate them. The process continues till the user approves the prototype and finds the
working model to be satisfactory.
Prototype Model
• This is a valuable mechanism for gaining better understanding of the
customer’s needs:
• how the screens might look like
• how the user interface would behave
• how the system would produce outputs
• The developer may be unsure of the efficiency of an algorithm, the
adaptability of an operating system, the form that the human-
machine interaction should take etc.
Build Prototype

Requirements Customer Evaluation ofCustomer satisfied


Gathering Prototype
Quick Design Design

Refine Requirements Implement

Test

Maintain
Prototype Model
 Basic Requirement Identification: This step involves understanding the very basics product
requirements especially in terms of user interface. The more intricate details of the internal
design and external aspects like performance and security can be ignored at this stage.
 Developing the initial Prototype: The initial Prototype is developed in this stage, where the very
basic requirements are show cased and user interfaces are provided. These features may not
exactly work in the same manner internally in the actual software developed and the
workarounds are used to give the same look and feel to the customer in the prototype
developed.
 Review of the Prototype: The prototype developed is then presented to the customer and the other
important stakeholders in the project. The feedback is collected in an organized manner and
used for further enhancements in the product under development.
Prototype Model
 Revise and enhance the Prototype: The feedback and the review comments are discussed during
this stage and some negotiations happen with the customer based on factors like, time and
budget constraints and technical feasibility of actual implementation. The changes accepted are
again incorporated in the new Prototype developed and the cycle repeats until customer
expectations are met.
Prototype Model: Advantages
• The customers get to see the partial product early in the life cycle. This ensures a greater
level of customer satisfaction and comfort.
• New requirements can be easily accommodated as there is scope for refinement.
• Missing functionalities can be easily figured out.
• Errors can be detected much earlier thereby saving a lot of effort and cost, besides
enhancing the quality of the software.
• The developed prototype can be reused by the developer for more complicated projects in
the future.
• Flexibility in design.
Prototype Model: Disadvantages
• Costly w.r.t time as well as money.
• There may be too much variation in requirements each time the prototype is
evaluated by the customer.
• Poor Documentation due to continuously changing customer requirements.
• It is very difficult for the developers to accommodate all the changes demanded
by the customer.
• There is uncertainty in determining the number of iterations that would be
required before the prototype is finally accepted by the customer.
• After seeing an early prototype, the customers sometimes demand the actual
product to be delivered soon.
• Developers in a hurry to build prototypes may end up with sub-optimal solutions.
• The customer might lose interest in the product if he/she is not satisfied with the
initial prototype.
Spiral Model
• Spiral model is one of the most important Software Development Life Cycle models,
which provides support for Risk Handling.
• In its diagrammatic representation, it looks like a spiral with many loops. The exact
number of loops of the spiral is unknown and can vary from project to project.
• Each loop of the spiral is called a Phase of the software development process.
• The exact number of phases needed to develop the product can be varied by the project
manager depending upon the project risks.
• As the project manager dynamically determines the number of phases, so the project
manager has an important role to develop a product using spiral model.
• The Radius of the spiral at any point represents the expenses(cost) of the project so far, and the angular dimension represents
the progress made so far in the current phase.
Spiral Model
• Each phase of Spiral Model is divided into four quadrants as shown in the above figure. The
functions of these four quadrants are discussed below-
1. Objectives determination and identify alternative solutions: Requirements are gathered from
the customers and the objectives are identified, elaborated and analyzed at the start of every
phase. Then alternative solutions possible for the phase are proposed in this quadrant.
2. Identify and resolve Risks: During the second quadrant all the possible solutions are evaluated to
select the best possible solution. Then the risks associated with that solution is identified and the
risks are resolved using the best possible strategy. At the end of this quadrant, Prototype is built
for the best possible solution.
3. Develop next version of the Product: During the third quadrant, the identified features are
developed and verified through testing. At the end of the third quadrant, the next version of the
software is available.
4. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so far
developed version of the software. In the end, planning for the next phase is started.
Spiral Model
• The most important feature of the spiral model is handling these unknown risks after the
project has started. Such risk resolutions are easier done by developing a prototype.
• The spiral model supports coping up with risks by providing the scope to build a prototype
at every phase of the software development.
• Prototyping Model also support risk handling, but the risks must be identified completely
before the start of the development work of the project.
• But in real life project risk may occur after the development work starts, in that case, we
cannot use Prototyping Model.
• In each phase of the Spiral Model, the features of the product dated and analyzed and the
risks at that point of time are identified and are resolved through prototyping. Thus, this
model is much more flexible compared to other SDLC models.
Spiral Model as Meta Model
• The Spiral model is called as a Meta Model because it
subsumes all the other SDLC models. For example, a single
loop spiral represents the Iterative Waterfall Model.
• The spiral model incorporates the stepwise approach of
the Classical Waterfall Model.
• The spiral model uses the approach of Prototyping Model by
building a prototype at the start of each phase as a risk handling
technique. Also, the spiral model can be considered as
supporting the evolutionary model – the iterations along the
spiral can be considered as evolutionary levels through which
the complete system is built.
Spiral Model: Advantages
• Risk Handling: The projects with many unknown risks that occur as
the development proceeds, in that case, Spiral Model is the best
development model to follow due to the risk analysis and risk
handling at every phase.
• Good for large projects: It is recommended to use the Spiral Model
in large and complex projects.
• Flexibility in Requirements: Change requests in the Requirements
at later phase can be incorporated accurately by using this model.
• Customer Satisfaction: Customer can see the development of the
product at the early phase of the software development and thus,
they habituated with the system by using it before completion of the
total product.
Spiral Model: Disadvantages
• Complex: The Spiral Model is much more complex than other SDLC models.
• Expensive: Spiral Model is not suitable for small projects as it is expensive.
• Too much dependable on Risk Analysis: The successful completion of the project is very much
dependent on Risk Analysis. Without very highly experienced expertise, it is going to be a failure
to develop a project using this model.
• Difficulty in time management: As the number of phases is unknown at the start of the project,
so time estimation is very difficult.

Iterative Enhancement Model
•In Iterative model, iterative process starts with a simple implementation of a small set of the
software requirements and iteratively enhances the evolving versions until the complete system is
implemented and ready to be deployed.
• An iterative life cycle model does not attempt to start with a full specification of requirements.
Instead, development begins by specifying and implementing just part of the software, which is then
reviewed in order to identify further requirements. This process is then repeated, producing a new
version of the software at the end of each iteration of the model.
Iterative Model design
• Iterative process starts with a simple implementation of a subset of the software requirements and
iteratively enhances the evolving versions until the full system is implemented. At each iteration,
design modifications are made and new functional capabilities are added. The basic idea behind
this method is to develop a system through repeated cycles (iterative) and in smaller portions at a
time (incremental).
Iterative Model design
• "During software development, more than one iteration of the software development cycle may be
in progress at the same time." and "This process may be described as an "evolutionary acquisition" or
"incremental build" approach."

• In incremental model the whole requirement is divided into various builds. During each iteration,
the development module goes through the requirements, design, implementation and testing phases.
Each subsequent release of the module adds function to the previous release. The process continues
till the complete system is ready as per the requirement.

• The key to successful use of an iterative software development lifecycle is rigorous validation of
requirements, and verification & testing of each version of the software against those requirements
within each cycle of the model. As the software evolves through successive cycles, tests have to be
repeated and extended to verify each version of the software.
Iterative Model Application
• Like other SDLC models, Iterative and incremental development has some specific applications in
the software industry. This model is most often used in the following scenarios:
• Requirements of the complete system are clearly defined and understood.
 Major requirements must be defined; however, some functionalities or requested enhancements
may evolve with time.
 There is a time to the market constraint.
 A new technology is being used and is being learnt by the development team while working on
the project.
 Resources with needed skill set are not available and are planned to be used on contract basis for
specific iterations.
 There are some high-risk features and goals which may change in the future.
Pros Cons
Some working functionality can be developed quickly
More resources may be required.
and early in the life cycle.
Although cost of change is lesser, but it is not very suitable for changing
Results are obtained early and periodically.
requirements.
Parallel development can be planned. More management attention is required.
System architecture or design issues may arise because not all
Progress can be measured.
requirements are gathered in the beginning of the entire life cycle.
Less costly to change the scope/requirements. Defining increments may require definition of the complete system.
Testing and debugging during smaller iteration is easy. Not suitable for smaller projects.
Risks are identified and resolved during iteration; and
Management complexity is more.
each iteration is an easily managed milestone.
Easier to manage risk - High risk part is done first. End of project may not be known which a risk is.
With every increment operational product is delivered. Highly skilled resources are required for risk analysis.
Issues, challenges & risks identified from each
increment can be utilized/applied to the next Projects progress is highly dependent upon the risk analysis phase.
increment.
It supports changing requirements.
Initial Operating time is less.
Better suited for large and mission-critical projects.
During life cycle software is produced early which
Evolutionary Model
• Evolutionary model is a combination of Iterative and Incremental model of software
development life cycle. Delivering your system in a big bang release, delivering it in incremental
process over time is the action done in this model. Some initial requirements and architecture
envisioning need to be done.
• It is better for software products that have their feature sets redefined during development
because of user feedback and other factors. The Evolutionary development model divides the
development cycle into smaller, incremental waterfall models in which users are able to get
access to the product at the end of each cycle.
• Feedback is provided by the users on the product for the planning stage of the next cycle and the
development team responds, often by changing the product, plan or process. Therefore, the
software product evolves with time.

• All the models have the disadvantage that the duration of time from start of the project to the
delivery time of a solution is very high. Evolutionary model solves this problem in a different
approach.
Evolutionary Model
• Evolutionary model suggests breaking down of work into smaller chunks, prioritizing them and then
delivering those chunks to the customer one by one.
• The number of chunks is huge and is the number of deliveries made to the customer.
• The main advantage is that the customer’s confidence increases as he constantly gets quantifiable
goods or services from the beginning of the project to verify and validate his requirements.
• The model allows for changing requirements as well as all work in broken down into maintainable
work chunks.

Specification Initial version


Outline
description Intermediate
Development
versions

Validation Final version


Application of Evolutionary Model:
• It is used in large projects where you can easily find modules for
incremental implementation. Evolutionary model is commonly used
when the customer wants to start using the core features instead of
waiting for the full software.
• Evolutionary model is also used in object-oriented software
development because the system can be easily portioned into units in
terms of objects.
Advantages and Disadvantages
• Advantages:
• In evolutionary model, a user gets a chance to experiment partially developed system.
• It reduces the error because the core modules get tested thoroughly.
• Disadvantages:
• Sometimes it is hard to divide the problem into several versions that would be acceptable to
the customer which can be incrementally implemented and delivered.

You might also like