Unit 1 Process Models; and Agile Development
CHAPTER I Software and Software Engineering
CHAPTER 2 the Software Process Models
CHAPTER 3 Agile Process Model
CHAPTER I Software and Software Engineering
Q.1 what is 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) documentation that describes the operation and use of the programs.
Q.2 Define Nature of the Software
Software delivers the most important product of our time-information. It transforms personal data, it
manages business information to enhance competitiveness, and it provides a gateway to worldwide
information networks and provides the means for acquiring information in all of its forms
Q.3 Explain Characteristic of Software Engineering
Mainly Three Characteristics of Software Which Listed and Explain Below
 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 is developed or engineered; it is not manufactured in
the classical sense.
Although some similarities exist between software envelopment and hardware manufacturing the two
activities is fundamentally different in both Activities, high quality is achieved through good design, but
the manufacturing Phase for hardware can introduce quality problem
Both activities are dependent on people, but the relationship between people applied and work
accomplished is both activities require the construction of a "product," but the approaches are different
This means that software projects cannot be managed as if they were manufacturing projects.
Software doesn't "wear out."
Often called the "bathtub curve," indicates that hardware exhibits relatively high failure rates early in its
life (these failures are often attributable to design or manufacturing defects); defects are corrected and
the failure
Rate drops to a steady-state level (hopefully, quite low) for some period of Time. As time passes,
however, the failure rate rises again as hardware components Suffer from the cumulative effects of
dust, vibration, abuse, and temperature Extremes and many other environmental maladies. Stated
simply, the hardware begins to wear out.
We can say that Hardware effect the Environments and Software doesn’t
Although the industry is moving toward component-based
construction, most software continues to be custom-built.
As an engineering discipline evolves a, collection of standard design Components Is created Standard
screws and off-the-shelf integrated circuits are only two of thousands of standard components that are
used by mechanical and electrical engineers Design the new System
A software component should be designed and implemented so that it can be reused in many different
programs. Modern reusable component
Q.4 Explain Types of Software or Different Software Application
Today, seven broad categories of computer software present continuing challenges for software engineers







system software
application software
engineering/scientific software
embedded software
product-line software
WebApps (Web applications)
AI software
System software-a collection of programs written to service other programs system software-a
collection of programs written to service other programs some system software g., compilers, editors,
and file management, operating system components, drivers, networking the systems software area is
characterized by heavy interaction with computer hardware hevily y usage by multiple users
Application software-stand-alone programs that solve a specific business Applications in this area
process business or technical data in a way facilitates business operations or management technical
decision
Engineering /scientific software - has been characterized by number “crunching" algorithms.
Applications range from astronomy to volcanology, from automotive stress analysis to space shuttle
orbital dynamics, and computer-aided design, system simulation example of Engineering /scientific
software which take real time input
Embedded software-resides within a product or system and is used to implement and control features
and functions for the end user and for the system itself. Embedded software can perform limited and
esoteric functions (e.g., key pad control for a microwave oven (e.g., digital functions in an automobile
such as fuel control, dashboard displays, and breaking systems its example of embedded system which
perform Specific task.
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 (e.g., inventory control products
or address mass consumer markets (e.g., word processing, spreadsheets, computer graphics'
multimedia, entertainment, database management, and personal system these all Are example of
Product-line software
Web applications- called “webApps," this network-centric software category Spans wide array of
applications. In their simples it form, WebApp be little more than a set of linked hypertext files that
present information using text and limited graphics that Provides integrated with corporate databases
and business application
Artificial intelligence software-makes use of no numerical algorithms to solve complex problems that is
not amenable to computation or straightforward Analysis Applications within this area include robotics,
expert systems pattern recognition (image and voice), artificial neural networks, theorem proving, and
game Playing.
Other Systems:-




Open world computing—pervasive, distributed computing
Ubiquitous computing—wireless networks
Netsourcing—the Web as a computing engine
Open source—”free” source code open to the computing community (a blessing, but also a
potential curse!)
 Data mining
 Grid computing
 Cognitive machines
 Software for nanotechnologies
Q.5 Explain Legacy Software
Why must it change?
 Software must be adapted to meet the needs of new computing environments or
technology.
 Software must be enhanced to implement new business requirements.
 Software must be extended to make it interoperable with other more modern systems
or databases.
 Software must be re-architected to make it viable within a network environment.
Q.6 what is Software Engineering
 Some realities:

a concerted effort should be made to understand the problem before a software
solution is developed
 design becomes a pivotal activity
 software should exhibit high quality
 software should be maintainable
 The seminal definition:
 [Software engineering is] the establishment and use of sound engineering principles in
order to obtain economically software that is reliable and works efficiently on real
machines.
 The IEEE definition:
 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).
Q.7 give the Details of a Layered Technology for Software Engineering
Software Engineering Layered Consists:-
Software engineering tools provide automated or semi automated support for the Process and the
methods When tools are integrated so that information created by one tool can be used by another, a
system for the support of software development' Computer aided Software engineering
Software engineering methods provide the technical how-to's for building software. Methods
encompass a broad array of tasks that include communication, Requirements analysis, design modeling,
program construction, testing, and support.
The foundation for software engineering is the process layer. The software engineering Process is the
glue that holds the technology layers together and enables Rational and timely development of
computer software. The software process forms the basis for management control of software projects.
It’s Design Work Products such as (models, documents, data, reports, forms, etc.).
Software engineering is a layered technology Focus on Quality that include Total quality management, six
sigma, that Control software Design which affected to the customer
Q.8 Explain Framework Activities in details
Framework Activities
 Communication
 Planning
 Modeling
 Analysis of requirements
 Design
 Construction
 Code generation
 Testing
 Deployment
Communication Before any technical work can commence, it is critically important to communicate and
collaborate with the customer (and other Stakeholders the intent is to understand stakeholders,
objectives for the Project and to gather requirements that help define software features and Functions
Planning any complicated journey can be simplified if a map exists. A software project is a complicated
journey, and the planning activity. The MAP called Software Project Plane which include Schedule of
Project and also include Risk Assessment and Management.
Modeling whether you're a landscaper, a bridge builder, an aeronautical Engineer, a carpenter, or an
architect, you work with models every day. A software engineer does the same thing by creating models
to better understand software requirements and the design
Construction this activity combines code generation (either manual or automated) and the testing that
is required uncovering errors in the code.
Deployment The software (as a complete entity or as a partially completed Increment) is delivered to
the customer who evaluates the delivered Product and provides feedback based on the evaluation.
Q.9 List out and Explain umbrella Activities








Software project management
Formal technical reviews
Software quality assurance
Software configuration management
Work product preparation and production
Reusability management
Measurement
Risk management
Q.10 List out S/W Myths
Some Myths are Management Myths and Customer Myths and Practitioners Myths
CHAPTER 2 the Software Process Models
Q.1 Define Different Process Flow
Q.2 what is Process Pattern? Explain its type in detail
 A process pattern
 describes a process-related problem that is encountered during software engineering
work,
 identifies 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 [Amb98]—a consistent
method for describing problem solutions within the context of the software process
 Stage patterns—defines a problem associated with a framework activity for the process.
 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.
Q.3 what is Prescriptive Process Models? Explain its each Process Models in details
 Prescriptive process models advocate an orderly approach to software engineering
That leads to a few questions …
 If prescriptive process models strive for structure and order, are they inappropriate for a
software world that thrives on change?
 Yet, if we reject traditional process models (and the order they imply) and replace them with
something less structured, do we make it impossible to achieve coordination and coherence in
software work?
Common Prescriptive Models are:The Waterfall Model
The V-Model
The Incremental Model
The Waterfall Model:-
Com m unic a t ion
proje c t init ia t ion
re quire m e nt ga t he ring
Planning
es timating
sc heduling
track ing
Mode ling
analysis
design
Const r uc t ion
code
t est
De ploy m e nt
de liv e ry
s upport
f e e dba c k
There are times when the requirements for a problem are well understood-when Work flows from
communication through development in a reasonably linear fashion.
This situation s sometimes called Enhancement of exiting system.
The waterfall Models sometimes called the classic life cycle, suggest systematic sequential approach
software development that begins with customer specification of requirements progresses the planning,
modeling construction and deployment of the Completed the Software
The V-Model:-
A variation in the representation of the waterfall model is called the V-model) depicts the relationship of
quality
In Waterfall Model flow are sequential you can’t back the process whenever you not finish the first cycle
but in V model support the back Process flow during the process of action
As software team moves down the left side of the v as a software team moves down the left side of the
v representations of the problem and its solution' Once code has been generate the team moves up the
right side of the v that validate each of the models created as the team moved down the left side there
is no fundamental difference between the classic life cycle and the V-model The V-model provides a way
of visualizing how verification and validation actions are applied to earlier engineering work.
The Following Problems in Waterfall Models: Changes can cause confusion as the project team proceeds
 It is often difficult for the customer states all requirements explicitly
 The customer have make the patience until not Produce Working versions of S/W
These problems are solved in different Process Models
The Incremental Model:-
increment # n
Co m m u n i c a t i o n
Pla nning
M odeling
a na ly s i s
d es ig n
Co n s t ru c t i o n
c ode
t es t
De p l o y m e n t
d e l i v e ry
fe e dba c k
deliv ery of
nt h increment
increment # 2
Co m m u n i c a t i o n
Pla nning
M odeling
a na l y s i s
d es i gn
Co n s t ru c t i o n
c o de
De p l o y m e n t
t es t
d e l i v e ry
fe e dba c k
increment # 1
deliv ery of
2nd increment
Co m m u n i c a t i o n
Pla nning
M odeling
an a l y s i s
de s i gn
Co n s t ru c t i o n
c od e
De p l o y m e n t
t es t
d e l i v e ry
fe e dba c k
deliv ery of
1st increment
project calendar t ime
•
•
•
•
Used when requirements are well understood
Multiple independent deliveries are identified
Work flow is in a linear and Parallel (i.e., sequential) fashion within an increment and is
staggered between increments
Iterative in nature; focuses on an operational product with each increment
•
•
•
•
Provides a needed set of functionality sooner while delivering optional components later
Useful also when staffing is too short for a full-scale development
Focus on no of increments
Every Increments produce new features of software
Q.4 what is Evolutionary Process Models? Explain its each Process Models in details
Evolutionary Process Models when System is Complex and Requirement change over time. Also useful
when make complete Software. Evolutionary Process Models are following the iterative flow Process
Common Prescriptive Models are:


Prototyping Process Model
The Spiral Process Model
Concurrent Process Model
Prototyping Process Model:-
•
•
•
•
•
•
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
Better for stakeholder when Requirements are fuzzy
•
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)
Lesson learned
– Define the rules up front on the final disposition of the prototype before it is built
– In most circumstances, plan to discard the prototype and engineer the actual
production software with a goal toward quality
•
•
The Spiral Process Model:-
planning
estimation
scheduling
risk analysis
communication
modeling
analysis
design
start
deployment
delivery
feedback
construction
code
test
•
•
•
•
•
•
•
•
Invented by Dr. Barry Boehm in 1988 while working at TRW
Follows an evolutionary approach
Used when requirements are not well understood and risks are high
Inner spirals focus on identifying software requirements and project risks; may also incorporate
prototyping
Outer spirals take on a classical waterfall approach after requirements have been defined, but
permit iterative growth of the software
Operates as a risk-driven model…a go/no-go decision occurs after each complete spiral in order
to react to risk determinations
Requires considerable expertise in risk assessment
Serves as a realistic model for large-scale software development
Concurrent Process Model:-
none
Modeling act ivit y
represent s t he st at e
of a sof t ware engineering
act ivit y or t ask
Under
development
A wait ing
changes
Under review
Under
revision
Baselined
Done
General Weaknesses of Evolutionary Process Models:1) Prototyping poses a problem to project planning because of the uncertain number of iterations
required to construct the product
2) Evolutionary software processes do not establish the maximum speed of the evolution
• If too fast, the process will fall into chaos
• If too slow, productivity could be affected
3) Software processes should focus first on flexibility and extensibility, and second on high quality
• We should prioritize the speed of the development over zero defects
• Extending the development in order to reach higher quality could result in late delivery
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
 AOSD—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)
Component-based Development Model:•
•
•
Consists of the following process steps
– Available component-based products are researched and evaluated for the application
domain in question
– 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
Relies on a robust component library
Capitalizes on software reuse, which leads to documented savings in project cost and time
Formal Methods Model:•
•
•
Development of formal methods is currently quite time-consuming and expensive
Because few software developers have the necessary background to apply formal methods,
extensive training is required
It is difficult to use the models as a communication mechanism for technically unsophisticated
customers
The Unified Process (UP) Process Models:-
•
•
•
Birthed during the late 1980's and early 1990s when object-oriented languages were gaining
wide-spread use
Many object-oriented analysis and design methods were proposed; three top authors were
Grady Booch, Ivar Jacobson, and James Rumbaugh
They eventually worked together on a unified method, called the Unified Modelling Language
(UML)
– UML is a robust notation for the modeling and development of object-oriented systems
– UML became an industry standard in 1997
– However, UML does not provide the process framework, only the necessary technology
for object-oriented development
Inception Phase:•
•
•
•
•
Encompasses both customer communication and planning activities of the generic process
Business requirements for the software are identified
A rough architecture for the system is proposed
A plan is created for an incremental, iterative development
Fundamental business requirements are described through preliminary use cases
– A use case describes a sequence of actions that are performed by a user
Elaboration Phase:•
•
•
Encompasses both the planning and modeling activities of the generic process
Refines and expands the preliminary use cases
Expands the architectural representation to include five views
•
•
– Use-case model
– Analysis model
– Design model
– Implementation model
– Deployment model
Often results in an executable architectural baseline that represents a first cut executable
system
The baseline demonstrates the viability of the architecture but does not provide all features and
functions required to use the system
Construction Phase:•
•
•
•
•
Encompasses the construction activity of the generic process
Uses the architectural model from the elaboration phase as input
Develops or acquires the software components that make each use-case operational
Analysis and design models from the previous phase are completed to reflect the final version of
the increment
Use cases are used to derive a set of acceptance tests that are executed prior to the next phase
Transition Phase:•
•
•
•
Encompasses the last part of the construction activity and the first part of the deployment
activity of the generic process
Software is given to end users for beta testing and user feedback reports on defects and
necessary changes
The software teams create necessary support documentation (user manuals, trouble-shooting
guides, installation procedures)
At the conclusion of this phase, the software increment becomes a usable software release
Production Phase:• Encompasses the last part of the deployment activity of the generic process
• On-going use of the software is monitored
• Support for the operating environment (infrastructure) is provided
• Defect reports and requests for changes are submitted and evaluated
Q.5 Give the short note in PSP
PSP stands for Personal Software Process
 Planning. This activity isolates requirements and develops both size and resource estimates. In
addition, a defect estimate (the number of defects projected for the work) is made. All metrics
are recorded on worksheets or templates. Finally, development tasks are identified and a
project schedule is created.
 High-level design. External specifications for each component to be constructed are developed
and a component design is created. Prototypes are built when uncertainty exists. All issues are
recorded and tracked.
 High-level design review. Formal verification methods (Chapter 21) are applied to uncover errors
in the design. Metrics are maintained for all important tasks and work results.
 Development. The component level design is refined and reviewed. Code is generated,
reviewed, compiled, and tested. Metrics are maintained for all important tasks and work results.
Postmortem. Using the measures and metrics collected (this is a substantial amount of data that should
be analyzed statistically), the effectiveness of the process is determined. Measures and metrics should
provide guidance for modifying the process to improve its effectiveness
Q.6 Give the short note in TSP
Team Software Process
 Build self-directed teams that plan and track their work, establish goals, and own their processes
and plans. These can be pure software teams or integrated product teams (IPT) of three to
about 20 engineers.
 Show managers how to coach and motivate their teams and how to help them sustain peak
performance.
 Accelerate software process improvement by making CMM Level 5 behavior normal and
expected.
 The Capability Maturity Model (CMM), a measure of the effectiveness of a software
process, is discussed in Chapter 30.
 Provide improvement guidance to high-maturity organizations.
 Facilitate university teaching of industrial-grade team skills.
CHAPTER 3 Agile Process Model
Q.1 Give the short Agile Process Model in detail
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
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
Agility and the Cost of Change:-
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 – I: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.
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.
Agile Process Models:There are three main Agile Process Models
 Extreme Programming (XP)
 Adaptive Software Development
 Scrum
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) Process steps: XP Design
 Follows the KIS principle
 Encourage the use of CRC cards Class Responsibility Collaborator (see Chapter 8)
 For difficult design problems, suggests the creation of “spike solutions”—a design
prototype
 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”
 XP Testing
 All unit tests are executed daily
 “Acceptance tests” are defined by the customer and excuted to assess customer visible
functionality
simple design
CRC cards
spike solut ions
prot ot ypes
user st ories
values
accept ance t est crit eria
it erat ion plan
refact oring
pair
programming
Release
sof t ware increment
project velocit y comput ed
unit t est
cont inuous int egrat ion
accept ance t est ing
Adaptive Software Development Process Model: Originally proposed by Jim Highsmith
 ASD — distinguishing features
 Mission-driven planning
 Component-based focus
 Uses “time-boxing” (See Chapter 24)
 Explicit consideration of risks
 Emphasizes collaboration for requirements gathering
 Emphasizes “learning” throughout the process
adapt ive cycle planning
uses mission st at ement
project const raint s
basic requirement s
Requirement s gat hering
JAD
mini-specs
t ime-boxed release plan
Release
sof t ware increment
adjust ment s f or subsequent cycles
component s implement ed/ t est ed
f ocus groups f or f eedback
f ormal t echnical reviews
post mort ems
Scrum: Originally proposed by Schwaber and Beedle
 Scrum—distinguishing features
 Development work is partitioned into “packets”
 Testing and documentation are on-going as the product is constructed
 Work occurs in “sprints” and is derived from a “backlog” of existing requirements
 Meetings are very short and sometimes conducted without chairs
 “demos” are delivered to the customer with the time-box allocated