0% found this document useful (0 votes)
58 views54 pages

Unit-5 Sepm

Software release management is the process of planning and implementing integrated functional components and processes in a controlled manner. A key part of release management is the release management process, which involves planning, scheduling, building, testing, deploying, and supporting application releases. The objectives of release management include managing risks, coordinating resources, ensuring compliance, overseeing live releases, and maintaining business and IT alignment.

Uploaded by

prince verma
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
58 views54 pages

Unit-5 Sepm

Software release management is the process of planning and implementing integrated functional components and processes in a controlled manner. A key part of release management is the release management process, which involves planning, scheduling, building, testing, deploying, and supporting application releases. The objectives of release management include managing risks, coordinating resources, ensuring compliance, overseeing live releases, and maintaining business and IT alignment.

Uploaded by

prince verma
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 54

Software Engineering

Dr. R. P. Mahapatra
Professor & HOD CSE
SRMIST,NCR Campus, Modinagar, Ghaziabad
UNIT-5
•A product release is the process of delivering a new
product experience to your customers.

•A release is the result of all the cross-functional work


required to get the product to market and support every
customer interaction associated with it.

• A release is a change or set of changes that is created


to be delivered to the production environment.
• A system release is not just executable code of system. Release
may also include following :

I. Configuration files : It defines release should be configured


for particular installations.
II. Data Files : These are needed for successful system
operation.
III. Installation Program : It is used to help install system on
target hardware.
IV. Electronic and Paper documentation : It describes system.
V. Packaging and associated publicity : It defines that have
been designed for that release.
What is Release Management?

• Product release can be defined as methodology for planning


and implementing an integrated set of functional component
and process in control manner.

• Date driven: Releases are scoped in order to meet pre defined


delivery dates.

• Reversed Planned: Start with your target implementation


dates and work backwards.

• Mechanized: Process should try to emulate typical factory


operations.
• Forecasted schedule as well as functionality: Force an
organization to strategize and plan in advance.

• Integrated and predictable: Many business needs folded into


one release and everyone knows the schedule.

• Uses standard SDLC and Project management methodologies


and best practices.
Release Management Process Flow?
• It follows a sequence of steps covering elements like planning,
scheduling, and managing application development—guiding
the project through the development, test, deployment, and
support stages.
• The release management process is typically broken down into
the following stages:
1. Plan Release: The plan breaks the release into stages, sets up
the overall workflow, and explains who is responsible for each
task. The plan should have:
I. Any relevant timelines
II. All delivery dates
III. Project requirements
IV. The project’s overall scope
2. Build Release: At this stage, the product is actually designed
and built following the standards and requirements put forth in
the release plan.
• It may occur several times, as the product is sent to user
testing, revealing issues and bugs that require attention.

3. User Acceptance Testing (UAT): Here end-users test the


product. Here can be multiple user acceptance testing stages. If
the UAT discovers issues with the app, it’s sent back to the
build release stage for changes and fixes. Once the issues are
dealt with, the product goes through UAT again to ensure the
problems have been adequately resolved.
4. Prepare Release : The product is now running down the
home stretch. The team puts the finishing polish on the
product, using the UAT evaluations as a roadmap. Finally, the
quality assurance (QA) team gives the product one final
quality review, ensuring the app meets the minimum
standards of acceptance and business requirements as detailed
in the release plan.

5. Deploy Release: Here the product is now live! But the team’s
work isn’t over. Both the end-users and your home
organization need training and information on the product’s
functions and any future changes.
Objectives & Benefits of Release Management
Release management exists to meet specific and critical goals
in product development. The objectives are:
• Manage risks
• Coordinate all applicable IT resources
• Ensure compliance and auditing processes
• Oversee the live release of new versions
• Maintain alignment and harmony between software
development and the business
Benefits:
• Provides for an integrated view of both business and IT
plans.
-Open planning can provide a clear view of what is being
developed and when the key milestone will be achieved.
• Results in a more stable production system
-The result of integrated release in early development
cycle allows more careful analysis and testing of impact to
normal operations.

• Creates a predictability in delivery timeframes, cost and


support requirements
-It provides all corporate entities with a clear view of
functionality being delivered and release scheduling in both
long and small run.
• Used by many large organization such Cisco, sun etc.
• Delivers changes and new features to users faster and more
consistently
• Reduces the risk of unauthorized releases breaking the features
that end-users rely on
• Ensures that all new or changed services will meet any agreed-
on service requirements
• Provides the transfer of proper knowledge to users and any
support staff
Software Implementation

• The software implementation stage involves the


transformation of the software technical data package
(TDP) into one or more fabricated, integrated, and
tested software configuration items that are ready for
software acceptance testing.
Pre-selection
Process

Package Evaluation

Project Planning

Gap Analysis Reengineering Configuration

Implementation End User


Testing
team training Training

Going Live

Post Implementation
Phase
Elements of a successful software
implementation initiative

• Defining the organization's needs


• Choosing the appropriate software
• Installing the application
• Configuring features
• Customizing features
• Integrating with existing systems
• Training employees
• Testing the software
Software Implementation Challenges
• There are some challenges faced by the development team while
implementing the software. Some of them are mentioned below:
Code-reuse - Programming interfaces of present-day languages are very
sophisticated and are equipped huge library functions. Still, to bring the
cost down of end product, the organization management prefers to re-use
the code, which was created earlier for some other software. There are huge
issues faced by programmers for compatibility checks and deciding how
much code to re-use.
Version Management - Every time a new software is issued to the
customer, developers have to maintain version and configuration related
documentation. This documentation needs to be highly accurate and
available on time.
Target-Host - The software program, which is being developed in the
organization, needs to be designed for host machines at the customers end.
But at times, it is impossible to design a software that works on the target
machines.
Software Testing
• Software Testing is evaluation of the software against
requirements gathered from users and system specifications.
• Testing comprises validation and Verification.
Software Validation: Validation is process of examining
whether or not the software satisfies the user requirements. It
is carried out at the end of the SDLC. If the software matches
requirements for which it was made, it is validated.
• Validation answers the question – "Are we developing the
product which attempts all that user needs from this
software ?".
• Validation emphasizes on user requirements.
• Software Verification: Verification is the process of
confirming if the software is meeting the business
requirements, and is developed adhering to the proper
specifications and methodologies.
• Verification answers the question– "Are we developing this
product by firmly following all design specifications ?"
• Verifications concentrates on the design and system
specifications.
Target of the test are
• Errors - These are actual coding mistakes made by
developers.
• Fault - When error exists fault occurs. A fault, also known as a
bug, is a result of an error which can cause system to fail.
• Failure - failure is said to be the inability of the system to
perform the desired task.
Manual Vs Automated Testing
• Testing can either be done manually or using an automated
testing tool:
• Manual - This testing is performed without taking help of
automated testing tools. The software tester prepares test cases
for different sections and levels of the code, executes the tests
and reports the result to the manager.
• Manual testing is time and resource consuming. The tester
needs to confirm whether or not right test cases are used.
Major portion of testing involves manual testing.
• Automated This testing is a testing procedure done with aid of
automated testing tools. The limitations with manual testing
can be overcome using automated test tools.
Software Maintenance
• It stands for all the modifications and updations done after the
delivery of software product.

Why Maintenance??

• Market Conditions - Policies, which changes over the time,


such as taxation and newly introduced constraints.
• Client Requirements - Over the time, customer may ask for
new features or functions in the software.
• Host Modifications - If any of the hardware or platform (such
as operating system) of the target host changes, software
changes are needed to keep adaptability.
• Software maintenance is the general process of
changing a system after it has been diverted.

• The change may be simple changes to correct coding


errors, more extensive changes to correct design
errors or significant enhancement to correct
specification error or accommodate new
requirements.
• Organization Changes - If there is any business level change
at client end, such as reduction of organization strength,
acquiring another company, organization venturing into new
business, need to modify in the original software may arise.

Types of maintenance
• Corrective Maintenance - This includes modifications and
updation done in order to correct or fix problems, which are
either discovered by user or concluded by user error reports.
• Adaptive Maintenance - This includes modifications and
updations applied to keep the software product up-to date
and tuned to the ever changing world of technology and
business environment.
• Perfective Maintenance - This includes modifications and
updates done in order to keep the software usable over long
period of time. It includes new features, new user requirements
for refining the software and improve its reliability and
performance.
• Preventive Maintenance - This includes modifications and
updations to prevent future problems of the software. It aims
to attend problems, which are not significant at this moment
but may cause serious issues in future.
Cost of Maintenance

• Cost of maintenance is high. A study on estimating software


maintenance found that the cost of maintenance is as high as
67% of the cost of entire software process cycle.
Maintenance Activities

• IEEE provides a framework for sequential maintenance


process activities. It can be used in iterative manner and can be
extended so that customized items and processes can be
included.
• Identification & Tracing - It involves activities pertaining to
identification of requirement of modification or maintenance.
It is generated by user or system may itself report via logs or
error messages.

• Analysis - The modification is analyzed for its impact on the


system including safety and security. The cost of maintenance
is analyzed and estimation is concluded.

• Design - New modules, which need to be replaced or


modified, are designed against requirement specifications set
in the previous stage. Test cases are created for validation and
verification.
• Implementation - The new modules are coded with the help
of structured design created in the design step. Every
programmer is expected to do unit testing in parallel.

• System Testing - Integration testing is done among newly


created modules. Finally the system is tested as a whole,
following regressive testing procedures.

• Acceptance Testing - After testing the system internally, it is


tested for acceptance with the help of users. If at this state,
user complaints some issues they are addressed or noted to
address in next iteration.
• Delivery - After acceptance test, the system is deployed all
over the organization either by small update package or fresh
installation of the system. The final testing takes place at client
end after the software is delivered.
• Training facility is provided if required, in addition to the hard
copy of user manual.

• Maintenance management - Configuration management is an


essential part of system maintenance. It is aided with version
control tools to control versions, semi-version or patch
management.
Software Evolution Approaches
• There are a number of different strategies for software
change.
– Software maintenance
– Architectural transformation
– Software re-engineering.

• Software maintenance
– Changes to the software are made in response to changed
requirements but the fundamental structure of the software
remains stable. This is most common approach used to
system change.
Software Evolution Approaches (cont’d)
• Architectural transformation
– This is a more radical approach to software change then
maintenance as it involves making significant change to
the architecture of the system.
• Software re-engineering
– This is different from other strategies in that no new
functionality is added to the system.
– System re-engineering may involve some structural
modifications but dose not usually involves major
architectural change.
Fault repair
(17%)

functionality
software
addition or
adaption
modification
(18%)
(65%)

Maintenance effort distribution


Maintenance Examples
• Y2K
– many, many systems had to be updated
– language analyzers (find where changes need to be made)
• Anti-Virus Software
– don't usually have to update software, but must send virus
definitions
• Operating System Patching
– Microsoft, Apple, Linux/Unix
– OS is core to use of computer, so it must be constantly
maintained
• Commercial Software in General
– customers need to be informed of updates
– updates have to be easily available - web is good tool
The Maintenance Process
• Maintenance process vary considerably depending on the
types of software being maintained, the development
processes used in an organization and people involved in the
process.

Change Impact Release Change


System
requests analysi planning implementati
release
s on

System
Fault Flat form
enhanceme
repair adaptation
nt

Overview of the Maintenance Process


Why is Maintenance Inefficient?
• Factors adversely effect maintenance
– Lack of models or ignorance of available models (73%)
– Lack of documentation (67.6%)
– Lack of time to update existing documentation (54.1%)
• Other factors (1994 study)
– Quality of original application
– Documentation quality
– Rotation of maintenance people
Why is Maintenance Inefficient? (cont’d)

• More factors (Yip ’95 study)


– Lack of human resources
– Different programming styles conflict
– Lack of documentation and tools
– Bad maintenance management
– Documentation policy
– Turnover
Model of Maintenance Effort

Model of maintenance effort M = p + K^(c-d)

• M = total maintenance effort over entire lifecycle


• p = productive efforts: analysis, design, code, test
• c = complexity due to lack of structured design and
documentation
• d = degree of familiarization with the system
• K = empirically determined constant
What Affects the Maintainability of an
Application?

• Application age
– (software rust?) older programs were probably
worse written and have probably been patched
more
• Size
– measured in KLOC, number of input/output files
• Programming language
– 4th generation are supposed to produce more
maintainable code than 3 rd generaytion
What Affects the Maintainability of an
Application? (cont’d)
• Processing environment
– files harder to maintain than databases, real-time harder
than batch
• Analysis and design methodologies
– well designed software is supposed to be much easier to
maintain
• Structured programming
– there is conflicting evidence whether this really helps
What Affects the Maintainability of an
Application? (cont’d)
• Modularization
– (central thesis of all the oo techniques) small reasonably
self contained pieces of code should be easier to maintain
• Documentation generation
– maintenance of documentation is as expensive as
maintenance of code
• End-user involvement
– some researchers believe when end users are more
involved maintenance decreases
• Maintenance management
– scheduling and the attitudes of management to affects
productivity
Problems in Managing Maintenance

• Changing priorities
– chaotic nature of maintenance requests, the length of
maintenance tasks causing new requests to come along
before an ongoing task is done.

• Inadequate testing methods


– lack of time set aside for testing, of comprehensive test
data, of rigorous testing requirements as a standard for
signing off.

• Performance measurement difficulties


– how do you measure individual or group performance?

• System documentation incomplete or non-existent


– training takes a long time for learning an application so
programmers get stuck on one piece of software.
Maintenance Costs

• Usually greater than development costs (2* to


100* depending on the application)
• Affected by both technical and non-technical
factors
• Increases as software is maintained.
Maintenance corrupts the software structure so
makes further maintenance more difficult.
• Ageing software can have high support costs
(e.g. old languages, compilers etc.)
Maintenance Costs (cont’d)
• Time and money (software that costs £ 10 a line to develop
costs £ 400 a line to maintain)
• Organizations become maintenance bound and cannot
produce new software
• Customer dissatisfaction when seemingly legitimate requests
for repair or modification cannot be addressed in a timely
manner
• Reduction in overall software quality as changes introduce
latent errors in the maintained software
• Upheaval caused during development efforts when staff must
be “pulled” to work on a maintenance task
Development/Maintenance Costs

System 1

System 2

0 50 100 150 200 250 300 350 400 450 500 $

Development costs Maintenance costs


Maintenance Cost Factors
• Team stability
– Maintenance costs are reduced if the same staff are
involved with them for some time
• Contractual responsibility
– The developers of a system may have no contractual
responsibility for maintenance so there is no incentive
to design for future change
• Staff skills
– Maintenance staff are often inexperienced and have
limited domain knowledge
• Program age and structure
– As programs age, their structure is degraded and they
become harder to understand and change
Re-engineering, Reverse Engineering and
Forward Engineering,
Software Rejuvenation
• Re-documentation
– Creation or revision of alternative representations of
software
• at the same level of abstraction
– Generates:
• data interface tables, call graphs, component/variable
cross references etc.
• Restructuring
– transformation of the system’s code without changing its
behavior
Software Rejuvenation(Cont.)
• Reverse Engineering
– Analyzing a system to extract information about the
behavior and/or structure
• also Design Recovery - recreation of design
abstractions from code, documentation, and domain
knowledge
– Generates:
• structure charts, entity relationship diagrams, DFDs,
requirements models
• Re-engineering
– Examination and alteration of a system to reconstitute it in
another form
– Also known as renovation, reclamation
System Re-engineering
• Re-structuring or re-writing part or all of a
legacy system without changing its
functionality
• Applicable where some but not all sub-systems
of a larger system require frequent
maintenance
• Re-engineering involves adding effort to make
them easier to maintain. The system may be re-structured
and re-documented
• When system changes are mostly confined to
part of the system then re-engineer that part
• When hardware or software support becomes
obsolete
Re-engineering Advantages
• Reduced risk
– There is a high risk in new software development. There
may be development problems, staffing problems and
specification problems
• Reduced cost
– The cost of re-engineering is often significantly less than
the costs of developing new software
Forward Engineering and Re-engineering

System Design and Ne w


specification implementation system

Forward engineering

Existing Understanding and Re-engineered


software system transformation system

Software re-engineering
Re-Engineering Cost Factors
• The quality of the software to be re-engineered
• The tool support available for re-engineering
• The extent of the data conversion which is required
• The availability of expert staff for re-engineering
Module types
• Data abstractions
– Abstract data types where data structures and associated
operations are grouped
• Hardware modules
– All functions required to interface with a hardware unit
• Functional modules
– Modules containing functions that carry out closely
related tasks
• Process support modules
– Modules where the functions support a business process
or process fragment
Data Re-engineering
• Involves analysing and reorganising the data structures (and
sometimes the data values) in a program
• May be part of the process of migrating from a file-based
system to a DBMS-based system or changing from one
DBMS to another
• Objective is to create a managed data environment
Reverse Engineering
• Analysing software with a view to understanding its design
and specification
• May be part of a re-engineering process but may also be used
to re-specify a system for re-implementation
• Builds a program data base and generates information from
this
• Program understanding tools (browsers, cross-reference
generators, etc.) may be used in this process
THANKING YOU!

You might also like