A.

Nature of Software
B. Software Process
C. Software Engineering Practice
D. Software Myths
E. Generic Process model
F. Process Assessment and Improvement
G. Perspective Process Models
H. Specialized Process Models
I. Personal and Team Process Models
Agile Process models:
J. Agile process
K. Extreme programming
 THE NATURE OF SOFTWARE
 Defining Software
Software is: (1) instructions (computer programs) that when
executed provide desired features, function, and
performance; (2) data structures that enable the programs
to effectively manipulate information, and (3) descriptive
information in both hard copy and virtual forms that
describes the operation and use of the programs.
 software characteristics
1. Software is developed or engineered; it is not
manufactured in the classical sense.
2. Although the industry is moving toward component-based
construction, most software continues to be custom built.
3. Software doesn’t “wear out.” But it does deteriorate!
4. Although the industry is moving toward component-based
construction, most software continues to be custom built.
Figure 1: Failure curve
for hardware

Figure 1.2: Failure curves

for software
 Software Application Domains
• System software
a collection of programs written to service other programs. Some system
software (e.g., compilers, editors, and file management utilities) processes
complex, but determinate, information structures. Other systems
applications (e.g., operating system components, drivers, networking
software, telecommunications processors) process largely indeterminate
data.
• Application software
stand-alone programs that solve a specific business need.
Applications in this area process business or technical data in
a way that facilitates business operations or
management/technical decision making
• Engineering/scientific software
characterized by “number crunching” algorithms. Computer-aided design,
system simulation, and other interactive applications have begun to take on
real-time and even system software characteristics.

• Embedded software
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

• 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)

• Web applications
called “WebApps,” this network-centric software category spans a wide array
of applications. In their simplest form, WebApps can be little more than a set of
linked hypertext files that present information using text and limited graphics
• Artificial intelligence software
- makes use of nonnumerical algorithms to solve complex problems that are
not amenable to computation or straightforward analysis. Applications within
this area include robotics, expert systems, pattern recognition
New Challenges
•Open-world computing
•Netsourcing
•Open source
Legacy software (A poor quality software)
•Some other programs are older, in some cases much older.
•Legacy software systems . . . were developed decades ago
and have been continually modified to meet changes in
business requirements and computing platforms. The
production of such systems is causing headaches for large
organizations who find them costly to maintain and risky to
evolve.

1
Legacy Software
• Many legacy systems remain supportive to core business
functions and are ‘essential’ to the business. What to do?
• What types of changes are made to legacy systems?
 The software must be adapted to meet the needs of new
computing environments or technology.
 The software must be enhanced to implement new business
requirements.
 The software must be extended to make it interoperable with
other more modern systems or databases.
 The software must be re-architected to make it feasible within a
network environment.

1
 THE SOFTWARE PROCESS
A process is a collection of activities, actions, and tasks that are performed when
some work product is to be created.
A generic process framework for software engineering encompasses five activities:
 Communication
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
 Planning
planning activity creates a “map” that helps, guide .The map—called a software
project plan—defines the software engineering work by describing the technical
tasks to be conducted
 Modeling
creating models to better understand software requirements and the design that
will achieve requirements.
 Construction
This activity combines code generation (either manual or automated) and the
testing that is required to uncover 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
 Software engineering process framework activities are complemented by a
number of 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.
 Technical reviews
assesses software engineering work products in an effort to uncover and
remove errors before they are propagated to the next activity.
 Software quality assurance
defines and conducts the activities required to ensure software quality.
 Measurement
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
 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 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 for accuracy (testing and quality assurance).
 General Principles
1. The Reason It All Exists
-A software system exists for one reason: to provide value to its
users . “Does this add real value to the system?” If the answer is
“no,” don’t do it.
2. KISS (Keep It Simple, Stupid!)
All design should be as simple as possible, but no simpler. This
facilitates having a more easily understood and easily maintained
system.
3. Maintain the Vision
A clear vision is essential to the success of a software project
4. What You Produce, Others Will Consume
always specify, design, and implement knowing someone else will have to
understand what you are doing
5. Be Open to the Future
system with a long lifetime has more value. systems must be ready to
adapt to these and other changes. Never design yourself into a corner.
Always ask “what if,” and prepare for all possible answers by creating
systems that solve the general problem.
6. Plan Ahead for Reuse
Reuse saves time and effort. Achieving a high level of reuse is arguably
the hardest goal to accomplish in developing a software system.
Planning ahead for reuse reduces the cost and increases the value of
both the reusable components and the systems into which they are
incorporated.
7. Think!
Placing clear, complete thought before action almost always produces
better results. When you think about something, you are more likely to
do it right. You also gain knowledge about how to do it right again
 Software Myths
Management Myths
i)Myth: We already have a book that's full of standards and
procedures for building software,
Reality: but is it used? Are software practitioners aware of its
existence? Is it complete
ii)Myth: My people have state-of-the-art software
development tools,
Reality: Computer-Aided Software Engineering (CASE)
tools are more important than hardware for achieving good
quality and productivity, yet the majority of software
developers still do not use them effectively.

1
iii)Myth: If we get behind schedule, we can add more
programmers and catch up
Reality: “Adding people to a late software project makes it
later”. However, as new people are added, people who were
working must spend time educating the newcomers. People
can be added but only in a planned and well-coordinated
manner.
iv)Myth: If I decide to outsource the software project to a
third party, I can just relax and let that firm build it.
Reality: If an organization does not understand how to
manage and control software projects internally, it will be
problematic to build that project.
1
Customer’s Myths
i)Myth: A general statement of objectives is sufficient to begin
writing programs, we can fill in the details later.
Reality: A poor up-front definition is the major cause of failed
software efforts. A formal and detailed description of the
information domain, function, behavior, performance,
interfaces, design constraints, and validation criteria is
essential which is determined only after thorough
communication between customer and developer.
ii)Myth: Project requirements continually change, but change
can be easily accommodated because software is flexible.
Reality: It is true that software requirements change, but the
impact of change varies with the time & cost is increases.
1
Practitioner Myths
(Related To Practitioner or Programmer)
i)Myth: Once we write the program and get it to work, our
job is done.
Reality: “ The sooner you begin 'writing code', the longer
it'll take you to get done”.
ii)Myth: The only deliverable work product for a successful
project is the working program.
Reality : A working program is only one part of a software
configuration that includes many elements. Documentation
provides a foundation for successful engineering and, more
important, guidance for software support.

1
 A GENERIC PROCESS MODEL

A software process Process flow

framework
 A GENERIC PROCESS MODEL
 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
 Defining a Framework Activity
-What actions are appropriate for a framework activity, given the nature of the
problem to be solved, the characteristics of the people doing the work, and the
stakeholders who are sponsoring the project?
- action encompasses 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.

 Identifying a Task Set

- number of different task sets—each a collection of software engineering work tasks,
related work products, quality assurance points, and project milestones
 PROCESS ASSESSMENT AND IMPROVEMENT
 Standard CMMI Assessment Method for Process Improvement
(SCAMPI)
- provides a five-step process assessment model that incorporates five
phases: initiating, diagnosing, establishing, acting, and learning. The
SCAMPI method uses the SEI CMMI as the basis for assessment.
 CMM-Based Appraisal for Internal Process Improvement (CBA IPI)
- provides a diagnostic technique for assessing the relative maturity of a
software organization; uses the SEI CMM as the basis for the assessment.
 SPICE (ISO/IEC15504)
- a standard that 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
- a generic standard that applies to any organization that wants to improve
the overall quality of the products, systems, or services that it provides
 PRESCRIPTIVE PROCESS MODELS
1. The Waterfall Model
• The waterfall model, sometimes called the classic life cycle,
suggests a systematic, sequential approach to software
development that begins with customer specification of
requirements and progresses through planning, modeling,
construction, and deployment.
• A variation in the representation of the waterfall model is called the
V-model .
• As a software team moves down the left side of the V, basic
problem requirements are refined into progressively more detailed
and technical representations of the problem and its solution.
• oldest paradigm for software engineering.
• serve as a useful process model in situations where requirements
are fixed and work is to proceed to completion in a linear manner.
 PRESCRIPTIVE PROCESS MODELS
[Link] Process Models
• The incremental model combines elements of linear and parallel
process flows.
• When an incremental model is used, the first increment is often a core
product. That is, basic requirements are addressed but many
supplementary features (some known, others unknown) remain
undelivered.
• The core product is used by the customer (or undergoes detailed
evaluation). As a result of use and/or evaluation, a plan is developed
for the next increment.
• The plan addresses the modification of the core product to better meet
the needs of the customer and the delivery of additional features and
functionality.
• This process is repeated following the delivery of each increment, until
the complete product is produced.
• focuses on the delivery of an operational product with each
increment.
 PRESCRIPTIVE PROCESS MODELS
3. Evolutionary Process Models
I. Prototyping
• The prototyping paradigm begins with communication.
• You meet with other stakeholders to define the overall objectives
for the software, identify whatever requirements are known, and
outline areas where further definition is mandatory.
• A prototyping iteration is planned quickly, and modeling (in the
form of a “quick design”) occurs.
• A quick design focuses on a representation of those aspects of the
software that will be visible to end users (e.g., human interface
layout or output display formats).
• The quick design leads to the construction of a prototype.
• The prototype is deployed and evaluated by stakeholders, who
provide feedback that is used to further refine requirements .
• prototype serves as a mechanism for identifying software
requirements. If a working prototype is to be built, you can
make use of existing program fragments or apply tools .
• The prototype can serve as “the first system “
 PRESCRIPTIVE PROCESS MODELS
II. The Spiral Model
• Originally proposed by Barry Boehm, the spiral model is an evolutionary
software process model that couples the iterative nature of prototyping
with the controlled and systematic aspects of the waterfall model.
• It provides the potential for rapid development of increasingly more
complete versions of the software.
• risk-driven process model generator that is used to guide multi-
stakeholder concurrent engineering of software intensive systems.
• It has two main distinguishing features. One is a cyclic approach for
incrementally growing a system’s degree of definition and implementation
while decreasing its degree of risk .
• Software is developed in a series of evolutionary releases. During early
iterations, the release might be a model or prototype. During later
iterations, increasingly more complete versions of the engineered system
are produced.
• divided into a set of framework activities defined by the software
engineering team.
• The spiral model is a realistic approach to the development of large-scale
systems and software
 PRESCRIPTIVE PROCESS MODELS
4. Concurrent Models
• called concurrent engineering, allows a software
team to represent iterative and concurrent elements
of any of the process models.
• All software engineering activities exist concurrently
but reside in different states.
• Concurrent modeling defines a series of events that
will trigger transitions from state to state for each of
the software engineering activities, actions, or tasks .
• Concurrent modeling is applicable to all types of
software development and provides an accurate
picture of the current state of a project.
AGILE PROCESS MODELS
 AGILE PROCESS
 What Is An Agile Process
 Agility Principles
• The Agile Alliance defines agility principles for those who want to
achieve agility:
• Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile
processes harness change for the customer’s competitive
advantage.
• Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily
throughout the project.
• Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get
the job done.
• The most efficient and effective method of conveying
information to and within a development team is face-to-face
conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
• Continuous attention to technical excellence and good design
enhances agility.
•The best architectures, requirements, and designs emerge from
self– organizing teams.
At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
 The Politics of Agile Development
 Human Factors
- Agile development focuses on the talents and skills of individuals, molding the
process to specific people and teams
 Competence.
- Skill and knowledge of process can and should be taught to all people who
serve as agile team members.
 Common focus
- focused on one goal
- the team will also focus on continual adaptations (small and large)
 Collaboration.
- team members must collaborate—with one another and all other stakeholders.
 Self-organization
(1) the agile team organizes itself for the work to be done,
(2) the team organizes the process to best accommodate its local
environment.
(3) the team organizes the work schedule to best achieve delivery of the
software increment.
 Decision-making ability.
- team is given autonomy—decision-making authority for both technical and
project issues.
 Fuzzy problem-solving ability
- team must accept the fact that the problem they are solving today may not
be the problem that needs to be solved tomorrow.
 Mutual trust and respect
 EXTREME PROGRAMMING (XP)
 XP Values
- communication, simplicity, feedback, courage, and respect. Each of these
values is used as a driver for specific XP activities, actions, and tasks
 The XP Process
 Planning
-begins with listening—a requirements gathering activity that enables the
technical members of the XP team to understand the business context .
- creation of a set of “stories” (also called user stories) that describe required
output, features, and functionality for software to be built. Each story is
written by the customer and is placed on an index card.
- assign a cost—measured in development weeks—to it.
 Design
 Coding
 Testing
Industrial XP
-IXP is an organic evolution of XP.
- customer-centric, test-driven spirit.
- IXP differs most from the original XP in its greater inclusion of
management, its expanded role for customers, and its upgraded technical
practices.

 Readiness assessment
(1) an appropriate development environment exists to support IXP, (2) the
team will be populated by the proper set of stakeholders, (3) the
organization has a distinct quality program and supports continuous
improvement, (4) the organizational culture will support the new values of
an agile team, and (5) the broader project community will be populated
appropriately.
 Project community
- people on the team must be well-trained, adaptable and skilled, and
have the proper temperament to contribute to a self-organizing team
 Project chartering
- examines the context of the project to determine how it complements,
extends, or replaces existing systems or processes
 Test-driven management
- requires measurable criteria for assessing the state of the project and
the progress
 Retrospectives
-IXP team conducts a specialized technical review after a software
increment is delivered. Called a retrospective
 Continuous learn
- XP team are encouraged (and possibly, incented) to learn new methods
and techniques that can lead to a higher quality product.
 The XP Debate