Unit_I.pptx

20IT402 - SOFTWARE
ENGINEERING
II Year / III Semester

UNIT I - SOFTWARE PROCESS
AND AGILE DEVELOPMENT
Introduction to Software Engineering,
Software Process, Perspective and Specialized
Process Models –Introduction to Agility-Agile
process-Extreme programming-XP Process.

SOFTWARE
Software is: (1) instructions (computer programs) that
when executed provide desired features, function, and
performance; (2) data structures that enable the
programs to adequately manipulate information, and (3)
descriptive information in both hard copy and virtual
forms that describes the operation and use of the
programs.

Categories of Software:
• System Software
• Application Software
• Engineering/ Scientific Software
• Web Application Software
• Artificial Intelligence Software

SOFTWARE - Characteristics
 Software is developed or engineered; it is not
manufactured in the classical sense.
 Software doesn’t “wear out.”
 Although the industry is moving toward
component-based construction, most software
continues to be custom built.

SOFTWARE – Applications
 System software: Collection of programs
written to service other programs.
 Example: Compilers, Editors
 Application software—Stand-alone programs
that solve a specific business need.
 Example: Online ticket booking

 Engineering/scientific software: 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.
 Example: ATM Systems
 Product-line software: designed to provide a specific
capability for use by many different customers
 Example: Word processing, Spreadsheets

 Web applications: a set of linked hypertext files that
present information using text and limited graphics.
 Artificial intelligence software: Applications within
this area include robotics, expert systems, pattern
recognition (image and voice), artificial neural
networks, theorem proving, and game playing

 New Challenges:
 Open-world computing - to develop systems and
application software that will allow mobile devices,
personal computers
 Netsourcing - targeted end-user markets worldwide.
 Open source - a growing trend that results in
distribution of source code for systems applications

SOFTWARE ENGINEERING
 Definition(IEEE):
 Software Engineering: (1) The application of a
systematic, disciplined, quantifiable approach to
the development, operation, and maintenance of
software; that is, the application of engineering to
software. (2) The study of approaches as in (1).

 Layers:

 Layers – Quality:
 an organizational commitment to quality.
 Total quality management and Six Sigma

 Layers – Process:
 The glue that holds the technology layers together and
enables rational and timely development of computer
software.
 Process defines a framework that must be established for
effective delivery of software engineering technology.
 the basis for management control of software projects

 Layers – Methods:
 Tasks: communication, requirements analysis,
design modeling, program construction, testing,
and support.

 Layers – Tools:
 To provide automated or semi automated support
for the process and the methods.
 A system for the support of software development,
called computer-aided software engineering

SOFTWARE PROCESS
 Process: A collection of activities, actions, and
tasks that are performed when some work product
is to be created.
 Activity: to achieve a broad objective (e.g.,
communication with stakeholders)
 Action: encompasses a set of tasks that produce a
major work product

SOFTWARE PROCESS
 Process: A collection of activities, actions, and
tasks that are performed when some work
product is to be created.
 Task: Small, but well-defined objective that
produces a tangible outcome. (e.g., conducting a
unit test)

SOFTWARE PROCESS
 Activities:
 Communication
 Planning
 Modeling
 Construction
 Deployment

SOFTWARE PROCESS
 Activities – Communication:
 To communicate and collaborate with the
customer
 To understand stakeholders’ objectives for the
project and to gather requirements that help define
software features and functions.

SOFTWARE PROCESS
 Activities – Planning:
 Software project plan—defines the software
engineering work by describing the technical tasks
to be conducted, the risks that are likely, the
resources that will be required, the work products
to be produced, and a work schedule.

SOFTWARE PROCESS
 Activities – Modeling:
 Creating models to better understand software
requirements and the design that will achieve those
requirements.

SOFTWARE PROCESS
 Activities – Construction:
 This activity combines code generation and the
testing that is required to uncover errors in the
code.

SOFTWARE PROCESS
 Activities – Deployment:
 The software is delivered to the customer who
evaluates the delivered product and provides
feedback based on the evaluation.

Objectives of Software
 Satisfy users Requirements
 High reliability
 Low Maintenance Costs
 Delivery on time
 Low production costs
 High Performance
 Ease of reuse

SOFTWARE PROCESS
 Software engineering process framework
activities are complemented by a number of
umbrella activities.
 To help a software team manage and control
progress, quality, change, and risk.

SOFTWARE PROCESS
 Umbrella activities:
 Software project tracking and control - allows the
software team to assess progress against the project
plan and take any necessary action to maintain the
schedule.
 Risk management - assesses risks that may affect the
outcome of the project or the quality of the product.

SOFTWARE PROCESS
 Software quality assurance - defines and conducts the
activities required to ensure software quality.
 Technical reviews - assesses software engineering
work products in an effort to uncover and remove
errors before they are propagated to the next activity.

SOFTWARE PROCESS
 Measurement - defines and collects process, project,
and product measures that assist the team in delivering
software that meets stakeholders’ needs.
 Software configuration management - manages the
effects of change throughout the software process.

SOFTWARE PROCESS
 Reusability management—defines criteria for work
product reuse (including software components) and
establishes mechanisms to achieve reusable components.
Work product preparation and production—encompasses
the activities required to create work products such as
models, documents, logs, forms, and lists.

SOFTWARE PROCESS
 Process Model:
 a process was defined as a collection of work
activities, actions, and tasks that are performed
when some work product is to be created.
A framework or model that defines their
relationship with the process and with one another

SOFTWARE PROCESS
 Process Model:

SOFTWARE PROCESS
ASSESSMENT
 Capability Maturity Model(CMM):
 CMM is used in assessing how well an
organization’s processes allow to complete and
manage new software projects.

SOFTWARE PROCESS
ASSESSMENT
 Level 1 – Initial: Few processes are defined and
individual efforts are taken.
 Level 2 – Repeatable: Depending on earlier
successes of projects with similar applications
necessary process discipline can be repeated.

SOFTWARE PROCESS
ASSESSMENT
 Level 3 – Defined: The process is standardized,
document and followed.
 Level 4 – Managed: Process and product are
quantitatively understood and controlled using
detailed measure.

SOFTWARE PROCESS
ASSESSMENT
 Level 5 – Optimizing: To plan and implement
change.
 CMM is used for improving the software project.

Prescriptive Process Models
 It is a useful structure to software engineering
work and have provided a reasonably effective
road map for software teams
 Also known as Software Development Life
Cycle(SDLC) Model.

 Need:
 Process model will bring the definiteness and
discipline in overall development process.
 Every process model consists of definite entry and
exit criteria for each phase.

Process
Model
Incremental
Process
Model
Incremental
Model
RAD Model
Evolutionary
Process
Model
Prototyping
Model
Spiral Model
Concurrent
Development
Model
Waterfall
Model

 Waterfall Model:
 A linear-sequential life cycle model.
 Each phase must be completed before the next
phase can begin and there is no overlapping in the
phases.

 Requirement Gathering and analysis:
 The basic requirements of the system must be
understood by software engineer – Analyst.
 All these requirements are then well documented and
discussed further with customer, for reviewing.

 Design:
 It helps in specifying hardware and system
requirements and helps in defining the overall system
architecture.
 Attributes: Data Structure, Software architecture,
Interface representation.

 Coding or Implementation:
 The design is translated into machine-readable
form.
 Programs are developed in this phase.

 Testing:
 Focus on logical internals of software.
 To uncover errors, fix the bugs and meet the
customer requirements.

 Deployment and Maintenance:
 The longest life cycle phase.
 When the system is installed and put in practical use
then error may get introduced, correcting such errors
and putting it in use.
 Enhancing system’s services

 Waterfall Model – Advantages:
 Simple and easy to understand and use
 Each phase has specific deliverables and a review
process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements
are very well understood

 Waterfall Model – Disadvantages:
 No working software is produced until late during
the life cycle.
 Cannot accommodate changing requirements.
Adjusting scope during the life cycle can end a
project.

 Incremental Process Model:
 Iterative process starts with a simple implementation
of a small set of the software requirements
Iteratively enhances the evolving versions until the
complete system is implemented and ready to be
deployed

 Incremental Process Model – Iterative Model:
 Iterative process starts with a simple implementation
of a small set of the software requirements
Iteratively enhances the evolving versions until the
complete system is implemented and ready to be
deployed

 The basic idea behind this method is to develop a
system through repeated cycles (iterative) and in
smaller portions at a time (incremental).

 During software development, more than one iteration of
the software development cycle may be in progress at the
same time.
 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.

 rigorous validation of requirements, and verification
& testing of each version of the software against those
requirements within each cycle of the model.
 A new technology is being used and is being learnt by
the development team while working on the project.

 Advantages:
 Some working functionality can be developed quickly and
early in the life cycle.
 Results are obtained early and periodically.
 Better suited for large and mission-critical projects.
 During the life cycle, software is produced early which
facilitates customer evaluation and feedback.

 Disadvantages:
 More resources may be required.
 System architecture or design issues may arise because not
all requirements are gathered in the beginning of the entire
life cycle.
 Projects progress is highly dependent upon the risk
analysis phase.

 Incremental Process Model – RAD Model:
 RAD - Rapid Application Development
 It is based on prototyping and iterative development
with no specific planning involved.
 A prototype is a working model that is functionally
equivalent to a component of the product.

 Business Modeling:
 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 Modeling:
 Information gathered from business modeling is
used to define data objects that are needed for the
business.

 Process Modeling:
 The process model for any changes or
enhancements to the data object sets is defined in
this phase.

 Application Generation:
 The actual system is built and coding is done by
using automation tools to convert process and data
models into actual prototypes.

 Testing and Turnover:
 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.

 Advantages:
 Changing requirements can be accommodated.
 Productivity with fewer people in a short time.
Reduced development time.
 Encourages customer feedback.

 Disadvantages:
 Dependency on technically strong team members for
identifying business requirements.
 Only system that can be modularized can be built
using RAD.
 Requires user involvement throughout the life cycle.

 Evolutionary Process Model:
 While developing the software systems, it is often
needed to make modifications in earlier
development phases or tasks sets.
 In such cases, the iterative approach needs to be
adopted.

 Evolutionary Process Model – Prototyping:
 Initially the requirement gathering is done
 Prototype model is a set of general objectives for
software.
 It is software working model of limited functionality.
In this model, working programs are quickly produced.

 Communication:
 Developer and customer meet and discuss the
overall objectives of the software.

 Quick design:
 It includes only the important aspects i.e input and
output format of the software.
 It focuses on those aspects which are visible to the
user rather than the detailed plan.

 Modeling quick design:
 This phase gives the clear idea about the development
of software as the software is now constructed.
It allows the developer to better understand the exact
requirements.

 Construction of prototype:
 The prototype is evaluated by the customer itself.

 Deployment, delivery, feedback:
 If the user is not satisfied with current prototype then it is
refined according to the requirements of the user.
 The process of refining the prototype is repeated till all
the requirements of users are met.
 When the users are satisfied with the developed prototype then
the system is developed on the basis of final prototype.

Advantages:
 In the development process of this model users are
actively involved.
 Earlier error detection takes place in this model.
 It identifies the missing functionality easily. It also
identifies the confusing or difficult functions.

 Disadvantages:
 The client involvement is more and it is not always
considered by the developer.
 It is a slow process because it takes more time for
development.
Many changes can disturb the rhythm of the development
team.

 Evolutionary Process Model – Spiral:
 The spiral model combines the idea of iterative
development with the systematic, controlled
aspects of the waterfall model.

 Determine Objectives:
 This phase starts with gathering the business requirements
in the baseline spiral.
 In the subsequent spirals as the product matures,
identification of system requirements, subsystem
requirements and unit requirements are all done in this
phase.

 Determine Objectives:
 This phase also includes understanding the system
requirements by continuous communication between
the customer and the system analyst.
At the end of the spiral, the product is deployed in the
identified market.

Risk Analysis:
 Risk Analysis includes identifying, estimating and
monitoring the technical feasibility and
management risks, such as schedule slippage and
cost overrun.

Risk Analysis:
 After testing the build, at the end of first iteration,
the customer evaluates the software and provides
feedback.

 Development and Test:
 The Construct phase refers to production of the actual
software product at every spiral.
 In the baseline spiral, when the product is just thought of
and the design is being developed a POC (Proof of
Concept) is developed in this phase to get customer
feedback.

 Applications:
 Customer is not sure of their requirements which is usually
the case.
Requirements are complex and need evaluation to get
clarity.
 Significant changes are expected in the product during the
development cycle.

 Advantages:
 Changing requirements can be accommodated.
 Requirements can be captured more accurately.
 Development can be divided into smaller parts and the
risky parts can be developed earlier which helps in
better risk management.

 Disadvantages:
Management is more complex.
 Not suitable for small or low risk projects and could
be expensive for small projects.
 Large number of intermediate stages requires
excessive documentation.

 Concurrent Development Model:

 The communication activity has completed in the
first iteration and exits in the awaiting changes state.
 The modeling activity completed its initial
communication and then go to the underdevelopment
state.

 If the customer specifies the change in the requirement,
then the modeling activity moves from the under
development state into the awaiting change state.
 The concurrent process model activities moving from one
state to another state.

 Concurrent Development Model – Advantages:
 This model is applicable to all types of software
development processes.
 It gives immediate feedback from testing.
It provides an accurate picture of the current state of a
project.

 Concurrent Development Model –
Disadvantages:
 It needs better communication between the team
members. This may not be achieved all the time.
It requires to remember the status of the different
activities.

Prescriptive Process Models -
Comparison
Waterfall model Spiral Model Prototyping
Model
Incremental
Model
Requirements
must be clearly
understood and
defined at the
beginning only.
The
requirements
analysis can be
gathering can be
done in iterations
because
requirements get
changed quite
often.
Requirements
analysis can be
made in the later
stage of the
development
cycle.
Requirements
analysis can be
made in the later
stage of the
development
cycle.
The development
team having the
adequate
experience
The development
having less
experience
The development
having less
experience
The development
having less
experience

Prescriptive Process Models -
Comparison
Waterfall model Spiral Model Prototyping
Model
Incremental
Model
No user
involvement
No user
involvement
User involvement
in all the phases of
the development
process
User involvement
in all the phases of
the development
process
Requirements are
well defined and
the development
effort suggests a
purely linear effort
then the waterfall
model is chosen.
Risk identification
and rectification is
done before they
get problematic.
For handling real
time problems the
spiral model is
chosen.
When developer is
unsure about the
efficiency of an
algorithm or the
adaptability of an
OS then the
prototyping model
is chosen
When limited set
of software
functionality is
needed quickly
then the
incremental model
is chosen.

Specialized Process Models
 Special process models take many features from one or
more conventional models.
 Component based development (Promotes reusable
components)
 The formal methods model (Mathematical formal methods
are backbone here)
 Aspect oriented software development (Uses crosscutting
technology)

 Component Based development:
 It incorporates many of the characteristics of the
spiral model.
 It is evolutionary in nature.
 It promotes software reusability.

 Component Based development – Steps:
 Available component based products are researched and
evaluated for the application domain.
 Component integration issues are considered.
 A software architecture is designed to accommodate the
components.
 Components are integrated into the architecture.
 Comprehensive testing is conducted to ensure proper
functionality

 Formal Methods Model:
 A set of activities that leads to formal
mathematical specification of software.
 Formal methods enable a software engineer to
specify, develop and verify a computer system by
applying rigorous mathematical notation.

 When mathematical methods are used during
software development, they provide a mechanism
for eliminating many of the problems that are
difficult to overcome using other software
engineering paradigms.

 A basis for software verification
 To discover and correct errors that might
otherwise go undetected.

 Formal Methods Model – Problems:
 It is currently time-consuming and expensive
 Developers have the necessary background
knowledge to apply formal methods, extensive
training is required to others.

 Aspect oriented Software Development:
 It provides process and methodology for defining,
specifying designing and constructing aspects.
 It aims to address crosscutting concerns by
providing means for systematic identification,
separation, representation and composition.

Introduction to Agility
 Agile Development:
Agile is the ability to create and respond to change.
 It is a way of dealing with, and ultimately
succeeding in, an uncertain and unstable
environment.

 Agile Development:
 An umbrella term for several iterative and incremental
software development methodologies.
 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

 Agile Process:
 The light weight methods are people based rather than
plan based software.
 It forces the development team to focus on software
itself rather than design and documentation.
 To deliver the working model of software quickly to
the customer.

 Agile Principles:
 To satisfy the customer through early and continuous
delivery of valuable software.
 The changes in the requirements must be accommodated,
even late in development.
 Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the
shorter timescale.

 Business people and developers must work
together daily throughout the project.
 Build projects around motivated individuals. Give
them the environment and support they need, and
trust them to get the job done.

 Working software is the primary measure of
progress.
 Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

 Continuous attention to technical excellence and
good design enhances agility.
 Simplicity-the art of maximizing the amount of
work not done-is essential.

 The best architectures, requirements, and designs
emerge from self-organizing teams.
 At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behavior accordingly.

 The most efficient and effective method of
conveying information to and within a
development team is face-to-face conversation.

 Extreme Programming
 eXtreme Programming (XP) was conceived and
developed to address the specific needs of software
development by small teams in the face of vague
and changing requirements.

 Writing unit tests before programming and
keeping all of the tests running at all times.
 Starting with a simple design just enough to code
the features at hand and redesigning when
required.

 Integrating and testing the whole system several times
a day.
Putting a minimal working system into the production
quickly and upgrading it whenever required.
Keeping the customer involved all the time and
obtaining constant feedback.

 Why is it called “Extreme?”
 Code reviews are effective as the code is reviewed all the time.
 Testing is effective as there is continuous regression and testing.
 Design is effective as everybody needs to do refactoring daily.
 Integration testing is important as integrate and test several
times a day.
 Short iterations are effective as the planning game for release
planning and iteration planning.

 Extreme Programming Values
 Communication: Extreme Programming
emphasizes continuous and constant
communication among the team members,
managers and the customer.
 Face-to-Face communication is preferred

 Simplicity: Extreme Programming believes in ‘it is better
to do a simple thing today and pay a little more tomorrow to
change it’.
 Take small simple steps to your goal and mitigate failures
as they happen.
 Create something that you are proud of and maintain it for
a long term for reasonable costs.

Feedback: The software is delivered early to the
customer and a feedback is taken so that
necessary changes can be made if needed.
 The value of the feedback is a continuously
running system that delivers information about
itself in a reliable way.

 Extreme Programming Values - Courage:
 To focus on only what is required
 To communicate and accept feedback
 To tell the truth about progress and estimates
 To refactor the code
To adapt to changes whenever they happen

 Extreme Programming Values - Respect:
 Everyone respects each other as a valued team member.
Everyone contributes value such as enthusiasm.
Developers respect the expertise of the customers and vice
versa.
Management respects the right of the developers to accept
the responsibility and receive authority over their own
work.

 Extreme Programming Process:

 Customer specifies and priorities the system
requirements. The developer and customer together
prepare a story-card in which customer needs are
mentioned.
 After developing the story-card the development team
breaks down the total work in small task.

 The efforts and the estimated resources required for
these tasks are estimated.
 The customer priorities the stories for implementation.
 For accommodating new changes, new story-card
must be developed.
Evaluate, the system along with the customer.

 Extreme Programming Practices:
 The Planning Game - determine the scope of the next release by
combining business priorities and technical estimates.
 Small Releases - a simple system into production quickly, and
then release new versions in very short cycles
 Metaphor - he architecture of the system to be built in a way that
it is easily understandable by everyone involved in the
development.

Simple Design - The system should be designed as simply
as possible at any given moment.
Testing - The developers continually write unit tests, which
need to pass for the development to continue.
Refactoring - restructure the system without changing its
behavior to remove duplication, improve communication,
simplify, or add flexibility

Pair Programming: the entire code is written with two
developers at one machine, with one keyboard and one
mouse.
Collective Ownership: the entire team takes
responsibility for the whole of the system. If a pair is
working and they see an opportunity to improve the
code, they go ahead and improve it.

 Continuous Integration: Code is integrated and tested
many times a day, one set of changes at a time.
40-hour week: The limited number of hours of work
per week for every team members, based on their
sustainability, to a maximum of 45 hours a week.

On-site Customer: Include a real, live user on the
team, available full-time to answer the questions,
resolve disputes and set small-scale priorities.

Coding Standards: Developers write all code in
accordance with the rules emphasizing
 Communication through the code.
The least amount of work possible.
Consistent with the “once and only once” rule (no duplicate
code).
Voluntary adoption by the whole team.

Unit_I.pptx

More Related Content

What's hot

Similar to Unit_I.pptx

More from Baskarkncet

Recently uploaded

Unit_I.pptx