Introduction to software Engineering :

Software Engineering is a framework for building software and is an engineering approach to

software development.

Software programs can be developed without S/E principles and methodologies but they are
indispensable if we want to achieve good quality software in a cost effective manner.

Software is defined as:

Instructions + Data Structures + Documents

Engineering is the branch of science and technology concerned with the design, building, and
use of engines, machines, and structures.

SOFTWARE ENGINEERING is defined as a systematic, disciplined and quantifiable

approach for the development, operation and maintenance of software.
Software is:
(1) instructions (computer programs) that when executed provide desired features, function, and
performance;
(2) data structures that enable the programs to adequately manipulate information, and
(3) descriptive information in both hard copy and virtual forms that describes the operation and
use of the programs.

Characteristics of software

Software is a logical rather than a physical system element.

Therefore, software has characteristics that are considerably different than those of hardware:
• Software is developed or engineered; it is not manufactured in the classical
sense.
Although some similarities exist between software development and hardware manufacturing,
the two activities are fundamentally different.
In both activities, high quality is achieved through good design, but the manufacturing phase
for hardware can introduce quality problems that are nonexistent for software.

Both activities are dependent on people, but the relationship between people applied and
work accomplished is entirely different)
. Both activities require the construction of a “product,” but the approaches are different.
Software costs are concentrated in engineering.
 2.Software does not wear out

Hardware components suffer from the growing effects of many other

environmental factors. Stated simply, the hardware begins to wear out.

Software is not susceptible to the environmental maladies that cause hardware

to wear out.
When a hardware component wears out, it is replaced by a spare part.
There are no software spare parts.
Every software failure indicates an error in design or in the process through which
design was translated into machine-executable code. However, the implication is
clear—the software doesn’t wear out. But it does deteriorate.

3.Although the industry is moving toward component-based

construction, most software continues to be custom built
A software part should be planned and carried out with the goal that it tends to
be reused in various projects.`
• Current reusable segments encapsulate the two information
and the preparation that is applied to the information,
empowering the programmer to make new applications from
reusable parts.
• In the hardware world, component reuse is a natural part of
the engineering process.
The Changing Nature of software

1.System Software:
System software is a collection of programs which are written to service other
programs.
Some system software processes complex but determinate, information
structures.
Other system application process largely indeterminate data.
Sometimes when, the system software area is characterized by the heavy
interaction with computer hardware that requires scheduling, resource sharing,
and sophisticated process management.
e.g., compilers, editors, and file management utilities

2.Application_Software:……,stand-alone_programs
Application software is defined as programs that solve a specific business need.
. In addition to convention data processing application, application software is
used to control business function in real time.
e.g., point-of-sale
transaction processing, real-time manufacturing process control

3.Engineering and Scientific Software:

has been characterized by “number crunching” algorithms.
This software is used to facilitate the engineering function and task.
however modern application within the engineering and scientific area are
moving away from the conventional numerical algorithms.
Computer-aided design, system simulation, and other interactive
applications have begun to take a real-time and even system software
characteristic.

4. Embedded Software:
Embedded software resides within the system or product and is used to
implement and control feature and function for the end-user and for the
system itself.
Embedded software can perform the limited and esoteric function or
provided significant function and control capability.
e.g., key pad control for a microwave oven) or provide significant function
and control capability (e.g., digital functions in an automobile such as fuel
control, dashboard displays, and braking systems).
5. Product-line software—designed to provide a specific capability for user by
many different customers.
Product-line software can focus on a limited and esoteric marketplace (e.g., inventory
control products) or address mass consumer markets (e.g., word processing,
spreadsheets, computer graphics, multimedia, entertainment, database management,
and personal and business financial applications).

6.Web Application:
It is a client-server computer program which the client runs on the web browser.
In their simplest form, Web apps can be little more than a set of linked hypertext
files that present information using text and limited graphics. However, as e-
commerce and B2B application grow in importance. Web apps are evolving into
a sophisticate computing environment that not only provides a standalone
feature, computing function, and content to the end user.

7.Artificial Intelligence Software:

Artificial intelligence software makes use of a nonnumerical algorithm to solve a
complex problem that is not amenable to computation or straightforward
analysis
. Application within this area includes robotics, expert system, pattern
recognition, artificial neural network, theorem proving and game playing.

Millions of software engineers worldwide are hard at work on software projects in

one or more of these categories.
In some cases, new systems are being built, but in many others, existing applications are being
corrected, adapted, and enhanced.
, the legacy to be left behind by this generation will ease the burden of future software
engineers.

Open-world computing—the rapid growth of wireless networking may

soon lead to true pervasive, distributed computing.
The challenge for software engineers will be to develop systems and application software that
will allow mobile devices, personal computers, and enterprise systems to communicate
across vast networks.
Netsourcing—the World Wide Web is rapidly becoming a computing engine as well as a
content provider.
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.

Open source—a growing trend that results in distribution of source code for
systems applications (e.g., operating systems, database, and development environments)
so that many people can contribute to its development.
The challenge for software engineers is to build source code that is self-descriptive,
but more importantly, to develop techniques that will enable both customers
and developers to know what changes have been made and how those
changes manifest themselves within the software.

LEGACY SOFTWARE
Legacy software are older programs that are developed decades ago.
The quality of legacy software is poor because it has inextensible 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 rearchitected to make it viable within a network environment.

MYTHS
Myths are widely held but false beliefs and views which propagate misinformation and confusion.
Three types of myth are associated with software:
- Management myth
- Customer myth
- Practitioner’s myth
MANAGEMENT MYTHS
• Myth (1)-The available standards and procedures for software are enough.
• Myth (2)-Each organization feel that they have state-of-art software development tools since
they have latest computer.
• Myth(3)-Adding more programmers when the work is behind schedule can catch up.
• Myth(4)-Outsourcing the software project to third party, we can relax and let that party build it.
CUSTOMER MYTHS
• Myth(1)- General statement of objective is enough to begin writing programs, the details can be
filled in later.
• Myth (2)-Software is easy to change because software is flexible
PRACTITIONER’S MYTH
• Myth (1)-Once the program is written, the job has been done.
• Myth (2)-Until the program is running, there is no way of assessing the quality.
• Myth (3)-The only deliverable work product is the working program
• Myth (4)-Software Engineering creates voluminous and unnecessary documentation and
invariably slows down software development
Software engineering is a layered technology
Any engineering approach (including software engineering) must rest on an
organizational commitment to quality.
• quality focus - bedrock that supports software engineering.
• process - 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.
• methods - provide 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.
• tools - provide semi-automatic and automatic support to 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.
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 (e.g., architectural design) 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 process by

identifying a small number of framework activities that are applicable to all software
projects, regardless of size or complexity.

• It also includes a set of umbrella activities that are applicable across the entire
software process.
• Each framework activity is populated by a set of software engineering actions – a
collection of related tasks that produces a major software engineering work product
(e.g. design is a software engineering action).
• The following generic process framework is applicable to the vast majority of software
projects :
1. Communication: This framework activity involves heavy communication and
collaboration with the customer (and other stakeholders) and encompasses
requirements gathering and other related activities.
2. Planning: This activity establishes a plan for the software engineering work that
follows. It describes the technical tasks to be conducted, the risks that are likely, the
resources that will be required, the work products to be produced and a work
schedule.
3. Modeling: This activity encompasses the creation of models that allow the
developer and the customer to better understand software requirements and the
design that will achieve those requirements.
4. Construction: This activity combines code generation (either manual or
automated) and the testing that is required to uncover errors in the code.
5. Deployment: The software is delivered to the customer who evaluates the
delivered product and provides feedback based on evaluation.

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—allows the software team to
assess progress against the project plan and take any necessary action to
maintain the schedule.
Risk management—assesses risks that may affect the outcome of the
project or the quality of the product.
Software quality assurance—defines and conducts the activities required
to ensure software quality.
Technical reviews—assesses software engineering work products in an effort
to uncover and remove errors before they are propagated to the next activity.
Measurement—defines and collects process, project, and product measures
that assist the team in delivering software that meets stakeholders’ needs;
can be used in conjunction with all other framework and umbrella activities.
Software configuration management—manages the effects of change
throughout the software process.
Reusability management—defines criteria for work product reuse
(including software components) and establishes mechanisms to achieve
reusable components.
Work product preparation and production—encompasses the activities
required to create work products such as models, documents, logs, forms,
and lists.
CAPABILITY MATURITY MODEL INTEGRATION(CMMI)
• Developed by SEI(Software Engineering institute)
• Assess the process model followed by an organization and rate the organization with
different levels
• A set of software engineering capabilities should be present as organizations reach different
levels of process capability and maturity.
CMMI process meta model can be represented in different ways
1.A continuous model
2.A staged model
Continuous model:
-Lets organization select specific improvement that best meet its business objectives and
minimize risk-Levels are called capability levels.
-Describes a process in 2 dimensions
-Each process area is assessed against specific goals and practices and is rated according to
the following capability levels.
CMMI
• Six levels of CMMI
– Level 0:Incomplete
– Level 1:Performed
– Level 2:Managed
– Level 3:Defined
– Level 4:Quantitatively managed
– Level 5:Optimized
CMMI
• Incomplete -Process is adhoc . Objective and goal of process areas are not known
• Performed -Goal objective, work tasks, work products and other activities of software
process are carried out
• Managed -Activities are monitored, reviewed, evaluated and controlled
• Defined -Activities are standardized, integrated and documented
• Quantitatively Managed -Metrics and indicators are available to measure the process and
quality
• Optimized - Continuous process improvement based on quantitative feed back from
the user
-Use of innovative ideas and techniques, statistical quality control and other
methods for process improvement.
CMMI - Staged model
- This model is used if you have no clue of how to improve the process for quality software.
- It gives a suggestion of what things other organizations have found helpful to work first
- Levels are called maturity levels

Process Patterns
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.
Patterns can be defined at any level of abstraction.2
In some cases, 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 [Amb98] 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., TechnicalReviews)
.
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 [Amb98] suggests three types:
1.Stage pattern –
Problems associated with a framework activity for process are described by
stage pattern. Establishing Communication might be an example of a staged
pattern. This pattern would incorporate task pattern Requirements Gathering
and others.
2.Task-pattern –
Problems associated with a software engineering action or work task and
relevant to successful software engineering practice (e.g., Requirements
Gathering is a task pattern) are defined by task-pattern.
3.Phase pattern –
Even when the overall flow of activities is iterative in nature, it defines sequence
of framework activities that occurs within process. Spiral Model or Prototyping
might be an example of a phase pattern.
Initial Context :
Conditions under which the pattern applies are described by initial context. Prior
to the initiation of the pattern :
1. What organizational or term-related activities have already occurred?
2. Entry state for the process?
3. Software engineering information or project information already exists?
For example, the Planning pattern requires that :
• Collaborative communication has been established between
customers and software engineers.
• Successful completion of a number of task patterns for the
communication pattern has occurred.
• The project constraints, basic requirements, and the project scope are
known.
Problem :
Any specific problem is to be solved by pattern.
Solution –
Describes how to implement pattern successfully. This section describes how
initial state of process is modified as a consequence of initiation of pattern.
Resulting Context :
Once the pattern has been successfully implemented, it describes conditions.
Upon completion of pattern :
1. Organizational or term-related activities must have occurred?
2. What should be the exit state for the process?
3. What software engineering information has been developed?
Related pattern :
Provide a list of all process patterns that are directly related to this one. It can
be represented n a hierarchy or in some other diagrammatic form.
Known uses and Examples –
In which the pattern is applicable, it indicates the specific instances. For
example, communication is mandatory at the beginning of every software
project, is recommended throughout the software project, and is mandatory
once the deployment activity is underway.

process assessment
Does not specify the quality of the software or whether the software will be
delivered on time or will it stand up to the user requirements.
It attempts to keep a check on the current state of the software process with the intention of
improving it.

PROCESS ASSESSMENT
Software Process
Software Process Assessment
Software Process improvement
Motivates Capability determination

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 [SEI00].

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
[Dun01].

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 [ISO08].

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 [Ant06].

PROCESS MODELS
• Help in the software development
• Guide the software team through a set of framework activities
• Process Models may be linear, incremental or evolutionary

What is a software process model?

A software process model is an abstraction of the software development
process.

The models specify the stages and order of a process.

So, think of this as a representation of the order of activities of the process

and the sequence in which they are performed.

A model will define the following:

• The tasks to be performed

• The input and output of each task
• The pre and post conditions for each task
• The flow and sequence of each task

There are many kinds of process models for meeting different requirements.
We refer to these as SDLC models (Software Development Life Cycle
models).

The most popular and important SDLC models are as follows:

• Waterfall model
• V model
• Incremental model
• RAD model

• Agile model
• Iterative model
• Prototype model
• Spiral model

Waterfall model
• The waterfall model, sometimes called the classic life cycle,
• suggests a systematic, sequential approach to software development
• begins with customer specification of requirements and progresses
through planning,
modeling,
construction,
and deployment,
culminating in ongoing support of the completed software
 • A variation in the representation of the waterfall model is called the V-
model.

The V-model provides a way of visualizing how verification and validation

actions are applied to earlier engineering work.

PROBLEMS IN WATERFALLMODEL
• Real projects rarely follow the sequential flow since they are always iterative
• The model requires requirements to be explicitly spelled out in the beginning,
which is often difficult
• A working model is not available until late in the project time plan

THE RAD (Rapid Application Development) MODEL

• An incremental software process model
• Having a short development cycle
• High-speed adoption of the waterfall model using a component based
construction approach
• Creates a fully functional system within a very short span time of 60 to 90
days
The RAD Model consists of the following phases:
Communication
Planning
Construction
Component reuse
automatic code generation
testing
Modeling
Business modeling
Data modeling
Process modeling
Deployment
integration
delivery
feedback

THE RAD MODEL

• Multiple software teams work in parallel on different functions
• Modeling encompasses three major phases: Business modeling, Data modeling
and process modeling
• Construction uses reusable components, automatic code generation and testing
Problems in RAD
• Requires a number of RAD teams
• Requires commitment from both developer and customer for rapid-fire
completion of activities
• Requires modularity
• Not suited when technical risks are high

Iterative Model
In this Model, you can start with some of the software specifications and develop the first
version of the software.

After the first version if there is a need to change the software, then a new version of the
software is created with a new iteration.

Every release of the Iterative Model finishes in an exact and fixed period that is called
iteration.

The Iterative Model allows the accessing earlier phases, in which the variations made
respectively.

The final output of the project renewed at the end of the Software Development Life Cycle
(SDLC) process.
The various phases of Iterative model are as follows:
1.Requirement gathering & analysis:

In this phase, requirements are gathered from customers and check by an analyst whether
requirements will fulfil or not. Analyst checks that need will achieve within budget or not.
After all of this, the software team skips to the next phase.

2. Design: In the design phase, team design the software by the different diagrams like
Data Flow diagram, activity diagram, class diagram, state transition diagram, etc.

oint

3. Implementation: In the implementation, requirements are written in the coding

language and transformed into computer programmes which are called Software.

4. Testing: After completing the coding phase, software testing starts using different test
methods. There are many test methods, but the most common are white box, black box,
and grey box test methods.

5. Deployment: After completing all the phases, software is deployed to its work
environment.
6. Review: In this phase, after the product deployment, review phase is performed to
check the behaviour and validity of the developed product. And if there are any error
found then the process starts again from the requirement gathering.

7. Maintenance: In the maintenance phase, after deployment of the software in the

working environment there may be some bugs, some errors or new updates are required.
Maintenance involves debugging and new addition options.

When to use the Iterative Model?

1. When requirements are defined clearly and easy to understand.
2. When the software application is large.
3. When there is a requirement of changes in future.

Advantage(Pros) of Iterative Model:

1. Testing and debugging during smaller iteration is easy.
2. A Parallel development can plan.
3. It is easily acceptable to ever-changing needs of the project.
4. Risks are identified and resolved during iteration.

Disadvantage(Cons) of Iterative Model:

1. It is not suitable for smaller projects.
2. More Resources may be required.
3. Design can be changed again and again because of imperfect requirements.
4. Requirement changes can cause over budget.
5. Project completion date not confirmed because of changing requirements.

THE INCREMENTAL PROCESS MODEL

• Linear sequential model is not suited for projects which are iterative in nature
• Incremental model suits such projects
• Used when initial requirements are reasonably well-defined and compelling
need to provide limited functionality quickly
• Functionality expanded further in later releases
• Software is developed in increments
The Incremental Model
Communication
Planning
Modeling
Construction
Deployment

THE INCREMENTAL MODEL

• Software releases in increments
• 1st increment constitutes Core product
• Basic requirements are addressed
• Core product undergoes detailed evaluation by the customer
• As a result, plan is developed for the next increment. Plan addresses the
modification of core product to better meet the needs of customer
• Process is repeated until the complete product is produced

Advantages

• The software will be generated quickly during the software life cycle
• It is flexible and less expensive to change requirements and scope
• Throughout the development stages changes can be done
• This model is less costly compared to others

Disadvantages
 • It requires a good planning designing
• Problems might cause due to system architecture as such not all
requirements collected up front for the entire software lifecycle
• Each iteration phase is rigid and does not overlap each other

EVOLUTIONARY PROCESSMODEL
• Software evolves over a period of time
• Business and product requirements often change as development proceeds making a
straight-line path to an end product unrealistic
• Evolutionary models are iterative and as such are applicable to modern day
applications
Types of evolutionary models
– Prototyping
– Spiral model
– Concurrent development model

PROTOTYPING
Prototyping Model is a software development model in which prototype is built,
tested, and reworked until an acceptable prototype is achieved. It also creates
base to produce the final system or software. It works best in scenarios where the
project’s requirements are not known in detail. It is an iterative, trial and error
method which takes place between developer and client.

STEPS IN PROTOTYPING
• Begins with requirement gathering
• Identify whatever requirements are known
• Outline areas where further definition is mandatory
• A quick design occur
• Quick design leads to the construction of prototype
• Prototype is evaluated by the customer
• Requirements are refined
• Prototype is turned to satisfy the needs of customer

Advantages of the Prototyping Model

• Users are actively involved in development. Therefore, errors can be
detected in the initial stage of the software development process.
• Missing functionality can be identified, which helps to reduce the risk of
failure as Prototyping is also considered as a risk reduction activity.

Disadvantages of the Prototyping Model

• Prototyping is a slow and time taking process.
• The cost of developing a prototype is a total waste as the prototype is
ultimately thrown away.
• Prototyping may encourage excessive change requests.

THE SPIRAL MODEL

Spiral Model is a risk-driven software development process model. It is a
combination of waterfall model and iterative model.
here are specific activities that are done in one iteration (spiral) where the output
is a small prototype of the large software. The same activities are then repeated
for all the spirals until the entire software is built.

Each phase of spiral model in software engineering begins with a design goal and
ends with the client reviewing the progress. The spiral model in software
engineering was first mentioned by Barry Boehm in his 1986 paper.

The development process in Spiral model in SDLC, starts with a small set of
requirement and goes through each development phase for those set of
requirements.
The software engineering team adds functionality for the additional requirement in
every-increasing spirals until the application is ready for the production phase. The
below figure very well explain Spiral Model:

When project is large

When releases are required to be frequent

When risk and cost evolution is imp

When req are unclear nd complex

When changes may require at any time

Advantages of using Spiral Model:

• Development is fast
• Risk evaluation is proper.
• Software is produced early.
• Has room for customer feedback and the changes are implemented
faster.
Disadvantages of using Spiral model:
Disadvantages of Spiral model are as follows:

• Risk analysis is important phase so requires expert people.

• Is not beneficial for smaller projects.
• Spiral may go infinitely.

The name 'prescriptive' is given because the model prescribes a set of

activities, actions, tasks, quality assurance and change the mechanism for
every project.

There are three types of prescriptive process models. They are:

1. The Waterfall Model

2. Incremental Process model
3. RAD model
SDLC Phases
Given below are the various phases:
• Requirement gathering and analysis
• Design
• Implementation or coding
• Testing
• Deployment
• Maintenance
1) Requirement Gathering and Analysis
During this phase, all the relevant information is collected from the customer to
develop a product as per their expectation. Any ambiguities must be resolved in
this phase only.

2) Design
In this phase, the requirement gathered in the SRS document is used as an input
and software architecture that is used for implementing system development is
derived.

#3) Implementation or Coding

Implementation/Coding starts once the developer gets the Design document. The
Software design is translated into source code. All the components of the
software are implemented in this phase.
#4) Testing
Testing starts once the coding is complete and the modules are released for
testing. In this phase, the developed software is tested thoroughly and any
defects found are assigned to developers to get them fixed.

Retesting, regression testing is done until the point at which the software is as
per the customer’s expectation. Testers refer SRS document to make sure that
the software is as per the customer’s standard.

#5) Deployment
Once the product is tested, it is deployed in the production environment or
first UAT (User Acceptance testing) is done depending on the customer
expectation.
In the case of UAT, a replica of the production environment is created and the
customer along with the developers does the testing. If the customer finds the
application as expected, then sign off is provided by the customer to go live.

#6) Maintenance
After the deployment of a product on the production environment, maintenance
of the product i.e. if any issue comes up and needs to be fixed or any
enhancement is to be done is taken care by the developers.
Memory Management
When concerns cut across multiple system functions, features, and information, they are often referred
to as crosscutting concerns
SPECIALIZED PROCESS MODEL
Specialized process models take on many of the characteristics of one or more
of the traditional models.
However, these models tend to be applied when a specialized or narrowly
defined software engineering approach is chosen

Component based development

Regardless of the technology that is used to create the components, the

component-based development model incorporates the following steps
(implemented using an evolutionary approach):

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.
Your software engineering team can achieve a reduction in development cycle
time as well as a reduction in project cost if component reuse becomes part of
your culture.

Aspect-Oriented Software Development

Aspect-oriented software development (AOSD) is a software design solution
that helps address the modularity issues that are not properly resolved by
other software approaches, like procedural, structured and object-oriented
programming (OOP). AOSD complements, rather than replaces, these other
types of software approaches.

AOSD is also known as aspect-oriented programming (AOP).

AOSD features are as follows:

• Smaller code size, due to tackling cross cutting concerns

• Reduced efficiency from increased overhead
• Key focus - Identification, representation and specification of concerns,
which also may be cross-cutting
THE UNIFIED PROCESS

The unified process model (or UPM) is an iterative, incremental, architecture-centric, and use-
case driven approach to software development.

PHASES OF UNIFIED PROCESS

• INCEPTION PHASE
• ELABORATION PHASE
• CONSTRUCTION PHASE
• TRANSITION PHASE
The Unified Process (UP)
elaboration phase
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.
An agile view of process:
Combines
A philosophy
A set of development guidelines
Software engineers and other project stake holders work together on an agile team.
Software product is fast paced and ever changing that’s why agile process is important today
.Framework activities :customer communication ,planning ,modeling ,construction ,delivery
,evaluation.

Agile is a time-bound, iterative approach to software delivery that builds

software incrementally from the start of the project, instead of trying to deliver
all at once.

What is “Agility”? Rapid and adaptive response to change

Effective communication among all stakeholders
Drawing the customer onto the team
Organizing a team so that it is in control of the work performed
Yielding …
Rapid, incremental delivery of software

Agile Teams are

responsive to changes during project development
recognize that project plans must be flexible
liminates the separation between customers and developers

Any agile software process is characterized in a manner that addresses a

number of
key assumptions [Fow02] about the majority of software projects:
1. It is difficult to predict in advance which software requirements will
persist
and which will change. It is equally difficult to predict how customer
priorities will change as the project proceeds.
2. For many types of software, design and construction are interleaved.
That is,
both activities should be performed in tandem so that design models are
proven as they are created. It is difficult to predict how much design is
necessary before construction is used to prove the design.
3. Analysis, design, construction, and testing are not as predictable (from a
planning point of view) as we might like.
Agility Principles
The Agile Alliance (see [Agi03], [Fow01]) defines 12 agility principles for those
who
want to achieve agility:
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
9.Continuous attention to technical excellence and good design enhances
agility.
10. Simplicity—the art of maximizing the amount of work not done—is
essential.
11. The best architectures, requirements, and designs emerge from self–
organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.

Human Factors
Traits that need to exist in members of agile development teams:
Competence
Common focus
CollaborationDecision-making ability
Fuzzy-problem solving ability
Mutual trust and respect
Self-organization
Agile model

The agile process model encourages continuous iterations of

development and testing.

Each incremental part is developed over an iteration, and each iteration is

designed to be small and manageable so it can be completed within a few
weeks.

Each iteration focuses on implementing a small set of features completely. It

involves customers in the development process and minimizes documentation
by using informal communication.

Though agile provides a very realistic approach to software development, it

isn’t great for complex projects. It can also present challenges during transfers
as there is very little documentation. Agile is great for projects with changing
requirements.

Some commonly used agile methodologies include:

• Scrum: One of the most popular agile models, Scrum consists of

iterations called sprints. Each sprint is between 2 to 4 weeks long and is
preceded by planning. You cannot make changes after the sprint
activities have been defined.
• Extreme Programming (XP): With Extreme Programming, an
iteration can last between 1 to 2 weeks. XP uses pair programming,
continuous integration, test-driven development and test automation,
small releases, and simple software design.
• Kanban: Kanban focuses on visualizations, and if any iterations are
used they are kept very short. You use the Kanban Board that has a clear
representation of all project activities and their numbers, responsible
people, and progress

Advantage(Pros) of Agile Method:

1. Frequent Delivery
2. Face-to-Face Communication with clients.
3. Efficient design and fulfils the business requirement.
4. Anytime changes are acceptable.
5. It reduces total development time.
Disadvantages(Cons) of Agile Model:
1. Due to the shortage of formal documents, it creates confusion and crucial decisions
taken throughout various phases can be misinterpreted at any time by different
team members.
2. Due to the lack of proper documentation, once the project completes and the
developers allotted to another project, maintenance of the finished project can
become a difficulty.