SOFTWARE ENGINEERING

Textbook
Software Engineering,
Roger S. Pressman,
Seventh Edition

UNIT-1
 CONTENTS
 The Nature of Software
 The Unique Nature of Web Apps
 Software Engineering
 The Software Process
 Software Engineering Practice
 Software Myths
 A Generic Process Model
 Process Assessment and Improvement
 Prescriptive Process Models
 Specialized Process Models
 The Unified Process
 Personal and Team Process Models
 Process Technology
 INTRODUCTION OF SOFTWARE
 Software is:
(1) instructions (computer programs) that when executed provide desired features,
function, and performance;
(2) data structures that enable the programs to adequately manipulate information,
and
(3) descriptive information in both hard copy and virtual forms that describes the
operation and use of the programs.
 Software is an information transformer—producing, managing, acquiring,
modifying, displaying, or transmitting information. It transforms the personal
data and useful in a local context.
 Software manages business information to enhance competitiveness, provides a
gateway to worldwide information networks, provides the means for acquiring
information in all of its forms.
 CHARACTERISTICS OF SOFTWARE:

There are various characteristic of software including:

 Understandability- To what extent is the process explicitly defined and how
easy is to understand the process.
 Visibility- Do the process activities culminate in clear result so that the progress
of process is visible.
 Robustness- Can the process continues in spite of unexpected problems.
 Acceptability- Is the defined process acceptable to and usable by engineers
responsible for producing software product.
 Supportability- To what extent CASE tools support the process activities.
 Software Application Domains

Different Types of Software are:

1) System software- A collection of programs written to service other
programs. e.g., operating system components, drivers, networking software,
telecommunications processors.
2) Application software- stand-alone programs that solve a specific business
need. e.g., point-of-sale transaction processing, real-time manufacturing
process control.
3) Engineering/Scientific software- is a special software to implement
Engineering and Scientific applications. e.g., Computer-aided design, system
simulation, and other interactive applications have begun to take on real-time
and even system software characteristics.
4) 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.(e.g., key pad control for a microwave oven).
5) Product-line software- designed to provide a specific capability for use by
many different customers.(e.g., inventory control products, word processing,
spreadsheets, computer graphics, multimedia, entertainment, database
management, and personal and business financial applications).
6) Web applications- called “Web Apps,”. Web Apps are evolving into
sophisticated computing environments that not only provide stand-alone
features, computing functions, and content to the end user, but also are
integrated with corporate databases and business applications.
7) Artificial intelligence software- Applications within this area include robotics,
expert systems, pattern recognition(image and voice), artificial neural networks,
theorem proving, and game playing.
8) Open-world computing- Software related to wireless networking may soon
lead to true pervasive, distributed computing.
9) Netsourcing- The World Wide Web is rapidly becoming a computing engine as
well as a content provider. e.g., personal financial planning.
10) Open source- a growing trend that results in distribution of source code for
systems applications (e.g., operating systems, database, and development
environments)
 LEGACY SOFTWARE
 Legacy software systems were developed decades ago and have been
continually modified to meet changes in business requirements and computing
platforms. The maintenance of such systems is causing headaches for large
organizations who find them costly to maintain and risky to evolve.
 Legacy systems often evolve for one or more of the following reasons:
 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 viable within a network
environment.
 THE UNIQUE NATURE OF WEB APPS
 Web Apps means Web Applications. Web Apps have evolved into sophisticated
computing tools that provide stand-alone function to the end user, but also have
been integrated with corporate databases and business applications.
 The following attributes are encountered in the vast majority of Web Apps.

i. Network intensiveness:-A Web App resides on a network and must serve the
needs of a different types of clients.
ii. Concurrency:-A large number of users may access the Web App at one time.
iii. Unpredictable load:-The number of users of the Web App may vary by orders
of magnitude from day to day.
iv. Performance:- Web App should work effectively in terms of processing
speed.
v. Availability:- Although expectation of 100 percent availability is unreasonable,
users of popular Web Apps often demand access on a 24/7/365 basis.
vi. Data driven:- The primary function of many Web Apps is to use hypermedia
to present text, graphics, audio, and video content to the end user. Web Apps
are commonly used to access information that exists on databases.
vii. Content sensitive:- The quality and aesthetic (beauty) nature of content
remains an important determinant of the quality of a Web App.
viii. Continuous evolution:- Unlike conventional application software that
evolves over a series of planned, chronologically spaced releases, Web
applications evolve continuously.
ix. Immediacy:- The compelling need to get software to market quickly, is a
characteristic of many application domains.
x. Security:- Because Web Apps are available via network access, it is difficult, if
not impossible, to limit the population of end users who may access the
application
xi. Aesthetics:- An undeniable part of the appeal of a Web App is its look and
feel. When an application has been designed to market or sell products or ideas,
aesthetics may have as much to do with success as technical design.
 SOFTWARE CRISIS
 It is the symptoms of the problem of engineering the software and approaches
for software development.
 Software crisis symptoms are
• Complexity
• Hardware versus software cost
• Lateness and costliness
• Poor quality
• Unmanageable nature
• Immaturity
• Lack of planning and management practices
• Change
• Maintenance and Migration etc.
SOFTWARE CRISIS

Increasing Increase
Increasing complexit challenge
demand y s

Software crisis

Same Same
Same
workforc tools
methods
e
SOFTWARE ENGINEERING

 IEEE defines- The systematic approach to the development, operation,

maintenance, and retirement of software.
 The solution to these software crises is to introduce systematic software
engineering practices for systematic software development, maintenance,
operation, retirement, planning, and management of software.
 Development means the construction of software through a series of activities,
i.e., analysis, design, coding, testing, and deployment.
 Software Engineering-
 It follows that a concerted effort should be made to understand the problem
before a software solution is developed.
 It follows that design becomes a unique activity.
 It follows that software should exhibit high quality.
 It follows that software should be maintainable, software in all of its forms and
across all of its application domains should be engineered.
THE SOFTWARE PROCESS
 A process is a collection of activities, actions, and tasks that are performed
when some work product is to be created.
 An activity strives to achieve a broad objective (e.g., communication with
stakeholders), size of the project, complexity of the effort, or degree of rigor
with which software engineering is to be applied.
 An action (e.g., architectural design) encompasses a set of tasks that produce a
major work product.
 A task focuses on a small, but well-defined objective (e.g., conducting a unit
test) that produces a tangible outcome.
THE SOFTWARE PROCESS ACTIVITIES

A generic process framework for software engineering encompasses five activities:

i. Communication:- it is critically important to communicate and collaborate with
the customer and to understand stakeholders objectives.
ii. Planning:- A software project is a complicated journey, and the planning
activity creates a “map” that helps guide the team as it makes the journey.
iii. Modeling:- A software engineer does the same thing by creating models to
better understand software requirements.
iv. Construction:- This activity combines code generation and the testing that is
required to uncover errors in the code.
v. Deployment:- The software 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.

 Software quality assurance- defines and conducts the activities required to

ensure software quality.

 Technical reviews- assesses software engineering work products in an effort to

uncover and remove errors before they are propagated to the next activity.
 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 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
 Generic software process model composed of a set of activities that
establish a framework for software engineering practice. Generic
framework activities are communication, planning, modeling,
construction, and deployment.
 The essence of software engineering 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:- David Hooker has proposed seven principles that focus on
software engineering practice as a whole. They are reproduced in the following.
 The First Principle: The Reason It All Exists- to provide value to its users.
 The Second Principle: KISS (Keep It Simple, Stupid!)- All design should be as
simple as possible, but no simpler.
 The Third Principle: Maintain the Vision- A clear vision is essential to the
success of a software project.
 The Fourth Principle: What You Produce, Others Will Consume- always
specify, design, and implement knowing someone else will have to understand
what you are doing.
 The Fifth Principle: Be Open to the Future- Never design yourself into a
corner.
 The Sixth Principle: Plan Ahead for Reuse- Planning ahead for reuse reduces
the cost and increases the value of both the reusable components and the systems
into which they are incorporated.
 The Seventh principle: Think!- Placing clear, complete thought before action
almost always produces better results.
SOFTWARE DEVELOPMENT MYTHS
 A number of common beliefs or myths that software managers, customers, and
developers believe falsely.
 These myths as misleading attitudes that have caused serious problems.
 To see why they are false, and why they lead to trouble.
 Three types of myths:
 Management Myths- Software manager for improving quality &
controlling budges.
 Customer Myths- Software myths believed by customer who can be
internal or external .
 Practitioner’s Myths/Developer- Misconception believed by software
developer.
MANAGEMENT MYTHS
 Some standard tools are present ,they are sufficient for development.
 We can add more program to catch up.
 They think they have latest computer .
 A good manager can manage any project.

Myth: We already have a book that’s full of standards and procedures for
building software. Won’t that provide my people with everything they need
to know?
Reality: The book of standards may very well exist, but is it used? Are
software practitioners aware of its existence? Does it reflect modern
software engineering practice? Is it complete? Is it adaptable? Is it
streamlined to improve time-to-delivery while still maintaining a focus on
quality?
In many cases, the answer to all of these questions is “no.”
CUSTOMER MYTHS

 Customer believes that, general statement of objective is sufficient to begin

writing program.
 Change requirements is easy because software is flexible.
 Customer always think that software development is an easy process.

Myth: A general statement of objectives is sufficient to begin writing programs.

Reality: Although a comprehensive and stable statement of requirements is not
always possible, an ambiguous “statement of objectives” is a recipe for
disaster. Unambiguous requirements (usually derived iteratively) are
developed only through effective and Continuous communication between
customer and developer.
PRACTITIONER’S MYTHS/DEVELOPER
 If I miss something now, I can fix it later.
 Once the program written & running , my job is done.

Myth: Once we write the program and get it to work, our job is done.
Reality: Someone once said that “the sooner you begin ‘writing code,’ the longer
it’ll take you to get done.” Industry data indicate that between 60 and 80
percent of all effort expended on software will be expended after it is delivered
to the customer for the first time.
A GENERIC PROCESS MODEL
 A generic process framework for software engineering defines five framework
activities like communication, planning, modeling, construction and
deployment and in addition, a set of umbrella activities.
 The process flow describes how the framework activities and the actions and
tasks that occur within each framework activity are organized with respect to
sequence and time.
PROCESS FLOW TYPES

 A linear process flow executes each of the five framework activities in

sequence, beginning with communication and culminating with deployment.

Fig: Linear Process Flow

 An iterative process flow repeats one or more of the activities before
proceeding to the next.

Fig: Iterative Process Flow

 An evolutionary process flow executes the activities in a “circular”
manner. Each circuit through the five activities leads to a more complete
version of the software.

Fig: Evolutionary Process Flow

 A Parallel process flow executes one or more activities in parallel with
other activities (e.g., modeling for one aspect of the software might be
executed in parallel with construction of another aspect of the software).

Fig: Parallel Process Flow

IDENTIFYING A TASK SET

 Each software engineering action can be represented by a number of different

task sets—each a task set is a collection of software engineering work tasks,
related work products, quality assurance points, and project milestones.
 We should choose a task set that best accommodates the needs of the project
and the characteristics of your team.
 This implies that a software engineering action can be adapted to the specific
needs of the software project and the characteristics of the project team.
PROCESS PATTERNS

 Every software team encounters problems as it moves through the software

process.
 It would be useful if proven solutions to these problems were readily
available to the team so that the problems could be addressed and resolved
quickly.
 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.
PROCESS PATTERNS TYPES

 Stage pattern: defines a problem associated with a framework activity for the
process. An example of a stage pattern might be establishing communication.
 Task pattern: defines a problem associated with a software engineering action
or work task and relevant to successful software engineering practice (e.g.,
Requirements Gathering is a task pattern).
 Phase pattern: defines the sequence of framework activities that occurs
within the process, even when the overall flow of activities is iterative in
nature.
PROCESS ASSESSMENT AND IMPROVEMENT
1. PRESCRIPTIVE PROCESS MODELS

 The name prescriptive is given because the model prescribes a set of activities,
actions, tasks, quality assurance and change control mechanisms for each
project.
 Linear/Sequential Process Models– The Waterfall Model, V-Model and
Iterative waterfall Model
 Incremental Process Models– The Incremental Model and the RAD Model.
 Evolutionary Process Models– The Prototype Model , The Spiral Model.
 Concurrent Development Model
THE WATERFALL MODEL

 The Waterfall Model was the first Process Model.

 It is also referred to as a linear-sequential life cycle model. It is very simple
to understand and use.
 In a waterfall model, each phase must be completed before the next phase
can begin and there is no overlapping in the phases.
 The waterfall Model illustrates the software development process in a linear
sequential flow. This means that any phase in the development process
begins only if the previous phase is complete.
 It suggests a systematic, sequential approach to software development that
begins with customer specification of requirements and progresses through
planning, modeling, construction, and deployment, culminating in ongoing
support of the completed software.
FIG: THE WATERFALL MODEL
AN ALTERNATIVE DESIGN FOR CLASSICAL WATERFALL
MODEL IS:
 The phases starting from the feasibility study to the integration and system
testing phase are known as the development phases.
1. Feasibility study:
 The main focus of the feasibility study stage is to determine whether it
would be financially and technically feasible to develop the software. The
feasibility study involves carrying out several activities such as collection
of basic information relating to the software such as the different data
items that would be input to the system, the processing required to be
carried out on these data, the output data required to be produced by the
system, as well as various constraints on the development.
2. Requirements analysis and specification:
 The aim of the requirements analysis and specification phase is to
understand the exact requirements of the customer and to document them
properly. This phase consists of two distinct activities, namely
requirements gathering and analysis, and requirements specification.
 Requirements gathering and analysis: The goal of the requirements
gathering activity is to collect all relevant information regarding the
software to be developed from the customer with a view to clearly
understand the requirements. For this, first requirements are gathered from
the customer and then the gathered requirements are analyzed.
 Requirements specification: After the requirement gathering and analysis
activities are complete, the identified requirements are documented. This is
called a software requirements specification (SRS) document. The SRS
document is written using end-user terminology.
3. Design:
 The goal of the design phase is to transform the requirements specified in
the SRS document into a structure that is suitable for implementation in
some programming language. In technical terms, during the design phase the
software architecture is derived from the SRS document.
4. Coding and unit testing:
 The purpose of the coding and unit testing phase is to translate a software
design into source code and to ensure that individually each function is
working correctly. Each component of the design is implemented as a
program module. The end-product of this phase is a set of program modules
that have been individually unit tested. The main objective of unit testing is to
determine the correct working of the individual modules.
5. Integration and system testing:
 Integration of different modules is undertaken soon after they have been
coded and unit tested. During the integration and system testing phase, the
different modules are integrated in a planned manner and then tested. after all
the modules have been successfully integrated and tested, the full working
system is obtained. System testing is carried out on this fully working system.
6. Maintenance:
 The total effort spent on maintenance of typical software during its operation
phase is much more than that required for developing the software itself.
ITERATIVE WATERFALL MODEL

 It is hard to use the classical waterfall model in real projects. In any

practical development environment, as the software takes shape, several
iterations through the different waterfall stages become necessary for
correction of errors committed during various phases.
 The main change brought about by the iterative waterfall model to the
classical waterfall model is in the form of providing feedback paths from
every phase to its preceding phases.
 The feedback paths allow for correcting errors committed by a programmer
during some phase, as and when these are detected in a later phase.
 For example, if during the testing phase a design error is identified, then the
feedback path allows the design to be reworked and the changes to be
reflected in the design documents and all other subsequent documents.
 The principle of detecting errors as close to their points of commitment as
possible is known as phase containment of errors.
Fig: Iterative Waterfall Model
V- MODEL

 A variation in the representation of the waterfall model is called the V-

model.
 In this model verification and validation activities are carried out throughout
the development life cycle, and therefore the chances of bugs in the work
products considerably reduce.
 There are two main phases in this model as shown in figure.
 They are development and validation phases.
 The left half of the model comprises the development phases and the right
half comprises the validation phases.
 In each development phase, along with the development of a
work product, test case design and the plan for testing the
work product are carried out, whereas the actual testing is
carried out in the validation phase.
 This validation plan created during the development phases is carried out in
the corresponding validation phase which is shown by dotted arcs.
 In the validation phase, testing is carried out in three steps—unit,
integration, and system testing.
 The purpose of these three different steps of testing during the validation
phase is to detect defects that arise in the corresponding phases of software
development requirements analysis and specification, design, and coding
respectively.
FIG: V-MODEL
INCREMENTAL PROCESS MODELS
 There are many situations in which initial software requirements are
reasonably well defined, but the overall scope of the development effort
prevents a purely linear process.
 In addition, there may be a need to provide a limited set of software
functionality to users quickly and then refine and expand on that
functionality in later software releases.
 In such cases, we can choose a process model that is designed to produce
the software in increments.
 The incremental model combines elements of linear and parallel process
flows.
 In the incremental life cycle model, the requirements of the software are
first broken down into several modules or features that can be incrementally
constructed and delivered.
 The development team first undertakes to develop the core features of the
system.
 The core or basic features are those that do not need to invoke any services
from the other features.
 On the other hand, non-core features need services from the core features.
 Once the initial core features are developed, these are refined into
increasing levels of capability by adding new functionalities in successive
versions.
FIG: INCREMENTAL PROCESS MODEL
RAD MODEL

 Rapid Application Development model.

 It is a type of incremental model.
 In RAD model the components or functions are developed in parallel as if
they were mini projects.
 The developments are time boxed, delivered and then assembled into a
working prototype.
 This can quickly give the customer something to see and use and to provide
feedback regarding the delivery and their requirements.
FIG: RAD MODEL
 The phases in the rapid application development (RAD) model are:
Business modeling: The information flow is identified between various
business functions.
Data modeling: Information gathered from business modeling is used to
define data objects that are needed for the business.
Process modeling: Data objects defined in data modeling are converted to
achieve the business information flow to achieve some specific business
objective. Process descriptions for adding, deleting, retrieving or modifying
a data object are given.
Application generation: The actual system is built and coding is done by
using automation tools to convert process and data models into actual
prototypes.
o Testing and turnover: The overall testing time is reduced in the RAD
model as the prototypes are independently tested during every iteration.
However, the data flow and the interfaces between all the components need
to be thoroughly tested with complete test coverage.
Advantages of the RAD model:
 Reduced development time.
 Increases reusability of components
 Quick initial reviews occur
 Encourages customer feedback
 Integration from very beginning solves a lot of integration issues.

Disadvantages of RAD model:

 Depends on strong team and individual performances for identifying
business requirements.
 Only system that can be modularized can be built using RAD
 Requires highly skilled developers/designers.
 High dependency on modeling skills
 Inapplicable to cheaper projects as cost of modeling and automated code
generation is very high.
EVOLUTIONARY PROCESS MODELS
 Software, like all complex systems, evolves over a period of time.
 Business and product requirements often change as development proceeds,
making a straight line path to an end product unrealistic
 Tight market deadlines make completion of a comprehensive software
product impossible, but a limited version must be introduced to meet
competitive or business pressure.
 A set of core product or system requirements is well understood, but the
details of product or system extensions have yet to be defined.
 Evolutionary models are iterative.
 The two common evolutionary process models are The Prototype Model and
The Spiral Model.
THE PROTOTYPE MODEL
 Often, a customer defines a set of general objectives for software, but does
not identify detailed requirements for functions and features.
 In other cases, the developer may be unsure of the efficiency of an
algorithm, the adaptability of an operating system, or the form that human-
machine interaction should take.
 In these, and many other situations, a prototyping paradigm may offer the
best approach.
 The prototyping model can be considered to be an extension of the
waterfall model.
 This model suggests building a working prototype of the system, before
development of the actual software.
 A prototype is a toy and crude implementation of a system. It has limited
functional capabilities, low reliability, or inefficient performance as
compared to the actual software.
 It is a toy implementation which provides a chance to give feedback for
final product development.
FIG: PROTOTYPE MODEL
Advantages of the prototyping model:
 This model is the most appropriate for projects that suffer from technical
and requirements risks. A constructed prototype helps overcome these risks.
 It minimizes redesign and redevelopment costs.

Disadvantages of the prototyping model:

 The prototype model can increase the cost of development for projects that
are routine development work and do not suffer from any significant risks.
 This model is effective only when the risks are identified before the
development starts.
THE SPIRAL MODEL
 Each loop in the spiral represents a phase of software development.
 The exact number of loops in the spiral is not fixed.
 In the spiral model prototypes are built at the start of every phase. Each phase
of the model is represented as a loop in its diagrammatic representation. Over
each loop, one or more features of the product are elaborated and analyzed
and the risks at that point of time are identified and are resolved through
prototyping. Based on this, the identified features are implemented.
 Quadrant 1: The objectives are investigated, elaborated, and analysed.
Based on this, the risks involved in meeting the phase objectives are
identified. In this quadrant, alternative solutions possible for the phase
under consideration are proposed.
 Quadrant 2: During the second quadrant, the alternative solutions are
evaluated to select the best possible solution. To be able to do this, the
solutions are evaluated by developing an appropriate prototype.
 Quadrant 3: Activities during the third quadrant consist of developing and
verifying the next level of the software. At the end of the third quadrant,
the identified features have been implemented and the next version of the
software is available.
 Quadrant 4: Activities during the fourth quadrant concern reviewing the
results of the stages traversed so far (i.e. the developed version of the
software) with the customer and planning the next iteration of the spiral.
The radius of the spiral at any point represents the cost incurred in the
project so far, and the angular dimension represents the progress made so
far in the current phase.
CONCURRENT MODELS
 The concurrent development model, sometimes called concurrent
engineering, allows a software team to represent iterative and concurrent
elements of any of the process models.
 For example, the modeling activity defined for the spiral model is
accomplished by invoking one or more of the following software
engineering actions: prototyping, analysis, and design.
 The activity—modeling—may be in any one of the states - noted at any
given time.
 Similarly, other activities, actions, or tasks (e.g., communication or
construction) can be represented in an analogous manner.
 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.
 For example, during early stages of design an inconsistency in the
requirements model is uncovered. This generates the event analysis model
correction, which will trigger the requirements analysis action from the
done state into the awaiting changes state.
 Concurrent modeling is applicable to all types of software development and
provides an accurate picture of the current state of a project.
 Each activity, action, or task on the network exists simultaneously with
other activities, actions, or tasks. Events generated at one point in the
process network trigger transitions among the states.
2. SPECIALIZED PROCESS MODELS

 Specialized process models take on many of the characteristics of one

or more of the traditional model.
 However, these models tend to be applied when a specialized or
narrowly defined software engineering approach is chosen.
 Some of the specialized process models are:
1. Component-Based Development
2. The Formal Methods Model
3. Aspect-Oriented Software Development
COMPONENT-BASED DEVELOPMENT
 Commercial off-the-shelf (COTS) software components, developed by
vendors (a person or company offering something fro sale) who offer them
as products, can be used when software is to be built.
 These components 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 constructs applications from
prepackaged software components.
 The component-based development model leads to software reuse, and
reusability provides software engineers with a number of measurable
benefits.
The following are the activities of this model, which are implemented using an
evolutionary approach:
 Available component-based products are researched and evaluated for the
application domain in question.
 Component integration issues are considered.
 Software architecture is designed to accommodate the components.
 Components are integrated into the architecture.
 Comprehensive testing is conducted to ensure proper functionality.
THE FORMAL METHODS MODEL
 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 clean room 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.
ASPECT-ORIENTED SOFTWARE DEVELOPMENT
 Regardless of the software process that is chosen, the builders of complex
software invariably implement a set of localized features, functions, and
information content.
 These localized software characteristics are modeled as components (e.g.,
object oriented classes) and then constructed within the context of a system
architecture.
 As modern computer-based systems become more sophisticated (and
complex), certain concerns like customer required properties or areas of
technical interest, span the entire architecture.
 When concerns cut across multiple system functions, features, and
information, they are often referred to as crosscutting concerns.
 When concerns cut across multiple system functions, features, and
information, they are often referred to as crosscutting concerns.
 Aspectual requirements define those crosscutting concerns that have an
impact across the software architecture.
 Aspect-oriented software development (AOSD), often referred to as aspect-
oriented programming(AOP), is a relatively new software engineering
paradigm that provides a process and methodological approach for
defining, specifying, designing, and constructing aspects—“mechanisms
beyond subroutines and inheritance for localizing the expression of a
crosscutting concern”.
3. THE UNIFIED PROCESS

 The Unified Process is an attempt to draw on the best features and

characteristics of traditional software process models, but characterize them
in a way that implements many of the best principles of agile software
development.
 The Unified Process recognizes the importance of customer communication
and streamlined methods for describing the customer’s view of a system.
 It emphasizes the important role of software architecture and “helps the
architect focus on the right goals, such as understandability, reliance to
future changes, and reuse”.
 It suggests a process flow that is iterative and incremental, providing the
evolutionary feel that is essential in modern software development.
FIG: UNIFIED PROCESS MODEL
 The inception phase of the UP encompasses both customer communication
and planning activities.
 By collaborating with stakeholders, business requirements for the software
are identified; a rough architecture for the system is proposed; and a plan
for the iterative, incremental nature of the ensuing project is developed.
 The elaboration phase encompasses the communication and modeling
activities of the generic process model. Elaboration refines and expands the
preliminary use cases that were developed as part of the inception phase
and expands the architectural representation.
 The construction phase of the UP is identical to the construction activity
defined for the generic software process. Using the architectural model as
input, the construction phase develops or acquires the software components
that will make each use case operational for end users. To accomplish this,
requirements and design models that were started during the elaboration
phase are completed to reflect the final version of the software increment.
 The transition phase of the UP encompasses the latter stages of the
generic construction activity and the first part of the generic deployment
(delivery and feedback) activity. Software is given to end users for beta
testing and user feedback reports both defects and necessary changes. In
addition, the software team creates the necessary support information (e.g.,
user manuals, troubleshooting guides, installation procedures) that is
required for the release. At the conclusion of the transition phase, the
software increment becomes a usable software release.
PERSONAL AND TEAM PROCESS MODELS

 Software process model has been developed at a corporate or organizational

level.
 It can be effective only if it is helpful to significant adaptation to meet the
needs of the project team that is actually doing software engineering work.
 In an ideal setting, it create a process that best fits your needs, and at the
same time, meets the broader needs of the team and the organization.
 Alternatively, the team itself can create its own process, and at the same time
meet the narrower needs of individuals and the broader needs of the
organization.
 It is possible to create a “personal software process” and/or a “team
software process.”
 Both require hard work, training, and coordination, but both are achievable.
PERSONAL SOFTWARE PROCESS (PSP)
 Every developer uses some process to build computer software.
 The process may be temporary; may change on a daily basis; may not be
efficient, effective, or even successful; but a “process” does exist.
 Personal process, an individual must move through four phases, each
requiring training and careful instrumentation.
 The Personal Software Process (PSP) emphasizes personal measurement of
both the work product that is produced and the resultant quality of the work
product.
 In addition PSP makes the practitioner responsible for project planning
(e.g., estimating and scheduling) and empowers the practitioner to control
the quality of all software work products that are developed.
 The PSP model defines five framework activities:
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
 PSP represents a disciplined, metrics-based approach to software engineering
that may lead to culture shock for many practitioners. However, when PSP is
properly introduced to software engineers, the resulting improvement in
software engineering productivity and software quality are significant.

Team Software Process (TSP)

 Team Software Process (TSP) build a “self-directed” project team that
organizes itself to produce high-quality software.
 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 of 3 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.
 Provide improvement guidance to high-maturity organizations.
 Facilitate university teaching of industrial-grade team skills.
 A self-directed team has a consistent understanding of its overall goals and
objectives; defines roles and responsibilities for each team member; tracks
quantitative project data (about productivity and quality);
 TSP identifies a team process that is appropriate for the project and a
strategy for implementing the process.
 TSP defines local standards that are applicable to the team’s software
engineering work; continually assesses risk and reacts to it; and tracks,
manages, and reports project status.
 TSP defines the following framework activities:
 project launch
 high-level design
 implementation
 integration and test and
 postmortem
 These activities enable the team to plan, design, and construct software in a
disciplined manner while at the same time quantitatively measuring the
process and the product.
 The postmortem sets the stage for process improvements.
 TSP makes use of a wide variety of scripts, forms, and standards that serve
to guide team members in their work.
 TSP recognizes that the best software teams are self-directed.
 Team members set
 project objectives,
 adapt the process to meet their needs,
 control the project schedule, and
 analysis of the metrics collected,
 work continually to improve the team’s approach to software engineering.
 Like PSP, TSP is a rigorous approach to software engineering that provides
distinct and quantifiable benefits in productivity and quality.
 The team must make a full commitment to the process and must undergo
thorough training to ensure that the approach is properly applied.
PROCESS TECHNOLOGY
 Process technology tools have been developed to help software
organizations analyze their current process, organize work tasks, control and
monitor progress, and manage technical quality.
 Process technology tools allow a software organization to build an
automated model of the 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 or cost.
 Once an acceptable process has been created, other process technology tools
can be used to allocate, monitor, and even control all software engineering
activities, actions, and tasks defined as part of the process model.
 Each member of a software team can use such tools to develop a checklist of
work tasks to be performed, work products to be produced, and quality
assurance activities to be conducted.
 The process technology tool can also be used to coordinate the use of other
software engineering tools that are appropriate for a particular work task.