New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by David West on Feb 17, 2009
Dean Leffingwell, author of Scaling Software Agility and Chief Product Methodologist at Rally, has concluded that Use Cases can be a valuable tool to model requirements for a large-scale Lean/Agile Project. Use cases are not commonly encountered in Lean/Agile (especially XP and Scrum), where stories are the requirements gathering tool of choice, but Leffingwell notes:
... when building systems of scale, there is no tool quite so powerful as a use case for exploring the interactions amongst users, the systems, and the subsystems of the solution. Moreover, the use-case technique is the best way I know to help identify all the alternate scenarios that trip us so often when it comes to system level quality and readiness.
In both his book and blog, Leffingwell has developed a set of models and meta-models to assist developers in the application of Lean and Agile practices to large scale projects. The absence of any mention of Use Cases in his 'Agile Enterprise Requirements Information Model' was called to his attention by a reader and former colleague. Leffingwell attributed the omission of use cases to two primary factors: their close association with RUP and not Agile coupled with his own possible pro-RUP bias; and, several examples of advise to avoid use cases as "too detailed and not understandable by customers."
Ultimately, Leffingwell came to the conclusion, "While use cases are not a replacement for the user story in agile development, they can be of tremendous benefit in elaborating, analyzing and better understanding the intended behavior of complex systems." Accordingly, use cases have been added to Leffingwell's model as an optional means for elaborating backlog items.
- Use cases are optional but can add tremendous value to understanding behavior when the system is complex;
- Use cases help teams understand all the 'what if' scenarios that ultimately affect system quality;
- Use cases can be used to understand where new stories are likely to be found;
- and, Use cases can provide a logical way to sequence value delivery in big systems, story by story.
It is important to note that the rationale for including Use Cases in an Agile model is primarily driven by the need to address issues of scale and that use cases remain an optional requirements elaboration tool.
As of this writing, there has been no response to Leffingwell's modification of his model. It will be interesting to see if he has addressed his reader's concerns and if other users of his model find this addition useful.
Case Study: IBM's Agile Transformation
A practical guide to choosing the right agile tools
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.
I've almost always used some form of use case modeling on my projects. And I consider my approach to development very agile. I use TDD, iterative development, continuous integration, burn down charts, etc.
I just find user stories alone do not provide enough context for structure. I frequently break down and use cases into specific user stories selected to be estimated within an iteration.
That being said, there is a lot of bad material out there talking about how to build use cases. IMHO the material written by Alastair Cockburn is a must if you are going to consider agile in any way. I talk more about this on my post @
agileconsulting.blogspot.com/2008/02/can-use-ca...
jeffanderson
agileconsulting.blogspot.com
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
1 comment
Watch Thread Reply