You are on page 1of 36

Software Engineering

UNIT-I

Software Engineering:

The term software engineering is the product of two words, software and
engineering.
The Software is a collection of integrated programs. Software subsists of
carefully-organized instructions and code written by developers on any of
various particular computer languages.

Engineering is the application of scientific and practical knowledge to


invent, design, build, maintain, and improve frameworks, processes, etc.

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 IEEE fully defines software engineering as:


The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the
application of engineering to software

Fritz Bauer, a German computer scientist, defines software


engineering as:
Software engineering is the establishment and use of sound engineering
principles in order to obtain economically software that is reliable and
work efficiently on real machines.

Need of Software Engineering


The need of software engineering arises because of higher rate of change
in user requirements and environment on which the software is working.
1. Large software - It is easier to build a wall than to a house or
building, likewise, as the size of software become large engineering
has to step to give it a scientific process.
2. Scalability- If the software process were not based on scientific and
engineering concepts, it would be easier to re-create new software
than to scale an existing one.
3. Cost- As hardware industry has shown its skills and huge
manufacturing has lower down the price of computer and electronic
hardware. But the cost of software remains high if proper process is
not adapted.
4. Dynamic Nature- The always growing and adapting nature of
software hugely depends upon the environment in which user works.
If the nature of software is always changing, new enhancements need
to be done in the existing one. This is where software engineering
plays a good role.
5. Quality Management- Better process of software development
provides better quality software product.

Software Engineering helps

1. To Reduces complexity: Big software is always complicated and


challenging to progress. Software Engineering has a great solution
to reduce the complication of any project. Software engineering
divides big problems into various small issues. And then start
solving each small issue one by one. All these small problems are
solved independently to each other.

2. To minimize software cost: Software needs a lot of hard work and


software engineers are highly paid experts. A lot of manpower is
required to develop software with a large number of codes. But in
software engineering, programmers project everything and
decrease all those things that are not needed. In turn, the cost for
software productions becomes less as compared to any software
that does not use software engineering method.
3. To decrease time: Anything that is not made according to the
project always wastes time. And if you are making great software,
then you may need to run many codes to get the definitive running
code. This is a very time-consuming procedure, and if it is not well
handled, then this can take a lot of time. So if you are making your
software according to the software engineering method, then it will
decrease a lot of time.

4. To Handling big projects: Big projects are not done in a couple of


days, and they need lots of patience, planning, and management.
And to invest six and seven months of any company, it requires
heaps of planning, direction, testing, and maintenance. No one can
say that he has given four months of a company to the task, and the
project is still in its first stage. Because the company has provided
many resources to the plan and it should be completed. So to
handle a big project without any problem, the company has to go
for a software engineering method.

5.To make reliable software: Software should be secure, means if


you have delivered the software, then it should work for at least its
given time or subscription. And if any bugs come in the software,
the company is responsible for solving all these bugs. Because in
software engineering, testing and maintenance are given, so there is
no worry of its reliability.

6. Effectiveness: Effectiveness comes if anything has made according


to the standards. Software standards are the big target of companies
to make it more effective. So Software becomes more effective in
the act with the help of software engineering.

Characteristics of good software


A software product can be judged by what it offers and how well it can
be used. This software must satisfy on the following grounds:

1. Operational

2. Transitional

3. Maintenance

Well-engineered and crafted software is expected to have the following


characteristics:

Operational

This tells us how well software works in operations. It can be measured


on:

1. Budget

2. Usability

3. Efficiency

4. Correctness

5. Functionality

6. Security

7. Safety

Transitional

This aspect is important when the software is moved from one platform
to another:

1. Portability

2. Interoperability

3. Reusability

4. Adaptability
Maintenance

This aspect briefs about how well a software has the capabilities to
maintain itself in the ever-changing environment:

1. Modularity

2. Maintainability

3. Flexibility

4. Scalability

Process Framework

The process of framework defines a small set of activities that are


applicable to all types of projects. The software process framework is a
collection of task sets. Task sets consist of a collection of small work
tasks, project milestones, work productivity and software quality
assurance points.
Umbrella activities:

Typical umbrella activities are:

1. Software project tracking and control


· In this activity, the developing team accesses project plan and
compares it with the predefined schedule.
· If these project plans do not match with the predefined schedule, then
the required actions are taken to maintain the schedule.

2. Risk management

· Risk is an event that may or may not occur.


· If the event occurs, then it causes some unwanted outcome. Hence,
proper risk management is required.

3. Software Quality Assurance (SQA)


· SQA is the planned and systematic pattern of activities which are
required to give a guarantee of software quality.
For example, during the software development meetings are conducted
at every stage of development to find out the defects and suggest
improvements to produce good quality software.

4. Formal Technical Reviews (FTR)

· FTR is a meeting conducted by the technical staff.


· The motive of the meeting is to detect quality problems and suggest
improvements.
· The technical person focuses on the quality of the software from the
customer point of view.

5. Measurement
· Measurement consists of the effort required to measure the software.
· The software cannot be measured directly. It is measured by direct and
indirect measures.
· Direct measures like cost, lines of code, size of software etc.
· Indirect measures such as quality of software which is measured by
some other factor. Hence, it is an indirect measure of software.

6. Software Configuration Management (SCM)

· It manages the effect of change throughout the software process.

7. Re-usability management

· It defines the criteria for reuse the product.


· The quality of software is good when the components of the software
are developed for certain application and are useful for developing
other applications.

8. Work product preparation and production

· It consists of the activities that are needed to create the documents,


forms, lists, logs and user manuals for developing a software.

Capability maturity model (CMM)

CMM was developed by the Software Engineering Institute (SEI) at


Carnegie Mellon University in 1987.
· It is not a software process model. It is a framework that is used to
analyze the approach and techniques followed by any organization to
develop software products.
· It also provides guidelines to further enhance the maturity of the process
used to develop those software products.
· It is based on profound feedback and development practices adopted by
the most successful organizations worldwide.
· This model describes a strategy for software process improvement that
should be followed by moving through 5 different levels.
· Each level of maturity shows a process capability level. All the levels
except level-1 are further described by Key Process Areas (KPA’s).

Shortcomings of SEI/CMM:
· It encourages the achievement of a higher maturity level in some cases
by displacing the true mission, which is improving the process and
overall software quality.
· It only helps if it is put into place early in the software development
process.
· It has no formal theoretical basis and in fact is based on the experience
of very knowledgeable people.
· It does not have good empirical support and this same empirical support
could also be constructed to support other models.

Key Process Areas (KPA’s):

Each of these KPA’s defines the basic requirements that should be met by
a software process in order to satisfy the KPA and achieve that level of
maturity. Conceptually, key process areas form the basis for management
control of the software project and establish a context in which technical
methods are applied, work products like models, documents, data, reports,
etc. are produced, milestones are established, quality is ensured and
change is properly managed.

The 5 levels of CMM are as follows:

Level-1: Initial –

· No KPA’s defined.
· Processes followed are Adhoc and immature and are not well defined.
· Unstable environment for software development.
· No basis for predicting product quality, time for completion, etc.

Level-2: Repeatable –

· Focuses on establishing basic project management policies.


· Experience with earlier projects is used for managing new similar
natured projects.
· Project Planning- It includes defining resources required, goals,
constraints, etc. for the project. It presents a detailed plan to be
followed systematically for the successful completion of good quality
software.
· Configuration Management- The focus is on maintaining the
performance of the software product, including all its components, for
the entire lifecycle.
· Requirements Management- It includes the management of customer
reviews and feedback which result in some changes in the requirement
set. It also consists of accommodation of those modified requirements.
· Subcontract Management- It focuses on the effective management of
qualified software contractors i.e. it manages the parts of the software
which are developed by third parties.
· Software Quality Assurance- It guarantees a good quality software
product by following certain rules and quality standard guidelines
while developing.

Level-3: Defined –

· At this level, documentation of the standard guidelines and procedures


takes place.
· It is a well-defined integrated set of project-specific software
engineering and management processes.
· Peer Reviews- In this method, defects are removed by using a number
of review methods like walkthroughs, inspections, buddy checks, etc.
· Intergroup Coordination- It consists of planned interactions between
different development teams to ensure efficient and proper fulfillment
of customer needs.
· Organization Process Definition- Its key focus is on the development
and maintenance of the standard development processes.
· Organization Process Focus- It includes activities and practices that
should be followed to improve the process capabilities of an
organization.
· Training Programs- It focuses on the enhancement of knowledge and
skills of the team members including the developers and ensuring an
increase in work efficiency.

Level-4: Managed –
· At this stage, quantitative quality goals are set for the organization for
software products as well as software processes.
· The measurements made help the organization to predict the product
and process quality within some limits defined quantitatively.
· Software Quality Management- It includes the establishment of plans
and strategies to develop quantitative analysis and understanding of
the product’s quality.
· Quantitative Management- It focuses on controlling the project
performance in a quantitative manner.

Level-5: Optimizing –

· This is the highest level of process maturity in CMM and focuses on


continuous process improvement in the organization using quantitative
feedback.
· Use of new tools, techniques, and evaluation of software processes is
done to prevent recurrence of known defects.
· Process Change Management- Its focus is on the continuous
improvement of the organization’s software processes to improve
productivity, quality, and cycle time for the software product.
· Technology Change Management- It consists of the identification and
use of new technologies to improve product quality and decrease
product development time.
· Defect Prevention- It focuses on the identification of causes of defects
and prevents them from recurring in future projects by improving
project-defined processes.

Process Assessment
A software process assessment is a disciplined examination of the
software processes used by an organization, based on a process model.
The assessment includes the identification and characterization of current
practices, identifying areas of strengths and weaknesses, and the ability
of current practices to control or avoid significant causes of poor
(software) quality, cost, and schedule.

A software assessment (or audit) can be of three types.

1.A self-assessment (first-party assessment) is performed internally by


an organization's own personnel.

2.A second-party assessment is performed by an external assessment


team or the organization is assessed by a customer.

3.A third-party assessment is performed by an external party or (e.g., a


supplier being assessed by a third party to verify its ability to enter
contracts with a customer).

Software process assessments are performed in an open and


collaborative environment. They are for the use of the organization to
improve its software processes, and the results are confidential to the
organization. The organization being assessed must have members on
the assessment team.

Process Model
Prescriptive process models
Prescriptive process models prescribe a set of framework and other
activities, quality assurance points, and software process-related elements.
They define a workflow among these elements that shows their inter-
relationship.
Prescriptive software models are those which prescribe the components
which make up a software model, including the activities, the inputs and
outputs of the activities, how quality assurance is performed, how change
is managed, and so on. A prescriptive model also describes how each of
these elements are related to one another. The process models described
here are,

Waterfall Model.

Incremental Process Model.

Evolutionary Process Model.

The Waterfall Model


The Waterfall model is also known as ‘Linear sequential model‘ or
‘Classic life cycle model‘. It is used in small projects where requirements
are well defined and known before starting the project. Activities are
carried out in a linear and systematic fashion.

The Waterfall Model

The process starts with communication, where requirements are gathered


from the customer and recorded.
Then goes to the planning stage where the cost and time constraints are
estimated, a schedule is outlined and project tracking variables are
defined.
Modelling is where a design based on the requirements and keeping the
project constraints in mind is created. After this, code is generated and the
actual building of the product is started in the construction phase.
Testing (unit testing, integration testing) is done after code completion in
this phase.
Deployment is the last stage where the product is delivered, customer
feedback is received and support and maintenance for the product are
provided.
Advantages of the waterfall model

 A simple model to use and implement.


 Easily understandable workflow.
 Easy to manage since requirements are known prior to the start of the
project.
 Can be applied to projects where quality is preferred over cost.

Disadvantages of the waterfall model

 It may be difficult for the customer to provide all the specific


requirements beforehand.
 Cannot be used for complex and object-oriented projects.
 Testing and customer evaluation are done at the last stages and hence
the risk is high.
 Iteration of activities is not promoted which is unavoidable for certain
projects.
 May lead to “blocking states” in which some project team members
must wait for other members of the team to complete dependent tasks.

Incremental Process Model


The Incremental process model is also known as ‘Successive version
model‘.
In the Incremental process model, a series of releases, called increments,
are built and delivered to the customer. First, a simple working
system(core product), that addresses basic requirements, is delivered.
Customer feedback is recorded after each incremental delivery. Many
increments are delivered, by adding more functions, until the required
system is released. This model is used when a user demands a model of
product with limited functionality quickly.

The Incremental Process Model


Advantages of incremental process model

 Flexible to change requirements.


 Changes can be done throughout the development stages.
 Errors are reduced since the product is tested by the customer in each
phase.
 Working software available at the early stage of the process.
 Easy to test because of small iterations.
 The initial cost is lower.

Disadvantages of incremental process model

 Requires good planning and design.


 Modules and interfaces should be well defined.
 The total cost is high.
 Demands a complete planning strategy before commencement.
 Refining requirements in each iteration may affect system architecture.
 Breaking the problem into increments needs skilful management
supervising.

Evolutionary Process Models

Evolutionary process models are opted when the requirements may tend
to change and also when the complete sophisticated product delivery
cannot be done before a given deadline, but the delivery of a limited
version of it is possible.
In the incremental model, complete requirements are specified
beforehand and these requirements are refined over time for each
increment. The evolutionary model permits requirements, plans and
estimates to evolve over time.
In cases when the requirements are unclear and are likely to change or
when the developer is doubtful about working of an algorithm, a solution
is to build a prototype and find out what is actually needed. Hence, in this
model, one or more prototypes are made with unrefined currently known
requirements before the actual product is made.
Evolutionary Process Models
 The prototyping model.
 The spiral model.
 Concurrent development model

The prototyping model


Prototyping
A quick design is what occurs in a prototype model. The client evaluates
the prototype and gives feedback and other requirements which are
incorporated in the next prototype. This is repeated until the prototype
becomes a complete product that is acceptable to the client. Some
prototypes are built as “throwaways”, others are “evolutionary” in nature
as they evolve into the actual system.
Advantages of prototyping

 Active involvement of the user.


 Errors are detected earlier.
 Feedback after each prototype helps in understanding the system
better.
 Does not need to know detailed processes, input and output from the
beginning.

Disadvantages of prototyping

 Multiple prototypes can slow down the process.


 Frequent changes can increase complexity.
 Unsatisfied client leads to multiple throwaways.
 The customer may not be interested or satisfied after evaluating the
initial prototype.
Spiral Model
In spiral model, the software is developed through a series of increments.
The diagram looks like a spiral with loops where each loop is a phase.
Each phase is split into four sectors/quadrant.

The Spiral Model

The first circuit around the spiral might result in the development of a
product specification. The subsequent passes around the spiral might be
used to develop a prototype and then progressively more mature versions
of the software.
Planning is where the objectives, alternatives and other constraints are
determined. The alternatives are considered, risks in each alternative are
analyzed and prototypes are refined in the risk analysis sector. At the
development quadrant level risks are known and it proceeds with
developing and testing the product. In the assessment sector, customer
evaluation of product developed is reviewed and the next phase is
planned. This loop continues until acceptable software is built and
deployed.
Hence, the spiral model follows an incremental process methodology and
unlike other process models, it deals with the uncertainty by applying a
series of risk analysis strategies throughout the process.
Advantages of spiral model

 Reduces risk.
 Recommended for complex projects.
 Changes can be incorporated at a later stage.
 Strong documentation helps in better management.

Disadvantages of spiral model

 Costly and not recommended for small projects.


 Demands risk assessment expertise.
 Looping is a complex process.
 Heavy documentation.

The concurrent development model

 The concurrent development model is called as concurrent model.


 The communication activity has completed in the first iteration and
exits in the awaiting changes state.
 The modeling activity completed its initial communication and then
go to the underdevelopment state.
 If the customer specifies the change in the requirement, then the
modeling activity moves from the under development state into the
awaiting change state.
 The concurrent process model activities moving from one state to
another state.
Advantages of the concurrent development model

 This model is applicable to all types of software development


processes.
 It is easy for understanding and use.
 It gives immediate feedback from testing.
 It provides an accurate picture of the current state of a project.

Disadvantages of the concurrent development model

 It needs better communication between the team members. This may


not be achieved all the time.
 It requires to remember the status of the different activities.

Specialized process models:

Specialized process models use many of the characteristics of one or


more of the conventional models presented so far, however they tend to
be applied when a narrowly defined software engineering approach is
chosen. They include

 Component based development


 The formal method model
 Aspect oriented software development

Component based development:

In this approach, commercial off_the_shelf (cots) s\w component,


developed by vendors who offers them as products are used in the
development of software. Characteristics resemble to spiral models.

Merits:

Leads to software reuse, which provides number of benefits.

 70% reduction in development cycle time


 84%reduction in project cost
 Productivity index goes up to 26.2

Demerits:

 Components library must be robust


 Performance may degrade

The formal method model:

 The formal method encompasses a set of activities that leads to


formal mathematical specification of computer software.
 It consists of specification, development & verifications by applying
rigorous mathematical notation. Example , clean room s/w
engineering (CRSE)

Merits:
 Removes many of the problems that are difficult to remove using
other s/w engg paradigms.
 Ambiguity , incompleteness & inconsistency can be discovered &
corrected easily by using formal methods of mathematical analysis.

Demerits:

 Development is time consuming & expensive.


 Extensive training is required.
 Difficult to use with technically unsophisticated customers.

Aspects oriented software development(AOSD):

 A Set of localized features, function & information content are used


while building complex software.
 These are localized s/w characteristics are modeled as component (e.g.
OO classes) & then constructed within the context of the system
architecture.
 Certain “concerns” (customer required properties or area of the
technical interest) span the entire architecture i.e. cross cutting
concerns like system security, fault tolerance etc.

Merits:

 It is similar to components based development for aspects.

Demerits:

 Component library must be robust.


 Performance may degrade.

The Unified Process in Software Engineering

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 in Software Engineering

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
understand-ability, 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 (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 Model in Software Engineering


The best software process is personal and team process model 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 SEI CMM which is reference model for raising the maturity levels of
software and predicts the most expected outcome from the next project
undertaken by the organizations does not tell software developers about
how to analyze, design, code, test and document the software products,
but expects that the developers use effectual practices. The Personal
Software Process realized that the process of individual use is completely
different from that required by the team.

Personal Software Process (PSP) is the skeleton or the structure that assist
the engineers in finding a way to measure and improve the way of
working to a great extend. It helps them in developing their respective
skills at a personal level and the way of doing planning, estimations
against the plans.

Objectives of PSP:

The aim of PSP is to give software engineers with the regulated methods
for the betterment of personal software development processes.

The PSP helps software engineers to:

 Improve their approximating and planning skills.


 Make promises that can be fulfilled.
 Manage the standards of their projects.
 Reduce the number of faults and imperfections in their work.

Time measurement:

Personal Software Process recommend that the developers should


structure the way to spend the time. The developer must measure and
count the time they spend on different activities during the development.

PSP Planning :
The engineers should plan the project before developing because without
planning a high effort may be wasted on unimportant activities which
may lead to a poor and unsatisfactory quality of the result.

Levels of Personal Software Process :

Personal Software Process (PSP) has four levels-

 PSP 0 –
The first level of Personal Software Process, PSP 0 includes Personal
measurement , basic size measures, coding standards.
 PSP 1 –
This level includes the planning of time and scheduling .
 PSP 2 –
This level introduces the personal quality management ,design and
code reviews.
 PSP 3 –
The last level of the Personal Software Process is for the Personal
process evolution.

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.

The success of an organization that produces software-intensive systems


mainly depends on a well-managed software development process.
Implementing disciplined and quality software methods are often
challenging. Organizations always want to know what their software
development teams are doing, but they find themselves struggling with
how to do it.
Team Software Process (TSP) comes in handy to offer operational
procedures and strategies that assist engineers and managers organize
projects effectively and produce quality software using disciplined
software process methods. TSP is used in combination with personal
software process (PSP) at individual and team levels. Organizations
implemented TSP experience significant improvements in the overall
quality of their software products. They also experience reduced schedule
deviation.
Objective of TSP

The primary objective of TSP is creating a team environment that


supports disciplined work while still building and maintaining a self-
directed team. TSP guides a team in addressing essential business needs
of schedule management, cycle-time reduction, effective quality
management, and better cost management. It defines a product
framework of customizable software processes and introduces strategies
that include training for engineers and managers, building management
sponsorship, automated tool support, mentoring, and coaching.
Team software process can be applied in all aspects of software
development, that is requirements analysis and definition, design,
implementation, testing, and maintenance. Additionally, TSP can also be
used to support multidisciplinary teams ranging from a team of two
engineers to a team of hundreds of engineers. It can also be used in
developing different software products ranging from embedded real-time
control systems to commercial client-server applications.
What Makes TSP Work?

Typical software projects tend to be late, difficult to track, over budget,


and of poor quality. Software development teams often have unrealistic
schedules and deadlines dictated to them. They’re required to use
imposed standards, tools and process. They find themselves taking
shortcuts to meet tight schedule pressures. Only a few teams can work
successfully and consistently in such environments. As software systems
become more complex such problems get worse than before. Moreover,
teams have to consider customer desires, technical capability, and
business needs.
To balance all these pressures and conflicting forces and handling
software development projects a team has to be self-directed. A self-
directed team should have these qualities:

 Understands product and business goals


 Produces their own plans for addressing the goals
 Makes their personal commitments
 Directs their own projects
 Consistently uses processes and methods that they select
 Manages quality.

Team software process builds and maintains self-directed teams. A


successful self-directed team requires capable and skilled team members.
Their commitment, discipline, and skills come together to produce high-
quality software. Therefore, high-quality software products are a team
effort. TSP creates an environment that supports disciplined and self-
directed teamwork.

Product and Process

Product: In the context of software engineering, Product includes any


software manufactured based on the customer’s request. This can be a
problem solving software or computer based system. It can also be said
that this is the result of a project.
Process: Process is a set of sequence steps that have to be followed to
create a project. The main purpose of a process is to improve the quality
of the project. The process serves as a template that can be used through
the creation of its examples and is used to direct the project.
The main difference between a process and a product is that the process is
a set of steps that guide the project to achieve a convenient product. while
on the other hand, the product is the result of a project that is
manufactured by a wide variety of people.

Difference between Product and Process

Product Process
Product is the final production of While the process is a set of sequence steps
the project. that have to be followed to create a project.
A Product focuses on final result Whereas the process is focused on
completing each step being developed
In the case of products, the firm In contrast, the process consistently follows
guidelines are followed. guidelines.
A product tends to be short-term Whereas the process tends to be
The main goal of the product is to While the purpose of the process is to make
complete the work successfully. the quality of the project better

An Agile view of Process

Agility:
 Agility is dynamic, content specific, aggressively change embracing,
and growth oriented
 It encourages team structures and attitudes that make communication
more simplistic
 It emphasizes rapid delivery of operational software and de-
emphasizes the importance of intermediate work products
 It recognizes that planning in an uncertain world has its limits and that
a project plan must be flexible
 Agility can be applied to any software process

Agile Process:
Any agile software process is characterized in a manner that addresses a
number of key assumptions

 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.
 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.
 Analysis, design, construction, and testing are not as predictable as
we might be like

Agility Principles:
 Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
 Welcome changing requirements, even late in development
 Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
 Business people and developers must work together daily throughout
the project.
 Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job done
 The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation
 Working software is the primary measure of progress
 Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
 Continuous attention to technical excellence and good design
enhances agility
 Simplicity—the art of maximizing the amount of work not done—is
essential
 The best architectures, requirements, and designs emerge from self–
organizing teams
 At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly

Agile Model

Agile model is a combination of iterative and incremental process models


with focus on process adaptability and customer satisfaction by rapid
delivery of working software.
The meaning of Agile is swift or versatile. "Agile process model" refers
to a software development approach based on iterative development.
Agile methods break tasks into smaller iterations, or parts do not directly
involve long term planning. The project scope and requirements are laid
down at the beginning of the development process. Plans regarding the
number of iterations, the duration and the scope of each iteration are
clearly defined in advance.
Each iteration is considered as a short time "frame" in the Agile process
model, which typically lasts from one to four weeks. The division of the
entire project into smaller parts helps to minimize the project risk and to
reduce the overall project delivery time requirements. Each iteration
involves a team working through a full software development life cycle
including planning, requirements analysis, design, coding, and testing
before a working product is demonstrated to the client.
Fig: Agile Process Model

Phases of Agile Model:


Following are the phases in the Agile model are as follows:

 Requirements gathering
 Design the requirements
 Construction/ iteration
 Testing/ Quality assurance
 Deployment
 Feedback

1. Requirements gathering: In this phase, you must define the


requirements. You should explain business opportunities and plan the
time and effort needed to build the project. Based on this information,
you can evaluate technical and economic feasibility.
2. Design the requirements: When you have identified the project, work
with stakeholders to define requirements. You can use the user flow
diagram or the high-level UML diagram to show the work of new
features and show how it will apply to your existing system.
3. Construction/ iteration: When the team defines the requirements, the
work begins. Designers and developers start working on their project,
which aims to deploy a working product. The product will undergo
various stages of improvement, so it includes simple, minimal
functionality.
4. Testing: In this phase, the Quality Assurance team examines the
product's performance and looks for the bug.
5. Deployment: In this phase, the team issues a product for the user's
work environment.
6. Feedback: After releasing the product, the last step is feedback. In this,
the team receives feedback about the product and works through the
feedback.
Agile Testing Methods:

 Scrum
 Crystal
 Dynamic Software Development Method(DSDM)
 Feature Driven Development(FDD)
 Lean Software Development
 eXtreme Programming(XP)

Scrum
SCRUM is an agile development process focused primarily on ways to
manage tasks in team-based development conditions.
There are three roles in it, and their responsibilities are:

 Scrum Master: The scrum can set up the master team, arrange the
meeting and remove obstacles for the process
 Product owner: The product owner makes the product backlog,
prioritizes the delay and is responsible for the distribution of
functionality on each repetition.
 Scrum Team: The team manages its work and organizes the work to
complete the sprint or cycle.
eXtreme Programming(XP)
This type of methodology is used when customers are constantly
changing demands or requirements, or when they are not sure about the
system's performance.
Crystal:
There are three concepts of this method-

 Chartering: Multi activities are involved in this phase such as making


a development team, performing feasibility analysis, developing plans,
etc.
 Cyclic delivery: under this, two more cycles consist, these are:
 Team updates the release plan.
 Integrated product delivers to the users.
 Wrap up: According to the user environment, this phase performs
deployment, post-deployment.

Dynamic Software Development Method(DSDM):


DSDM is a rapid application development strategy for software
development and gives an agile project distribution structure. The
essential features of DSDM are that users must be actively connected, and
teams have been given the right to make decisions. The techniques used
in DSDM are:

 Time Boxing
 MoSCoW Rules
 Prototyping

The DSDM project contains seven stages:

 Pre-project

 Feasibility Study

 Business Study
 Functional Model Iteration
 Design and build Iteration
 Implementation
 Post-project

When to use the Agile Model?

 When frequent changes are required.


 When a highly qualified and experienced team is available.
 When a customer is ready to have a meeting with a software team all
the time.
 When project size is small.

Advantage(Pros) of Agile Method:

 Frequent Delivery
 Face-to-Face Communication with clients.
 Efficient design and fulfils the business requirement.
 Anytime changes are acceptable.
 It reduces total development time.

Disadvantages(Cons) of Agile Model:

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

You might also like