Software Engineering(R22) 1

UNIT I:
The Nature of Software, The Unique Nature of WebApps, 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.

UNIT - I
Software and Software Engineering

1.1 The Nature of Software:

Dual Role of Software
• Both a product and a vehicle for delivering a product
– Product
• Delivers computing potential
• Produces, manages, acquires, modifies, display, or transmits information
– Vehicle
• Supports or directly provides system functionality
• Controls other programs (e.g., operating systems)
• Effects communications (e.g., networking software)
Helps build other software (Software tools and environments).
1.1.1 Software Definition :
Software is
– Instructions : Programs that when executed provides desired
features,function and performance
– Data structures: that enable the programs to adequately manipulate information
– Documents :that describe the operation and use of the program
EX:-An example of software is Excel or Windows

Characteristics of software
software has characteristics that are considerably different than those of hardware:
1. Software is developed or engineered, it is not manufactured in the classical sense.
– Manufacturing phase of a product introduces quality problems.
– Software costs are concentrated in engineering, hence cannot be managed as if they
are manufacturing projects.
2. Software doesn’t “wear out”. It deteriorates.
Hardware:
 Software Engineering(R22) 2
The failure rate rises again as hardware components suffer from the cumulative effects
of dust. vibration, abuse, temperatures extremes
✓ The relationship,often called the “bathtub curve,” indicates that hardware exhibits
relatively high failure rates early in its life
✓ Worn out hardware components can be replaced.

Failure rate curve for hardware

Failure rate curve for software

Software:
▪ the failure rate curve for software should take the form of the “idealized curve”
▪ Undiscovered defects will cause high failure rates early in the life of a program.
Software maintenance requires changing the design and or code

3. Although the industry is moving toward component-based construction, most software

continues to be custom built:
A software component should be designed and implemented so that it can be reused in many
different programs
 Software Engineering(R22) 3

1.1.2 Software Application Domains: (or Changing Nature of Software):

Seven broad categories of computer software present continuing challenges for software engineers:

1. System Software: A collection of programs written to service other programs.

(e.g., compilers, editors, and file management utilities).

2. Application Software: Stand-alone programs that solve a specific business need.

Ex:Microsoft office,Media player.

3. Engineering and Scientific Software: These software are based upon complex numeric
applications
-Used as tools for specific purpose
Ex:MATLAB,WEKA,SCILAB.

4. Embedded Software: Embedded software resides in read-only memory and is used to

control products.
Eg. Robots,drones
5. Product-line software: Product line software designed to provide a specific capability for
use by many different customers.(eg. Word processing, spreadsheets, computer graphics,
multimedia, entertainment, database management and personal and financial applications.).

6. Web Applications: The Web pages retrieved by a browser (e.g., CGI, HTML, Perl, or Java),
(e.g., hypertext and a variety of visual and audio formats).

7. Artificial Intelligence Software: Based on knowledge based expert systems

Ex: (image and voice),Artificial neural networks, Theorem proving, and Game playing.

Challenges to Software Engineers:

New challenges have appeared on the horizon:

1.Open-world computing: the rapid growth of wireless networking may soon lead to true pervasive,
distributed computing

Challenge:
To develop systems and application software that will allow mobile devices, personal computers
and enterprise systems to communicate across vast networks.

2.Netsourcing: It is the World Wide Web is rapidly becoming a computing engine as well as a
content provider.

Challenge:
The challenge for software engineers is to Architect simple (e.g., personal financial planning)
and sophisticated applications that provide a benefit to targeted end-user markets worldwide.

3.Open- Source: Open source is a growing trend that results in distribution of source code for
systems applications so that many people can contribute to its development.
Challenge:
The challenge for software engineers is to build source code that is self-descriptive
 Software Engineering(R22) 4
Software Issues:
• Problems associated with software development are not just restricted to software that doesn’t
function but it also includes
– How we develop software?
– How we support a growing volume of existing software?
– How we keep pace with a growing demand for more software?
Participants in Software Development:
• Software Managers – manage budgets, monitor progress made against project plans, always
look for time to market without compromising quality
• Customers - users
• Practitioners – developers, testers
1.1.3 Legacy Software:
The older programs that are developed decades ago are referred to as Legacy software.

Legacy software systems have been continually modified to meet changes in business requirements and
computing platforms
Why must it change?
As time passes, legacy systems often evolve for one or more of the following reasons:
• Software must be adapted to meet the needs of new computing environments or technology.
• Software must be enhanced to implement new business requirements.
• Software must be extended to make it interoperable with other more modern systems or
databases.
• Software must be re-architected to make it viable within a network environment.
1.2 The Unique Nature of WebApps:
---Web applications (WebApps) encompasses everything from a simple Web page that might help a
consumer compute an automobile lease payment to a comprehensive website
---WebApps have evolved into sophisticated computing tools that not only provide stand-alone
function to the end user, but also have be integrated with corporate databases and business
applications.

The following attributes are found in majority of WebApps:

• Network intensiveness. A WebApp resides on a network and must serve the needs of a
diverse community of clients
• Concurrency. A large number of users may access the WebApp at one time.
• Unpredictable load. The number of users of the WebApp may vary by orders of magnitude
from day to day.
• Performance. If a WebApp user must wait too long, he or she may decide to go elsewhere..
• Availability. Although expectation of 100 percent availability is unreasonable, users of
popular WebApps often demand access on a “24/7/365” basis.
• Data driven. The primary function of many WebApps is to use hypermedia to present text,
graphics, audio, and video content to the end-user.
• Content sensitive. The quality and aesthetic nature of content remains an important
determinant of the quality of a WebApp.
• Continuous evolution. Unlike conventional application software that evolves over a series of
planned, chronologically-spaced releases, Web applications evolve continuously.
• Immediacy. Although immediacy—the compelling need to get software to market quickly—
is a characteristic of many application domains, WebApps often exhibit a time to market that
can be a matter of a few days or weeks.
• Security. Because WebApps are available via network access, it is difficult, if not
impossible, to limit the population of end-users who may access the application.
• Aesthetics. An undeniable part of the appeal of a WebApp is its look and feel.
Software Engineering(R22) 5

A Generic View of Software

1.3 Software Engineering:
Definition
Software Engineering is
• The application of a systematic, disciplined, quantifiable approach to the development,
operation and maintenance of software; i.e., the application of engineering to software.
• The study of approaches as in above.

A Layered Technology

Software Engineering is a layered technology.It cosists of 4 layers

• Quality
• Process
• Methods
• Tools

Quality:
– Engineering approach must rely on quality
– Bed rock that supports Software Engineering
Process:
• To manage software development,
• establish milestones,
• determine the work products to produce,
• manage quality and change
 Software Engineering(R22) 6
Methods:
– Provide the technical “how to” for building Software
– rely on a set of basic principles;
– encompass a broad array of tasks such as
• analysis,
• design,
• program construction,
• Testing,
• support
-include modeling activities
Tools:
– Support the process and the methods
– Could be automated or semi-automated
– e.g., Computer Aided Software Engineering (CASE) Tool

1.5 Software Engineering Practice

1.5.1 The Essence of Practice

George Polya outlined the essence of problem solving as follows:
1.Understand the problem (communication and analysis).
2..Plan a solution (modeling and software design).
3.Carry out the plan (code generation).
4.Examine the result for accuracy (testing and quality
assurance
.
1. Understand the Problem (communication and analysis).

• Who are the stakeholders?

• What functions and features are required to solve the problem?
• Is it possible to create smaller problems that are easier to understand?
• Can a graphic analysis model be created?
2. Plan the Solution (modeling and software design).
• Have you seen similar problems before?
• Has a similar problem been solved?
• Can readily solvable sub problems be defined?
• Can a design model be created?
3.Carry Out the Plan (code generation)

• Does solution conform to the plan?

• Is each solution component probably correct?

4.Examine the Result y (testing and quality assurance).

• Is it possible to test each component part of the solution?
• Does the solution produce results that conform to the data, functions, and
features required?
1.5.2 Software General
Principles
The word principle is
“an important
underlying law or
assumption required
in a system of
thought.”
 Software Engineering(R22) 7

Hooker has proposed seven principles that focus on software engineering practice as a whole
1.The First Principal:The Reason It All Exists

A software system exists for one reason to provide values to the user.
2.The Second Principal: KISS (Keep It Simple, Stupid!)

Software design is not a haphazard process.There are many factors to consider in any
design effort.All design should be kept as simple as possible

3.The Third Principal: Maintain the Vision

A clear vision is essential to the success of a software project.without one, a project
almost unfailingly ends up .

4.The Fourth principal: What You Produce, Others Will Consume

Always specify,design,and implement knowing someone else will have to understand
what you are doing.

5.The Fifth Principal: Be Open to the Future

A system with a long lifetime has more value. Never design yourself into a corner.
be sure that the software has a business purpose

6.The Sixth Principal: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.
7.The Seventh
Principal:Think!
Placing clear, complete thought before action almost always produces better results.
When you think about something, you are more likely to do it right

1.5 SOFTWARE MYTHS

Software myths are erroneous beliefs about software and the process that is used to build it.

- We categorize myths from three different perspectives.

- : Management myth
- Customer myth
- Practitioner’s myth

1.MANAGEMENT MYTHS
Myth 1:The available standards and procedures for software are enough.

Reality:
• The book of standards may very well exist, but is it used?

• Are software practitioners aware of its existence?

• Is it complete?

• Is it adaptable?
 Software Engineering(R22) 8
In many cases, the answer to these entire question is NO.

Myth 2:Adding more programmers when the work is behind schedule can catch up.
Reality:
– Adding people to a late software project makes it later
– Training time, increased communication lines
Myth 3:Outsourcing the software project to third party, we can relax and let that party build it.
Reality:
-Software projects need to be controlled and managed.
2.CUSTOMER MYTHS
Myth(1)- General statement of objective is enough to begin writing programs, the details can
be filled in later.
Reality:

– Ambiguous statement of objectives spells disaster

Myth(2)-Software is easy to change because software is flexible

Reality: Impact of change depends on where and when it occurs in the software life cycle (requirements
analysis, design, code, test).

3.PRACTITIONER’S MYTH
• Myth(1)-Once the program is written, the job has been done.
Reality: 50% to 70% of all the efforts are expended after the software is delivered to the user.

• Myth(2)-Until the program is running, there is no way of assessing the quality.

Reality: Formal technical reviews of requirements analysis documents, design documents, and
source code (more effective than actual testing)
Myth(3)-The only deliverable work product is the working program
Reality: Software, documentation, test drivers, test results.

• Myth(4)-Software Engineering creates voluminous and unnecessary documentation and invariably

slows down software development.
Reality: Creates quality, not documents; quality reduces rework and provides software on time and
within the budget
1.6 A Generic Process Model
Software Process:
• A process is a collection of activities, actions, and tasks that are performed when
some work product is to be created.
➢ Software process includes :
➢ Tasks – focus on a small, specific objective.
➢ Action – set of tasks that produce a major work product.
➢ Activities – group of related tasks and actions for a major objective
Process Framework:
• Establishes foundation to Software Engineering by identifying small no of framework
activities and umbrella activities
• That are applicable for entire software process.
• A process framework(basic structure) for software engineering defines five framework
activities.
Software Engineering(R22) 12

Generic process Model framework activities:

A generic process framework for software engineering encompasses five activities:

• Communication,
• Planning,
• Modelling,
• Construction and
• Deployment.
1. Communication: Involves heavy communication and collaboration with the customer and
encompasses requirement gathering etc.
2. Planning: Establishes a plan for the technical tasks to be conducted,
--- resources, work products, and work schedule
3. Modeling: Encompasses the creation of models and the design
4. Construction: This activity combines code generation and the testing that is required to
uncover errors.

5. Deployment: Involves delivery of software to the customer for evaluation and feedback
Software Engineering(R22) 13

• Each framework activity includes a set of engineering actions and each action defines a set of
tasks that incorporates
• work products,
• project milestones and
• software quality assurance (SQA) points that are required.
• Umbrella activities are carried throughout the process.

A Software Process Framework

✓ A Process Framework establishes the foundations for a complete software process by identifying
a small number of framework activities that are applicable to all software projects.
✓ It also encompasses a set of umbrella activities that are applicable across the entire software
process.
 Software Engineering(R22) 14
1.6.1 Defining a Framework Activity

A software team would need significantly more information before it could properly execute any one of
these activities as part of the software process.
What actions are appropriate for a framework activity, given the nature of the problem to be solved, the
characteristics of the people doing the work, and the stakeholders who are sponsoring the project.
1.6.2 Identifying a Task Set

A task set defines the actual work to be done to accomplish the objectives of a software engineering
action.
• A list of the task to be accomplished
• A list of the work products to be produced
• A list of the quality assurance filters to be applied
For example, a small software project requested by one person with simple requirements, the
communication activity might encompass little more than a phone all with the stakeholder.
Therefore, the only necessary action is phone conversation, the work tasks of this action are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval.
5.
1.6.3 PROCESS PATTERNS
Software Process is defined as collection of Patterns.
Process pattern provides a template.
It comprises of

• Process pattern Template

1. Pattern Name:
Meaningful name must be given to a pattern within context of software process Ex:Customer
communication.

2.Intent:
The objective of this is described briefly.
Ex:The purpose of customer communication is to establish connection with customer.
3.Types:
Pattern type is specified
i) Task pattern
action or work.
ii) Stage pattern
framework activity for process
iii)Phase Pattern
sequence of framework activities
4. Initial Context
Conditions under which the pattern applies are described by initial context.
5. Problem
Any specific problem is to be solved by pattern.
6. Solution
Describes how to implement pattern successfully.
7.Resulting Context
It describes conditions that pattern results once implemented successfully.
8.Related Patterns
Provide a list of all process patterns that are directly related to this one
 Software Engineering(R22) 15
1.9 Process Flow

Process flow determines how activities, actions and tasks are arranged with respect to sequence and time

• Linear process flow executes each of the five activities in sequence.

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

1.10 Umbrella Activities:

1. Software project tracking and control:

• Assessing the progress against the project plan and

• Take necessary action to maintain schedule.

2. Risk Management: Assesses risks that may effect the outcome and quality of the product.
3. Software quality assurance: Defines and conducts the activities to ensure software quality.

4. Formal technical reviews: To uncover and remove errors before going to next
action or activity.

5. Measurement:

Defines and collects process, project and products measures t o e n s u r e customer’s needs.
6. Software configuration management: M anages the effects of change throughout the
software process.
7. Reusability management: Defines and establishes to achieve reusable components.
8. Work product preparation production: Create work products such as models, documents,
logs, forms and lists.

Umbrella Activities are applied throughout the software process. All process models can be
characterized within process framework.
Software Engineering(R22) 17
1.11 Process Assessment and Improvement:
The process should be assessed to ensure that it meets a set of basic process criteria that are essential
for a successful software engineering.
• The relationship between the software process and the methods applied for assessment and
improvement is show in the following figure.

Different Approaches to software process assessment:

1. Standard CMMI Assessment Method for Process Improvement(SCAMPI):
It provides a five-step process assessment model i.e.
• Initiating
• Diagnosing
• Establishing
• Acting
• Learning.
SEI CMMI is the basis for assessment.
2. CMM-Based Appraisal for Internal Process Improvement(CBA IPI):
It provides a diagnostic technique for assessing the relative maturity of a software organization. It
also uses SEI CMMI as the basis for assessment.

3.SPICE (ISO/IEC 15504):

This standard defines a set of requirements for software process assessment.
 Software Engineering(R22) 18

4. ISO 9001:2000 for software:

It is a generic standard that applies to any organization.
The International Organization for Standardization (ISO) has developed the ISO 9001:2000 standard
to define the requirements for a quality management system that will serve to produce higher quality
products and thereby improve customer satisfaction.
ISO 9001:2000 has adopted a “plan-do-check-act” cycle.
Plan establishes the process objectives, activities and tasks necessary to achieve high quality
software.
Do implements the software process.
Check monitors and measures the process to ensure that all requirements established for quality
management have been achieved.
Act initiates software process improvement activities that continually work to improve the process.

Prescriptive Process Models:

Every software engineering organization should describe unique set of framework activities for the
software process it adopts.
The framework activities should populate with set of software engineering actions and define each
engineering actions in terms of task sets
The tasks (and degree of rigor) for each activity will vary based on:
▪ the type of project (an “entry point” to the model)
▪ nature of the project
▪ people who work on the project
▪ the environment in which the work will be conducted.
 Software Engineering(R22) 19
--Process models are called to be “prescriptive”
because they prescribe
1. a set of process elements – framework activities, software engineering actions, tasks, work
products, quality assurance and change control mechanisms for each project.
2. a workflow – that is the manner in which the process elements are interrelated to one another.

Software Process Models:

1. Sequential/Linear Process Models
2. Incremental Process Models
3. Evolutionary Process Models
4. Specialized Process Models

1. Sequential/Linear Process Models:

a) The Waterfall Model:

It is also known as Linear Sequential Model or Classic Life Cycle.

Communication: This framework activity involves heavy communication and collaboration with the
customer and encompasses requirement gathering etc.
Planning: This activity establishes a plan for the technical tasks to be conducted, the risks that are
likely to be occurred, the resources that will be required, the work products to be produced and a
work schedule.
Modeling: This activity encompasses the creation of models and the design that will achieve the
requirements.
i) Analysis
– Provide a clear definition of the required functionality, performance and interface.
Focus is on Software.
– Documented and Reviewed with the Customer.
ii) Design
– Translates requirements into a representation of software e.g., data structures,
algorithms, interfaces etc.
– Documented and Reviewed.
– Serves as a quality check point before coding begins.
Construction: This activity combines code generation and and the resting that is required to uncover
errors in the code.
 Software Engineering(R22) 20
Code Generation
– Translation of the design into machine executable code
– Could be mechanized
Testing
a. Check that all functional requirements are met.
b. Ensure that defined input will produce results that agree with required results.
c. Focus is on the logical internals of the software
Deployment: The software is delivered to the customer who evaluates the delivered product and
provides feed back.

• Advantages of the waterfall model

• A simple model to use and implement.
• Easily understandable workflow.
• Easy to manage since requirements are known prior to the start of the project.
• Can be applied to projects where quality is preferred over cost.

Drawbacks or Issues:
• Requires that the customer state all requirements clearly upfront. In reality, it is very difficult.
• A working version of the software will not be available until late in the project life cycle.
• Difficult to accommodate changes in mid-stream as changes have to wait till the end of the
current cycle.
• Leads to blocking states as some team members have to wait for the others to complete
dependent tasks.

b) The V-Model
 Software Engineering(R22) 21

A variation of waterfall model depicts the relationship of quality assurance actions to the actions
associated with communication, modeling and early code construction activates.
Team first moves down the left side of the V to refine the problem requirements.
Once code is generated, the team moves up the right side of the V, performing a series of tests that
validate each of the models created as the team moved down the left side.

Incremental Process Models:

Incremental Model
Software Engineering(R20) 23

• When initial requirements are reasonably well defined, but the overall scope of the
development effort precludes a purely linear process. A compelling need to expand a limited
set of new functions to a later system release.
• It combines elements of linear and parallel process flows. Each linear sequence produces
deliverable increments of the software.
• Applies Linear Sequences in a staggered fashion resulting in multiple incremental
deliverables
• The first increment is often a core product with many supplementary features. Users use it
and evaluate it with more modifications to better meet the needs.
• Develops a plan based on feedback from the use of the product (both development and
customer feedback) to fix problems, augment functionality in the next deliverable.

Suitable for
• Where there is short of skilled resources
• Where new technology is being used
• When business deadlines are aggressive

b) RAD Model:
• Rapid Application Development
• Emphasizes extremely short development cycle-60 to 90 days
• Incremental Software Development Process

Use multiple teams on scaleable projects.

• Requires heavy resource.
• Uses Component Based Software Development
• High-speed adaptation of Linear Sequential Model
• Used primarily for Information Systems Applications

– Students Academic Information

– Library Information
 Software Engineering(R20) 24
Suitable for applications that can be modularized (say one module for each function) and canbe worked

upon by multiple independent teams

Drawbacks:
– Requires large manpower for larger projects to create sufficient number of RAD
teams
– Requires high commitment to develop software in a shorter time span

Not suitable when application relies on new technology and requires high degree of interoperability
with existing software

Evolutionary Models:

• The evolutionary model permits requirements, plans and estimates to evolve over time.
• Evolutionary models are iterative. They are characterized in a manner that enables software
engineers to develop increasingly more complete versions of the software.
• Two types
1)prototyping and the
2) spiral model
 Software Engineering(R22) 26
– .

Prototyping Model:

The prototyping paradigm begins with communication.

A “quick plan” and a "quick design" then occurs.

The quick design focuses on a representation of those aspects of the software that will be visible to
the customer/user.
Two types of prototypes exist:
1. Throw away prototype
2. Evolutionary prototype

The different phases of Prototyping model are:

1. Communication
In this phase, developer and customer meet and discuss the overall objectives of the software.

2. Quick design:Quick design is implemented when requirements are known.

• It includes only the important aspects like input and output format of the software.

• It focuses on those aspects which are visible to the user rather than the detailed plan.

• It helps to construct a prototype.

3. Modeling quick designThis phase gives the clear idea about the development of software because the
software is now built.

• It allows the developer to better understand the exact requirements.

 Software Engineering(R22) 27
4. Construction of prototype
The prototype is evaluated by the customer itself.

5. Deployment, delivery, feedbackIf the user is not satisfied with current prototype then it refines
according to the requirements of the user.

• The process of refining the prototype is repeated until all the requirements of users are met.
Some prototypes are built as “throwaways”,

b) Spiral Model:

• Proposed by Boehm

• the spiral model is an evolutionary software process model that Combines the iterative nature of
prototyping with Prototype model with the Linear Sequential Model.
● Using the spiral model, software is developed in a series of evolutionary releases.
○ During early iterations, the release might be a model or prototype.
○ During later iterations, increasingly more complete versions of the engineered system are produced.
○ A spiral model is divided into a set of framework activities-– task regions
○ Each of the framework activities represent one segment of the spiral path.

○ 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.
Phase1: Concept development
Phase2: New product development
Phase3: Product enhancements
Phase4: Product Maintenance

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.

Framework Activities of spiral model

Software Engineering(R22) 28

a) Concurrent Model:

Concurrent Process model is an evolutionary process model in software engineering

Advantages of the concurrent development model

• This model is applicable to all types of software development processes.
• It is easy for understanding and use.
• It gives immediate feedback from testing
• It provides an accurate picture of the current state of a project.
Disadvantages of the concurrent development model
• It needs better communication between the team members. This may not be achieved all the time.
• It requires to remember the status of the different activities
Software Engineering(R22) 29
4. Specialized Process Models:
Special process models take many features from one or more conventional models
a) Component based development model: (Promotes reusable components)
The component-based development model incorporates many of the characteristics of the
spiral model. It is evolutionary in nature.
This model composes applications from pre-packaged software components.

It incorporates the following steps:

1. Available component-based products are researched and evaluated for the application
domain.
2. Component issues are considered.
3. Software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality.
The component based development model leads to software reuse.
6. It provides software engineers with a number of measurable benefits
7.
b) The Formal Method 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 a software engineer 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.
• Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily
through mathematical analysis
• Offers the promise of defect-free software
• Used often when building safety-critical systems
Challenges of Formal method model:
• 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.
Software Engineering(R22) 30

Aspect-Oriented Software Development:

Aspect-oriented software development (AOSD), referred to as aspect-oriented programming (AOP)
is relatively new software engineering paradigm that provides a process and methodological
approach for defining, specifying, designing and constructing aspects.
Certain “concerns” – customer required properties or areas of technical interest – span the entire
s/w architecture
Example “concerns”
Security
Fault Tolerance
Task synchronization
Memory Management
When concerns cut across multiple system functions, features, and information, they are often
referred to as crosscutting concerns.
 Software Engineering(R22) 31

The Unified Process:

The Unified Process (UP) is an attempt to draw on the best features and characteristics of
conventional software process models.
The UP recognizes the importance of customer communication and streamlined methods for
describing the customer’s view of a system through use-cases. A use-case is a text narrative or
template that describes a system function or feature from the user’s (or actor’s) point of view. The
UP came about as a result of the need to meet a growing demand for bigger and more complex
systems.
Phases of Unified Process
The UP consists of five (5) phases which are similar to the five generic phases discussed
earlier. These phases are: Inception, Elaboration, Constructions, Transition and Production.

Phase Name Description

Inception Encompasses both customer communication and planning activities. Through
Phase collaboration with customer and end-users, business requirements for the software are
identified through the development of use-cases, a rough architecture is proposed and
a plan for iterative, incremental nature of the project is developed.
Elaboration At this stage the preliminary use-cases developed in previous phase are refined and
Phase expanded. In addition the architecture and plans are refined to ensure that the scope,
risks, and delivery times remain reasonable.
Construction Using the architectural model as input, this phase of the process develops or acquires
Phase the software components that will make each use-case operational for end-users. As
these components are being developed, unit tests are designed and executed for each.
The different components are also integrated and tested.
Transition At this stage, the software is given to users for testing with the intent of uncovering
Phase defects and deficiencies. A defect/deficiency reporting scheme is established, and the
software team assesses the feedback. Also at this stage, user manuals, trouble-
shooting guides, and installation procedures are produced.
Production During this phase, the on-going use of the software is monitored, support is provided
Phase and defect reports and requests for changes are submitted and evaluated.
Unified process phases
Software Engineering(R22) 32

Personal and Team Process Models:

Watts Humphrey suggests that it is possible to create a personal software process and a team
software process. Both require hard work, training and coordination, but both are achievable.

Personal Software Process (PSP):

1. Personal software process(PSP) emphasizes personal measurement of both the work product that
is produced and the resultant quality of the work product.
2. PSP makes the practitioner responsible for project planning and controlling the quality of all
software work products that are developed.
3. PSP process model defines five framework activities:
• Planning
• High-Level Design
• High-Level design review
• Development
• Postmortem
Software Engineering(R22) 33

Planning: This activity isolates requirements. Based on these, size and resource estimates, defect
estimates etc. are made.
High-Level Design: External Specifications for each component are developed and a component
design is created.
High-Level Design review: Formal verification methods are applied to uncover errors in the design.
Development: The component level design is refined and reviewed. Code is generated, reviewed,
complied and tested.
Postmortem: using measures and metrics the effectiveness of the process is determined.
.

Team Software Process (TSP):

The goal of TSP is to build “a self-directed” project team the organizes itself to produce high-quality
software.
The following are the objectives for TSP:
• Build self-directed teams that plan and track their work, establish goals and own
their processes and plans.
• Team of 3 to 20 engineers
• Show managers how to coach and motivate their teams and how to help them.
• Accelerate software process improvement
• Provide improvement guidance to organizations.
• Facilitate University teaching.
• Track,manages and reports project status

TSP defines the following framework activities:

• Launch
• High-Level Design
• Implementation
• Integration and Test
• Postmortem.

TSP provides a framework and a set of tools that help

teams to:
• Define and track their goals, roles, and
responsibilities
• Plan and estimate their tasks, resources, and
schedules
• Measure and monitor their progress and performance
• Identify and resolve their issues and risks
• Review and improve their processes and products
• Communicate and collaborate effectively with each other and with other stakeholder
Software Engineering(R22) 34

• These activities enable the team to plan, design and construct software in a disciplined manner.
• 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.
• Scripts define specific process activities i.e., project launch, design, implementation, integration &
testing and postmortem and other more detailed work functions like development planning,
requirements development, software configuration management and unit test.

1.12 PROCESS TECHNOLOGY

Process technology refers to the use of machines, equipment, and devices for operations for
creating and delivering products/services
• Process technology tools allow a software organization to build an automated model of the
process framework, task sets, and umbrella activities
• 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.
Software Engineering(R22) 35
Product
The product is the final outcome of the software development process. A product is built on the
customer's requirements/requests.
Process
The process is a set of steps that are to be followed to create a product. A process is a template that
can be used to create multiple products in a similar fashion.

The following are some of the important differences between Product and Process.

Sr. No. Key Product Process

The process is a sequence or set of
The product is the final result of a
1 Concept steps that should be followed to create
development cycle.
a product.
The process focuses on each step to
Product development focus is on final
2 Focus be followed during software product
outcome.
development.

A product life cycle tends to be in the short A process life cycle is generally long
Life
3 term. term.
The main goal of product development isto
The main goal of a process is to make
4 Goal finish the work and get the product
a good quality products.
delivered successfully.

*********************