Unit 1 - Software Engineering Notes (22413)

Course Name : Computer Engineering Subject Title : Software Engineering
Course Code : CO/CM/IF/CD Subject Code : 22413
Unit 1 Software Development Process

1.1 Software, Software Engineering as layered approach and its characteristics, Types of
Software
Computer Software is the product that software professionals build and then support over the long
term. Software is a set of instructions to acquire inputs and manipulate them to produce the desired
output in terms of functions and performance as determined by the user of the software.
Software Engineering is defined as a discipline that addresses the following aspects of the software
and its development. They are:
1. Economic : Cost, Benefits, and Returns on Investment (ROI).
2. Design : Ease of development and ensuring delivery of customer requirements.
3. Maintenance : Ease of effecting changes and modifications.
4. Implementation : Ease of installation, Demonstration, and implementation of software by the
customer and users.
It is an engineering discipline which is systemic, scientific, methodical, uses standards, models
algorithms in design and development.
The IEEE (Institution of Electrical and Electronics Engineers) defines Software Engineering as the
application of a systematic, disciplined, quantifiable approach to the development, operations and
maintenance of software.
Today, software performs a dual role. It is both a product and a vehicle for delivering a product. As
a product, it delivers the computing potential embodied by computer hardware or, more broadly, by a
network of computers that are accessible by local hardware. Software is an information transformer
- producing, managing, acquiring, modifying, displaying, transmitting information that can be as
simple as a single bit or as complex as a multimedia presentation.
As a vehicle, for delivering the product, software acts as the basis for the control of computer
(Operating System),the communication of information (networks), and the creation and control of
other programs (Software tools and environments).
Characteristics of Software:
Software is written to handle an Input – Process – Output system to achieve predetermined goals.
Software is logical rather than a physical system element. Therefore software has characteristics that
are different than that of hardware.
1. Software is developed or engineered; it is not manufactured in the classical sense.
2. Software doesn’t “wear out” like hardware and it is not degradable over a period.
3. Although the industry is moving toward component – based construction, most software
continues to be custom built.
4. A software component should be designed and implemented so that it can be reused in many
different programs.
5. The following figure depicts failure rate as a function of time for hardware. The relationship
often called as “bathtub curve”, indicates that, hardware exhibits relatively high failure rates
early in its life.
1
6. Software is not susceptible to the environmental maladies that cause hardware to wear out.
Hence, the failure rate curve for software should take the form of “idealized curve” as shown in
the figure. Undiscovered defects will cause high failure rates early in the life of a program.
However, these are corrected and the curve flattens as shown. Hence the software doesn’t wear
out, but it does deteriorate.
Time
Failure curve for Hardware
Failure curve for Software

The classical and conventional definition of software is that it is a set of instructions which when
executed through a computing device produces the desired result by the execution of functions and
processes. It also includes a set of documents, such as the software manual, meant for users to
understand the software system. Today’s software comprises the source code, Executable, Design
Documents, Operations Manual, System Manual, Installation /Implementation Manuals.
Software is described by its capabilities. The capabilities relate to the functions it executes, the
features it provides and the facilities it offers.
2
Software Engineering- Definition, Need

According to Fritz Bauer, software engineering is establishment and use of sound engineering
principles in order to obtain economical software that is reliable and works efficiently on real
machines.
“More than a discipline or a body of knowledge, engineering is a verb, an action word, a way of
approaching a problem”. - Scott Whit mire
Relationship between Systems Engineering and Software Engineering
Software Engineering
Software engineering deals with designing and developing software of the highest quality. A
software engineer does analyzing, designing, developing and testing software. Software engineers
carry out software engineering projects, which usually have a standard software life cycle. For
example, the Water Fall Software Life cycle will include an analysis phase, design phase,
development phase, testing and verification phase and finally the implementation phase. Analysis
phase looks at the problem to be solved or the opportunities to be seized by developing the software.
Sometimes, a separate business analyst carries out this phase. However, in small companies,
software engineers may do this task. Design phase involves producing the design documents such as
UML diagrams and ER diagrams depicting the overall structure of the software to be developed and
its components. Development phase involves programming or coding using a certain programming
environment. Testing phase deals with verifying that software is bug free and also satisfies all the
customer requirements. Finally, the completed software is implemented at the customer site
(sometimes by a separate implementation engineer). In recent years, there has been a rapid growth of
other software development methodologies in order to further improve the efficiency of the software
engineering process. For example, Agile methods focus on incremental development with very short
development cycles. Software Engineering profession is a highly rated job because of its very high
salary range.
System Engineering
System Engineering is the sub discipline of engineering which deals with the overall management of
engineering projects during their life cycle focusing more on physical aspects. It deals with logistics,
team coordination, automatic machinery control, work processes and similar tools. Most of the times,
System Engineering overlaps with the concepts of Industrial Engineering, Control Engineering,
Organizational and Project Management and even Software Engineering. System Engineering is
identified as an interdisciplinary engineering field due to this reason. System Engineer may carry out
system designing, developing requirements, verifying requirements, system testing and other
engineering studies.
Software engineering layers: A Layered Technology Approach
Software engineering is a layered technology. The layers of software engineering as shown in the
above diagram are:-
3
1. A Quality Focus:
Any engineering approach including software engineering must rest on an organizational
commitment to quality. Total quality management, six sigma and similar philosophies foster a
continuous process improvement culture, and it is this culture that ultimately leads to the
development of increasingly more effective approaches to software engineering. The bedrock that
supports software engineering is a quality focus.
2. Process Layer:
The foundation for software engineering is the process layer. Software Engineering process is the
glue that holds the technology layers together and enables rational and timely development of
computer software. Process defines a framework that must be established for effective delivery of
software engineering technology. The software process forms the basis for management control of
software projects and establishes the context in which technical methods are applied, works products
(models, documents, data, reports, forms etc.) are produced, milestones are established, quality is
ensured and change is properly managed.
3. Methods:
Software Engineering methods provide the technical know-how’s for building software. Methods
encompass a broad array of tasks that include communication, requirements analysis, design
modeling, program construction, testing and support.
4. Tools:
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, called computer–aided software engineering is
established.
Types/ Categories of Software:
Today, seven broad categories of computer software present continuing challenges for software
engineers.
1. System Software:
System Software is a collection of programs written to serve other programs. Some system software
(e.g.- compliers, editors, and file management utilities) processes complex, but determinate
information structures. Other system applications (e.g.- operating system components, drivers,
networking software, telecommunications processors) process largely indeterminate data. In either
case, the systems software area 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.
2. Application Software:
Application Software consists of standalone programs that solve a specific business need.
Applications in this area process business or technical data in a way that facilitates business
operations, management, and technical decision-making. In addition to conventional data processing
applications, application software is used to control business functions in real time (e.g., point-of-
sale transaction processing, real-time manufacturing process control).
4
3. Engineering / Scientific Software:

Formerly characterized by “number crunching” algorithms, engineering and scientific software
applications range from astronomy to volcanology, from automotive stress analysis to space shuttle
orbital dynamics, and from molecular biology to automated manufacturing. Computer-aided design,
system simulation, and other interactive applications have begun to take on real–time and even
system software characteristics.
4. Embedded Software:
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. keypad control for a microwave oven) or provide significant function and
control capability (e.g. digital functions in an automobile such as fuel control, dashboard displays,
braking systems, etc.)
5. Product–line Software:
Designed to provide a specific capability for use by many different customers, product–line software
can focus on a limited & esoteric market place (e.g. – inventory control products) or address mass
consumer markets (e.g. – word processing, spreadsheets, computer graphics, multimedia,
entertainment, database management, personal and business financial applications.)
6. Web – applications:
“WebApps”, span a wide array of applications. WebApps are evolving into sophisticated computing
environments that not only provide standalone features, computing functions and content to the end
user, but also are integrated with corporate databases and business applications.
7. Artificial Intelligence(AI) Software:
AI Software makes use of non–numerical algorithms to solve complex problems that are not
amenable to computation or straight forward analysis. Applications within this area include robotics,
expert systems, pattern recognition (image and voice), artificial neural networks, theorem proving,
and game playing.
Due to changing nature of software and rapid growth of technology, the challenge for software
engineers will be –
a) To develop systems and application software that will allow small devices, personal computers,
and enterprise system to communicate across vast networks to meet rapid growth of wireless
networking.
b) To architect simple (e.g.- personal financial planning) and sophisticated applications that provide
benefit to targeted end-user markets worldwide to meet rapid growth of net sourcing (World
Wide Web)
c) To build source code that is self-descriptive, but, more importantly, to develop techniques that
will enable both customers and developers to know what changes have been made and how those
changes manifest themselves within the software.
d) To build applications that will facilitate mass communication and mass product distribution using
concepts that is only now forming.
e) The computer itself will make a historic transition from something that is used for analytic tasks
to something that can elicit emotion. - David Vaskevitch
5
1.2 Software Development Framework

1.3 Software Process Framework, Process models: Perspective Process Models, Specialized
Process Models
A process framework establishes the foundation for a complete software process by identifying a
small number of framework activities that are applicable to all software projects, regardless of their
size or complexity. In addition, the process framework encompasses a set of umbrella activities that
are applicable across the entire software process.
Software Process
Process Framework
Umbrella activities
Framework activity #1
Software engineering action #1.1
Work tasks
Task sets Work products
. Quality assurance points
. Project milestones
.
Software engineering action #1.k
Task sets
Work tasks
Work products
Quality assurance points
.
Framework activity #n
Software engineering action #n.1
Work tasks
Task sets Work products
. Quality assurance points
.
Software engineering action #n.m
Task sets
Work tasks
Work products
Quality assurance points
Project milestones
From the above figure, each framework activity is populated by a set of software engineering
actions- a collection of related tasks that produces a major software engineering work product (e.g.
6
design is a SE action). Each action is populated with individual work tasks that accomplish some
part of the work implied by the action.
A process defines who is doing what, when and how to reach a certain goal. The following generic
process framework is applicable to the vast majority of software projects.
1. Communication :
This framework activity involves heavy communication & collaboration with the customer (and the
stakeholders) and encompasses requirements gathering and other related activities.
2. Planning :
This activity establishes a plan for the software engineering work that follows. It describes the
technical tasks to be conducted, the risks that are likely, the resources that will be required, the work
products to be produced and a work schedule.
3. Modeling :
This activity encompasses the creation of models that allow the developer & the customer to better
understand software requirements & the design that will achieve those requirements.
4. Construction :
This activity combines code generation and the testing that is required to uncover errors in the code.
5. Deployment :
The software is delivered to the customer who evaluates the delivered product and provides feedback
based on the evaluation.
Umbrella Activities:Generic views of SE has a set of unbrella activities. They are
Software Project tracking and control:
The framework described in the generic view of SE is complemented by a number of umbrella
activities, one of which is software project tracking and control. It allows the software team to
access progress against the project plan and takes necessary action to maintain schedule. Umbrella
activities occur throughout the software process and focus primarily on project management,
tracking and control.
Risk Management:
Assess risks that are likely to affect performance and quality of project.
Software quality assurance:
Define and conduct activities to ensure software quality.
Formal Technical Review:
Work products to uncover and remove errors before they are shifted to next level of activity.
Measurement:
Defines and collects process, project and product measures to assist the team in delivering the
software that meets customer needs can be used in conjunction with all framework and umbrella
activities.
Software Configuration Management (SCM):
Manages and effects the changes throughout the software process.
7
Reusability management:
Defines criteria for work product reuse (including software components) and establishes the
mechanism to achieve reusable components.
Work product preparation and production:
Includes activities for creating work product such as models, documents, data, reports etc.
Process Models : Perspective Process Models and Specailzed Process Models
The generic process models must be adapted for use by a software project team. To accomplish this,
process technology tools have been developed to help software organizations analyze their current
process, organize work tasks, control, monitor progress and manage technical quality.
Process technology tools allow a software organization to build an automated model of the common
process framework, task sets and umbrella activities. The model, normally represented as a network
can then be analyzed to determine typical workflow and examine alternative process structures that
might lead to reduced development time and cost.
Once, an acceptable process is created, other process technology tools can be used to allocate,
monitor and even control all software engineering tasks defined as part of the process model, to
develop a checklist of work tasks to be performed, work products to be produced and quality
assurance activities to be conducted, to coordinate the use of other computer-aided software
engineering tools that are appropriate for a particular work task.
In some cases, the process technology tools incorporate standard project management tasks such as
estimating, scheduling, tracking and control.
Prescriptive Process Models:
Irrespective of which level of CMM the organization has, the software engineer has five choices for
selection of software process models.
They are –
1. Waterfall Model
2. Incremental Model
3. RAD Model
4. Prototype Model
5. Spiral Model
8
1. The Waterfall Model:
There are times when the requirements of a problem are reasonably well understood – when work
flows from communication through deployment in a reasonably linear fashion.
The waterfall model is a traditional method, sometimes called the classic life cycle. This is one of the
initial models. As the figure implies stages are cascaded and shall be developed one after the other.
In other words one stage should be completed before the other begins. Hence, when all the
requirements are elicited by the customer, analyzed for completeness and consistency, documented
as per requirements, the development and design activities commence.
One of the main needs of this model is the user’s explicit prescription of complete requirements at
the start of development. For developers it is useful to layout what they need to do at the initial
stages. Its simplicity makes it easy to explain to customers who may not be aware of software
development process. It makes explicit with intermediate products to begin at every stage of
development.
One of the biggest limitation is it does not reflect the way code is really developed.
Problem is well understood but software is developed with great deal of iteration.
Often this is a solution to a problem which was not solved earlier and hence software developers
shall have extensive experience to develop such application; as neither the user nor the developers
are aware of the key factors affecting the desired outcome and the time needed. Hence at times the
software development process may remain uncontrolled.
Today software work is fast paced and subject to a never-ending stream of changes in features,
functions and information content. Waterfall model is inappropriate for such work. This model is
useful in situation where the requirements are fixed and work proceeds to completion in a linear
manner.
Among the problems that are sometimes encountered when the waterfall model is applied are
1. Real projects rarely follow the sequential flow that the model proposes. Although the linear
model can accommodate iteration, it does so directly. As a result, changes can cause confusion
as the project team proceeds.
2. It is often difficult for the customer to state all requirements explicitly. The Waterfall Model
requires this and has difficulty accommodating the natural uncertainty that exists at the beginning
of many projects.
3. The customer must have patience. A working version of the program will not be available until
late in the project time-span. A major blunder, if undetected until the working program is
received, can be disastrous.
9
The waterfall model is often inappropriate for such work. However, it can serve as a useful process
model in situations where requirements are fixed and work is to proceed to completion in a linear
manner.
2. The Incremental Model:
The incremental model combines elements of the waterfall model applied in an iterative fashion.
The incremental model delivers a series of releases, called increments, that provides progressively
more functionality for the customer at each increment is delivered. In each increment, additional
functions and features are added after confirming the utility of earlier increments.
In the early years of development users were willing to wait for software projects to be ready.
Today’s business does not tolerate long delays. Software helps to distinguish products in the market
place and customers are always looking for new quality and functions. One of the ways to reduce
time is the phased development. The system is developed such that it can be delivered in parts
enabling the users to have few functions while the rest are being developed. Thus development and
usage will happen in parallel.
In incremental development the system is partitioned into subsystems or increments. The releases are
defined in the beginning with initial function and them adding functionalities with subsequent
releases. Incremented development slowly builds up to full functionality with subsequent releases.
This model combines the elements of waterfall model in an iterative fashion. The model applies
linear sequences in a staggered manner as the calendar time progresses. In this model first increment
is the core product or primary function. The core product implemented undergoes detailed evaluation
by the user which becomes advantages for future increments. The feedback also addresses future
modifications which are included in the next increments for additional features and functionality. He
process is repeated till delivery of each increment till the final product is delivered.
This is useful when the software team is smaller in size. Additional increments can be planned and
managed to address technical risks. This has the advantage of prompt system delivery to users
without hassle.
In case of availability of new hardware are delayed and early increments which could be executed on
existing systems for partial functionality to prevent inordinate delays.
10
From this diagram, the incremental model applies linear sequences in a staggered fashion as calendar
time progresses. Each linear sequence produces deliverable “Increments” of the software.
For example, word-processing software developed using the incremental paradigm might deliver
basic file management, editing and document production functions in the first increment; more
sophisticated editing and document production capabilities in the second increment; spelling and
grammar checking in the third increment; and advanced page layout capability in the fourth
increment.
3. The RAD Model:
Rapid Application Development (RAD) is a modern software process model that emphasizes a short
development cycle. The RAD Model is a “high-speed” adaptation of the waterfall model, in which
rapid development is achieved by using a component based construction approach. If requirements
are well understood and project scope is considered, the RAD process enables a development team to
create a “Fully Functional System” within a very short period of time (e.g. 60 to 90 days).
One of the distinct features of RAD model is the possibility of cross life cycle activities which will
be assigned to teams, teams #1 to team #n leading to each module getting developed almost
simultaneously.
This approach is very useful if the business application requirements are modularized as function to
be completed by individual teams and finally to integrate into a complete system. As such compared
to waterfall model the team will be of larger size to function with proper coordination.
RAD model distributes the analysis and construction phases into a series of short iterative
development cycles. The activities of each phase per team are Business modeling, Data modeling
and process modeling.
This model is useful for projects with possibility of modularization. RAD may fail if modularization
is difficult. This model should be used if domain experts are available with relevant business
knowledge.
11
Advantages:
1. Changing requirements can be accommodated and progress can be measured.
2. Powerful RAD tools can reduce development time.
3. Productivity with small team in short development time and quick reviews, risk control increases
reusability of components, better quality.
4. Due to risks in new approach only modularized systems are recommended through RAD.
5. Suitable for scalable component based systems.
Limitations:
1. Success of RAD model depends on strong technical team expertise and skills.
2. Highly skilled developers needed with modeling skills.
3. User involvement throughout life cycle. If developers & customers are not committed to the
rapid fire activities necessary to complete the System in a much-abbreviated time frame, RAD
projects will fail.
4. May not be appropriate for very large scale systems where the technical risks are high.
4. The Prototype Model:
The prototyping paradigm begins with communication as shown in the diagram below.
The software development process can help to control by including activities and sub processes to
enhance understanding. Prototyping is a sub process or a partially developed product that enable
customers and developers to examine aspects of a proposed system and decide if it is suitable or
appropriate for the finished product.
Developers may build a system to implement a small portion of some of the key requirements to
ensure that the requirements are consistent, feasible and practical. In case of changes, revisions are
made at the requirements stage by prototyping parts of the design.
Design prototyping helps the developers assess alternative strategies and decide which best suits for
the project. There may be radically different designs to get best performances. Often user interface is
built and tested as a prototype for users to understand the new system and developers to get the idea
of user’s reaction/response to the system.
12
In Business needs, requirements change very often making earlier methods unrealistic and redundant.
Short market deadlines make it difficult to complete comprehensive software products. The
evolutionary models are iterative and help the developers to complete short version within the given
deadlines.
Ideally prototype serves as a mechanism to identify software requirements for working prototypes.
The developer attempts to make use of existing program fragments and applies tools such as report
generators which enable working programs to be generated quickly.
The software engineer & customer meet and define the overall objectives for the software, identify
whatever requirements are known and outline areas where further definition is mandatory.
Prototyping iteration is planned quickly and modeling (in the form of quick design) occurs. The
quick design focuses on a representation of those aspects of the software that will be visible to the
customer/end-user (e.g. human interface layout or output display formats). The quick design leads to
the construction of a prototype. The prototype is deployed & then evaluated by the customer/user.
Feedback is used to refine requirements for the software.
5. The Spiral Model:
Boehm (1988) viewed the software development process in light of risks involved, Spiral model
could combine development activities with risk management to minimize and control the risk impact.
It is an evolutionary model which couples iterative nature of prototyping with controlled and
systematic aspects of the waterfall model. It also provides scope for RAD for increasingly complete
software.
The spiral development model is a 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. The other is a set of anchor point milestones for
ensuring stakeholder commitment to feasible and mutually satisfactory system solutions.
From the figure given above, a spiral model is divided into a set of framework activities defined by
the software engineering team. As this evolutionary process begins, the software team performs
activities that are implied by a circuit around the spiral in a clockwise direction, beginning at the
center. Risk is considered as each revolution is made. Anchor point milestones – a combination of
work products and conditions that are attained along the path of the spiral – are noted for each
evolutionary pass.
13
Each pass through the planning region results in adjustments to the project plan. Cost & schedule are
adjusted based on feedback derived from the customer after delivery. In addition, the project
manager adjusts the planned number of iterations required to complete the software.
The initial circuit around the spiral can be for the concept development and with multiple iterations.
The spiral traverses outward for new product development spiral development remains operative for
the life span of software. This may be a realistic approach for large scale software development. As
the process progresses both users and developers better understand the system. However the system,
demands risks, identification and monitoring to prevent hurdles.
Advantages:
1. One is a cyclic approach for incrementally growing a system‘s degree of definition and
implementation while decreasing its degree of risk.
2. The set of anchor point milestones for ensuring stakeholder commitment to obtain feasible and
mutually satisfactory system solutions.
Limitations:
1. The system demands risks identification and monitoring to prevent hurdles.
2. System can get into infinite iterations.
Specialized Process Models
Special process models take many features from one or more conventional models. However these
special models tend to be applied when a narrowly defined software engineering approach is chosen.
Types in Specialized process models:
1. Component based development (Promotes reusable components)
Commercial off-the-shelf (COTS) software components, developed by vendors who offer them
as products, provide targeted functionality with well-defined interfaces that enable the
component to be integrated into the software that is to be built. The component-based
development model incorporates many of the characteristics of the spiral model. It is
evolutionary in nature, demanding an iterative approach to the creation of software. However, the
component-based development model constructs applications from prepackaged software
components. Modeling and construction activities begin with the identification of candidate
components. These components can be designed as either conventional software modules or
object-oriented classes or packages of classes. Regardless of the technology that is used to create
the components, the component-based development model incorporates the following steps
(implemented using an evolutionary approach):
a.Available component-based products are researched and evaluated for the application domain
in question.
b. Component integration issues are considered.
c.A software architecture is designed to accommodate the components.
d. Components are integrated into the architecture.
e.Comprehensive testing is conducted to ensure proper functionality.
The component-based development model leads to software reuse, and reusability provides software
engineers with a number of measurable benefits.
14
2. The formal methods model (Mathematical formal methods are backbone here)
 The formal methods model encompasses a set of activities that leads to formal mathematical
specification of computer software. Formal methods enable you to specify, develop, and
verify a computer-based system by applying a rigorous, mathematical notation.
 A variation on this approach, called cleanroom software engineering, is currently applied by
some software development organizations. When formal methods are used during
development, they provide a mechanism for eliminating many of the problems that are
difficult to overcome using other software engineering paradigms.
 Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily—
not through ad hoc review, but through the application of mathematical analysis. When
formal methods are used during design, they serve as a basis for program verification and
therefore enable to discover and correct errors that might otherwise go undetected. Although
not a mainstream approach, the formal methods model offers the promise of defect-free
software.
 The development of formal models 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.
3. Aspect oriented software development (Uses crosscutting technology)
 Aspect Oriented Software Development(AOSD) often referred to as aspect oriented
programming(AOP),a relatively new paradigm that provides process and methodology for
defining, specifying designing and constructing aspects.
15
 It addresses limitations inherent in other approaches, including object-oriented programming.

AOSD aims to address crosscutting concerns by providing means for systematic
identification, separation, representation and composition.
 This results in better support for modularization hence reducing development, maintenance
and evolution costs.
1.4 Agile Software Development: Agile Process and its importance, Extreme Programming,
Adaptive Software Development, Scrum, Dynamic Systems Development Method
(DSDM), Crystal
Agile programming is an approach to project management, typically used in software development.
It helps teams react to the instability of building software through incremental, iterative work cycles,
known as sprints.
Features of the Agile Software Development Approach
The name “agile software process” first originated in Japan. The Japanese faced competitive
pressures, and many of their companies, like their American counterparts, promoted cycle-time
reduction as the most important characteristic of software process improvement efforts
Modularity
Modularity is a key element of any good process. Modularity allows a process to be broken into
components called activities. A software development process prescribes a set of activities capable of
transforming the vision of the software system into reality.
Activities are used in the agile software process like a good tool. They are to be wielded by software
craftsman who know the proper circumstances for their use. They are not utilized to create a
production-line atmosphere for manufacturing software.
Iterative
Agile software processes acknowledge that we get things wrong before we get them right. Therefore,
they focus on short cycles. Within each cycle, a certain set of activities is completed. These cycles
will be started and completed in a matter of weeks. However, a single cycle called iteration will
probably not be enough to get the element 100% correct.
Time-Bound
Iterations become the perfect unit for planning the software development project. One can set time
limits (between one and six weeks is normal) on each iteration and schedule them accordingly.
Chances are that the designer will not (unless the process contains very few activities) schedule all of
the activities the process in a single iteration. Instead, will only attempt those activities necessary to
achieve the goals set out at the beginning of the iteration. Functionality may be reduced or activities
may be rescheduled if they cannot be completed within the allotted time period.
Parsimony
Agile Process is more than a traditional software development process with some time constraints.
Attempting to create impossible deadlines under a process not suited for rapid delivery puts the onus
on the software developers. This leads to burnout and poor quality Instead, agile software processes
focus on parsimony. That is, they require a minimal number of activities necessary to mitigate risks
and achieve their goals.
16
Adaptive
During an iteration, new risks may be exposed which require some activities that were not planned.
The agile process adapts the process to attack these new found risks. If the goal cannot be achieved
using the activities planned during the iteration, new activities can be added to allow the goal to be
reached. Similarly, activities may be discarded if the risks turn out to be ungrounded.
Incremental
An agile process does not try to build the entire system at once. Instead, it partitions the nontrivial
system into increments which may be developed in parallel, at different times, and at different rates.
We unit test each increment independently. When an increment is completed and tested, it is
integrated into the system.
Convergent
Convergence states that we are actively attacking all of the risks worth attacking. As a result, the
system becomes closer to the reality that we seek with each iteration. As risks are being proactively
attacked, the system is being delivered in increments. We are doing everything within our power to
ensure success in the most rapid fashion.
People-Oriented
Agile processes favor people over process and technology. They evolve through adaptation in an
organic manner. Developers that are empowered raise their productivity, quality, and performance.
Collaborative
Agile processes foster communication among team members. Communication is a vital part of any
software development project. When a project is developed in pieces, understanding how the pieces
fit together is vital to creating the finished product. There is more to integration than simple
communication. Quickly integrating a large project while increments are being developed in parallel
requires collaboration.
Concept of Extreme Programming
Extreme Programming is an instance of an Agile Software Development method. XP is a method
that is optimized for small to medium-sized project teams that fit a certain profile. It promotes rapid
feedback and response to continual change. It is based upon the four values of simplicity,
communication, feedback, and courage and is consistent with the values of agile software
development.
Characteristics of an XP Project
Extreme Programming or XP is a development process that can be used by small to medium-sized
teams to develop high quality software within a predictable schedule and budget and with a
minimum of overhead. Since XP relies heavily on direct and frequent communication between the
team members, the team should be co-located. An ideal project for using XP would be one that has
most of the following characteristics:
 A small to medium-sized team (fewer than 20 people on the complete team)
 Co-located, preferably in a single area with a large common space
 A committed, full-time, on-site customer or customer representative
17
The Extreme Programming Process

Goals
Extreme Programming Explained describes Extreme Programming as a software-development
discipline that organizes people to produce higher-quality software more productively.
XP attempts to reduce the cost of changes in requirements by having multiple short development
cycles, rather than a long one. In this doctrine, changes are a natural, inescapable and desirable
aspect of software-development projects, and should be planned for, instead of attempting to define a
stable set of requirements.
Extreme programming also introduces a number of basic values, principles and practices on top of
the agile programming framework.
Activities
XP describes four basic activities that are performed within the software development process:
coding, testing, listening, and designing. Each of those activities is described below.
Coding
The advocates of XP argue that the only truly important product of the system development process
is code – software instructions that a computer can interpret. Without code, there is no working
product.
Coding can also be used to figure out the most suitable solution. Coding can also help to
communicate thoughts about programming problems. A programmer dealing with a complex
programming problem, or finding it hard to explain the solution to fellow programmers, might code
it in a simplified manner and use the code to demonstrate what he or she means. Code, say the
proponents of this position, is always clear and concise and cannot be interpreted in more than one
way. Other programmers can give feedback on this code by also coding their thoughts.
Testing
Extreme programming's approach is that if a little testing can eliminate a few flaws, a lot of testing
can eliminate many more flaws.
Unit tests determine whether a given feature works as intended. A programmer writes as many
automated tests as they can think of that might "break" the code; if all tests run successfully, then the
coding is complete. Every piece of code that is written is tested before moving on to the next feature.
18
Acceptance tests verify that the requirements as understood by the programmers satisfy the
customer's actual requirements. System-wide integration testing was encouraged, initially, as a daily
end-of-day activity, for early detection of incompatible interfaces, to reconnect before the separate
sections diverged widely from coherent functionality. However, system-wide integration testing has
been reduced, to weekly, or less often, depending on the stability of the overall interfaces in the
system.
Listening
Programmers must listen to what the customers need the system to do, what "business logic" is
needed. They must understand these needs well enough to give the customer feedback about the
technical aspects of how the problem might be solved, or cannot be solved. Communication between
the customer and programmer is further addressed in the Planning Game.
Designing
From the point of view of simplicity, of course one could say that system development doesn't need
more than coding, testing and listening. If those activities are performed well, the result should
always be a system that works. In practice, this will not work. One can come a long way without
designing but at a given time one will get stuck. The system becomes too complex and the
dependencies within the system cease to be clear. One can avoid this by creating a design structure
that organizes the logic in the system. Good design will avoid lots of dependencies within a system;
this means that changing one part of the system will not affect other parts of the system.
Adaptive Software Development (ASD)
Adaptive Software Development (ASD) has been proposed by Jim Highsmith as a technique for
building complex software and systems. The philosophical underpinnings of ASD focus on human
collaboration and team self-organization. Highsmith argues that an agile, adaptive development
approach based on collaboration is “as much a source of order in our complex interactions as
discipline and engineering.” He defines an ASD “life cycle” that incorporates three phases,
speculation, collaboration, and learning.
Adaptive Software Development
19
During speculation, the project is initiated and adaptive cycle planning is conducted. Adaptive cycle
planning uses project initiation information—the customer’s mission statement, project constraints
(e.g., delivery dates or user descriptions), and basic requirements—to define the set of release cycles
(software increments) that will be required for the project. No matter how complete and farsighted
the cycle plan, it will invariably change. Based on information obtained at the completion of the first
cycle, the plan is reviewed and adjusted so that planned work better fits the reality in which an ASD
team is working.
Motivated people use collaboration in a way that multiplies their talent and creative output beyond
their absolute numbers. This approach is a recurring theme in all agile methods. But collaboration is
not easy. It encompasses communication and teamwork, but it also emphasizes individualism,
because individual creativity plays an important role in collaborative thinking. It is, above all, a
matter of trust. People working together must trust one another to (1) criticize without animosity,
(2) assist without resentment, (3) work as hard as or harder than they do, (4) have the skill set to
contribute to the work at hand, and (5) communicate problems or concerns in a way that leads to
effective action.
As members of an ASD team begin to develop the components that are part of an adaptive cycle, the
emphasis is on “learning” as much as it is on progress toward a completed cycle.
Scrum
Scrum (the name is derived from an activity that occurs during a rugby match) is an agile software
development method that was conceived by Jeff Sutherland and his development team in the early
1990s. In recent years, further development on the Scrum methods has been performed by Schwaber
and Beedle. Scrum principles are consistent with the agile manifesto and are used to guide
development activities within a process that incorporates the following framework activities:
requirements, analysis, design, evolution, and delivery. Within each framework activity, work tasks
occur within a process pattern called a sprint. The work conducted within a sprint (the number of
sprints required for each framework activity will vary depending on product complexity and size) is
adapted to the problem at hand and is defined and often modified in real time by the Scrum team.
The overall flow of the Scrum process is illustrated in figure below. Scrum emphasizes the use of a
set of software process patterns that have proven effective for projects with tight timelines, changing
requirements, and business criticality. Each of these process patterns defines a set of development
actions: Backlog—a prioritized list of project requirements or features that provide business value
for the customer. Items can be added to the backlog at any time (this is how changes are introduced).
The product manager assesses the backlog and updates priorities as required. Sprints—consist of
work units that are required to achieve a requirement defined in the backlog that must be fit into a
predefined time-box14 (typically 30 days).
Changes (e.g., backlog work items) are not introduced during the sprint. Hence, the sprint allows
team members to work in a short-term, but stable environment.
Scrum meetings—are short (typically 15 minutes) meetings held daily by the Scrum team. Three key
questions are asked and answered by all team members:
• What did you do since the last team meeting?
• What obstacles are you encountering?
• What do you plan to accomplish by the next team meeting?
20
A team leader, called a Scrum master, leads the meeting and assesses the responses from each
person. The Scrum meeting helps the team to uncover potential problems as early as possible. Also,
these daily meetings lead to “knowledge socialization” and thereby promote a self-organizing team
structure.
Scrum
Dynamic Systems Development Method (DSDM)

The Dynamic Systems Development Method (DSDM) is an agile software development approach
that “provides a framework for building and maintaining systems which meet tight time constraints
through the use of incremental prototyping in a controlled project environment”.
The DSDM philosophy is borrowed from a modified version of the Pareto principle—80 percent of
an application can be delivered in 20 percent of the time it would take to deliver the complete (100
percent) application.
DSDM is an iterative software process in which each iteration follows the 80 percent rule. That is,
only enough work is required for each increment to facilitate movement to the next increment. The
remaining detail can be completed later when more business requirements are known or changes
have been requested and accommodated.
The DSDM Consortium (www.dsdm.org) is a worldwide group of member companies
that collectively take on the role of “keeper” of the method. The consortium has defined an agile
process model, called the DSDM life cycle that defines three different iterative cycles, preceded by
two additional life cycle activities:
21
Feasibility study—establishes the basic business requirements and constraints associated with the
application to be built and then assesses whether the application is a viable candidate for the DSDM
process.
Business study—establishes the functional and information requirements that will allow the
application to provide business value; also, defines the basic application architecture and identifies
the maintainability requirements for the application.
Functional model iteration—produces a set of incremental prototypes that demonstrate functionality
for the customer. (Note: All DSDM prototypes are intended to evolve into the deliverable
application.) The intent during this iterative cycle is to gather additional requirements by eliciting
feedback from users as they exercise the prototype.
Design and build iteration—revisits prototypes built during functional model iteration to ensure that
each has been engineered in a manner that will enable it to provide operational business value for
end users. In some cases, functional model iteration and design and build iteration occur
concurrently.
Implementation—places the latest software increment (an “operationalized” prototype) into the
operational environment. It should be noted that (1) the increment may not be 100 percent complete
or (2) changes may be requested as the increment is put into place. In either case, DSDM
development work continues by returning to the functional model iteration activity.
DSDM can be combined with XP (Section 3.4) to provide a combination approach that defines a
solid process model (the DSDM life cycle) with the nuts and bolts practices (XP) that are required to
build software increments. In addition, the ASD concepts of collaboration and self-organizing teams
can be adapted to a combined process model.
Crystal
Alistair Cockburn and Jim Highsmith created the Crystal family of agile methods in order to achieve
a software development approach that puts a premium on “maneuverability” during what Cockburn
characterizes as “a resource limited, cooperative game of invention and communication, with a
primary goal of delivering useful, working software and a secondary goal of setting up for the next
game”.
To achieve maneuverability, Cockburn and Highsmith have defined a set of methodologies, each
with core elements that are common to all, and roles, process patterns, work products, and practice
that are unique to each. The Crystal family is actually a set of example agile processes that have been
proven effective for different types of projects. The intent is to allow agile teams to select the
member of the crystal family that is most appropriate for their project and environment.
1.5 Selection Criteria for Software Process Model
The software process model framework is specific to the project. Thus, it is essential to select the
software process model according to the software which is to be developed. The software project is
considered efficient if the process model is selected according to the requirements. It is also essential
to consider time and cost while choosing a process model as cost and/ or time constraints play an
important role in software development. The basic characteristics required to select the process
model are project type and associated risks, requirements of the project, and the users.
22
Following are the parameters which is used to select

1. Requirements Characteristics
• Reliability of Requirements
• How often the requirements can change
• Types of requirements
• Number of requirements
• Can the requirements be defined at an early stage
• Requirements indicate the complexity of the system
2. Development team :
• Team size
• Experience of developers on similar type of projects
• Level of understanding of user requirements by the developers
• Environment
• Domain knowledge of developers
• Experience on technologies to be used
• Availability of training
3. User involvement in the project :
• Expertise of user in project
• Involvement of user in all phases of the project
• Experience of user in similar project in the past
4. Project type and associated risk :
• Stability of funds
• Tightness of project schedule
• Availability of resources
• Type of project
• Size of the project
• Expected duration for the completion of project
• Complexity of the project
• Level and the type of associated risk
23
Question Bank
1. Define Software and Software Engineering. 4 Marks
2. State four characteristics of software. 4 Marks
3. Explain and differentiate between hardware and software. 4 Marks
4. State and explain broad categories of software (Changing nature of software) 4 Marks
5. Explain challenges faced by Software developers due to changing nature. 4 Marks
6. Explain Software Engineering as layered technology approach. 4 Marks
7. Using schematic diagram explain software process framework. 4 Marks
8. State and define generic process framework activities. 4 Marks
9. Enlist and define Umbrella activities in a Software Process framework. 4 Marks
10. Explain Waterfall process model with their advantages and limitations 4 Marks
11. Explain Incremental process model with its advantages and limitations 4 Marks
12. Explain RAD process model with advantages and limitations. 4 Marks
13. Explain Prototype model with advantages and limitations. 4 Marks
14. Explain Spiral model with advantages and limitations. 4 Marks
15. Write a note on Component based process model 4 Marks
16. Explain in brief Specialized process models AOSP/AOP 4 Marks
17. State features of Agile Software development. 4 Marks
18. Explain concept of Extreme Programming (XP). 4 Marks
19. Write a note on Adaptive Software Development 4 Marks
20. Describe the Scrum process with the help of a schematic diagram 4 Marks
21. Write a detailed note on Dynamic Systems Development Method 4 Marks
22. Write a note on Crystal family of agile software development 4 Marks
23. State various parameters of selection of software process model 4 Marks
24

Unit 1 - Software Engineering Notes (22413)

Uploaded by

Copyright:

Available Formats

Unit 1 - Software Engineering Notes (22413)

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit 1 - Software Engineering Notes (22413)

Uploaded by

Copyright:

Available Formats

Course Name : Computer Engineering Subject Title : Software Engineering

Course Code : CO/CM/IF/CD Subject Code : 22413

Unit 1 Software Development Process

Failure curve for Software

Software Engineering- Definition, Need

3. Engineering / Scientific Software:

1.2 Software Development Framework

1. The Waterfall Model:

 It addresses limitations inherent in other approaches, including object-oriented programming.

The Extreme Programming Process

Adaptive Software Development

Dynamic Systems Development Method (DSDM)

Following are the parameters which is used to select

You might also like