Module 1

Software and Software Engineering

Process Models
 Definitions
• Software:
Software is a collection of programs solving a particular problem
over a computer device within an acceptable amount of time

• Software engineering:
Software Engineering is an engineering branch which is a
systematic and disciplined approach to software development that aims
to create high-quality, reliable, and maintainable software
Why is Software Engineering required?
Software Engineering is required due to the following reasons:

• To manage Large software

• For more Scalability
• Cost Management
• To manage the dynamic nature of software
• For better quality Management
 The Nature of Software
• software takes on a dual role.

• It is a product, and at the same time, the 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.
• Whether it resides within a mobile phone or operates inside a mainframe computer, software
is an information transformer—producing, managing, acquiring, modifying, displaying, or
transmitting information that can be as simple as a single bit or as complex as a multimedia
presentation derived from data acquired from dozens of independent sources.

• As the vehicle used to deliver the product, software acts as the basis for the control
of the computer (operating systems), the communication of information (networks),
and the creation and control of other programs (software tools and environments).
 The Nature of Software
• Software delivers the most important product of our time—information.

• It transforms personal data (e.g., an individual’s financial transactions) so that the data
can be more useful in a local context
• it manages business information to enhance competitiveness
• it provides a gateway to worldwide information networks (e.g., the Internet),
• provides the means for acquiring information in all of its forms.

• A huge software industry has become a dominant factor in the economies of

the industrialized world.

• Teams of software specialists, each focusing on one part of the technology

required to deliver a complex application, have replaced the lone programmer
of an earlier era
 The Nature of Software
Some of the same questions asked from lone developer to a team of dedicated
developers are as follows:
• Why does it take so long to get software finished?
• Why are development costs so high?
• Why can’t we find all errors before we give the software to our customers?
• Why do we spend so much time and effort maintaining existing programs?
• Why do we continue to have difficulty in measuring progress as software is being
developed and maintained?

• Such questions acts as a manifestation of the concern about software and the
manner in which it is developed—
a concern that has lead to the adoption of
software engineering practice
 Defining Software
• Software is:
(1) instructions (computer programs) that when executed
provide desired features, function, and performance
(2) data structures that enable the programs to adequately
manipulate information, and
(3) descriptive information in both hard copy and virtual
forms that describes the operation and use of the
programs.
 Characteristics of Software
• Software has characteristics that are considerably different than those of
hardware

• Software is developed or engineered; it is not manufactured in the classical sense

• Software doesn’t “wear out.”

Failure Curve of Hardware and Software

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

continues to be custom built.
 Software Application Domains
• System software
• Application software
• Engineering/scientific software
• Embedded software
• Product-line software
• Web applications
• Artificial intelligence software
 Legacy Software
• Legacy software systems are developed decades ago and have been
continually modified to meet changes in business requirements and
computing platforms.

• “many legacy systems remain supportive to core business functions

and are ‘indispensable’ to the business.” Hence, legacy software is
characterized by longevity and business criticality.
 The Unique Nature of WebApps
• A Web App is like a special computer program that you can use on the internet
without having to download it onto your computer. It is different from regular
apps that you need to install

• Web-based systems and applications (referred as WebApps) have evolved into

sophisticated computing tools that not only provide stand-alone function to the
end user, but also have been integrated with corporate databases and business
applications

• Web-based systems and applications involve a mixture between

• print publishing and software development, between marketing and computing,
between internal communications and external relations, and between art and
technology
 WebApp Attributes
• Network intensiveness
• Concurrency
• Unpredictable load
• Performance
• Availability
• Data driven
• Content sensitive
• Continuous evolution
• Immediacy
• Security
• Aesthetics
 Software Engineering
• Definition:
Software engineering is the discipline that enables establishment and use of sound
engineering principles in order to obtain economically software that is reliable and works
efficiently on real machines

• In order to build software that is ready to meet the challenges of the twenty-first
century, recognizing a few simple realities is important and they are:
• a concerted effort should be made to understand the problem before a software solution is
developed
• design becomes a pivotal activity.
• software should exhibit high quality
• software should be maintainable
PROCESS MODELS
• Definition:
Software process is a framework for the activities, actions, and tasks
that are required to build high-quality software

• Software process is a “Road Map” involving a series of predictable steps

that helps in building a timely, high-quality products
A Generic Process Model
• The software process is represented
schematically in the following figure,
referring to the figure:
• Each framework activity is populated by
a set of software engineering actions.
• Each software engineering action is
defined by a task set that identifies the
work tasks that are to be completed,
the work products that will be
produced, the quality assurance points
that will be required, and the
milestones that will be used to indicate
progress
 Defining a Framework Activity
• A software team would need significantly more information before it could properly execute any
one of the five framework activities as part of the software process

• For a small software project requested by one person (at a remote location) with simple,
straightforward requirements, the communication activity might encompass little more than a
phone call with the appropriate stakeholder.

• Therefore, the only necessary action is phone conversation, and the work tasks (the task set) that
this action encompasses are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval.

• If the project was considerably more complex with many stakeholders, each with a different set of
(sometime conflicting) requirements, the communication activity might have six distinct actions:
• inception, elicitation, elaboration, negotiation, specification, and validation
 Identifying a Task Set
• Each software engineering action (e.g., elicitation, an action associated with the
communication activity) can be represented by a number of different task sets—
each 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 the 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
 Task Set
• For a larger, more complex software project, a different task set would be required. It
might encompass the following work tasks:

1. Make a list of stakeholders for the project.

2. Interview each stakeholder separately to determine overall wants and needs
3. Build a preliminary list of functions and features based on stakeholder input.
4. Schedule a series of facilitated application specification meetings.
5. Conduct meetings.
6. Produce informal user scenarios as part of each meeting.
7. Refine user scenarios based on stakeholder feedback.
8. Build a revised list of stakeholder requirements.
9. Use quality function deployment techniques to prioritize requirements.
10. Package requirements so that they can be delivered incrementally.
11. Note constraints and restrictions that will be placed on the system.
12. Discuss methods for validating the system
 Task Set
• For a small, relatively simple project, the task set for requirements
gathering might look like this:

1. Make a list of stakeholders for the project.

2. Invite all stakeholders to an informal meeting.
3. Ask each stakeholder to make a list of features and functions required.
4. Discuss requirements and build a final list.
5. Prioritize requirements.
6. Note areas of uncertainty.
 Process Patterns
• Definition:
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

• A Process Pattern provides a template - a consistent method for describing

problem solutions within the context of the software process.

• By combining patterns, a software team can solve problems and construct a

process that best meets the needs of a project
 Process Patterns(Contd..)
• Ambler has proposed a template for describing a process pattern:

1. Pattern Name.
The pattern is given a meaningful name describing it within the context of the software process (e.g., TechnicalReviews).

2. Forces
The environment in which the pattern is encountered and the issues that make the problem visible and may affect its
solution.

3. Type.
The pattern type is specified

4. Initial context
Describes the conditions under which the pattern applies

5. Resulting Context
Describes the conditions that will result once the pat tern has been successfully implemented

6. Related Patterns.
Provide a list of all process patterns that are directly related to this one. This may be represented as a hierarchy or in some other
diagrammatic form

7. Known Uses and Examples

 Process Patterns(Contd..)
• Ambler suggests three types:
1. Stage pattern—
defines a problem associated with a framework activityfor the process. Since a framework
activity encompasses multiple actions and worktasks, a stage pattern incorporates multiple task
patterns (see the following) that are relevant to the stage (framework activity). An example of a
stage pattern might be Establishing Communication. This pattern would incorporate the task
pattern Requirements Gathering and others.

2. 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).

3. Phase pattern—
define the sequence of framework activities that occurs within the process, even when the
overall flow of activities is iterative in nature. An example of a phase pattern might be Spiral
 Process Assessment and Improvement
• Standard CMMI Assessment Method for Process Improvement (SCAMPI)—
provides a five step process assessment model that incorporates five phases: initiating,
diagnosing, establishing, acting and learning.

• CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—

provides a diagnostic technique for assessing the relative maturity of a software
organization; uses the SEI CMM as the basis for the assessment

• SPICE—
The SPICE (ISO/IEC15504)standard defines a set of requirements for software process
assessment. The intent of the standard is to assist organizations in developing an
objective evaluation of the efficacy of any defined software process.

• ISO 9001:2000 for Software—

a generic standard that applies to any organization that wants to improve the overall
quality of the products, systems, or services that it provides. Therefore, the standard is
directly applicable to software organizations and companies.
Process Models
The Evolutionary Model:
Concurrent
 Description
• Early in a project the communication activity has completed its first iteration and exists in the
awaiting changes state.

• The modeling activity (which existed in the inactive state while initial communication was
completed, now makes a transition into the under-development state.

• If, however, the customer indicates that changes in requirements must be made, the modeling
activity moves from the under-development state into the awaiting changes state.

• 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
• Example:
an inconsistency in the requirements model is uncovered might uncovered in early design stage.

This generates the event analysis model correction, which will trigger the requirements analysis
action from the done state into the awaiting changes state
 Advantages
• We can use this model in all types of software development
processes.
• It is so much easier to understand.
• It also provides immediate feedback after the testing process is done.
• It also provides an accurate picture of the state of the project.

Disadvantages
• We have to improve communication between the team members.
• It requires remembering the status of the different activities.
 Points to be considered while
applying Evolutionary Models
1. Prototyping and other more sophisticated evolutionary processes poses a problem to
project planning because of the uncertain number of cycles required to construct the
product.

2. Evolutionary software processes do not establish the maximum speed of the evolution. If
the evolutions occur too fast, without a period of relaxation, it is certain that the process
will fall into chaos. On the other hand, if the speed is too slow then productivity could be
affected

3. Software processes should be focused on flexibility and extensibility rather than on high
quality. This assertion sounds scary. However, we should prioritize the speed of the
development over zero defects. Extending the development in order to reach high quality
could result in a late delivery of the product, when the opportunity niche has disappeared
 Specialized Process Models
1. Component-Based Development

2. The Formal Methods Model

3. Aspect-Oriented Software Development

 Component-Based Development
• Component-Based Software Engineering (CBSE) is a process that focuses on the design and
development of computer-based systems with the use of reusable software components.

• Adopts COTS(Commercial Off-The-Shelf) method

• It not only identifies candidate components but also qualifies each component’s interface, adapts
components to remove architectural mismatches, assembles components into a selected
architectural style, and updates components as requirements for the system change.

• The component-based development model incorporates the following steps (implemented using
an evolutionary approach):
1. Available component-based products are researched and evaluated for the application domain in question.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality.
Advantages
• Reduction in development cycle time
• Reduction in project cost
 Formal Methods Model
• The formal methods model is concerned with the application of a mathematical
technique to design and implement the 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
• Formal methods comprise formal specification using mathematics to specify
the desired properties of the system.
• Formal specification is expressed in a language whose syntax and semantics are
formally defined.
• This language comprises:
• a syntax that defines specific notation used for specification representation
• semantic, which uses objects to describe the system
• a set of relations, which uses rules to indicate the objects for satisfying the specification.
Advantages
• Discovers ambiguity, incompleteness, and inconsistency in the software.
• Offers defect-free software.
• Incrementally grows in effective solution after each iteration.
• This model does not involve high complexity rate.
• Formal specification language semantics verify self-consistency.

Disadvantages
• Time consuming and expensive.
• Difficult to use this model as a communication mechanism for non
technical personnel.
• Extensive training is required since only few developers have the
essential knowledge to implement this model.
 Aspect-oriented software
development
• It is a relatively new software engineering paradigm that provides a process and
methodological approach for defining, specifying, designing, and con structing aspects

• As modern computer-based systems become more sophisticated (and complex),

certain concerns—customer required properties or areas of technical interest—span
the entire architecture

• Some concerns are high-level properties of a system (e.g., security, fault tolerance).
Other concerns affect functions (e.g., the application of business rules), while others
are systemic (e.g., task synchronization or memory management)

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