Open Source : Free to fish but how?
As with any open source software, JBoss, is at times poorly documented or not documented at all. It therefore requires a significant investment of time and effort to learn the intricacies of these applications. For, medium IT firms, who seek to reduce cost by moving to open source based architectures, there is always a resistance to purchasing commercial support, especially when the support comes with a price tag of a few thousand dollars. These firms, with smaller budgets, typically seek first mover advantages to offset the lack of resources which enable larger firms to reduce learning curves, and utilize economies of scale to move into newer technologies when their viability is better ensured. To meet such a goal, instance based support, is rarely provided as it is found to be uneconomical and unviable.
Conversely, firms promoting these newer open source technologies, seek a revenue stream that will enable them maintain nd promote the acceptance of the technology and provide for an adequate return. A visit to the forums created to support JBoss, provide one such example. Individuals seeking help here are typically drawn from these smaller firms. They are faced with tight deadlines to execute a solution using ingrdient technologies that provide scant information. The information available is typically an example demonstrating a particular scenario. However, as with most things in business, the example is usually a little different from the example. This inevitably leads to frustration with open source in general and with individual products in particular.
It appears therefore, that a need clearly exists in the market for instance based support that is able to meet the needs of this small segment. Ironically it is this small segment of first movers that will determine the eventual success or demise of the product by the buzz (positive or negative) that they create.
(c) 2004 Vivek Pinto For more details please visit us at
Wonomi Technologies
Techniques for estimating software architecture changes
One of the most difficult challenges a project manager faces is determining the impact of a change when a project has already commenced. While plans by themselves involve a lot of estimation and are expected to change, individual performance is quite often measured by the success of a plan. Therefore besides the lack of certainty in the amount of time it can take to execute simple tasks, a project manager also needs to take into account the fact that estimates may be hedged to allow for an individuals level of risk averseness. This additional factor can obfuscate the clarity a manager has into the drivers of the project's timeline.
What compounds the problem is the fact that architectural changes involve modifications to multiple components or the infrastructure of the project itself. This can result in rework, changes in scope and changes in complexity to multiple components. The interaction of these components makes the problem of identifying the impact of changes very difficult. Furthermore, since a lot of the changes can be very technical in nature estimating the true implication of the changes can be very difficult.
There are three major ways that we have used successfully to be able to estimate software architecture changes.
1 - Estimate what you now know.
This method focuses on what is known and controllable and relegates most other issues to the unknown bucket. The impact of the change for the known sphere is the estimated with a set of pre-compiled metrics. The unknown bucket is then sub-categorized and estimated with proprietary techniques.
2 - Estimate afresh and determine the deltas
This technique begins the estimation process from scratch. The project manager creates a plan as if the project was starting anew. This estimate is then compared to the estimate of the original plan to determine where the changes occurred at. Any dependencies or reuse potential that have not been accounted for are used as buffer. While this is, in our opinion, the least reliable of the three methods, we have found that clients prefer this approach to the others.
3 - Use a scenario based approach
This technique requires the use of a whole new way of looking at a project. A project is no longer viewed as a group of related tasks, timelines and resources but rather as a set of scenarios. Each scenario is the decomposed into an intermediate set of scenarios and so on. Effectively, a project manager is moving from outcomes to inputs, instead of the traditional approach of looking at a set of inputs and determining the outcome. This techniques takes a lot longer primarily because its novelty implies that individuals using it need to go through a learning and experience curve before being able to use it. However, upper management finds this tool to be the most useful in providing visibility and the real options available to them in making decisions.
Estimating architecture changes therefore can be a daunting task but not one that cannot be resolved. The above three methods have been used successfully to deliver value to some of the largest firms in corporate America.
Bibliography
- [URL=http://www.cs.umd.edu/~basili/ICSE99.daniil.pdf]
Software architecture classification for estimating the
cost of COTS integration. Yakimovich et al[/url] - [url=http://www.win.tue.nl/oas/architecting/aimes/papers/Scenario-Based%20SWA%20Evaluation%20Methods.pdf]
Scenario-Based Software Architecture
Evaluation Methods: An Overview[/url] - [url=http://www.cs.ucl.ac.uk/staff/r.bahsoon/BahsoonAbstract.pdf]
Boehm, B., Sullivan, K. J.: Software Economics: A
Roadmap. In: Finkelstein, A. (ed.): The Future of Software
Engineering (2000)[/url] - [url= http://www.cs.rug.nl/~bosch/papers/SAAModifiability.pdf]
Analyzing Software Architectures for Modifiability.
PerOlof Bengtsson et al.[/url]
(c) 2004 Vivek Pinto For more details please visit us at Wonomi Technologies
