Regarding the WBS of an integration project of migrating an app from a platform to another (no hardware procurement involved), say I decomposed the project as follows: The first level is the project name. The second level is the development life cycle: 1.1 Requirement 1.2 Assessment (to determine dev(app team) and platform(arch/eng team) adaptation for a smooth migration 1.3 Architecture 1.4 Migration 1.5 Transition Ex of the subsequent level of deliverables for example for Requirement work package are: 1.1.1 Functional and non-functional requirements 1.1.2 Compliance requirements (Monitoring&Security requirements) 1.1.3 Transition requirements
Can you give an example of acceptance criteria for the work packages (say 1.1.1 or 1.1.2 )
I thought that when I'm gathering the requirement lists which will specify values for future test execution (ex post-migration), they cannot be used as acceptance criteria for the work package. However, I thought that Architect SME doing his inspection and verifying the completeness and correctness of data would be a better acceptance criterion. That being said, I'm afraid that would be leading to subjective interpretation or bad surprises later on...
What do you think? what did I miss? how can I ensure that the above interim deliverables are accepted?
Very interesting input. Thanks, Keith.
One thing is unfortunately we don't have all the exact documentation as we would love to and you probably know that in some cases, such apps were in the hand of consultants who left and no one knows all details. so it is a kind of challenge at the same time and reverse eng.
Although you may not have the original documentation, you don't necessarily have to reverse engineer it either.
At the end of your project, hopefully you will have some way to say the app works. How do you do that? You define what "it works" means to you.
In a gig working a very large digital transformation project of a configuration management system, some of the old systems were so archaic nobody really knew how they worked. Instead we had to devise a number of business scenarios (functions) to test such as processes for various change types. We didn't have network diagrams of how the old systems pass data (logical architecture), but we had to confirm that the data used on various applications came from the correct source.
This is similar to if you work in an enterprise level integration department and you are implementing new COTS software. The documentation is proprietary and you can't get it. The software has far more applications than you need. In that case you are not ensuring all the software works, but rather only the parts you need to use.
When you are working with an existing product, you don't necessarily have to verify all the requirements, test out all the functions, or even know how it all works. You do however have to validate that you know what requirements and functionality you care about, so that it will perform as expected when you buy off on the deliverable.
...
1 reply by Soha Karjawally
Jun 15, 2020 12:55 PM
Soha Karjawally
...
Keith,
This is exactly what I am having today. multiple apps working somehow and interlinked somehow and in one PROD env (missing test env or any other one)
What I am trying to find at this point, is how to make it work if I move it = looking at the critical dependencies to build it in another env to see if it could work :)
So far I found multiple scripts, connections to other apps. one of the things that is still complicated is the logical sequence because as you know you need to prioritize which one to move first and which ones are the dependant...
Your example is interesting: "Instead we had to devise a number of business scenarios (functions) to test such as processes for various change types. We didn't have network diagrams of how the old systems pass data (logical architecture), but we had to confirm that the data used on various applications came from the correct source. " could you elaborate a little bit more?
= how do you do to devise the business scenarios (functions)? is the analyst on the app who helped on that ? was any prioritization done?
Although you may not have the original documentation, you don't necessarily have to reverse engineer it either.
At the end of your project, hopefully you will have some way to say the app works. How do you do that? You define what "it works" means to you.
In a gig working a very large digital transformation project of a configuration management system, some of the old systems were so archaic nobody really knew how they worked. Instead we had to devise a number of business scenarios (functions) to test such as processes for various change types. We didn't have network diagrams of how the old systems pass data (logical architecture), but we had to confirm that the data used on various applications came from the correct source.
This is similar to if you work in an enterprise level integration department and you are implementing new COTS software. The documentation is proprietary and you can't get it. The software has far more applications than you need. In that case you are not ensuring all the software works, but rather only the parts you need to use.
When you are working with an existing product, you don't necessarily have to verify all the requirements, test out all the functions, or even know how it all works. You do however have to validate that you know what requirements and functionality you care about, so that it will perform as expected when you buy off on the deliverable.
Keith,
This is exactly what I am having today. multiple apps working somehow and interlinked somehow and in one PROD env (missing test env or any other one)
What I am trying to find at this point, is how to make it work if I move it = looking at the critical dependencies to build it in another env to see if it could work :)
So far I found multiple scripts, connections to other apps. one of the things that is still complicated is the logical sequence because as you know you need to prioritize which one to move first and which ones are the dependant...
Your example is interesting: "Instead we had to devise a number of business scenarios (functions) to test such as processes for various change types. We didn't have network diagrams of how the old systems pass data (logical architecture), but we had to confirm that the data used on various applications came from the correct source. " could you elaborate a little bit more?
= how do you do to devise the business scenarios (functions)? is the analyst on the app who helped on that ? was any prioritization done?
Thanks!!
...
1 reply by Keith Novak
Jun 15, 2020 7:08 PM
Keith Novak
...
Soha,
The developers did compile some business scenarios/use cases based on existing documented processes using the legacy tools. In our case they were primarily different change processes for managing product data. The problem was, the developers had no experience using many change processes and their ways of storing and managing the data didn't fit the needs of the end users at all. I spent a lot of time with end users to develop specific use cases for different teams using the software so that we could validate their specific needs were met rather than just some generic users. That also involved examining the needs throughout the value stream. For example, an engineer could find a very simple way to use the software for their design definition needs, but they would put their data into fields that are not read by downstream manufacturing systems, so we had to consider all the users who consume various types of data.
There were a number of ways we prioritized the work. The first was raw data prior to any integration. Basically old paper forms became object-oriented data. That could be duplicated in a new environment before it was electronically linked to systems that use the data, and we had to ensure it all came across correctly before we switched the data authority from legacy to new systems.
Then as systems shared data between apps, we had to ensure that worked properly. We would start using our most common scenarios without any unique boundary conditions (The Happy Path as we called it), before we added unique complexities, and test those out sequentially.
Linking systems was generally a bottoms up approach, and we would try to integrate specific important "threads" of data rather than trying to integrate all threads at once to reduce complexity. We also had to come up with ways to bring partial functionality online. For example before we linked engineering data to manufacturing systems, we could provide the manufacturing team printouts that could be used rather than depending on all the linkages between systems functioning correctly so they got all the same data correctly in their new systems.
In short, our prioritization was a combination of what functionality was most important, and where we could get some functionality without risking lots of unexpected downstream problems before moving on to the next layer of complexity.
This is exactly what I am having today. multiple apps working somehow and interlinked somehow and in one PROD env (missing test env or any other one)
What I am trying to find at this point, is how to make it work if I move it = looking at the critical dependencies to build it in another env to see if it could work :)
So far I found multiple scripts, connections to other apps. one of the things that is still complicated is the logical sequence because as you know you need to prioritize which one to move first and which ones are the dependant...
Your example is interesting: "Instead we had to devise a number of business scenarios (functions) to test such as processes for various change types. We didn't have network diagrams of how the old systems pass data (logical architecture), but we had to confirm that the data used on various applications came from the correct source. " could you elaborate a little bit more?
= how do you do to devise the business scenarios (functions)? is the analyst on the app who helped on that ? was any prioritization done?
Thanks!!
Soha,
The developers did compile some business scenarios/use cases based on existing documented processes using the legacy tools. In our case they were primarily different change processes for managing product data. The problem was, the developers had no experience using many change processes and their ways of storing and managing the data didn't fit the needs of the end users at all. I spent a lot of time with end users to develop specific use cases for different teams using the software so that we could validate their specific needs were met rather than just some generic users. That also involved examining the needs throughout the value stream. For example, an engineer could find a very simple way to use the software for their design definition needs, but they would put their data into fields that are not read by downstream manufacturing systems, so we had to consider all the users who consume various types of data.
There were a number of ways we prioritized the work. The first was raw data prior to any integration. Basically old paper forms became object-oriented data. That could be duplicated in a new environment before it was electronically linked to systems that use the data, and we had to ensure it all came across correctly before we switched the data authority from legacy to new systems.
Then as systems shared data between apps, we had to ensure that worked properly. We would start using our most common scenarios without any unique boundary conditions (The Happy Path as we called it), before we added unique complexities, and test those out sequentially.
Linking systems was generally a bottoms up approach, and we would try to integrate specific important "threads" of data rather than trying to integrate all threads at once to reduce complexity. We also had to come up with ways to bring partial functionality online. For example before we linked engineering data to manufacturing systems, we could provide the manufacturing team printouts that could be used rather than depending on all the linkages between systems functioning correctly so they got all the same data correctly in their new systems.
In short, our prioritization was a combination of what functionality was most important, and where we could get some functionality without risking lots of unexpected downstream problems before moving on to the next layer of complexity.
...
1 reply by Soha Karjawally
Jun 15, 2020 10:06 PM
Soha Karjawally
...
Very much appreciated Keith! Thank you. let's see how things will evolve, I started finding the right stakeholders.
Soha,
The developers did compile some business scenarios/use cases based on existing documented processes using the legacy tools. In our case they were primarily different change processes for managing product data. The problem was, the developers had no experience using many change processes and their ways of storing and managing the data didn't fit the needs of the end users at all. I spent a lot of time with end users to develop specific use cases for different teams using the software so that we could validate their specific needs were met rather than just some generic users. That also involved examining the needs throughout the value stream. For example, an engineer could find a very simple way to use the software for their design definition needs, but they would put their data into fields that are not read by downstream manufacturing systems, so we had to consider all the users who consume various types of data.
There were a number of ways we prioritized the work. The first was raw data prior to any integration. Basically old paper forms became object-oriented data. That could be duplicated in a new environment before it was electronically linked to systems that use the data, and we had to ensure it all came across correctly before we switched the data authority from legacy to new systems.
Then as systems shared data between apps, we had to ensure that worked properly. We would start using our most common scenarios without any unique boundary conditions (The Happy Path as we called it), before we added unique complexities, and test those out sequentially.
Linking systems was generally a bottoms up approach, and we would try to integrate specific important "threads" of data rather than trying to integrate all threads at once to reduce complexity. We also had to come up with ways to bring partial functionality online. For example before we linked engineering data to manufacturing systems, we could provide the manufacturing team printouts that could be used rather than depending on all the linkages between systems functioning correctly so they got all the same data correctly in their new systems.
In short, our prioritization was a combination of what functionality was most important, and where we could get some functionality without risking lots of unexpected downstream problems before moving on to the next layer of complexity.
Very much appreciated Keith! Thank you. let's see how things will evolve, I started finding the right stakeholders.
