Now that we’ve spent some time dwelling on the challenges faced by teams producing SOA solutions, I’d like to tell you a little bit about my AgileSOA process, which we’ve been using for many years to deliver SOA solutions for our customers. I’ll do so by describing each of the key aspects that I think have made it work for us.
Specialized Subteams in the Iteration Workflow
Using the RUP as a framework, AgileSOA has a specialization of roles in the project team. These are organized into subteams, each having well-defined work products that they are responsible for, and each having their place in the overall iteration workflow. In this way, the “workers” in the team are divided up quite sensibly(if not a bit predictably) as follows:
AgileSOA iterations across time boxes
but also for producing developer tests that will live with the code to be used for regression testing.
The SOA solution is delivered incrementally using iterations, with each iteration planned as four end-to-end time boxes, with each time box being used to focus the efforts of the four subteams just described earlier. In practice this looks a bit like what is described in . The net result is that, in any given time box, each of your subteams will be working on a different iteration–each being one ahead of the other in the sequence of requirements, design, implementation, and test.
This organizes the work done as part of each of the project iterations. Note that not all the work is organized this way. As an example, you may have business modellers producing models that provide a useful business context for the solution in terms of process models and information models. This would be done in advance of your iterations. Also you will have people responsible for setting up and executing the performance and acceptance tests of the solution. Most of this happens after your iterations have executed because they need to test the entire solution(all increments)that will be released to the end users.
Structuring Requirements for Iterative Delivery
Requirements are crucial to our development process as they are used to scope out the work that the overall project life cycle needs to deliver but also to divide this work into iterations.
We use two mechanisms for scoping requirements for our SOA projects:
Use cases contain flows
So why do I think use cases make such ideal units for our requirements specifications?
Let’s look at two useful properties:
These two properties make use cases the ideal format for our requirements specifications. First, the fact that use cases don’t overlap in their coverage of the systems scenarios means that they make good units for planning solution increments. You know that by allocating the full set of in-scope use cases to iterations you will have covered all the required functionality without any duplicated effort across iterations. Second, the fact that we can break up use cases into smaller parts means that we reduce the problem of having “fat” specifications that don’t fit into a single iteration. It is possible to assign a use case’s basic flow to an iteration, and then assign groups of its alternative flows to later iterations.
Use case plays planning example
I define a use case play as follows. Each iteration that a use case is assigned to contains a play of that use case. That is, a use case play is one or more flows of a use case assigned to an iteration for delivery. For planning purposes, it is normally a good idea to split a use case up into multiple use case plays to manage the risk associated with delivering the use case. For an idea as to what this looks like in practice, shows a set of use case plays from an example iteration planning work product. This example shows seven use case plays across two iterations. To understand how this works, we note the following:
Specifications That Are Rich but Get to the Point
One of the popularist aspects to agile methods is the disdain with which they treat lengthy, verbose specificaton documents. And quite rightly so! Vague, ambiguous specifications defeat the purpose of putting together specifications. Worse still is when the specifications attempt to make up for quality with quantity!
Specifications need to be concise, clear, and unambiguous for them to have value. But also they must be easy to change–and this would suggest that they are no more “wordy” than they need to be. In the AgileSOA process, the focus is on a key set of work products that attempt to achieve clarity and unambiguity while being as concise as possible. This is achieved by making the semantics of the specifications as rich as possible so that much can be said with little effort.
For SOA solutions, the key thing that we need to specify is the individual service contracts that are consumed by the various service consumers, and provided by the service providers. shows a set of work products that contributes to our goal of creating quality service contracts:
Key AgileSOA specification work products
Requirements and design specifications
Let’s briefly consider these work products in the context of the subteams working in our iterations:
Specifications Structured for Change
Not only must the specifications be concise in order to make them easy to change, but they must also be structured to make changes easier. In order to do this, for any given change we have to achieve the following:
Some examples of this structuring follow:
Workflow Tooling to Help Track What’s Going On
Most of our projects consist of hundreds of individual use case flows. According to the process, there are four high-level pieces of work to do for each of these use case flows–requirements, design, implementation, and test.
That means that, for a 200–use case flow project, there are at least 800 individual pieces of work that need to be done. As there are sequencing dependencies between these 800 individual work items(requirements needs to be done before design, design before implementation, and implementation before test), it’s crucial for a project manager to know what the status is of each of these work items so that any bottlenecks or other planning problems can be spotted. We use workflow tooling to help out here. This has two main benefits:
Handle Change While Avoiding Unnecessary Change
Being agile is about being able to handle change well when required. However, we still want to avoid unnecessary change as much as is possible as it causes unnecessary expense.Two types of change exist:
Now the first kind of change is unavoidable in our iterative development world. And this isn’t a bad thing. Each iteration will be adding new functionality to what was produced by the previous iteration. However, we want to avoid as much of the second type of change as possible. I’ll subdivide this modification type of change into
We avoid unnecessary modifications to the requirements as follows:
Risk Mitigation on Integration Projects
With any software development project there are the risks that the solution might not do what the end users want, that it might not do it in a way that suits their pattern of working, or that the technology that you’re using to build the solution doesn’t really suit the solution. But integration projects bring along a whole new bag of risks.
To provide a few examples:
For our projects we try and achieve two things:
For the first of these we use the previously mentioned external systems model. In this we capture a concrete view of the interfaces that we need to interact with and the information that the system holds. This will ensure that the way that we plan on integrating with the solution will work and also that it can be described to the developers.
Second, before we try and design against these interfaces, we write tests that verify that the system works the way we think it works. It doesn’t help to put in design effort against an interface specification that is incorrect. A large amount of the risk is taken out of integration projects by creating interface verification tests early on in the project.
Usage of SOA Design Patterns to Ensure Extensibility and Flexibility
The success of your SOA solutions over time will be measured by how well these solutions handle change. How easy is it to add new functionality to the solution?What impact does this have on other solutions? Does change cause a reduction in the quality of service offered by your solutions? Does it compromise their behavior?
The key to ensuring this success is good design. And one of the keys to good design is to have a good set of design patterns that are consistently used across your solutions.
An example list of these is provided in .
Estimation and Planning
To make our iteration planning effective, we ideally need an estimate for each of the work items on the project. By our previous calculation, a project of 200 use case flows will have an estimated 800 work items. We need a way to quickly get useful estimates for each of these 800 work items! The procedure we follow is a simple one:
Example of SOA design patterns
Estimates for iteration work items
Agile Testing Related Interview Questions
|ETL Testing Interview Questions||Manual Testing Interview Questions|
|Selenium Interview Questions||Database Testing Interview Questions|
|Automation Testing Interview Questions||Software testing Interview Questions|
|Performance Testing Interview Questions||Embedded Testing Interview Questions|
|A/B Testing Interview Questions||Hadoop Testing Interview Questions|
Agile Testing Tutorial
Old-school Development And Testing
Agile Development And Testing
From Waterfall To Evolutionary Development And Test
How To Test A System That Is Never Finished
Implementing An Agile Testing Approach
Agile Testing In A Remote Or Virtual Desktop Environment
Testing A Derivatives Trading System In An Uncooperative Environment
A Mixed Approach To System Development And Testing: Parallel Agile And Waterfall Approach Streams Within A Single Project
Agile Migration And Testing Of A Large-scale Financial System
Agile Testing With Mock Objects: A Cast-based Approach
Agile Testing – Learning From Your Own Mistakes
Agile: The Emperor’s New Test Plan?
The Power Of Continuous Integration Builds And Agile Deve- Lopment
The Payoffs And Perils Of Offshored Agile Projects
The Basic Rules Of Quality And Management Still Apply To Agile
Test-infecting A Development Team
Agile Success Through Test Automation: An Extreme Approach
Talking, Saying, And Listening: Communication In Agile Teams
Very-small-scale Agile Development And Testing Of A Wiki
Agile Special Tactics: Soa Projects
The Agile Test-driven Methodology Experiment
When Is A Scrum Not A Scrum?
Analysis Of The Case Studies
My Agile Process
The Roll-out And Adoption Of My Agile Process
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.