unit 1.pptx regasts sthatbabs shshsbsvsbsh

SOFTWARE ENGINEERING
Course Code: CS520

Course Out Comes:
CO1: Realize the concepts of software and software process models.
CO2: Analyze and model Software requirements
CO3: Apprise system design concepts and process
CO4: Apprehend software testing strategies
CO5: Comprehend post software deployment activities.

Unit 1
• Software Process
The Nature of Software, The software Process, Software Engineering
Practice, A Generic Process Model, Process Assessment and Improvement,
Prescriptive Process Models, Agile development: Agility, agile process and
principles, Extreme programming.

The Nature of Software
What is Software
• Software
 Computer programs and associated documentation.
 Software products may be developed for a particular customer or may be developed
for a general market.

Where can you find software?
Software is Almost
Everywhere.

Software can define as:
 Instruction – executed provide desire features, function & performance.
 Data structure – to adequately manipulate operation.
 Documents – operation and use of the program.
Software products may be developed for a particular customer or may be developed for a
general market.
 Software products may be
 Generic - developed to be sold to a range of different customers e.g. PC software
such as Excel or Word.
 custom - developed for a single customer according to their specification.

Evolving Role of Software
Software is a product
• Transforms information - produces, manages, acquires, modifies, displays, or
transmits information
• Delivers computing potential of hardware and networks
Software is a vehicle for delivering a product
• Controls other programs (operating system)
• Effects communications (networking software)
• Helps build other software (software tools & environments)

• What is Software Engineering?
Software Engineering is an engineering discipline that is concerned with all
aspects of software production.
Software engineers should adopt a systematic and organized approach to
their work and use appropriate tools and techniques depending on the
problem to be solved, the development constraints and the resources
available

Essential attributes of good software
• Maintainability
Software should be written in such a way so that it can evolve to meet the changing
needs of customers. This is a critical attribute because software change is an inevitable
requirement of a changing business environment.
• Dependability and security
Software dependability includes a range of characteristics including reliability,
security and safety. Dependable software should not cause physical or economic
damage in the event of system failure. Malicious users should not be able to access or
damage the system.

• Efficiency
Software should not make wasteful use of system resources such as
memory and processor cycles. Efficiency therefore includes responsiveness,
processing time, memory utilisation, etc.
• Acceptability
Software must be acceptable to the type of users for which it is designed.
This means that it must be understandable, usable and compatible with
other systems that they use.

Manufacturing vs. Development
(Software has characteristics that are considerably different than those of hardware)
• Once a hardware product has been manufactured, it is difficult or
impossible to modify. In contrast, software products are routinely
modified and upgraded.
• In hardware, hiring more people allows you to accomplish more
work, but the same does not necessarily hold true in software.
• Unlike hardware, software costs are concentrated in design rather
than production.

Software Characteristics
 Software is developed or engineered; it is not manufactured in the classical
sense.
 Software does not “wear out” but it does deteriorate.
 Software continues to be custom built, as industry is moving toward
component based construction.

Failure curve for Software
When a hardware component wears out, it is replaced by a spare part.
There are no software spare parts. Every software failure indicates an error in design or in the
process through which design was translated into machine executable code. Therefore, software
maintenance involves considerably more complexity

Software Application Domains
• System software
• Application software
• Engineering/scientific software
• Embedded software
• Product line software
• Web applications
• Artificial intelligence software

System Software:
• System software is a collection of programs written to service other programs.
• Software is determinate some are indeterminate
• It is characterized by heavy interaction with computer hardware; heavy usage by
multiple users; concurrent operation that requires scheduling, resource sharing, and
sophisticated process management; complex data structures; and multiple external
interfaces.
Ex. Compilers, operating system, drivers etc.

Application Software :
• Application software consists of standalone programs that solve a specific business
need.
• Application software is used to control the business function in real-time.
Engineering /Scientific software:
• Characterized by "number crunching" algorithms.
• Applications range from astronomy to volcanology, from automotive stress analysis to
space shuttle orbital dynamics, and from molecular biology to automated
manufacturing.
Ex: Computer Aided Design (CAD), system stimulation etc.

Embedded Software:
• It resides in read-only memory and is used to control products and systems
• Embedded software can perform limited and esoteric functions.
Ex: keypad control for a microwave oven.
Product line software:
• Designed to provide a specific capability for use by many different customers, product
line software can focus on a limited and esoteric marketplace.
Ex: Word processing, spreadsheet, CG, multimedia, etc.

Web Applications:
• Web apps can be little more than a set of linked hypertext files.
• It evolving into sophisticated computing environments that not only provide
standalone features, functions but also integrated with corporate database
and business applications.
Artificial Intelligence software
• AI software makes use of non-numerical algorithms to solve complex
problems that are not amenable to computation or straightforward analysis
Ex: Robotics, expert system, game playing, etc.

Legacy software
(Older Programs)
• The software must be adapted to meet the needs of new computing environment and
technology
• The software must be enhanced to implement new business requirement.
• The software must be extended to make it interoperable with modern systems or
databases.
• The software must be re-architected to make it viable within a network environment

Software Process
• A set of activities whose goal is the development or evolution of software.
Generic Process Framework Activities
• Communication:
– Heavy communication and collaboration with customers, stakeholders, team
– Encompasses requirements gathering and related activities

• Planning:
– Workflow that is to follow
– Describe technical task, likely risk, resources will require, work products to be produced and a
work schedule.
• Modeling:
– Help developer and customer to understand requirements (Analysis of requirements) & Design of
software
• Construction:
– Code generation: either manual or automated or both
– Testing – to uncover error in the code.
• Deployment:
– Delivery to the customer for evaluation
– Customer provide feedback

Umbrella Activities
• Software project tracking and control
– Assessing progress against the project plan.
– Take adequate action to maintain schedule.
• Formal technical reviews
– Assessing software work products in an effort to uncover and remove errors before
goes into next action or activity.
• Software quality assurance
– Define and conducts the activities required to ensure software quality.

• Software configuration management
– Manages the effects of change.
• Document preparation and production
– Help to create work products such as models, documents, logs, form and list.
• Reusability management
– Define criteria for work product reuse
– Mechanisms to achieve reusable components.
• Measurement
– Define and collects process, project, and product measures
– Assist the team in delivering software that meets customer’s needs.
• Risk management
– Assesses risks that may effect that outcome of project or quality of product (i.e. software)

Software Engineering Practice
The Essence of Practice:
• Understand the problem (communication and analysis).
• Plan a solution (Modeling and software design)
• Carry out the plan(code generation)
• Examine the result of accuracy(testing and quality assurance)

27
Understand the Problem
• Who has a stake in the solution to the problem? That is, who are the
stakeholders?
• What are the unknowns? What data, functions, and features are
required to properly solve the problem?
• Can the problem be compartmentalized? Is it possible to represent
smaller problems that may be easier to understand?
• Can the problem be represented graphically? Can an analysis model
be created?

28
Plan the Solution
• Have you seen similar problems before? Are there patterns that are
recognizable in a potential solution? Is there existing software that implements
the data, functions, and features that are required?
• Has a similar problem been solved? If so, are elements of the solution
reusable?
• Can subproblems be defined? If so, are solutions readily apparent for the
subproblems?
• Can you represent a solution in a manner that leads to effective
implementation? Can a design model be created?

29
Carry Out the Plan
• Does the solution conform to the plan? Is source code traceable to
the design model?
• Is each component part of the solution provably correct? Has the
design and code been reviewed, or better, have correctness proofs
been applied to algorithm?

30
Examine the Result
• Is it possible to test each component part of the solution? Has a
reasonable testing strategy been implemented?
• Does the solution produce results that conform to the data, functions,
and features that are required? Has the software been validated
against all stakeholder requirements?

31
Hooker’s General Principles
• 1: The Reason It All Exists
• 2: Keep It Simple, Stupid!
• 3: Maintain the Vision
• 4: What You Produce, Others Will Consume
• 5: Be Open to the Future
• 6: Plan Ahead for Reuse
• 7: Think!

A Generic Process Model
Definition of Software Process :
• A framework for the activities, actions, and tasks that are required to build
high-quality software.
• SP defines the approach that is taken as software is engineered.
• Is not equal to software engineering, which also encompasses technologies
that populate the process– technical methods and automated tools.

A Software Process Framework
Process framework
Umbrella Activities
Framework activity 1
Framework activity n
Software Process
Framework activities
work tasks
work products
milestones & deliverables
Quality Assurance checkpoints
Process Framework
Umbrella Activities

• As we discussed before, a generic process framework for software
engineering defines five framework activities communication, planning,
modeling, construction, and deployment.
• In addition, a set of umbrella activities- project tracking and control, risk
management, quality assurance, configuration management, technical
reviews, and others are applied throughout the process.
• Next question is: how the framework activities and the actions and tasks
that occur within each activity are organized with respect to sequence and
time? See the process flow for answer

Process Flow
• Linear process flow executes each of the five activities in sequence.
• An iterative process flow repeats one or more of the activities before
proceeding to the next.
• An evolutionary process flow executes the activities in a circular manner.
Each circuit leads to a more complete version of the software.
• A parallel process flow executes one or more activities in parallel with other
activities ( modeling for one aspect of the software in parallel with
construction of another aspect of the software).

Identifying task set
• Before you can proceed with the process model, a key question: what
actions are appropriate for a framework activity given the nature of the
problem, the characteristics of the people and the stakeholders.
• A task set deﬁnes the actual work to be done to accomplish the objectives
of a software engineering action.
• A list of the task to be accomplished.
• A list of the work products to be produced.
• A list of the quality assurance ﬁlters to be applied.

• For example, a small software project requested by one person with simple
requirements, the communication activity might encompass little more than
a phone all with the stakeholder. Therefore, the only necessary action is
phone conversation, the work tasks of this action are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval.

The task sets for Requirements gathering action for a simple project may
include:
1. Make a list of stakeholders for the project.
2. Invite all stakeholders to an informal meeting.
3. Ask each stakeholder to make a list of features and functions required.
4. Discuss requirements and build a ﬁnal list.
5. Prioritize requirements.
6. Note areas of uncertainty

Process Pattern
A process pattern
• describes a process-related problem that is encountered during software
engineering work,
• identiﬁes the environment in which the problem has been encountered, and
• suggests one or more proven solutions to the problem.
• Stated in more general terms, a process pattern provides you with a template a
consistent method for describing problem solutions within the context of the
software process. (deﬁned at different levels of abstraction)
1. Problems and solutions associated with a complete process model (e.g.
prototyping).
2. Problems and solutions associated with a framework activity (e.g. planning) or
3. an action with a framework activity (e.g. project estimating).

Process Pattern Types
• Stage patterns—defines a problem associated with a framework activity for the
process. It includes multiple task patterns as well.
For example: Establishing Communication would incorporate the task pattern
Requirements Gathering and others.
• Task patterns—defines a problem associated with a software engineering action
or work task and relevant to successful software engineering practice
• Phase patterns—define the sequence of framework activities that occur with the
process, even when the overall flow of activities is iterative in nature.
Example includes Sprial Model or Prototyping.

• Initial context – Describes the condition under which the pattern applies
• Problem – the specific problem solved by the pattern
• Solution – describes how to implement process pattern
• Resulting context – describes the condition that will result once the pattern
has been successfully implemented
• Related problem- Provides list of all process pattern that are directly
related to current pattern
• Known uses-Indicate the specific instances in which the pattern and
examples applicable

Process Assessment and Improvement
• Standard CMMI assessment method for process
improvement(SCAMPI)
- provides a five step process assessment model that incorporates initiating,
diagnosing, establishing, acting and learning
• CMM based appraisal for internal process improvement (CBA IPI)
- provides a diagnostic technique for assessing the relative maturity of a
software organization using the SEI CMM.

• SPICE(ISO/IEC 15504)
- standard defines a set of requirements for software process assessment.
The intent of the standard is to assist organizations in developing an
objective evaluation of the efficacy of any defined software process.
• ISO 9001:2000 for software
- is a generic standard that applies to any organization that wants to
improve the overall quality of the products, systems, or services that it
provides. Therefore, the standard is directly applicable to software
organizations and companies.

Software Process Model
• A software process model is a road map that helps you create a timely, high-
quality software.
• Aim to produce a high quality software that meets customer expectation
• Each process model followed the SDLC
• “Describing how to develop, maintain, replace and alter or enhance specific
software”

Prescriptive Process Model
• Prescriptive process models advocate an orderly approach to software
engineering.
i.e Defines a distinct set of activities, actions, tasks, milestones, and work
products that are required to engineer high-quality software
• The activities may be linear, incremental, or evolutionary

• Waterfall Model –represents elements of a linear process flow
• Incremental Model – combines elements of linear and parallel process flows
• Evolutionary Model – follows the evolutionary process flow that combines
elements of linear and iterative process flows
• Prototyping
• Spiral
• Concurrent Model – combines elements of iterative and parallel process
flows

Waterfall Model
• Oldest software lifecycle model
• Proposed by Winston Royce in 1970
• Used when requirements are well understood and risk is low
• Work flow is in a linear (i.e., sequential) fashion

unit 1.pptx regasts sthatbabs shshsbsvsbsh

52
Waterfall Model
(Diagram)
Communication
Project initiation
Requirements gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback

Requirement gathering and Analysis.
• This is the first phase of waterfall model which includes a meeting
with the customer to understand his requirements.
• This is the most crucial phase as any misinterpretation at this
stage may give rise to validation issues later.
• The software definition must be detailed and accurate with no
ambiguities.
• It is very important to understand the customer requirements and
expectations so that the end product meets his specifications.

• Requirement gathering and Analysis phase the basic requirements
of the system must be understood by software engineer, who is also
called ANALYST.
• All this requirements are then well documented and discussed
further with the customer for reviewing.

DESIGN
• The customer requirements are broken down into logical modules for the
ease of implementation. Hardware and software requirements for every
module are Identified and designed accordingly.
• Also the inter relation between the various logical modules is established at
this stage. Algorithms and diagrams defining the scope and objective of
each logical model are developed.
• In short, this phase lays a fundamental for actual programming and
implementation
• It is an intermediate step between requirements analysis and coding.

Design focuses on program attribute such as-
• Data Structure.
• Software Architecture.
• Algorithm Details
etc…….
• The requirements are translated in some easy to represent form using which
coding can be done effectively and efficiently.
• The design needs to be documented for further use.

Coding
• Coding is a step in which design is translated into machine-readable form.
• If design is done in sufficient detail then coding can be done effectively.
Programs are created in this phase.
• In this phase all software divided into small module then after doing coding
for that small module rather than do coding whole software.
• According to design programmers do code and make class and structure of
whole software

Testing
• In this stage, both individual components and the integrated whole are methodically verified to
ensure that they are error-free and fully meet the requirements outlined in the first step.
• In this phase testing whole software into two parts
1) HARDWARE
2) SOFTWARE.

Maintenance
• This is the final phase of the waterfall model, in which the completed
software product is handed over to the client after alpha, beta testing.
• After the software has been deployed on the client site, it is the duty of the
software development team to undertake routine maintenance activities by
visiting the client site.
• If the customer suggests changes or enhancements the software process has
to be followed all over again right from the first phase i.e. requirement
analysis.
• The usually the longest stage of the software. In this phase the software is
updated to:

• Meet the changing customer needs
• Adapted to accommodate changes in the external environment
• Correct errors and oversights previously undetected in the testing phases
• Enhancing the efficiency of the software
Observe that feed back loops allow for corrections to be incorporated into
the model.

When to use the Waterfall Model
• Requirements are very well known
• Product definition is stable
• Technology is understood
• New version of an existing product
• Porting an existing product to a new platform.

62
Waterfall Model
(Problems)
• Doesn't support iteration, so changes can cause confusion
• Difficult for customers to state all requirements explicitly and up front
• Requires customer patience because a working version of the program
doesn't occur until the final phase

Advantages
• Easy to understand, easy to use
• Provides structure
• Milestones are clear
• Good for management control (plan, staff, track)
• Works well when quality is more important than cost or schedule

Disadvantages
• All requirements must be known upfront
• Deliverables created for each phase are considered frozen – inhibits flexibility
• Can give a false impression of progress
• Does not reflect problem-solving nature of software development , i.e. iterations
of phases
• One big integration at the end
• Little opportunity for customer to preview the system (until it may be too late)

V Model:
• A variation of the waterfall model
• It is also known as Verification and Validation model.
• It is based on association of a testing phase for each corresponding
development stage.
• For every single phase in the development cycle there is a directly
associated testing phase.
• This is a highly disciplined model and next phase starts only after
completion of the previous phase.

• A variant of the Waterfall that emphasizes the verification and validation of
the product.
• Testing of the product is planned in parallel with a corresponding phase of
development.
STEPS
• Project and Requirements Planning – allocate resources
• Product Requirements and Specification Analysis – complete
specification of the software system
• Architecture or High-Level Design – defines how software functions
fulfill the design

• Detailed Design – develop algorithms for each architectural component.
• Production, operation and maintenance – provide for enhancement and
corrections.
• System and acceptance testing – check the entire software system in its
environment.
• Integration and Testing – check that modules interconnect correctly.
• Unit testing – check that each module acts as expected.
• Coding – transform algorithms into software.

• Unit testing
 The most ‘micro’ scale of Testing
The units are tested in isolation.
 Ensures the component is working according to the detailed design/build
specifications of the module.
 Not to be confused with debugging.
 Also known as component, module, or program testing.

• Integration Testing
 Testing of more than one (tested) unit together to determine if they function correctly.
It is done using the integration test design prepared during the architecture design
phase.
 Helps assembling incrementally a whole system, ensuring the correct ‘flow’ of data
from the first through the final component.
 Done by developers/designers and testers in collaboration
 Also called Interface Testing or Assembly Testing.

System testing
Testing the system as a whole - Black-box type testing that is based on overall requirements
specifications; covers all combined parts of a system.
 Ensures that system meets all functional and business requirements.
 Focus
 Verifying that specifications are met
 Validating that the system can be used for the intended purpose
 The system test design is derived from the system design documents and is used in this phase.
 It can involve a number of specialized types of tests to check performance, stress, documentation etc.
Sometimes testing is automated using testing tools.
 Done by Independent testing group

• Acceptance testing
 To determine whether a system satisfies its acceptance criteria and business
requirements or not.
 Similar to System testing in that the whole system is checked, but the important
difference is the change in focus.
 Done by real business users.
 It enables the customer to determine whether to accept the system or not.
 Also called as Beta Testing, Application Testing or End User Testing.
 Approach
 Should be performed in real operating environment .
 Customer should be able to perform any test based on their business processes.
 Final Customer sign-off.

V-Shaped Strengths
• Emphasize planning for verification and validation of the product in early
stages of product development
• Each deliverable must be testable
• Project management can track progress by milestones
• Easy to use

V-Shaped Weaknesses
• Does not easily handle concurrent events
• Does not handle iterations or phases
• Does not easily handle dynamic changes in requirements
• Does not contain risk analysis activities

When to use the V-Shaped Model
• Excellent choice for systems requiring high reliability – hospital patient
control applications
• All requirements are known up-front
• When it can be modified to handle changing requirements beyond analysis
phase
• Solution and technology are known.
• The V-shaped model should be used for small to medium sized projects
where requirements are clearly defined and fixed.

• The V-Shaped model should be chosen when technical resources are
available with needed technical expertise.
• High confidence of customer is required for choosing the V-Shaped model
approach.
• Since, no prototypes are produced, there is a very high risk involved in
meeting customer expectations.

Incremental Process Model
• All requirement knows
• Combines the advantages of both waterfall and prototype models.
• System will be delivered in parts
• Work flow is in a linear (i.e., sequential) fashion within an increment and is
staggered between increments

Incremental Process Steps
1. Customer identify—services provided by the system.
2. Then identify which of the services are most important and which are least important.
3. No of delivery increments are then identified with sub-set of the system functionality .
4. Highest priority services delivered first.
5. Requirements for the first increment are defined in detail
6. First Increment is developed and delivered ..customer can put into service.(Benefit for
customer?)
7. During development ….further requirements analysis for later increments can take place

It basically:
• Divides the overall project into a number of increments.
• Then it applies the waterfall model to each increment.
• The system is put into production when the first increment is delivered.
• As time passes additional increments are completed and added to the working system
Build2
build1
build3
Whole
requirement

• Software releases in increments
• 1st increment constitutes Core product
• Basic requirements are addressed
• Core product undergoes detailed evaluation by the customer
• As a result, plan is developed for the next increment
Plan addresses the modification of core product to better meet the needs of
customer
• Process is repeated until the complete product is produced

Advantages:
• Generates working software quickly and early during the software life
cycle.
• This model is more flexible – less costly to change scope and requirements.
• It is easier to test and debug during a smaller iteration.
• In this model customer can respond to each built.
• Lowers initial delivery cost.
• Easier to manage risk because risky pieces are identified and handled
during it’s iteration.

Disadvantages:
• Needs good planning and design.
• Needs a clear and complete definition of the whole system before it can be
broken down and built incrementally.
• Total cost is higher than waterfall.

When to use the Incremental model
• When the requirements of the complete system are clearly defined and
understood.
• Major requirements must be defined; however, some details can evolve
with time.
• There is a need to get a product to the market early.
• A new technology is being used Resources with needed skill set are not
available
Problem :
• User inconveniency

Evolutionary Process Model
Prototyping Model
• When a customer defines a set of general objectives for a software but does not identify detailed I/O or
processing requirements.
• A prototype is built to understand the requirements.
• By using this prototype, the client can get an “actual feel” of the system
• The interactions with prototype can enable the client to better understand the requirements of the desired
system.
• Prototyping is an attractive idea for complicated and large systems
Consists of 4 iterating phases:
• Requirements gathering.
• Design and build SW prototype.
• Evaluate prototype with customer.
• Refine requirements.

• Follows an evolutionary and iterative approach
• Used when requirements are not well understood
• Serves as a mechanism for identifying software requirements
• Focuses on those aspects of the software that are visible to the
customer/user
• Feedback is used to refine the prototype

Advantages:
• Users are actively involved in the development
• Users get a better understanding of the system being developed.
• Errors can be detected much earlier.
• Quicker user feedback is available leading to better solutions.

Disadvantages:
• Practically, this methodology may increase the complexity of the system as
scope of the system may expand beyond original plans.
• Incomplete application may cause application not to be used as the full
system was designed.
• Incomplete problem analysis.

Problems
• The customer sees a "working version" of the software, wants to stop all
development and then buy the prototype after a "few fixes" are made
• Developers often make implementation compromises to get the software
running quickly (e.g., language choice, user interface, operating system
choice, inefficient algorithms)

When to use Prototype Model
• Prototype model should be used when the desired system needs to have a
lot of interaction with the end users.
• Typically, online systems, web interfaces have a very high amount of
interaction with end users, are best suited for Prototype model.
• They are excellent for designing good human computer interface systems

Spiral Model
• Invented by Dr. Barry Boehm in 1988
• Follows an evolutionary approach
• similar to the incremental model,

• It couples the iterative nature of prototyping with the controlled and
systematic aspects of the waterfall model and is a risk-driven process
model generator that is used to guide multi-stakeholder concurrent
engineering of software intensive systems.
• Two main distinguishing features: one is cyclic approach for incrementally
growing a system’s degree of definition and implementation while
decreasing its degree of risk. The other is a set of anchor point milestones
for ensuring stakeholder commitment to feasible and mutually satisfactory
system solutions.

Planning Phase
• Requirements are gathered(BRS &SRS)
Risk Analysis:
• a process is undertaken to identify risk and alternate solutions.
• A prototype is produced at the end of the risk analysis phase.
Engineering Phase :
• software is developed,
• Testing at the end of the phase
Evaluation phase:
• This phase allows the customer to evaluate the output of the project to date
before the project continues to the next spiral.

Advantages :
• High amount of risk analysis hence, avoidance of Risk is enhanced.
• Good for large and mission-critical projects.
• Strong approval and documentation control.
• Additional Functionality can be added at a later date.
• Software is produced early in the software life

Disadvantages :
• Can be a costly model to use.
• Risk analysis requires highly specific expertise.
• Project’s success is highly dependent on the risk analysis phase.
• Doesn’t work well for smaller projects.

When to use Spiral model:
• When costs and risk evaluation is important
• For medium to high-risk projects
• Long-term project commitment unwise because of potential changes to
economic priorities
• Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected

• The concurrent process model sometimes called concurrent engineering
allows to a software team to represent iterative and concurrent elements of
any process model.
• This model is suited to all types of software but is generally used for client
server applications
• In real life the software development activities do not take place in
sequence
• Most activities will be going on concurrently but reside in different states.
• The states will change when some event occurs. So in this model all the
activities are shown along with their states at any point of time.
• As time goes on the states of the activities will change.
• It provides an accurate picture of the current state of a project.

• It defines software engineering as a network of activities each in a different
state, each dependent on one another and each going on concurrently.
• Awaiting changes state – after the completion of the 1st iteration
(communication activity)
• None state – while initial communication is carried out (modeling activity)
• Under development state – after the communication is completed.
• Awaiting changes state – if any changes in the requirement must be made

A FINAL COMMENT ON EVOLUTIONARY PROCESS
• Difficult in project planning
• Speed of evolution is not known
• Does not focus on flexibility and extensibility (more emphasis on high
quality)
• Requirement is balance between high quality and flexibility and
extensibility

Waterfall vs Spiral:
• The sequential nature of the waterfall model if a bug is found or an error is incurred for a
preliminary reason, we need to start from the scratch again.
• Whereas, under spiral model every prototype is tried and tested and hence the chances of
find errors at later stages are very rare.
• In spiral model, we can easily adjust the software development with the required changes.
• The prototypes which are created in every stage, enables us to roll back only a few steps.
• Waterfall model the stages are executed under a sequential flow. Every new phase is
processed only after completing the previous phase.

Incremental Vs Spiral:
• Incremental Development is a practice where the system functionalities are sliced into increments
(small portions).
• In each increment, a vertical slice of functionality is delivered by going through all the activities
of the software development process, from the requirements to the deployment.
• Incremental Development (adding) is often used together with Iterative Development (redo) in
software development. This is referred to as Iterative and Incremental Development (IID).
• The spiral model is similar to the incremental model, with more emphases placed on risk analysis.
• A software project repeatedly passes through these phases in iterations (called Spirals in this
model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is
assessed.

Prototype Model Vs Spiral Model:
• Prototype model is suitable when the requirement of the client is not clear and it is supposed to be
changed. It doesn’t cover any risk management. While Spiral model is an enhancement of the
prototyping model with so many extra features.
• Spiral model is called a meta model. Spiral model is made with the features of Prototype model and
Waterfall model. Spiral model takes special care about Risk Analysis.
Where as it is not given importance in Prototype model.
• Prototype model that end when software is delivered after software deliver is not responsible for any
problem of software.
• The spiral model can be adapt to apply throughout the life of computer software.

107
Still Other Process Models
• Component based development—the process to apply when reuse is a
development objective
• Formal methods—emphasizes the mathematical specification of
requirements
• Aspects Oriented Software Development—provides a process and
methodological approach for defining, specifying, designing, and
constructing aspects
• Unified Process—a “use-case driven, architecture-centric, iterative and
incremental” software process closely aligned with the Unified Modeling
Language (UML)

108
Principles that Guide Software Process &
Practice

Software Engineering Knowledge
You often hear people say that software development knowledge has a 3-year half-life i.e
half of what you need to know today will be obsolete within 3 years.
In the domain of technology-related knowledge, that’s probably about right.
But there is another kind of software development knowledge—a kind that I think of as
"software engineering principles"—that does not have a three-year half-life.
These software engineering principles are likely to serve a professional programmer
throughout his or her career.
Steve McConnell

Principles that Guide Process
• Principle #1. Be agile. Whether the process model you choose is prescriptive or agile, the
basic tenets of agile development should govern your approach.
• Principle #2. Focus on quality at every step. The exit condition for every process activity,
action, and task should focus on the quality of the work product that has been produced.
• Principle #3. Be ready to adapt. Process is not a religious experience and dogma has no
place in it. When necessary, adapt your approach to constraints imposed by the problem, the
people, and the project itself.
• Principle #4. Build an effective team. Software engineering process and practice are
important, but the bottom line is people. Build a self-organizing team that has mutual trust
and respect.

111
Principles that Guide Process …
• Principle #5. Establish mechanisms for communication and coordination. Projects fail
because important information falls into the cracks and/or stakeholders fail to coordinate
their efforts to create a successful end product.
• Principle #6. Manage change. The approach may be either formal or informal, but
mechanisms must be established to manage the way changes are requested, assessed,
approved and implemented.
• Principle #7. Assess risk. Lots of things can go wrong as software is being developed. It’s
essential that you establish contingency plans.
• Principle #8. Create work products that provide value for others. Create only those work
products that provide value for other process activities, actions or tasks.

Principles that Guide Practice
• Principle #1. Divide and conquer. Stated in a more technical manner, analysis and
design should always emphasize separation of concerns (SoC).
• Principle #2. Understand the use of abstraction. At it core, an abstraction is a
simplification of some complex element of a system used to communication meaning
in a single phrase.
• Principle #3. Strive for consistency. A familiar context makes software easier to use.
• Principle #4. Focus on the transfer of information. Pay special attention to the
analysis, design, construction, and testing of interfaces.

Principles that Guide Practice….
• Principle #5. Build software that exhibits effective modularity. Separation
of concerns (Principle #1) establishes a philosophy for software. Modularity
provides a mechanism for realizing the philosophy.
• Principle #6. Look for patterns. Brad Appleton [App00] suggests that: “The
goal of patterns within the software community is to create a body of literature
to help software developers resolve recurring problems encountered
throughout all of software development.
• Principle #7. When possible, represent the problem and its solution from
a number of different perspectives.
• Principle #8. Remember that someone will maintain the software.

The Manifesto for
Agile Software Development
“We are uncovering better ways of developing software by doing it and helping others do it. Through this
work we have come to value:
•Individuals and interactions over processes and tools
•Working software over comprehensive documentation
•Customer collaboration over contract negotiation
•Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
Kent Beck et al

116
What is “Agility”?
• Effective (rapid and adaptive) response to change
• Effective communication among all stakeholders
• Drawing the customer onto the team
• Organizing a team so that it is in control of the work performed
Yielding …
• Rapid, incremental delivery of software

117
Agility and the Cost of Change

118
An Agile Process
• Is driven by customer descriptions of what is required (scenarios)
• Recognizes that plans are short-lived
• Develops software iteratively with a heavy emphasis on construction activities
• Delivers multiple ‘software increments’
• Adapts as changes occur

Agility Principles
1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change
for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development
team is face–to–face conversation.

Agility Principles ……
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self–organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.

Human Factors
the process molds to the needs of the people and team, not the other way around
• key traits must exist among the people on an agile team and the team itself:
– Competence. ( talent, skills, knowledge)
– Common focus. ( deliver a working software increment )
– Collaboration. ( peers and stakeholders)
– Decision-making ability. ( freedom to control its own destiny)
– Fuzzy problem-solving ability.(ambiguity and constant changes, today problem may not be
tomorrow’s problem)
– Mutual trust and respect.
– Self-organization. ( themselves for the work done, process for its local environment, the
work schedule)

Extreme Programming (XP)
• The most widely used agile process, originally proposed by Kent Beck
• XP Planning
– Begins with the creation of “user stories”
– Agile team assesses each story and assigns a cost
– Stories are grouped to for a deliverable increment
– A commitment is made on delivery date
– After the first increment “project velocity” is used to help define subsequent delivery
dates for other increments

 XP Design
Follows the Keep It Simple principle (The Keep it simple principle states that most systems work best
if they are kept simple)
Encourage the use of CRC cards (Class-responsibility-collaboration (CRC) cards are a brainstorming
tool used in the design of object-oriented software.)
For difficult design problems, suggests the creation of “spike solutions”—a design prototype (Build
the spike to only addresses the problem under examination and ignore all other concerns).
Encourages “refactoring”—an iterative refinement of the internal program design
 XP Coding
Recommends the construction of a unit test for a store before coding commences
Encourages “pair programming” (two people collaborate in programming)
 XP Testing
All unit tests are executed daily
“Acceptance tests” are defined by the customer and executed to assess customer visible
functionality

unit t est
cont inuous int egrat ion
accept ance t est ing
pair
programming
R
elease
user st ories
values
accept ance t est crit eria
it erat ion plan
simple design
C
R
C cards
spike solut ions
prot ot ypes
ref act oring
sof t w are increment
proj ect v elocit y comput ed

END OF UNIT-1
• What we understood
– Difference between SE and Other decipline
– SE Process and Practices (Conventional
– Different Process models
– SE core Principles
– Agile development concepts and principles
– Extreme Programming.
125

unit 1.pptx regasts sthatbabs shshsbsvsbsh

More Related Content

Similar to unit 1.pptx regasts sthatbabs shshsbsvsbsh (20)

More from sagarjsicg (7)

Recently uploaded (20)

unit 1.pptx regasts sthatbabs shshsbsvsbsh

Editor's Notes