Software Transition Plan

Building a system is one thing and turning it over to production for the end users to reap it's utility is a totally different beast. Transitioning products to production involves training, documentation, support knowledge transfer, operational procedures, production readiness and end of life disposal. It is a complex process and requires good governance and leadership. A well known systems hueristic emphasizes that systems are least stable when transitioning from one governance mode to another.


Each of the areas above could require a detailed plan or set of checklists to ensure all needed actions have been considered. In this post we will focus on software products, and list below key items that should be included in a transition plan.


Training should cover all required functions by the end user, and should include special cases. emphasis should be on how to process business rules, verify transactions, run reports and review output. common artifacts used are handouts, videos, training web pages, online webinars, in person train the trainer sessions.


Documentation includes defect logs, knowledge base tip sheets, escalation procedures, notification requirements, schedules for batch jobs, lists of interfaces, details of interfaces, expected outcomes, lists of vendors, data sheets, user guides, admin guides, support levels and contacts. Requirements documents and functional specifications should also be shared with the operatonal support team for reference, manitenance and operational support puproses.


Support knowledge transfer usually takes place in progrsssive iterations in the form of meetings between the project development team and the operational transition team, it is a series of engagements of experts to transfer knowledge, review details of the software and identify all the transition requirements including the development of a transition plan and its execution.


Operational procedures are covered in the documentation above and also include run books, special processes for data archiving, licenses renewals, IT business functions and upport such as security audits, threat analysis and similar processes.


Production readiness covers the setup and installation of the software, user configuration, secuity profiles, smoke testing, functional spot checking, final hardware configuration and monirtoring systems (reportsing / dashboards) setup.


Finally end of life support should be considered at time of transition to ensure the user population understands how to dispose of the software at end of life, how to extract data and migrate into industry standard formats as needed.


The links below provide some more details and templates


https://www.projectmanagement.com/content/processes/10352.cfm


https://www.projectmanagement.com/content/processes/10350.cfm 

Common Software System Development Methodologies

There are 4 common software system development methodologies. These methodologies comprise of:

(1) A process - to define activities or tasks to achieve the goal of the methodology
(2) A vocabulary - to describe the process and work products created during the process application.
(3) Rules and guidelines - to define the quality of the process and the work products

The four methodologies are shown in the table below along with their strengths and weaknesses.

Domain	RUP	Shlaer-Mellar	CRC	XP
Emphasis	- Incremental and iteration	- Execution for verification	Scenarios and simplicity	Simplicity, design through integration and refactoring
Strengths	- Comprehensive - Well Defined artifacts and roles - Incremental deliveries	- Simulation capability - Well defined testing rules - Well defined transition from one step in the process to another - Real-time system support	- Simplicity - Easy to use to transition from procedural to object oriented concepts - Focuses on object value, leading to optimized system	- Focuses and cares about the programming environment - Supports and requires close relationship between clients and developers - Accounts for changes in the development process
Weakness	- Large and difficult - Complicated rules - Customization is not straight-forward - Limited vendors supporting the process	- Considerable learning curve - Focuses too much on state modeling. - Limited vendors supporting the process	- Supports primarily classes - Requires a facilitator	- Relies on an ideal development environment - Depends extensively on client commitments - Requires high quality human interaction among development team - The system is in a constant state of maintenance

Software Systems: What is Your Type?

Software systems are all around us. In the car, microwave machine, washing machine, traffic lights, bank, Internet, and just about every place we go to. The big question is how different are these software systems from one another?

Some software systems mission is to store data so other systems can retrieve it and process it. The Internet and a complex database cluster system are two examples. Other systems process data and provide results such as credit card processing systems and airline reservation systems. A third software system is one embedded in some control logic on an appliance like a microwave program or washing machine, and the list goes on...

We have heard of the terms pervasive computing and pervasive networking. They refer to distributed computing elements connected via a complex communication network allowing tight integration into our lives. An example would be a network of sensors communicating with one another and a number of management nodes.

Can we define a new type of software system called the pervasive software system? One which is deployed on a large number of computational devices across a complex network, each device performing a custom computational task - dependent on the devices location and mission, which could be time dependent - and sending the results to a larger "master" computer.

Note the difference between the pervasive computing and pervasive software is that in a pervasive computing environment the various nodes are dispersed, but each has a fixed computing configuration - fixed hardware and software. The pervasive software system on the other hand is a software system broken into pieces each running remotely on its own pervasive computer, and these software pieces could be reconfigurable and dynamic according to where the pervasive computer is and what its mission at a particular point in time is ...