Here is some important questions to discuss...

1. Submitted by:- BijayBhandari
1. Explain why Software Maintenance is less understood than Software
Development, and why it is so important.
2. Explain the relationship between software maintenance and software testing.
Ans1:- The software life cycle can be divided into two major parts:
(1) Initial software development and
(2) Software maintenance.
Software maintenance is the modification of a software product after delivery to correct faults, to
improve performance or other attributes, or to adapt the product to a changed environment.
Software maintenance is less understood than software development. It is different because of the
following characteristics:
1. The size and complexity of each maintenance work request are such that it can usually be
handled by one or two resources;
2. Maintenance work requests come in more or less randomly and cannot be accounted for
individually in the annual budget-planning process;
3. Minor enhancements (adaptive) work requests of the enhancement category are reviewed with
customers and can be assigned priorities;
4. The maintenance workload is not managed using project management techniques, but rather
with queue management techniques;
5. Maintenance has a broader scope of configuration management with more operational
considerations.
The software maintenance workload is user-services-oriented and systemresponsibility-oriented.
Priorities can be shifted around at any time, and workrequests of system correction often take priority
over other work in progress.
The four major aspects that software maintenance is important because of :
Maintaining control over the system’s day to day functions;
Maintaining control over system modification;
Perfecting existing acceptable functions;
Preventing system performance from degrading to unacceptable levels.

2. Ans2:-Software maintenance is the process of enhancing and optimizing deployed software (software
release), as well as remedying defects. Software maintenance is one of the phases in the software
development process, and follows deployment of the software into the field. The software maintenance
phase involves changes to the software in order to correct defects and deficiencies found during field
usage as well as the addition of new functionality to improve the software's usability and applicability.
Software maintenance involves different phases: Requirement, Analysis, Design, Implementation and
Testing.
The software maintenance phase is an explicit part of the waterfall model of the software development
process which was developed during the structured programming movement of computer
programming. The other major model, the spiral model developed during the object oriented movement
of software engineering makes no explicit mention of a maintenance phase. Nevertheless, this activity is
notable, considering the fact that two-thirds of a software system's lifetime cost involves maintenance.
Whereas, Software testing is the cost of repeating full testing on a major piece of software can be significant in
terms of time and money. Regression testing, the selective retesting of a software or component to verify that the
modifications have not caused unintended effects, is important to maintenance. As well, finding time to test is often
difficult. There is also the challenge of coordinating tests when different members of the maintenance team are
working on different problems at the same time. When software performs critical functions, it may be impossible to
bring it offline to test.
Software Testing
Software testing is the process of evaluation a software item to detect differences between given input and
expected output. Also to assess the feature of A software item. Testing assesses the quality of the product.
Software testing is a process that should be done during the development process. In other words software
testing is a verification and validation process.
Verification
Verification is the process to make sure the product satisfies the conditions imposed at the start of the
development phase. In other words, to make sure the product behaves the way we want it to.
Validation
Validation is the process to make sure the product satisfies the specified requirements at the end of the
development phase. In other words, to make sure the product is built as per customer requirements.
Overall, software testing is itself a part of software maintenance.

3. Assignment: 2
1. Explain the Product, Process, People Project paradigm. Why is this importnt in
Software Maingtenance but not critical in Software Developemnt.
Ans:Product: One simple definition is that it's everything that comes after the first release, whether adding new
functionality or fixing bugs. It's certainly true that for many products much of the code is written for
that first release and then never drastically changed, unless it's eventually discarded for a
completely different set of files. Another way to define maintenance is that for many companies and
projects, all releases except the next one—the one that is still to come—are in maintenance mode.
This includes any version of the product that is actually in use by customers.
Process:The progress or course taken, methods of operation, a series of actions taken to effect a change.
Software maintenance process is the series of actions taken to effect change during maintenance.
There are differences between products and services in general. These differences affect the way in
which customers assess the quality of products and services.In particular, service quality is assessed
on two dimensions: the technical quality—what the result of the service is—and the functional
quality—how the service is delivered.
People Project Paradigm:The software production process encompasses the whole activity from the initial idea to the final
withdrawal of the system.
Idea-> Analysis ->Requirements ->Design->Implementation ->Testing-> Use
This is important in software maintenance because the product, process and the project paradigm
are the factors which helps the software life-cycle starts with an idea, then goes through the stages
of feasibility study, analysis, design, implementation, testing, release, operation and use. The
software evolves through changes which lead to, or spring from, new ideas that start the cycle off
again.
In software development, it is important to follow a software development process in order to
understand, control and improve what happens as software products are built for customers.
Each stage of software development is itself a process (or a collection of processes) that can be
described by a set of activities. A process can be described in a variety of ways, using text, pictures

4. or a combination. In the software engineering literature, descriptions of process models are
prescriptions (or the way software development should progress) or descriptions (the way software
development is done in actuality).
2.Does the Product, Process, People Project paradigm apply eqully to the code
developed under thWrtrfall model as well as Spiral models, including Agile SW
developemnt?
Ans:Several models exist to streamline the development process. Each one has its pros and cons, and it's up
to the development team to adopt the most appropriate one for the project. Sometimes a combination
of the models may be more suitable.
Waterfall model
Spiral model
Iterative and incremental development
Agile development
Code and fix
Waterfall model:The traditional waterfall model gives a high-level view of the software life-cycle. At its most basic it is
effectively the tried and tested problem solving paradigm:
-Decide what to do
-Decide how to do it
-Do it
-Test it
-Use it.
The phases in the waterfall model are represented as a cascade. The outputs from one phase become
the inputs to the next. Many variations on this model are used in different situations but the underlying
philosophy in each is the same. It is a series of stages where the work of each stage is 'signed off and
development then proceeds to the following phase. The overall process is document driven. The outputs
from each stage that are required to keep the process moving are largely in the form of documents. The
main problem with the original waterfall model lay in its sequential nature, highlighted by later

5. refinements which adapted it to contain feedback loops.An error in the requirements stage, for
example, is far more costly to correct at a late stage in the cycle and more costly than a design error.
Spiral model :The phases in this model are defined cyclically. The basis of the spiral model is a four-stage
representation through which the development process spirals. At each level objectives, constraints and
alternatives are identified, alternatives are evaluated, risks are identified and resolved, the next level of
product is developed and verified, the next phases are planned. The focus is the identification of
problems and the classification of these into different levels of risk, the aim being to eliminate high-risk
problems before they threaten the software operation or cost.
In 1988, Barry Boehm published a formal software system development "spiral model," which combines
some key aspect of the waterfall model and rapid prototyping methodologies, but provided emphasis in
a key area many felt had been neglected by other methodologies: deliberate iterative risk analysis,
particularly suited to large-scale complex systems.
The spiral model combines development activities with risk management. No matter what process
model is used, many activities are common to all.
3. Which of the 10 success recipes is most important for software maintenance?
Explain your reasoning
Software Maintenance: Adaptive maintenance modifications operation to meet up with yet another
requirement in preference to a current requirement. Well-designed advancement brings additional
operation to help satisfy new specifications. Corrective maintenance simply serves to position the
program inside a are convinced that it will have got been in, from the start, provided that state has been
described.
There are many success recipes which are important for software maintenance in an organization they
are:
1. Functionality: The maintenance operation should at least preserve if not enhance the functionality of
the system under maintenance.
2. Quality: The maintenance operation should preserve if not increase the quality of the system under
maintenance.
3. Standards and Guide lines: various types of standards and guidelines can be developed to enhance
the maintainability of software . Standard format for requirements documents and design specifications
structured coding conventions and standardized formats for supporting documents like user’s manual
etc.
4. Complexity: The maintenance operation should not increase the complexity of the product relative to
the size.

6. 5. Volatility: The maintenance operation should not lead to an increase in the volatility of the product.
6. Implementation Activities: implementation, like design, should have the primary goal of producing
software that is easy to understand and easy to modify.
7. Costs: The relative costs per maintenance task should not increase, provided the tasks are of similar
scope.
8. Release deadlines: The agreed upon release deadlines should be kept and delays should not increase.
9. User satisfaction: The user satisfaction rate should remain at least at the same level, if not increase.
10. Profitability: Last but not least, the maintenance operation should be profitable or at least cover it’s
costs.
4. Explain the rationale for repairing vs replacing software as a maintenance
technique. Be complete in your analysis, to include cost factors.
Any software engineering textbook will tell you that the cost of fixing a defect rises dramatically the
later it is found in the development lifecycle of the program
One implication of this wisdom is that we should not be inspecting only source code. Indeed, any
human-readable artifact produced during software development can be inspected: requirements
specifications, design documents and models, test plans, system documentation, and user aids all are
candidates. Inspections are one of the few "testing" techniques available for software work products
other than code.
In fact, the greatest leverage from the time spent on software inspections comes from examining
requirements documents, since correcting a bug this early in the game will save you the most money. Of
course, this assumes that you HAVE written software requirements specifications. If you do not, ask
yourself how you and your customer will both know when the project is completed. If you don't come
up with a good answer, you might want to make written requirements documents a part of your
software development process.
Incorporating inspections into your software engineering process is not free. They can consume
between 5 and 15% of the total project budget. However, many companies have learned that the results
yielded by a good inspection process far outweigh the costs of performing them. Savings can be
estimated by multiplying the number of bugs found by inspection before the product is shipped by the
approximate cost of fixing a bug that is found by a customer. As an example, the Jet Propulsion
Laboratory estimated a net savings of $7.5 million from 300 inspections performed on software they
produced for NASA. Another large company estimated an annual savings of $2.5 million due to their
inspection activities, based on costs of $146 to fix a major defect found by inspection and $2,900 to fix
one found by the customer. As with all software practices, your mileage may vary.

7. Inspections shorten delivery time by reducing the time spent in the integration and system test/debug
phases, since a cleaner product is passed into those late-stage quality filters. Better quality in the
completed product saves on maintenance time, too. Reducing the effort that you have to spend fixing
bugs after delivery frees up time that can be used for new development work.
Cutting down on rework always improves productivity. While it is difficult to compute an anticipated
return on investment for implementing inspections in a particular organization, the software literature
has many examples that justify the investment made in this error detection technique. The excuse of "I
don't have time to do inspections" simply doesn't hold water.
In an organization functioning at a high level of software process maturity, the data collected from
inspections can be used to improve the process further. Data from inspection summary reports can be
used to identify the most common or most costly kinds of bugs, determine their root causes, and change
how work is performed so as to prevent those types of errors. At Bull HN Information Systems, such
inspection and test defect data is used to plan test activities, estimate the number of bugs to be found
at various test stages, and track and analyze project progress.
Inspections tend to reveal different kinds of errors than do testing activities. The combination of formal
inspections and structured, systematic testing provides a powerful tool for creating defect-free
programs, this can save time as well as money. (Time is Money).