UNIT- I

Software and Software Engineering

Software engineering stands for the term is made of two words, Software and
Engineering.

Software is more than just a program code. A program is an executable code, which serves some
computational purpose. Software is considered to be collection of executable programming code,
associated libraries and documentations. Software, when made for a specific requirement is
called software product.
Engineering on the other hand, is all about developing products, using well-defined,
scientific principles and methods.
Software engineering is an engineering branch associated with development of software
product using well-defined scientific principles, methods and procedures. The outcome of
software engineering is an efficient and reliable software product.

The Changing Nature of Software

Software takes Dual role of Software. It is a Product and at the same time a Vehicle for
delivering a product.
Software delivers the most important product of our time is called information
Defining Software
Software is defined as
1. Instructions

2. Data structures

3. Documents
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.
2) Software doesn’t “Wear Out”

1
Software Engineering (R18)
3) Although the industry is moving toward component-based construction, most
software continues to be custom built

Software Application Domains

Seven Broad Categories of software are challenges for software engineers
System software
Application software
Engineering/scientific software
Embedded software
Product-line software
Web applications
.Artificial intelligence software

2
Software Engineering (R18)
New Software Challenges
 Open-world computing
 Net-sourcing

 Open Source
Legacy Software
• Legacy software is older programs that are developed decades ago.
• The quality of legacy software is poor because it has in extensible design, convoluted
code, poor and nonexistent documentation, test cases and results that are not
achieved.
As time passes legacy systems evolve due to following reasons:
• The software must be adapted to meet the needs of new computing environment
or technology.
• The software must be enhanced to implement new business requirements.
• The software must be extended to make it interoperable with more modern systems
or database
• The software must be re-architecture to make it viable within a network environment.

Unique Nature of Web Apps

In the early days of the World Wide Web, websites consisted of little more than a set of
linked hypertext files that presented information using text and limited graphics. As time passed,
the augmentation of HTML by development tools (e.g., XML, Java) enabled Web engineers to
provide computing capability along with informational content. Web-based systems and
applications (Web Apps) were born. Today, Web Apps 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 Apps are one of a number of distinct software categories. 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.”
The following attributes are encountered in the vast majority of Web Apps.
 Network intensiveness
 Concurrency
 Unpredictable load
 Performance
 Availability
 Data driven
 Content sensitive
 Continuous evolution
 Immediacy
 Security
 Aesthetics

Software Engineering - A Layered Technology

In order to build software that is ready to meet the challenges
 Problem should be understood before software solution is developed
 Design is a pivotal Software Engineering activity
 Software should exhibit high quality
 Software should be maintainable
These simple realities lead to one conclusion. Software in all of its forms and across all of
its application domains should be engineered.
Software Engineering :

IEEE has developed a more comprehensive definition as :

1) Software engineering is the application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance of
software.
2) The study approaches as in (1)
 Software Engineering is a layered technology. Software Engineering encompasses a
Process, Methods for managing and engineering software and tools.

The following Figure represents Software engineering Layers

Software engineering is a layered technology. Referring to above Figure, any

engineering approach must rest on an organizational commitment to quality.
The bedrock that supports software engineering is a quality focus.
The foundation for software engineering is the process layer. The software engineering
process is the glue that holds the technology layers together and enables rational and timely
development of computer software. Process defines a framework that must be established for
effective delivery of software engineering technology.
Software engineering methods provide the technical how-to’s for building software.
Methods encompass a broad array of tasks that include communication, requirements analysis,
design modeling, program construction, testing, and support.
Software engineering tools provide automated or semi automated support for the
process and the methods. When tools are integrated so that information created by one tool can
be used by another, a system for the support of software development, called computer-aided
software engineering, is established.

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)
and is applied regardless of the application domain, size of the project, complexity of the effort,
or degree of rigor with which software engineering is to be applied.
An action encompasses a set of tasks that produce a major work product (e.g., an
architectural design model).

A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that
produces a tangible outcome.
A process framework establishes the foundation for a complete software engineering
process by identifying a small number of framework activities that are applicable to all software
projects, regardless of their size or complexity. In addition, the process framework encompasses
a set of umbrella activities that are applicable across the entire software process.
A generic process framework for software engineering encompasses five activities:
 Communication
 Planning
 Modeling
 Construction
 Deployment
These five generic framework activities can be used during the development of small, simple
programs, the creation of large Web applications, and for the engineering of large, complex
computer-based systems.
Software engineering process framework activities are complemented by a number of
Umbrella Activities. In general, umbrella activities are applied throughout a software project
and help a software team manage and control progress, quality, change, and risk. Typical
umbrella activities include:

 Software project tracking and control

 Risk management
 Software quality assurance
 Technical reviews
 Measurement
 Software configuration management
 Re usability management
 Work product preparation and production
Attributes for Comparing Process Models
 Overall flow and level of inter dependencies among tasks
 Degree to which work tasks are defined within each framework activity
 Degree to which work products are identified and required
 Manner in which quality assurance activities are applied
 Manner in which project tracking and control activities are applied
 Overall degree of detail and rigor of process description
 Degree to which stakeholders are involved in the project
 Level of autonomy given to project team
 Degree to which team organization and roles are prescribed

The Software Engineering Practice

The Essence of Practice
 Understand the problem (communication and analysis)
 Plan a solution (software design)
 Carry out the plan (code generation)
 Examine the result for accuracy (testing and quality assurance)
 Understand the Problem
 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?
Plan the Solution
 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?
Carry Out the Plan
 Does solution conform to the plan?
 Is each solution component provably correct?
Examine the Result
 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.1 Software General Principles
The dictionary defines the word principle as “an important underlying law or assumption
required in a system of thought.”
David Hooker has Proposed seven principles that focus on software Engineering practice.

The First Principle: The Reason It All Exists

The Second Principle: KISS (Keep It Simple, Stupid!)

The Third Principle: Maintain the Vision
The Fourth Principle: What You Produce, Others Will Consume
The Fifth Principle: Be Open to the Future
The Sixth Principle: Plan Ahead for Reuse
The Seventh principle: Think!

Software Myths
Software Myths- beliefs about software and the process used to build it - can be traced to
the earliest days of computing.

Management Myths :
Managers with software responsibility, like managers in most disciplines, are often
under pressure to maintain budgets, keep schedules from slipping, and improve quality. Like a
drowning person who grasps at a straw, a software manager often grasps at belief in a software
myth.
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 these entire question is NO.
Myth : If we get behind schedule, we can add more programmers and catch up
Reality : Software development is not a mechanistic process like manufacturing. “Adding
people to a late software project makes it later.” At first, this statement may seem counter
intuitive. However, as new people are added, people who were working must spend time
educating the newcomers, thereby reducing the amount of time spent on productive
development effort
Myth : If we decide to outsource the software project to a third party, I can just relax and
let that firm build it.
Reality : If an organization does not understand how to manage and control software project
internally, it will invariably struggle when it out sources software project.
Customer Myths
A customer who requests computer software may be a person at the next desk, a technical
group down the hall, the marketing /sales department, or an outside company that has requested
software under contract.
Myth : A general statement of objectives is sufficient to begin writing programs - we can fill in
details later.
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 are
developed only through effective and continuous communication between customer and
developer.
Myth : Project requirements continually change, but change can be easily
accommodated because software is flexible.
Reality : It’s true that software requirement change, but the impact of change varies with the
time at which it is introduced. When requirement changes are requested early, cost impact is
relatively small. However, as time passes, cost impact grows rapidly – resources have been
committed, a design framework has been established, and change can cause upheaval that
requires additional resources and major design modification.

Practitioner's myths.
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.
Myth: Until I get the program "running" I have no way of assessing its quality.
Reality: One of the most effective software quality assurance mechanisms can be applied from
the inception of a project—the formal technical review. Software reviews are a "quality filter"
that have been found to be more effective than testing for finding certain classes of software
defects.
Myth: The only deliverable work product for a successful project is the working program.
Reality: A working program is only one part of a software configuration that includes many
elements. Documentation provides a foundation for successful engineering and, more important,
guidance for software support.
Myth: Software engineering will make us create voluminous and unnecessary
documentation and will invariably slow us down.
Reality: Software engineering is not about creating documents. It is about creating quality. Better
quality leads to reduced rework. And reduced rework results in faster delivery times. Many
software professionals recognize the fallacy of the myths just described. Regrettably, habitual
attitudes and methods foster poor management and technical practices, even when reality dictates
a better approach. Recognition of software realities is the first step toward formulation of
practical solutions for software engineering.

PROCESS MODELS

A GENERIC PROCESS MODEL

The software process is represented schematically in following 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.

A generic process framework defines five framework activities—communication, planning,

modeling, construction, and deployment.

In addition, a set of umbrella activities project tracking and control, risk management, quality
assurance, configuration management, technical reviews, and others are applied throughout the
process.
This aspect is called process flow. It describes how the framework activities and the actions and
tasks that occur within each framework activity are organized with respect to sequence and time
and is illustrated in following figure
A generic process framework for software engineering A linear process flow executes each of
the five framework 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. A parallel process flow
executes one or more activities in parallel with other activities
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. Therefore, you are faced with a key
question: 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?
Identifying a Task Set
Different projects demand different task sets. The software team chooses the task set
based on problem and project characteristics. A task set defines the actual work to be done to
accomplish the objectives of a software engineering action.
Process Patterns
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. Stated in more general
terms, a process pattern provides you with a template —a consistent method for describing
problem solutions within the context of the software process.
Patterns can be defined at any level of abstraction. a pattern might be used to describe a
problem (and solution) associated with a complete process model (e.g., prototyping). In other
situations, patterns can be used to describe a problem (and solution) associated with a
framework activity (e.g., planning) or an action within a framework activity (e.g., project
estimating).
Ambler has proposed a template for describing a process pattern:
Pattern Name. The pattern is given a meaningful name describing it within the context of the
software process (e.g., Technical Reviews).
Forces. The environment in which the pattern is encountered and the issues that make the
problem visible and may affect its solution.
Type. The pattern type is specified. Ambler suggests three types:
1. Stage pattern—defines a problem associated with a framework activity for the process.
Since a framework activity encompasses multiple actions and work tasks, 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 Model or Prototyping.
Initial context. Describes the conditions under which the pattern applies. Prior to the
initiation of the pattern:
(1) What organizational or team-related activities have already occurred?
(2) What is the entry state for the process?
(3) What software engineering information or project information already exists?
Problem. The specific problem to be solved by the pattern.
Solution. Describes how to implement the pattern successfully. It also describes how software
engineering information or project information that is available before the initiation of the
pattern is transformed as a consequence of the successful execution of the pattern.
Resulting Context. Describes the conditions that will result once the pattern has been
successfully implemented. Upon completion of the pattern:
(1) What organizational or team-related activities must have occurred?
(2) What is the exit state for the process?
(3) What software engineering information or project information has been developed?
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.
Known Uses and Examples. Indicate the specific instances in which the pattern is applicable.
 Process patterns provide an effective mechanism for addressing problems associated with
any software process. The patterns enable you to develop a hierarchical process
description that begins at a high level of abstraction (a phase pattern).

PROCESS ASSESSMENT AND IMPROVEMENT

Assessment attempts to understand the current state of the software process with
the intent of improving it.
A number of different approaches to software process assessment and improvement have been
proposed over the past few decades.
Standard CMMI Assessment Method for Process Improvement (SCAMPI)—provides a five
step process assessment model that incorporates five phases: initiating, diagnosing,
establishing, acting, and learning. The SCAMPI method uses the SEI CMMI as the basis for
assessment.
CMM-Based Appraisal for Internal Process Improvement (CBA IPI)— provides a diagnostic
technique for assessing the relative maturity of a software organization; uses the SEI CMM as
the basis for the assessment.
SPICE (ISO/IEC15504)—a standard that defines a set of requirements for software process
assessment. The intent of the standard is to assist organizations in developing an objective
evaluation of the efficacy of any defined software process.
ISO 9001:2000 for Software—a generic standard that applies to any organization that wants to
improve the overall quality of the products, systems, or services that it provides. Therefore, the
standard is directly applicable to software organizations and companies.

Software Process

identifies
is examined by identifies capabilities
modifications to
and risk of

Software Process
Assessment

Capability
Software Process leads to leads to
Determination
Improvement
motivates
THE CAPABILITY MATURITY MODEL INTEGRATION (CMMI):
The CMMI represents a process meta-model in two different ways:
 As a continuous model
 As a staged model.
Each process area is formally assessed against specific goals and practices and is rated according to the
following capability levels.
Level 0: Incomplete. The process area is either not performed or does not achieve all goals and objectives
defined by CMMI for level 1 capability.
Level 1: Performed. All of the specific goals of the process area have been satisfied. Work tasks required
to produce defined work products are being conducted.
Level 2: Managed. All level 1 criteria have been satisfied. In addition, all work associated with the process
area conforms to an organizationally defined policy; all people doing the work have access to adequate
resources to get the job done; stakeholders are actively involved in the process area as required; all work
tasks and work products are “monitored, controlled, and reviewed;
Level 3: Defined. All level 2 criteria have been achieved. In addition, the process is “tailored from the
organizations set of standard processes according to the organizations tailoring guidelines, and contributes
and work products, measures and other process-improvement information to the organizational process
assets”.
Level 4: Quantitatively managed. All level 3 criteria have been achieved. In addition, the process area is
controlled and improved using measurement and quantitative assessment.”Quantitative objectives for
quality and process performance are established and used as criteria in managing the process”
Level 5: Optimized. All level 4 criteria have been achieved. In addition, the process area is adapted and
optimized using quantitative means to meet changing customer needs and to continually improve the
efficacy of the process area under consideration”

PRESCRIPTIVE PROCESS MODELS

Prescriptive process models were originally proposed to bring order to the chaos of
software development. Prescriptive process models define a prescribed set of process elements
and a predictable process work flow. “prescriptive” because they prescribe a set of process
elements—framework activities, software engineering actions, tasks, work products, quality
assurance, and change control mechanisms for each project.
The Waterfall Model
The waterfall model, sometimes called the classic life cycle, suggests a systematic,
sequential approach to software development that begins with customer specification of
requirements and progresses through planning, modeling, construction, and deployment.

A variation in the representation of the waterfall model is called the V-model. Represented in
following figure. The V-model depicts the relationship of quality assurance actions to the
actions associated with communication, modeling, and early construction activities.
 As a software team moves down the left side of the V, basic problem requirements are
refined into progressively more detailed and technical representations of the problem and its
solution. Once code has been generated, the team moves up the right side of the V, essentially
performing a series of tests that validate each of the models created as the team moved down the
left side. The V-model provides a way of visualizing how verification and validation actions are
applied to earlier engineering work.
The waterfall model is the oldest paradigm for software engineering. The problems that
are sometimes encountered when the waterfall model is applied are:
1. Real projects rarely follow the sequential flow that the model proposes. Although
the linear model can accommodate iteration, it does so indirectly. As a result,
changes can cause confusion as the project team proceeds.
2. It is often difficult for the customer to state all requirements explicitly. The
waterfall model requires this and has difficulty accommodating the natural
uncertainty that exists at the beginning of many projects.
3. The customer must have patience. A working version of the program(s) will not
be available until late in the project time span.
This model is suitable when ever limited number of new development efforts and when
requirements are well defined and reasonably stable.
Incremental Process Models
The incremental model delivers a series of releases, called increments, that provide
progressively more functionality for the customer as each increment is delivered.
The incremental model combines elements of linear and parallel process flows discussed
in Section 1.7. The incremental model applies linear sequences in a staggered fashion as calendar
time progresses. Each linear sequence produces deliverable “increments” of the software in a
manner that is similar to the increments produced by an evolutionary process flow.
For example, word-processing software developed using the incremental paradigm might
deliver basic file management, editing, and document production functions in the first increment;
more sophisticated editing and document production capabilities in the second increment;
spelling and grammar checking in the third increment; and advanced page layout capability in
the fourth increment.
When an incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed but many supplementary features remain undelivered. The core
product is used by the customer. As a result of use and/or evaluation, a plan is developed for the
next increment. The plan addresses the modification of the core product to better meet the needs
of the customer and the delivery of additional features and functionality. This process is repeated
following the delivery of each increment, until the complete product is produced.
Incremental development is particularly useful when staffing is unavailable for a
complete implementation by the business deadline that has been established for the project. Early
increments can be implemented with fewer people. If the core product is well received, then
additional staff (if required) can be added to implement the next increment. In addition,
increments can be planned to manage technical risks.

Fig : Incremental Model

 Evolutionary Process Models
Evolutionary models are iterative. They are characterized in a manner that enables you to
develop increasingly more complete versions of the software with each iteration. There are two
common evolutionary process models.
Prototyping 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.
Although prototyping can be used as a stand-alone process model, it is more
commonly used as a technique that can be implemented within the context of any one of the
process models. The prototyping paradigm begins with communication. You meet with other
stakeholders to define the overall objectives for the software, identify whatever requirements are
known, and outline areas where further definition is mandatory. A prototyping iteration is
planned quickly, and modeling (in the form of a “quick design”) occurs. A quick design
focuses on a representation of those aspects of the software that will be visible to end users.

Fig : prototyping paradigm

The quick design leads to the construction of a prototype. The prototype is deployed
and evaluated by stakeholders, who provide feedback that is used to further refine requirements.
Iteration occurs as the prototype is tuned to satisfy the needs of various stakeholders, while at the
same time enabling you to better understand what needs to be done.
The prototype serves as a mechanism for identifying software requirements. If a working
prototype is to be built, you can make use of existing program fragments or apply tools that
enable working programs to be generated quickly. The prototype can serve as “the first system.”
Prototyping can be problematic for the following reasons:
1. Stakeholders see what appears to be a working version of the software, unaware that
the prototype is held together haphazardly, unaware that in the rush to get it
working you haven’t considered overall software quality or long-term
maintainability.
2. As a software engineer, you often make implementation compromises in order to get
a prototype working quickly. An inappropriate operating system or programming
language may be used simply because it is available and known; an inefficient
algorithm may be implemented simply to demonstrate capability.
Although problems can occur, prototyping can be an effective paradigm for software
engineering.
The Spiral Model : Originally proposed by Barry Boehm, the spiral model is an
evolutionary software process model that couples the iterative nature of prototyping with the
controlled and systematic aspects of the waterfall model. It provides the potential for rapid
development of increasingly more complete versions of the software. Boehm describes the
model in the following manner
The spiral development model is a risk-driven process model generator that is used to
guide multi-stakeholder concurrent engineering of software intensive systems. It has two
main distinguishing features. One is a cyclic approach for incrementally growing a system’s
degree of definition and implementation while decreasing its degree of risk. The other is a set of
anchor point milestones for ensuring stakeholder commitment to feasible and mutually
satisfactory system solutions.
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.
 Fig : The Spiral Model
A spiral model is divided into a set of framework activities defined by the software
engineering team. As this evolutionary process begins, the software team performs activities that
are implied by a circuit around the spiral in a clockwise direction, beginning at the center. Risk
is considered as each revolution is made. Anchor point milestones are a combination of work
products and conditions that are attained along the path of the spiral are noted for each
evolutionary pass.
The first circuit around the spiral might result in the development of a product
specification; subsequent passes around the spiral might be used to develop a prototype and then
progressively more sophisticated versions of the software. Each pass through the planning region
results in adjustments to the project plan.
The spiral model can be adapted to apply throughout the life of the computer software.
Therefore, the first circuit around the spiral might represent a “concept development project”
that starts at the core of the spiral and continues for multiple iterations until concept development
is complete. The new product will evolve through a number of iterations around the spiral. Later,
a circuit around the spiral might be used to represent a “product enhancement project.”
 The spiral model is a realistic approach to the development of large-scale systems and
software. Because software evolves as the process progresses, the developer and customer better
understand and react to risks at each evolutionary level. It maintains the systematic stepwise
approach suggested by the classic life cycle but incorporates it into an iterative framework that
more realistically reflects the real world.
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. The
concurrent model is often more appropriate for product engineering projects where different
engineering teams are involved.
These models provides a schematic representation of one software engineering activity
within the modeling activity using a concurrent modeling approach. 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.

Fig : Concurrent development model

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

SPECIALIZED PROCESS MODELS

Component-Based Development
The component-based development model incorporates many of the characteristics of the
spiral model. It is evolutionary in nature, demanding an iterative approach to the creation of
software. However, the component-based development model constructs applications from
prepackaged software components.
Modeling and construction activities begin with the identification of candidate
components. These components can be designed as either conventional software modules or
object-oriented classes or packages of classes. Regardless of the technology that is used to create
the components, the component-based development model incorporates the following steps
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.
The component-based development model leads to software reuse, and reusability provides
software engineers with a number of measurable benefits.
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.
 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, but through the application of mathematical analysis.
When formal methods are used during design, they serve as a basis for program
verification and therefore enable you to discover and correct errors that might otherwise go
undetected. Although not a mainstream approach, the formal methods model offers the promise
of defect-free software.
Draw Backs:
• 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.
Aspect-Oriented Software Development
AOSD defines “aspects” that express customer concerns that cut across multiple system
functions, features, and information. 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.”
Grundy provides further discussion of aspects in the context of what he calls aspect-
oriented component engineering (AOCE):
AOCE uses a concept of horizontal slices through vertically-decomposed software
components, called “aspects,” to characterize cross-cutting functional and non-functional
properties of components.
 THE UNIFIED PROCESS
Unified process (UP) is an architecture-centric, use-case driven, iterative and incremental
development process. UP is also referred to as the unified software development 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.
Phases of the Unified Process

This process divides the development process into five phases:

 Inception
 Elaboration
 Conception
 Transition
 Production

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 to include
five different views of the software—the use case model, the requirements model, the design
model, the implementation model, and the deployment model. Elaboration creates an
“executable architectural baseline” that represents a “first cut” executable system.
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. All necessary and required
features and functions for the software increment (i.e., the release) are then implemented in
source code.

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. At the conclusion of the transition phase, the software increment becomes a usable
software release.
The production phase of the UP coincides with the deployment activity of the generic
process. During this phase, the ongoing use of the software is monitored, support for the
operating environment (infrastructure) is provided, and defect reports and requests for changes
are submitted and evaluated. It is likely that at the same time the construction, transition, and
production phases are being conducted, work may have already begun on the next software
increment. This means that the five UP phases do not occur in a sequence, but rather with
staggered concurrency.

PERSONAL AND TEAM PROCESS MODELS

The best software process is one that is close to the people who will be doing the work.
Watts Humphrey proposed two process models. Models - “Personal Software Process (PSP)”
and “Team Software Process (TSP).” Both require hard work, training, and coordination, but
both are achievable.
Personal Software Process (PSP)
 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 and empowers the practitioner to control
the quality of all software work products that are developed. The PSP model defines five
framework activities:
 Planning
 High-level design
 High-level design review
 Development
 Postmortem
PSP stresses the need to identify errors early and, just as important, to understand the types
of errors that you are likely to make. PSP represents a disciplined, metrics-based approach to
software engineering that may lead to culture shock for many practitioners.
Team Software Process (TSP)
Watts Humphrey extended the lessons learned from the introduction of PSP and proposed
a Team Software Process (TSP). The goal of TSP is to build a “self directed” project team that
organizes itself to produce high-quality software.
Humphrey defines the following objectives for TSP:
 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 (IPTs)
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 CMM23 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); identifies a team process that is appropriate for the project and a
strategy for implementing the process; 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. 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 and system
testing, postmortem) and other more detailed work functions (e.g., development planning,
requirements development, software configuration management, unit test) that are part of the
team process.

PRODUCT AND PROCESS

The Product is what we're actually building. What's our solution to the problem at hand? Half
of engineering is making sure you're building the right product and have the ability to actually
build it. For software engineers, that means coming up with a software solution and being able to
code it up properly.
The hidden side of engineering is the Process, which means how we're actually building
our product. Products don't just result from a single all-night coding session -- we need to make
sure we're following a process that lets us create that Product in the most efficient and effective
way possible.