SlideShare une entreprise Scribd logo
1  sur  128
CS8494 - SOFTWARE
ENGINEERING
III Year / V 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.
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
SOFTWARE – Applications
 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.
SOFTWARE – Applications
 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
SOFTWARE – Applications
 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
SOFTWARE – Applications
 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).
SOFTWARE ENGINEERING
 Layers:
SOFTWARE ENGINEERING
 Layers – Quality:
 an organizational commitment to quality.
 Total quality management and Six Sigma
SOFTWARE ENGINEERING
 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
SOFTWARE ENGINEERING
 Layers – Methods:
 Tasks: communication, requirements analysis,
design modeling, program construction, testing,
and support.
SOFTWARE ENGINEERING
 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
 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
 Umbrella activities:
 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
 Umbrella activities:
 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
 Umbrella activities:
 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
 Capability Maturity Model(CMM):
 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
 Capability Maturity Model(CMM):
 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
 Capability Maturity Model(CMM):
 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.
Prescriptive Process Models
 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.
Prescriptive Process Models
Process
Model
Incremental
Process
Model
Incremental
Model
RAD Model
Evolutionary
Process
Model
Prototyping
Model
Spiral Model
Concurrent
Development
Model
Waterfall
Model
Prescriptive Process Models
 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.
Prescriptive Process Models
 Waterfall Model:
Prescriptive Process Models
 Waterfall Model:
 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.
Prescriptive Process Models
 Waterfall Model:
 Design:
 It helps in specifying hardware and system
requirements and helps in defining the overall system
architecture.
 Attributes: Data Structure, Software architecture,
Interface representation.
Prescriptive Process Models
 Waterfall Model:
 Coding or Implementation:
 The design is translated into machine-readable
form.
 Programs are developed in this phase.
Prescriptive Process Models
 Waterfall Model:
 Testing:
 Focus on logical internals of software.
 To uncover errors, fix the bugs and meet the
customer requirements.
Prescriptive Process Models
 Waterfall Model:
 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
Prescriptive Process Models
 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
Prescriptive Process Models
 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.
Prescriptive Process Models
 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
Prescriptive Process Models
 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
Prescriptive Process Models
 Incremental Process Model – Iterative Model:
 The basic idea behind this method is to develop a
system through repeated cycles (iterative) and in
smaller portions at a time (incremental).
Prescriptive Process Models
 Incremental Process Model – Iterative Model:
Prescriptive Process Models
 Incremental Process Model – Iterative Model:
 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.
Prescriptive Process Models
 Incremental Process Model – Iterative Model:
 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.
Prescriptive Process Models
 Incremental Process Model – Iterative Model:
 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.
Prescriptive Process Models
 Incremental Process Model – Iterative Model:
 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.
Prescriptive Process Models
 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.
Prescriptive Process Models
 Incremental Process Model – RAD Model:
Prescriptive Process Models
 Incremental Process Model – RAD Model:
 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.
Prescriptive Process Models
 Incremental Process Model – RAD Model:
 Data Modeling:
 Information gathered from business modeling is
used to define data objects that are needed for the
business.
Prescriptive Process Models
 Incremental Process Model – RAD Model:
 Process Modeling:
 The process model for any changes or
enhancements to the data object sets is defined in
this phase.
Prescriptive Process Models
 Incremental Process Model – RAD Model:
 Application Generation:
 The actual system is built and coding is done by
using automation tools to convert process and data
models into actual prototypes.
Prescriptive Process Models
 Incremental Process Model – RAD Model:
 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.
Prescriptive Process Models
 Incremental Process Model – RAD Model:
 Advantages:
 Changing requirements can be accommodated.
 Productivity with fewer people in a short time.
Reduced development time.
 Encourages customer feedback.
Prescriptive Process Models
 Incremental Process Model – RAD Model:
 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.
Prescriptive Process Models
 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.
Prescriptive Process Models
 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.
Prescriptive Process Models
 Evolutionary Process Model – Prototyping:
Prescriptive Process Models
 Evolutionary Process Model – Prototyping:
 Communication:
 Developer and customer meet and discuss the
overall objectives of the software.
Prescriptive Process Models
 Evolutionary Process Model – Prototyping:
 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.
Prescriptive Process Models
 Evolutionary Process Model – Prototyping:
 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.
Prescriptive Process Models
 Evolutionary Process Model – Prototyping:
 Construction of prototype:
 The prototype is evaluated by the customer itself.
Prescriptive Process Models
 Evolutionary Process Model – Prototyping:
 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.
Prescriptive Process Models
 Evolutionary Process Model – Prototyping:
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.
Prescriptive Process Models
 Evolutionary Process Model – Prototyping:
 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.
Prescriptive Process Models
 Evolutionary Process Model – Spiral:
 The spiral model combines the idea of iterative
development with the systematic, controlled
aspects of the waterfall model.
Prescriptive Process Models
 Evolutionary Process Model – Spiral:
Prescriptive Process Models
 Evolutionary Process Model – Spiral:
 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.
Prescriptive Process Models
 Evolutionary Process Model – Spiral:
 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.
Prescriptive Process Models
 Evolutionary Process Model – Spiral:
Risk Analysis:
 Risk Analysis includes identifying, estimating and
monitoring the technical feasibility and
management risks, such as schedule slippage and
cost overrun.
Prescriptive Process Models
 Evolutionary Process Model – Spiral:
Risk Analysis:
 After testing the build, at the end of first iteration,
the customer evaluates the software and provides
feedback.
Prescriptive Process Models
 Evolutionary Process Model – Spiral:
 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.
Prescriptive Process Models
 Evolutionary Process Model – Spiral:
 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.
Prescriptive Process Models
 Evolutionary Process Model – Spiral:
 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.
Prescriptive Process Models
 Evolutionary Process Model – Spiral:
 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.
Prescriptive Process Models
 Evolutionary Process Model:
 Concurrent Development Model:
Prescriptive Process Models
 Evolutionary Process Model:
 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.
Prescriptive Process Models
 Evolutionary Process Model:
 Concurrent Development Model:
 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.
Prescriptive Process Models
 Evolutionary Process Model:
 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.
Prescriptive Process Models
 Evolutionary Process Model:
 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)
Specialized Process Models
 Component Based development:
 It incorporates many of the characteristics of the
spiral model.
 It is evolutionary in nature.
 It promotes software reusability.
Specialized Process Models
 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
Specialized Process Models
 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.
Specialized Process Models
 Formal Methods Model:
 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.
Specialized Process Models
 Formal Methods Model:
 A basis for software verification
 To discover and correct errors that might
otherwise go undetected.
Specialized Process Models
 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.
Specialized Process Models
 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.
Introduction to Agility
 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
Introduction to Agility
 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.
Introduction to Agility
 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.
Introduction to Agility
 Agile Principles:
 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.
Introduction to Agility
 Agile Principles:
 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.
Introduction to Agility
 Agile Principles:
 Continuous attention to technical excellence and
good design enhances agility.
 Simplicity-the art of maximizing the amount of
work not done-is essential.
Introduction to Agility
 Agile Principles:
 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.
Introduction to Agility
 Agile Principles:
 The most efficient and effective method of
conveying information to and within a
development team is face-to-face conversation.
Introduction to Agility
 Agile Principles:
 The most efficient and effective method of
conveying information to and within a
development team is face-to-face conversation.
Introduction to Agility
 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.
Introduction to Agility
 Extreme Programming
 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.
Introduction to Agility
 Extreme Programming
 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.
Introduction to Agility
 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.
Introduction to Agility
 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
Introduction to Agility
 Extreme Programming Values
 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.
Introduction to Agility
 Extreme Programming Values
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.
Introduction to Agility
 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
Introduction to Agility
 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.
Introduction to Agility
 Extreme Programming Process:
Introduction to Agility
 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.
Introduction to Agility
 Extreme Programming Process:
 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.
Introduction to Agility
 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.
Introduction to Agility
 Extreme Programming Practices:
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
Introduction to Agility
 Extreme Programming Practices:
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.
Introduction to Agility
 Extreme Programming Practices:
 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.
Introduction to Agility
 Extreme Programming Practices:
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.
Introduction to Agility
 Extreme Programming Practices:
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.

Contenu connexe

Tendances

Types of software testing
Types of software testingTypes of software testing
Types of software testingPrachi Sasankar
 
2- THE CHANGING NATURE OF SOFTWARE.pdf
2- THE CHANGING NATURE OF SOFTWARE.pdf2- THE CHANGING NATURE OF SOFTWARE.pdf
2- THE CHANGING NATURE OF SOFTWARE.pdfbcanawakadalcollege
 
Rational Unified Process
Rational Unified ProcessRational Unified Process
Rational Unified ProcessKumar
 
CS8494 SOFTWARE ENGINEERING Unit-2
CS8494 SOFTWARE ENGINEERING Unit-2CS8494 SOFTWARE ENGINEERING Unit-2
CS8494 SOFTWARE ENGINEERING Unit-2SIMONTHOMAS S
 
Software maintenance
Software maintenance Software maintenance
Software maintenance Rajeev Sharan
 
Coupling and cohesion
Coupling and cohesionCoupling and cohesion
Coupling and cohesionSutha31
 
Software myths | Software Engineering Notes
Software myths | Software Engineering NotesSoftware myths | Software Engineering Notes
Software myths | Software Engineering NotesNavjyotsinh Jadeja
 
Lecture 12 requirements modeling - (system analysis)
Lecture 12   requirements modeling - (system analysis)Lecture 12   requirements modeling - (system analysis)
Lecture 12 requirements modeling - (system analysis)IIUI
 
Incremental model
Incremental modelIncremental model
Incremental modelHpibmx
 
Pressman ch-22-process-and-project-metrics
Pressman ch-22-process-and-project-metricsPressman ch-22-process-and-project-metrics
Pressman ch-22-process-and-project-metricsSeema Kamble
 
REQUIREMENT ENGINEERING
REQUIREMENT ENGINEERINGREQUIREMENT ENGINEERING
REQUIREMENT ENGINEERINGSaqib Raza
 
Software Engineering Process Models
Software Engineering Process Models Software Engineering Process Models
Software Engineering Process Models Satya P. Joshi
 
Software Testing Strategies ,Validation Testing and System Testing.
Software Testing Strategies ,Validation Testing and System Testing.Software Testing Strategies ,Validation Testing and System Testing.
Software Testing Strategies ,Validation Testing and System Testing.Tanzeem Aslam
 

Tendances (20)

Types of software testing
Types of software testingTypes of software testing
Types of software testing
 
2- THE CHANGING NATURE OF SOFTWARE.pdf
2- THE CHANGING NATURE OF SOFTWARE.pdf2- THE CHANGING NATURE OF SOFTWARE.pdf
2- THE CHANGING NATURE OF SOFTWARE.pdf
 
Rational Unified Process
Rational Unified ProcessRational Unified Process
Rational Unified Process
 
CS8494 SOFTWARE ENGINEERING Unit-2
CS8494 SOFTWARE ENGINEERING Unit-2CS8494 SOFTWARE ENGINEERING Unit-2
CS8494 SOFTWARE ENGINEERING Unit-2
 
Software maintenance
Software maintenance Software maintenance
Software maintenance
 
Software engineering unit 1
Software engineering unit 1Software engineering unit 1
Software engineering unit 1
 
Coupling and cohesion
Coupling and cohesionCoupling and cohesion
Coupling and cohesion
 
Software myths | Software Engineering Notes
Software myths | Software Engineering NotesSoftware myths | Software Engineering Notes
Software myths | Software Engineering Notes
 
Lecture 12 requirements modeling - (system analysis)
Lecture 12   requirements modeling - (system analysis)Lecture 12   requirements modeling - (system analysis)
Lecture 12 requirements modeling - (system analysis)
 
Incremental model
Incremental modelIncremental model
Incremental model
 
Pressman ch-22-process-and-project-metrics
Pressman ch-22-process-and-project-metricsPressman ch-22-process-and-project-metrics
Pressman ch-22-process-and-project-metrics
 
REQUIREMENT ENGINEERING
REQUIREMENT ENGINEERINGREQUIREMENT ENGINEERING
REQUIREMENT ENGINEERING
 
Software Engineering Process Models
Software Engineering Process Models Software Engineering Process Models
Software Engineering Process Models
 
PROTOTYPE MODEL
PROTOTYPE MODELPROTOTYPE MODEL
PROTOTYPE MODEL
 
Rad model
Rad modelRad model
Rad model
 
Checkpoints of the Process
Checkpoints of the ProcessCheckpoints of the Process
Checkpoints of the Process
 
SDLC, Iterative Model
SDLC, Iterative ModelSDLC, Iterative Model
SDLC, Iterative Model
 
Software Testing Strategies ,Validation Testing and System Testing.
Software Testing Strategies ,Validation Testing and System Testing.Software Testing Strategies ,Validation Testing and System Testing.
Software Testing Strategies ,Validation Testing and System Testing.
 
Managment spectrum
Managment spectrumManagment spectrum
Managment spectrum
 
Software Myths
Software MythsSoftware Myths
Software Myths
 

Similaire à CS8494 SOFTWARE ENGINEERING Unit-1

Introduction of software engineering
Introduction of software engineeringIntroduction of software engineering
Introduction of software engineeringBhagyashriMore10
 
Software Process in software engineering
Software Process in software engineeringSoftware Process in software engineering
Software Process in software engineeringMuhammadTalha436
 
ccs356-software-engineering-notes.pdf
ccs356-software-engineering-notes.pdfccs356-software-engineering-notes.pdf
ccs356-software-engineering-notes.pdfVijayakumarKadumbadi
 
Chapter_01.ppt
Chapter_01.pptChapter_01.ppt
Chapter_01.pptMSahibKhan
 
Software Engineering Layered Technology Software Process Framework
Software Engineering  Layered Technology Software Process FrameworkSoftware Engineering  Layered Technology Software Process Framework
Software Engineering Layered Technology Software Process FrameworkJAINAM KAPADIYA
 
want to contact me login to www.stqa.org
want to contact me login to www.stqa.orgwant to contact me login to www.stqa.org
want to contact me login to www.stqa.orgnazeer pasha
 
Software engineering
Software engineeringSoftware engineering
Software engineeringAnanthiP8
 
Elementary Probability theory Chapter 2.pptx
Elementary Probability theory Chapter 2.pptxElementary Probability theory Chapter 2.pptx
Elementary Probability theory Chapter 2.pptxethiouniverse
 
Introduction,Software Process Models, Project Management
Introduction,Software Process Models, Project ManagementIntroduction,Software Process Models, Project Management
Introduction,Software Process Models, Project Managementswatisinghal
 
Software Specifications with details exp
Software Specifications with details expSoftware Specifications with details exp
Software Specifications with details expAkhileshPansare
 
Intoduction to software engineering part 2
Intoduction to software engineering part 2Intoduction to software engineering part 2
Intoduction to software engineering part 2Rupesh Vaishnav
 
Lecture-1,2-Introduction to SE.pptx
Lecture-1,2-Introduction to SE.pptxLecture-1,2-Introduction to SE.pptx
Lecture-1,2-Introduction to SE.pptxYaseenNazir3
 
Introduction to Software Engineering
Introduction to Software EngineeringIntroduction to Software Engineering
Introduction to Software EngineeringZahoor Khan
 
Fundamentals of software development
Fundamentals of software developmentFundamentals of software development
Fundamentals of software developmentPratik Devmurari
 

Similaire à CS8494 SOFTWARE ENGINEERING Unit-1 (20)

Unit_I.pptx
Unit_I.pptxUnit_I.pptx
Unit_I.pptx
 
Introduction of software engineering
Introduction of software engineeringIntroduction of software engineering
Introduction of software engineering
 
Software Process in software engineering
Software Process in software engineeringSoftware Process in software engineering
Software Process in software engineering
 
Lecture 1 SE.pptx
Lecture 1 SE.pptxLecture 1 SE.pptx
Lecture 1 SE.pptx
 
ccs356-software-engineering-notes.pdf
ccs356-software-engineering-notes.pdfccs356-software-engineering-notes.pdf
ccs356-software-engineering-notes.pdf
 
Chapter_01.ppt
Chapter_01.pptChapter_01.ppt
Chapter_01.ppt
 
Software Engineering Layered Technology Software Process Framework
Software Engineering  Layered Technology Software Process FrameworkSoftware Engineering  Layered Technology Software Process Framework
Software Engineering Layered Technology Software Process Framework
 
want to contact me login to www.stqa.org
want to contact me login to www.stqa.orgwant to contact me login to www.stqa.org
want to contact me login to www.stqa.org
 
Unit 1.pdf
Unit 1.pdfUnit 1.pdf
Unit 1.pdf
 
Software engineering
Software engineeringSoftware engineering
Software engineering
 
Elementary Probability theory Chapter 2.pptx
Elementary Probability theory Chapter 2.pptxElementary Probability theory Chapter 2.pptx
Elementary Probability theory Chapter 2.pptx
 
Introduction,Software Process Models, Project Management
Introduction,Software Process Models, Project ManagementIntroduction,Software Process Models, Project Management
Introduction,Software Process Models, Project Management
 
Software Specifications with details exp
Software Specifications with details expSoftware Specifications with details exp
Software Specifications with details exp
 
software engineering
software engineering software engineering
software engineering
 
Intoduction to software engineering part 2
Intoduction to software engineering part 2Intoduction to software engineering part 2
Intoduction to software engineering part 2
 
Lecture-1,2-Introduction to SE.pptx
Lecture-1,2-Introduction to SE.pptxLecture-1,2-Introduction to SE.pptx
Lecture-1,2-Introduction to SE.pptx
 
Introduction to Software Engineering
Introduction to Software EngineeringIntroduction to Software Engineering
Introduction to Software Engineering
 
Software Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC)Software Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC)
 
Fundamentals of software development
Fundamentals of software developmentFundamentals of software development
Fundamentals of software development
 
Software models
Software modelsSoftware models
Software models
 

Plus de SIMONTHOMAS S

Cs8092 computer graphics and multimedia unit 5
Cs8092 computer graphics and multimedia unit 5Cs8092 computer graphics and multimedia unit 5
Cs8092 computer graphics and multimedia unit 5SIMONTHOMAS S
 
Cs8092 computer graphics and multimedia unit 4
Cs8092 computer graphics and multimedia unit 4Cs8092 computer graphics and multimedia unit 4
Cs8092 computer graphics and multimedia unit 4SIMONTHOMAS S
 
Cs8092 computer graphics and multimedia unit 3
Cs8092 computer graphics and multimedia unit 3Cs8092 computer graphics and multimedia unit 3
Cs8092 computer graphics and multimedia unit 3SIMONTHOMAS S
 
Cs8092 computer graphics and multimedia unit 2
Cs8092 computer graphics and multimedia unit 2Cs8092 computer graphics and multimedia unit 2
Cs8092 computer graphics and multimedia unit 2SIMONTHOMAS S
 
Cs8092 computer graphics and multimedia unit 1
Cs8092 computer graphics and multimedia unit 1Cs8092 computer graphics and multimedia unit 1
Cs8092 computer graphics and multimedia unit 1SIMONTHOMAS S
 
IT6701-Information Management Unit 5
IT6701-Information Management Unit 5IT6701-Information Management Unit 5
IT6701-Information Management Unit 5SIMONTHOMAS S
 
IT6701-Information Management Unit 4
IT6701-Information Management Unit 4IT6701-Information Management Unit 4
IT6701-Information Management Unit 4SIMONTHOMAS S
 
IT6701-Information Management Unit 3
IT6701-Information Management Unit 3IT6701-Information Management Unit 3
IT6701-Information Management Unit 3SIMONTHOMAS S
 
IT6701-Information Management Unit 2
IT6701-Information Management Unit 2IT6701-Information Management Unit 2
IT6701-Information Management Unit 2SIMONTHOMAS S
 
IT6701-Information Management Unit 1
IT6701-Information Management Unit 1IT6701-Information Management Unit 1
IT6701-Information Management Unit 1SIMONTHOMAS S
 
CS8391-Data Structures Unit 5
CS8391-Data Structures Unit 5CS8391-Data Structures Unit 5
CS8391-Data Structures Unit 5SIMONTHOMAS S
 
CS8391-Data Structures Unit 4
CS8391-Data Structures Unit 4CS8391-Data Structures Unit 4
CS8391-Data Structures Unit 4SIMONTHOMAS S
 
CS8391-Data Structures Unit 3
CS8391-Data Structures Unit 3CS8391-Data Structures Unit 3
CS8391-Data Structures Unit 3SIMONTHOMAS S
 
CS8391-Data Structures Unit 2
CS8391-Data Structures Unit 2CS8391-Data Structures Unit 2
CS8391-Data Structures Unit 2SIMONTHOMAS S
 
CS8391-Data Structures Unit 1
CS8391-Data Structures Unit 1CS8391-Data Structures Unit 1
CS8391-Data Structures Unit 1SIMONTHOMAS S
 

Plus de SIMONTHOMAS S (20)

Cs8092 computer graphics and multimedia unit 5
Cs8092 computer graphics and multimedia unit 5Cs8092 computer graphics and multimedia unit 5
Cs8092 computer graphics and multimedia unit 5
 
Cs8092 computer graphics and multimedia unit 4
Cs8092 computer graphics and multimedia unit 4Cs8092 computer graphics and multimedia unit 4
Cs8092 computer graphics and multimedia unit 4
 
Cs8092 computer graphics and multimedia unit 3
Cs8092 computer graphics and multimedia unit 3Cs8092 computer graphics and multimedia unit 3
Cs8092 computer graphics and multimedia unit 3
 
Cs8092 computer graphics and multimedia unit 2
Cs8092 computer graphics and multimedia unit 2Cs8092 computer graphics and multimedia unit 2
Cs8092 computer graphics and multimedia unit 2
 
Cs8092 computer graphics and multimedia unit 1
Cs8092 computer graphics and multimedia unit 1Cs8092 computer graphics and multimedia unit 1
Cs8092 computer graphics and multimedia unit 1
 
Mg6088 spm unit-5
Mg6088 spm unit-5Mg6088 spm unit-5
Mg6088 spm unit-5
 
Mg6088 spm unit-4
Mg6088 spm unit-4Mg6088 spm unit-4
Mg6088 spm unit-4
 
Mg6088 spm unit-3
Mg6088 spm unit-3Mg6088 spm unit-3
Mg6088 spm unit-3
 
Mg6088 spm unit-2
Mg6088 spm unit-2Mg6088 spm unit-2
Mg6088 spm unit-2
 
Mg6088 spm unit-1
Mg6088 spm unit-1Mg6088 spm unit-1
Mg6088 spm unit-1
 
IT6701-Information Management Unit 5
IT6701-Information Management Unit 5IT6701-Information Management Unit 5
IT6701-Information Management Unit 5
 
IT6701-Information Management Unit 4
IT6701-Information Management Unit 4IT6701-Information Management Unit 4
IT6701-Information Management Unit 4
 
IT6701-Information Management Unit 3
IT6701-Information Management Unit 3IT6701-Information Management Unit 3
IT6701-Information Management Unit 3
 
IT6701-Information Management Unit 2
IT6701-Information Management Unit 2IT6701-Information Management Unit 2
IT6701-Information Management Unit 2
 
IT6701-Information Management Unit 1
IT6701-Information Management Unit 1IT6701-Information Management Unit 1
IT6701-Information Management Unit 1
 
CS8391-Data Structures Unit 5
CS8391-Data Structures Unit 5CS8391-Data Structures Unit 5
CS8391-Data Structures Unit 5
 
CS8391-Data Structures Unit 4
CS8391-Data Structures Unit 4CS8391-Data Structures Unit 4
CS8391-Data Structures Unit 4
 
CS8391-Data Structures Unit 3
CS8391-Data Structures Unit 3CS8391-Data Structures Unit 3
CS8391-Data Structures Unit 3
 
CS8391-Data Structures Unit 2
CS8391-Data Structures Unit 2CS8391-Data Structures Unit 2
CS8391-Data Structures Unit 2
 
CS8391-Data Structures Unit 1
CS8391-Data Structures Unit 1CS8391-Data Structures Unit 1
CS8391-Data Structures Unit 1
 

Dernier

Call Girls Service Nashik Vaishnavi 7001305949 Independent Escort Service Nashik
Call Girls Service Nashik Vaishnavi 7001305949 Independent Escort Service NashikCall Girls Service Nashik Vaishnavi 7001305949 Independent Escort Service Nashik
Call Girls Service Nashik Vaishnavi 7001305949 Independent Escort Service NashikCall Girls in Nagpur High Profile
 
Coefficient of Thermal Expansion and their Importance.pptx
Coefficient of Thermal Expansion and their Importance.pptxCoefficient of Thermal Expansion and their Importance.pptx
Coefficient of Thermal Expansion and their Importance.pptxAsutosh Ranjan
 
Processing & Properties of Floor and Wall Tiles.pptx
Processing & Properties of Floor and Wall Tiles.pptxProcessing & Properties of Floor and Wall Tiles.pptx
Processing & Properties of Floor and Wall Tiles.pptxpranjaldaimarysona
 
University management System project report..pdf
University management System project report..pdfUniversity management System project report..pdf
University management System project report..pdfKamal Acharya
 
Java Programming :Event Handling(Types of Events)
Java Programming :Event Handling(Types of Events)Java Programming :Event Handling(Types of Events)
Java Programming :Event Handling(Types of Events)simmis5
 
Porous Ceramics seminar and technical writing
Porous Ceramics seminar and technical writingPorous Ceramics seminar and technical writing
Porous Ceramics seminar and technical writingrakeshbaidya232001
 
CCS335 _ Neural Networks and Deep Learning Laboratory_Lab Complete Record
CCS335 _ Neural Networks and Deep Learning Laboratory_Lab Complete RecordCCS335 _ Neural Networks and Deep Learning Laboratory_Lab Complete Record
CCS335 _ Neural Networks and Deep Learning Laboratory_Lab Complete RecordAsst.prof M.Gokilavani
 
Glass Ceramics: Processing and Properties
Glass Ceramics: Processing and PropertiesGlass Ceramics: Processing and Properties
Glass Ceramics: Processing and PropertiesPrabhanshu Chaturvedi
 
Call for Papers - African Journal of Biological Sciences, E-ISSN: 2663-2187, ...
Call for Papers - African Journal of Biological Sciences, E-ISSN: 2663-2187, ...Call for Papers - African Journal of Biological Sciences, E-ISSN: 2663-2187, ...
Call for Papers - African Journal of Biological Sciences, E-ISSN: 2663-2187, ...Christo Ananth
 
Introduction to Multiple Access Protocol.pptx
Introduction to Multiple Access Protocol.pptxIntroduction to Multiple Access Protocol.pptx
Introduction to Multiple Access Protocol.pptxupamatechverse
 
UNIT-III FMM. DIMENSIONAL ANALYSIS
UNIT-III FMM.        DIMENSIONAL ANALYSISUNIT-III FMM.        DIMENSIONAL ANALYSIS
UNIT-III FMM. DIMENSIONAL ANALYSISrknatarajan
 
Booking open Available Pune Call Girls Koregaon Park 6297143586 Call Hot Ind...
Booking open Available Pune Call Girls Koregaon Park  6297143586 Call Hot Ind...Booking open Available Pune Call Girls Koregaon Park  6297143586 Call Hot Ind...
Booking open Available Pune Call Girls Koregaon Park 6297143586 Call Hot Ind...Call Girls in Nagpur High Profile
 
KubeKraft presentation @CloudNativeHooghly
KubeKraft presentation @CloudNativeHooghlyKubeKraft presentation @CloudNativeHooghly
KubeKraft presentation @CloudNativeHooghlysanyuktamishra911
 
(PRIYA) Rajgurunagar Call Girls Just Call 7001035870 [ Cash on Delivery ] Pun...
(PRIYA) Rajgurunagar Call Girls Just Call 7001035870 [ Cash on Delivery ] Pun...(PRIYA) Rajgurunagar Call Girls Just Call 7001035870 [ Cash on Delivery ] Pun...
(PRIYA) Rajgurunagar Call Girls Just Call 7001035870 [ Cash on Delivery ] Pun...ranjana rawat
 
Structural Analysis and Design of Foundations: A Comprehensive Handbook for S...
Structural Analysis and Design of Foundations: A Comprehensive Handbook for S...Structural Analysis and Design of Foundations: A Comprehensive Handbook for S...
Structural Analysis and Design of Foundations: A Comprehensive Handbook for S...Dr.Costas Sachpazis
 
ONLINE FOOD ORDER SYSTEM PROJECT REPORT.pdf
ONLINE FOOD ORDER SYSTEM PROJECT REPORT.pdfONLINE FOOD ORDER SYSTEM PROJECT REPORT.pdf
ONLINE FOOD ORDER SYSTEM PROJECT REPORT.pdfKamal Acharya
 
Extrusion Processes and Their Limitations
Extrusion Processes and Their LimitationsExtrusion Processes and Their Limitations
Extrusion Processes and Their Limitations120cr0395
 
Introduction to IEEE STANDARDS and its different types.pptx
Introduction to IEEE STANDARDS and its different types.pptxIntroduction to IEEE STANDARDS and its different types.pptx
Introduction to IEEE STANDARDS and its different types.pptxupamatechverse
 
(ANJALI) Dange Chowk Call Girls Just Call 7001035870 [ Cash on Delivery ] Pun...
(ANJALI) Dange Chowk Call Girls Just Call 7001035870 [ Cash on Delivery ] Pun...(ANJALI) Dange Chowk Call Girls Just Call 7001035870 [ Cash on Delivery ] Pun...
(ANJALI) Dange Chowk Call Girls Just Call 7001035870 [ Cash on Delivery ] Pun...ranjana rawat
 
BSides Seattle 2024 - Stopping Ethan Hunt From Taking Your Data.pptx
BSides Seattle 2024 - Stopping Ethan Hunt From Taking Your Data.pptxBSides Seattle 2024 - Stopping Ethan Hunt From Taking Your Data.pptx
BSides Seattle 2024 - Stopping Ethan Hunt From Taking Your Data.pptxfenichawla
 

Dernier (20)

Call Girls Service Nashik Vaishnavi 7001305949 Independent Escort Service Nashik
Call Girls Service Nashik Vaishnavi 7001305949 Independent Escort Service NashikCall Girls Service Nashik Vaishnavi 7001305949 Independent Escort Service Nashik
Call Girls Service Nashik Vaishnavi 7001305949 Independent Escort Service Nashik
 
Coefficient of Thermal Expansion and their Importance.pptx
Coefficient of Thermal Expansion and their Importance.pptxCoefficient of Thermal Expansion and their Importance.pptx
Coefficient of Thermal Expansion and their Importance.pptx
 
Processing & Properties of Floor and Wall Tiles.pptx
Processing & Properties of Floor and Wall Tiles.pptxProcessing & Properties of Floor and Wall Tiles.pptx
Processing & Properties of Floor and Wall Tiles.pptx
 
University management System project report..pdf
University management System project report..pdfUniversity management System project report..pdf
University management System project report..pdf
 
Java Programming :Event Handling(Types of Events)
Java Programming :Event Handling(Types of Events)Java Programming :Event Handling(Types of Events)
Java Programming :Event Handling(Types of Events)
 
Porous Ceramics seminar and technical writing
Porous Ceramics seminar and technical writingPorous Ceramics seminar and technical writing
Porous Ceramics seminar and technical writing
 
CCS335 _ Neural Networks and Deep Learning Laboratory_Lab Complete Record
CCS335 _ Neural Networks and Deep Learning Laboratory_Lab Complete RecordCCS335 _ Neural Networks and Deep Learning Laboratory_Lab Complete Record
CCS335 _ Neural Networks and Deep Learning Laboratory_Lab Complete Record
 
Glass Ceramics: Processing and Properties
Glass Ceramics: Processing and PropertiesGlass Ceramics: Processing and Properties
Glass Ceramics: Processing and Properties
 
Call for Papers - African Journal of Biological Sciences, E-ISSN: 2663-2187, ...
Call for Papers - African Journal of Biological Sciences, E-ISSN: 2663-2187, ...Call for Papers - African Journal of Biological Sciences, E-ISSN: 2663-2187, ...
Call for Papers - African Journal of Biological Sciences, E-ISSN: 2663-2187, ...
 
Introduction to Multiple Access Protocol.pptx
Introduction to Multiple Access Protocol.pptxIntroduction to Multiple Access Protocol.pptx
Introduction to Multiple Access Protocol.pptx
 
UNIT-III FMM. DIMENSIONAL ANALYSIS
UNIT-III FMM.        DIMENSIONAL ANALYSISUNIT-III FMM.        DIMENSIONAL ANALYSIS
UNIT-III FMM. DIMENSIONAL ANALYSIS
 
Booking open Available Pune Call Girls Koregaon Park 6297143586 Call Hot Ind...
Booking open Available Pune Call Girls Koregaon Park  6297143586 Call Hot Ind...Booking open Available Pune Call Girls Koregaon Park  6297143586 Call Hot Ind...
Booking open Available Pune Call Girls Koregaon Park 6297143586 Call Hot Ind...
 
KubeKraft presentation @CloudNativeHooghly
KubeKraft presentation @CloudNativeHooghlyKubeKraft presentation @CloudNativeHooghly
KubeKraft presentation @CloudNativeHooghly
 
(PRIYA) Rajgurunagar Call Girls Just Call 7001035870 [ Cash on Delivery ] Pun...
(PRIYA) Rajgurunagar Call Girls Just Call 7001035870 [ Cash on Delivery ] Pun...(PRIYA) Rajgurunagar Call Girls Just Call 7001035870 [ Cash on Delivery ] Pun...
(PRIYA) Rajgurunagar Call Girls Just Call 7001035870 [ Cash on Delivery ] Pun...
 
Structural Analysis and Design of Foundations: A Comprehensive Handbook for S...
Structural Analysis and Design of Foundations: A Comprehensive Handbook for S...Structural Analysis and Design of Foundations: A Comprehensive Handbook for S...
Structural Analysis and Design of Foundations: A Comprehensive Handbook for S...
 
ONLINE FOOD ORDER SYSTEM PROJECT REPORT.pdf
ONLINE FOOD ORDER SYSTEM PROJECT REPORT.pdfONLINE FOOD ORDER SYSTEM PROJECT REPORT.pdf
ONLINE FOOD ORDER SYSTEM PROJECT REPORT.pdf
 
Extrusion Processes and Their Limitations
Extrusion Processes and Their LimitationsExtrusion Processes and Their Limitations
Extrusion Processes and Their Limitations
 
Introduction to IEEE STANDARDS and its different types.pptx
Introduction to IEEE STANDARDS and its different types.pptxIntroduction to IEEE STANDARDS and its different types.pptx
Introduction to IEEE STANDARDS and its different types.pptx
 
(ANJALI) Dange Chowk Call Girls Just Call 7001035870 [ Cash on Delivery ] Pun...
(ANJALI) Dange Chowk Call Girls Just Call 7001035870 [ Cash on Delivery ] Pun...(ANJALI) Dange Chowk Call Girls Just Call 7001035870 [ Cash on Delivery ] Pun...
(ANJALI) Dange Chowk Call Girls Just Call 7001035870 [ Cash on Delivery ] Pun...
 
BSides Seattle 2024 - Stopping Ethan Hunt From Taking Your Data.pptx
BSides Seattle 2024 - Stopping Ethan Hunt From Taking Your Data.pptxBSides Seattle 2024 - Stopping Ethan Hunt From Taking Your Data.pptx
BSides Seattle 2024 - Stopping Ethan Hunt From Taking Your Data.pptx
 

CS8494 SOFTWARE ENGINEERING Unit-1

  • 2. 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.
  • 3. 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.
  • 4. 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.
  • 5. 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
  • 6. SOFTWARE – Applications  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.
  • 7. SOFTWARE – Applications  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
  • 8. SOFTWARE – Applications  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
  • 9. SOFTWARE – Applications  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
  • 10. 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).
  • 12. SOFTWARE ENGINEERING  Layers – Quality:  an organizational commitment to quality.  Total quality management and Six Sigma
  • 13. SOFTWARE ENGINEERING  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
  • 14. SOFTWARE ENGINEERING  Layers – Methods:  Tasks: communication, requirements analysis, design modeling, program construction, testing, and support.
  • 15. SOFTWARE ENGINEERING  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
  • 16. 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
  • 17. 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)
  • 18. SOFTWARE PROCESS  Activities:  Communication  Planning  Modeling  Construction  Deployment
  • 19. 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.
  • 20. 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.
  • 21. SOFTWARE PROCESS  Activities – Modeling:  Creating models to better understand software requirements and the design that will achieve those requirements.
  • 22. SOFTWARE PROCESS  Activities – Construction:  This activity combines code generation and the testing that is required to uncover errors in the code.
  • 23. SOFTWARE PROCESS  Activities – Deployment:  The software is delivered to the customer who evaluates the delivered product and provides feedback based on the evaluation.
  • 24. Objectives of Software  Satisfy users Requirements  High reliability  Low Maintenance Costs  Delivery on time  Low production costs  High Performance  Ease of reuse
  • 25. 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.
  • 26. 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.
  • 27. 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.
  • 28. SOFTWARE PROCESS  Umbrella activities:  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.
  • 29. SOFTWARE PROCESS  Umbrella activities:  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.
  • 30. SOFTWARE PROCESS  Umbrella activities:  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.
  • 31. 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
  • 33. 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.
  • 34. SOFTWARE PROCESS ASSESSMENT  Capability Maturity Model(CMM):  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.
  • 35. SOFTWARE PROCESS ASSESSMENT  Capability Maturity Model(CMM):  Level 3 – Defined: The process is standardized, document and followed.  Level 4 – Managed: Process and product are quantitatively understood and controlled using detailed measure.
  • 36. SOFTWARE PROCESS ASSESSMENT  Capability Maturity Model(CMM):  Level 5 – Optimizing: To plan and implement change.  CMM is used for improving the software project.
  • 37. 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.
  • 38. Prescriptive Process Models  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.
  • 39. Prescriptive Process Models Process Model Incremental Process Model Incremental Model RAD Model Evolutionary Process Model Prototyping Model Spiral Model Concurrent Development Model Waterfall Model
  • 40. Prescriptive Process Models  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.
  • 42. Prescriptive Process Models  Waterfall Model:  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.
  • 43. Prescriptive Process Models  Waterfall Model:  Design:  It helps in specifying hardware and system requirements and helps in defining the overall system architecture.  Attributes: Data Structure, Software architecture, Interface representation.
  • 44. Prescriptive Process Models  Waterfall Model:  Coding or Implementation:  The design is translated into machine-readable form.  Programs are developed in this phase.
  • 45. Prescriptive Process Models  Waterfall Model:  Testing:  Focus on logical internals of software.  To uncover errors, fix the bugs and meet the customer requirements.
  • 46. Prescriptive Process Models  Waterfall Model:  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
  • 47. Prescriptive Process Models  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
  • 48. Prescriptive Process Models  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.
  • 49. Prescriptive Process Models  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
  • 50. Prescriptive Process Models  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
  • 51. Prescriptive Process Models  Incremental Process Model – Iterative Model:  The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental).
  • 52. Prescriptive Process Models  Incremental Process Model – Iterative Model:
  • 53. Prescriptive Process Models  Incremental Process Model – Iterative Model:  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.
  • 54. Prescriptive Process Models  Incremental Process Model – Iterative Model:  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.
  • 55. Prescriptive Process Models  Incremental Process Model – Iterative Model:  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.
  • 56. Prescriptive Process Models  Incremental Process Model – Iterative Model:  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.
  • 57. Prescriptive Process Models  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.
  • 58. Prescriptive Process Models  Incremental Process Model – RAD Model:
  • 59. Prescriptive Process Models  Incremental Process Model – RAD Model:  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.
  • 60. Prescriptive Process Models  Incremental Process Model – RAD Model:  Data Modeling:  Information gathered from business modeling is used to define data objects that are needed for the business.
  • 61. Prescriptive Process Models  Incremental Process Model – RAD Model:  Process Modeling:  The process model for any changes or enhancements to the data object sets is defined in this phase.
  • 62. Prescriptive Process Models  Incremental Process Model – RAD Model:  Application Generation:  The actual system is built and coding is done by using automation tools to convert process and data models into actual prototypes.
  • 63. Prescriptive Process Models  Incremental Process Model – RAD Model:  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.
  • 64. Prescriptive Process Models  Incremental Process Model – RAD Model:  Advantages:  Changing requirements can be accommodated.  Productivity with fewer people in a short time. Reduced development time.  Encourages customer feedback.
  • 65. Prescriptive Process Models  Incremental Process Model – RAD Model:  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.
  • 66. Prescriptive Process Models  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.
  • 67. Prescriptive Process Models  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.
  • 68. Prescriptive Process Models  Evolutionary Process Model – Prototyping:
  • 69. Prescriptive Process Models  Evolutionary Process Model – Prototyping:  Communication:  Developer and customer meet and discuss the overall objectives of the software.
  • 70. Prescriptive Process Models  Evolutionary Process Model – Prototyping:  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.
  • 71. Prescriptive Process Models  Evolutionary Process Model – Prototyping:  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.
  • 72. Prescriptive Process Models  Evolutionary Process Model – Prototyping:  Construction of prototype:  The prototype is evaluated by the customer itself.
  • 73. Prescriptive Process Models  Evolutionary Process Model – Prototyping:  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.
  • 74. Prescriptive Process Models  Evolutionary Process Model – Prototyping: 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.
  • 75. Prescriptive Process Models  Evolutionary Process Model – Prototyping:  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.
  • 76. Prescriptive Process Models  Evolutionary Process Model – Spiral:  The spiral model combines the idea of iterative development with the systematic, controlled aspects of the waterfall model.
  • 77. Prescriptive Process Models  Evolutionary Process Model – Spiral:
  • 78. Prescriptive Process Models  Evolutionary Process Model – Spiral:  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.
  • 79. Prescriptive Process Models  Evolutionary Process Model – Spiral:  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.
  • 80. Prescriptive Process Models  Evolutionary Process Model – Spiral: Risk Analysis:  Risk Analysis includes identifying, estimating and monitoring the technical feasibility and management risks, such as schedule slippage and cost overrun.
  • 81. Prescriptive Process Models  Evolutionary Process Model – Spiral: Risk Analysis:  After testing the build, at the end of first iteration, the customer evaluates the software and provides feedback.
  • 82. Prescriptive Process Models  Evolutionary Process Model – Spiral:  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.
  • 83. Prescriptive Process Models  Evolutionary Process Model – Spiral:  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.
  • 84. Prescriptive Process Models  Evolutionary Process Model – Spiral:  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.
  • 85. Prescriptive Process Models  Evolutionary Process Model – Spiral:  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.
  • 86. Prescriptive Process Models  Evolutionary Process Model:  Concurrent Development Model:
  • 87. Prescriptive Process Models  Evolutionary Process Model:  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.
  • 88. Prescriptive Process Models  Evolutionary Process Model:  Concurrent Development Model:  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.
  • 89. Prescriptive Process Models  Evolutionary Process Model:  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.
  • 90. Prescriptive Process Models  Evolutionary Process Model:  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.
  • 91. 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
  • 92. 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.
  • 93. 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)
  • 94. Specialized Process Models  Component Based development:  It incorporates many of the characteristics of the spiral model.  It is evolutionary in nature.  It promotes software reusability.
  • 95. Specialized Process Models  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
  • 96. Specialized Process Models  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.
  • 97. Specialized Process Models  Formal Methods Model:  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.
  • 98. Specialized Process Models  Formal Methods Model:  A basis for software verification  To discover and correct errors that might otherwise go undetected.
  • 99. Specialized Process Models  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.
  • 100. Specialized Process Models  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.
  • 101. 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.
  • 102. Introduction to Agility  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
  • 103. Introduction to Agility  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.
  • 104. Introduction to Agility  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.
  • 105. Introduction to Agility  Agile Principles:  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.
  • 106. Introduction to Agility  Agile Principles:  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.
  • 107. Introduction to Agility  Agile Principles:  Continuous attention to technical excellence and good design enhances agility.  Simplicity-the art of maximizing the amount of work not done-is essential.
  • 108. Introduction to Agility  Agile Principles:  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.
  • 109. Introduction to Agility  Agile Principles:  The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • 110. Introduction to Agility  Agile Principles:  The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • 111. Introduction to Agility  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.
  • 112. Introduction to Agility  Extreme Programming  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.
  • 113. Introduction to Agility  Extreme Programming  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.
  • 114. Introduction to Agility  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.
  • 115. Introduction to Agility  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
  • 116. Introduction to Agility  Extreme Programming Values  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.
  • 117. Introduction to Agility  Extreme Programming Values 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.
  • 118. Introduction to Agility  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
  • 119. Introduction to Agility  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.
  • 120. Introduction to Agility  Extreme Programming Process:
  • 121. Introduction to Agility  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.
  • 122. Introduction to Agility  Extreme Programming Process:  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.
  • 123. Introduction to Agility  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.
  • 124. Introduction to Agility  Extreme Programming Practices: 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
  • 125. Introduction to Agility  Extreme Programming Practices: 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.
  • 126. Introduction to Agility  Extreme Programming Practices:  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.
  • 127. Introduction to Agility  Extreme Programming Practices: 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.
  • 128. Introduction to Agility  Extreme Programming Practices: 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.