GreenWor ds This Old Application Front-End Quality Management and Your Mission-Critical Fixer-Uppers.

Slides:



Advertisements
Similar presentations
Intelligence Step 5 - Capacity Analysis Capacity Analysis Without capacity, the most innovative and brilliant interventions will not be implemented, wont.
Advertisements

The knowledge capture tool for the 21 st Century C O M P R O S E © 2004.
Key-word Driven Automation Framework Shiva Kumar Soumya Dalvi May 25, 2007.
Delivery Business Solutions April 29, Nashville PMI Symposium April 29, 2013 Stephanie Dedmon, PMP Director, Business Solutions Delivery Department.
Chapter 10 Schedule Your Schedule. Copyright 2004 by Pearson Education, Inc. Identifying And Scheduling Tasks The schedule from the Software Development.
A community-maintained data store for descriptions of library resources Global Open Knowledgebase (GOKb)
1 Independent Verification and Validation Current Status, Challenges, and Research Opportunities Dan McCaugherty IV&V Program Manager Titan Systems Corporation.
1 / 24 CS 425/625 Software Engineering Software Evolution Based on Chapter 21 of the textbook [SE-8] Ian Sommerville, Software Engineering, 8 th Ed., Addison-Wesley,
Thee-Framework for Education & Research The e-Framework for Education & Research an Overview TEN Competence, Jan 2007 Bill Olivier,
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
1 IS371 WEEK 8 Last and Final Assignment Application Development Alternatives to Application Development Instructor Online Evaluations.
Information Systems Development Lecture 2: the idea of the Life Cycle.
Health Informatics Series
Software evolution.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 3: Basing Software Development on Reusable Technology.
Software Architecture Quality. Outline Importance of assessing software architecture Better predict the quality of the system to be built How to improve.
Troy Eversen | 19 May 2015 Data Integrity Workshop.
Chapter 24 - Quality Management
Chapter 9 – Software Evolution and Maintenance
Software Evolution Planning CIS 376 Bruce R. Maxim UM-Dearborn.
Chapter 5 Initiating and Planning Systems Development Projects
ENTERPRISE DATA INTEGRATION APPLICATION ARCHITECTURE COMMITTEE OCTOBER 8, Year Strategic Initiatives.
Continuation From Chapter From Chapter 1
© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 6 Slide 1 Chapter 5 Initiating and Planning Systems Development.
Organizing Information Technology Resources
Product Quality, Testing, Reviews and Standards
IT Systems Analysis & Design
Software evolution. Objectives l To explain why change is inevitable if software systems are to remain useful l To discuss software maintenance and maintenance.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Software change l Managing the processes of software system change.
Ch 5. The Evolution of Analytic Processes
CS 425/625 Software Engineering Legacy Systems
© S. Demeyer, S. Ducasse, O. Nierstrasz Intro.1 1. Introduction Goals Why Reengineering ?  Lehman's Laws  Object-Oriented Legacy Typical Problems  common.
Open Source and IP Telephony: Myth Busters, Best Practices and Real Life Application in the Contact Center Kelly Duerr, Senior Product Manager Tom Chamberlain,
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
© 2007 by Prentice Hall 1 Introduction to databases.
Creating Business Impact | Providing Expert Solutions | Delivering Quality Consistently | Building Partnerships Globally Large-Scale Enterprise GIS Systems.
IT Requirements Management Balancing Needs and Expectations.
SOFTWARE ENGINEERING MCS-2 LECTURE # 3. SOFTWARE PROCESS  A software development process, also known as a software development life- cycle (SDLC), is.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
The Systems Development Life Cycle
Clinical Application. The Problem Clinical Systems are extremely complex IT configures and deploys best practices (best guesses) about what users want.
Washington State Office of Insurance Commissioner State Insurance Management & Business Application Project Recap November 2007.
Manag ing Software Change CIS 376 Bruce R. Maxim UM-Dearborn.
EPA Geospatial Segment United States Environmental Protection Agency Office of Environmental Information Enterprise Architecture Program Segment Architecture.
Strategies for Knowledge Management Success SCP Best Practices Showcase March 18, 2004.
HNDIT23082 Lecture 06:Software Maintenance. Reasons for changes Errors in the existing system Changes in requirements Technological advances Legislation.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
CS223: Software Engineering Lecture 2: Introduction to Software Engineering.
1 SYS366 Week 1 - Lecture 1 Introduction to Systems.
1 TenStep Project Management Process ™ PM00.5 PM00.5 Project Management Preparation for Success * Manage Scope *
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Chapter 10 Software quality. This chapter discusses n Some important properties we want our system to have, specifically correctness and maintainability.
Software Maintenance1 Software Maintenance.
Driving Value from IT Services using ITIL and COBIT 5 July 24, 2013 Gary Hardy ITWinners.
Organizing and leading the IT function Two set of tensions guide policies for developing, deploying and managing IT systems. 1.Innovation and control a.How.
Practical IT Research that Drives Measurable Results Make the Case for IP Telephony 1Info-Tech Research Group.
RPA – Robotic Process Automation
Software Development Module Code: CST 240 Chapter 6: Software Maintenance Al Khawarizmi International College, AL AIN, U.A.E Lecturer: Karamath Ateeq.
Section 1 Delivering Value with IT
IT Architecture Technical blueprint for evolving a corporate infrastructure resource that can be shared by many users and services processing systems hardware.
Environment Assessment
VP, Institutional Services
How does a Requirements Package Vary from Project to Project?
IT Systems Analysis & Design
CS 425/625 Software Engineering Software Evolution
Software Testing and Maintenance Maintenance and Evolution Overview
Chapter 8 Software Evolution.
Legacy system components
Introduction Software maintenance:
Presentation transcript:

GreenWor ds This Old Application Front-End Quality Management and Your Mission-Critical Fixer-Uppers

GreenWord s —A fix-it-upper or a tear-it-downer? —The value proposition for renovating Legacy Systems —Why renovation projects go wrong: Quality management issues specific to renovation projects —A Quality Management process for renovation projects —Making sure your renovation projects go right Agenda

GreenWord s A fix-it-upper or a tear-it-downer? —Implemented on a 360 —Functional specification last seen in 1987 —COBOL source code incomplete —Last known update, enhancement or maintenance fix in 1991 —No documentation of updates, enhancements or maintenance fixes since 1989 On the other hand… —Last outage in 1991, for one hour —The central repository of current as well as historical data for critical business functions —Can be managed by a two-person team

GreenWord s Legacy Systems: the issues —Legacy Systems are still the information backbone of many organizations —Legacy Systems contain data with critical untapped value —Character-based Legacy System interfaces keep the value locked up —Fixing up or tearing down is a strategic decision that requires careful analysis

GreenWord s The issues become critical when… —The cost and difficulty of maintaining old code is becoming a serious drain —The limitations of character-based terminal access are impacting business processes —The business model implicit in the software may no longer be valid —The terminal-host communications architecture can no longer support important business information needs

GreenWord s Fix it up or tear it down? —Fixing up (renovating) an old application may add years of value —OR avoid the inevitable only for a short time and at a high cost —Tearing down (replacing) an old application may provide a necessary leap into new technology —OR divert scarce development resources from more essential projects at a high cost in organizational disruption

GreenWord s The Value Proposition for renovating a Legacy System Renovation can have a faster payback and a higher ROI when —The application works —Up-to-date documentation or Subject Matter Experts are available —The business rules are up to date or easily updated —Data volumes dictate keeping the current platforms —Replacement will take too long or be too disruptive —The current mainframe technology is stable, reliable, and cost- effective —The application’s core functions meet the most important user needs

GreenWord s The value proposition for tearing it down Replacement may be the best solution when —The application has only a few years life-expectancy with or without renovation —Subject Matter Experts are not available to support renovation —The business rules no longer apply —Design recovery is essential but prohibitively expensive or difficult —The cost and risk of replacement meets the parameters of a business case even if more expensive

GreenWord s Potential benefits of renovation —Increase ROI by leveraging existing host systems —Reduce costs —Increase revenue —Increase employee satisfaction —Maintain technological stability —Defer need for high-cost, high-risk alternatives

GreenWord s Opting for Renovation

GreenWord s Why renovation projects go wrong —The value proposition for renovation is weak —Poor requirements management —Poor communication with users —Lack of a renovation-centric quality management process

GreenWord s —The application’s basic functionality does not support business processes or user needs —Multiple physical formats and data definitions exist for the same data entities —The procedural code is a mess —Maintenance costs are already too high —The infrastructure costs too much or is unstable —No SMEs are available to extract business rules The value proposition may be weak if…

GreenWord s Poor requirements management —Most frequent cause of ALL project failures —Excuses, excuses, excuses —“We already know the requirements” —“We are only changing the front end” —"We don't know exactly what the product will be yet" —“We can’t get commitment for the extra up-front effort required“ —"We have a deadline and can't afford the luxury of writing a specification" —"Requirements are hard to write and all they do is keep changing“

GreenWord s Requirements Management is a classic “Wicked Problem” —The solution is often implemented before the problem is fully understood. —Developers and stakeholders understand the problem in different ways (that keep changing) – problem-solving becomes a cultural issue. —Budgets, external drivers, resources, and available technologies keep changing —The problem is never “solved” in the traditional sense - you simply run out of resources.

GreenWord s Poor communication with users —Failure to manage expectations —Failure to create or sustain partnership

GreenWord s Lack of a renovation-centric quality management process —A renovation project is a development project —Just like any other development project, renovation projects need a quality management process —Renovation projects have specific front-end quality management needs —Most development projects don’t have good front-end quality management —Why should renovation projects be any different?

GreenWord s A renovation-centric quality management process —Front-end loaded —Verification and Validation of key development deliverables —Business case —Technology and business impacts of alternatives —Readiness of the renovation environment —Application baseline —New services description —Assessment of application structure and code —New functional specification

GreenWord s Assess the business case —Development activity: Assess the business case for the current value of the application, and the projected payback and ROI through renovation —Verification and validation: Were enough of the following carefully collected and organized? —User interviews, surveys, and focus groups —Review of documentation —SME interviews —Vendor interviews —Technology assessments —Counter-evidence

GreenWord s Assess technology and business impacts —Development activity: Assess the technology and business impact of alternative renovation approaches —Verification and validation: Did the assessment consider costs, benefits and risks: —If implemented in current environment —If implemented in new or enhanced environment —To current business processes —Of taking resources from other opportunities —Counter-evidence

GreenWord s Assess readiness of renovation environment —Development activity: Assess the readiness of the renovation environment —Verification and validation: Did the assessment consider —Costs, benefits, and risks to establish required infrastructure, tools, and skills? —Counter-evidence?

GreenWord s Application baseline —Development activity: Baseline the application —Verification and validation: Did the baseline include the following? —State of the documentation —Impact of the application on others sharing the same production environment —Current maintenance costs —Level of user satisfaction —Validity of current business rules for core functions —Counter-evidence

GreenWord s New services —Development activity: Find something useful to add through renovation —Verification and validation: Did the selection process cover —Core requirements validated for quality and baselined —Users’ perceptions of the real value of the service —Costs, benefits, and risks of adding the service —Payback and ROI of the new service —Impact of the new service on others sharing the same production environment —Counter-evidence

GreenWord s Assess current application structure and code —Development activity: Assess the application structure and code —Verification and validation: Did the assessment cover —Duplicate functionality —Dead functionality —Functionality that needs to be reengineered independent of renovation —Maintainability of the code —Quality attributes, e.g. modularity, complexity, etc. —Adaptability of existing functionality to support new services

GreenWord s Create a new functional specification —Development activity: Create a functional specification incorporating new services —Verification and validation: Does the new specification do the following? —Separate the existing functionality from new functionality in a modular structure —Break down the functionality into manageable steps —Identify code to be reengineered for efficiency

GreenWord s Summing up —Managing quality issues from the beginning offers the best guarantee of success at the end —Focusing on quality management from the beginning is the surest way to reduce rework, speed payback and increase Return on Investment from every Legacy Renovation effort

GreenWord s Contact Us For more information, contact us by: Telephone, at , at