Tags
agile, analysis, best practice, business sponsors, conflict, data, data design, design, event, flowchart, functional decomposition, iterative, jackson, lifecyle, management, model choices, modeling, organization, perspective, priority issues, priority sequence, process, project charter, punch list, requirements, scope, SDLC, state, state transition, state transition diagrams, swim lane, technology, use case, visual
Could there be such a thing as a Testing Centric Life Cycle?
What would it have to look like to be Testing Centric? Wouldn’t we have to ask questions of each Deliverable to prove that it somehow supports what we believe our end goal to be not knowing all that they might be in the earlier stages? How would we construct these questions to ask of our Life Cycle Deliverables so that the answers would be good indications of our reasons to proceed?
Imaging if we were to create a Statement of Work for a project intended to build a new business application for an organization. If we wanted to TEST this SOW, what questions would we ask of it that could help us understand that its content was supportive of our end goals?
It might be possible for us to start asking questions about the Scope described in this Statement of Work:
- Does the scope indicate where our input data will be coming from?
- Does the scope explain how our product / application will affect the data?
- Does it show how the affected data will provide additional value over our inputs?
- Can we tell from the scope what external events and/or operators our application will have to respond to?
- Can we predict how we will have to maintain the data collected, modified, reported, used to accomplish the intended functions of our product / application?
- Is it Orthogonal? (Not a trick question; read other portions of this blog!)
If we accept the notion that each Deliverable in the path of our project plan must answer questions that relate to its completeness and its alignment with previous deliverables, then the Test Centric Life Cycle Model can be strongly directed by the premise behind Orthogonality:
- All modeling perspectives MUST be reflected in all Other Modeling perspectives so that when each component and its related model components are removed, nothing remains in any of the models
- Model perspectives should address the following disciplines or viewpoints:
- Event Diagram
- Process Diagram
- Data Model Diagram
- State Transition Diagram
Do you think, dear reader, that this thread of discussion should continue or be dropped?
Please Respond / Comment on this post OR Reply to me at whendoyoustoplooking@gmail.com
Thanx, bgbg
