Monday, May 08, 2006
Rapid Software Development
When I started this blog I was going to be working for these guys CYGNUS but as luck would have it they decided to concentrate their business in Japan and so I am back running my own company.
Thursday, April 27, 2006
Sunday, April 23, 2006
Tuesday, April 18, 2006
Friday, April 14, 2006
Agile in a Wiki
There is some useful background information on Agile Software Development. You can find that HERE at Wikipedia. There are some good links for further reading too.
Monday, April 10, 2006
The Difference Between Effort and Duration
It is an "old chestnut" but here goes:
Effort is the number of hours work it is estimated are needed to complete a task. Duration is the period over which this will be spread.
Effort is the number of hours work it is estimated are needed to complete a task. Duration is the period over which this will be spread.
Friday, April 07, 2006
Things Move On
Just to let you know that I'll be concentrating on the Farnborough Projects and its associated Blogs for a while. If you want to know anything about the subject then please contact us at Farnborough Projects or one of the many Networking sites we frequent. I'll try and put some more stuff up here as and when I can.
Saturday, January 07, 2006
Blue Genet - Rapid Application Development Suite
About Blue Genet
Blue Genet is a complete, integrated set of tools, methodologies, and repositories that we use to create and manage the full lifecycle of enterprise applications. Developed by the Cygnus team it provides the framework for our unique visualisation process and the necessary tool to manage today’s enterprise application development requirements.
Working visually we develop enterprise software applications rapidly in a technology neutral environment allowing us to produce the application in whatever language is required.
The benefits of this approach include substantial savings in time and cost allowing us to develop applications in a fraction of the time it would take using conventional methods.
Objectives of Blue Genet
Blue Genet provides fundamental improvements in key aspects of enterprise software application creation and usage with focus on the following objectives:
Significantly reduce the time to implement ideas into deployed solutions
Dramatically improve the overall costs associated with creation and deployment of solutions
Ongoing reductions in the risks associated with application development so that business managers can use information technology with significantly greater confidence levels
Facilitates using and reusing all aspects of software. (Knowledge in action)
Aids visualisation of and insights to business applications bringing them closer to the end-user.
The Gaps and Structures:
Two broad gaps exist between the business manager who wishes to harness technologies to their benefit and the impressive array of technologies that are emerging in the background:
Articulating business requirements in natural business terminologies in a structured manner
Translating those needs into implementation architectures leveraging the technologies of choice.
Blue Genet facilitates the articulation of business objectives in structured ways. Some of these include, for example:
Models of domains including domain objects, products and services, processes, events, policies, business rules, best practices etc
Models of enterprise structures, human, system, knowledge, and plant/equipment resources
Models of knowledge, costs, quality, risks and other key constructs.
Blue Genet assists describing the enterprise application architectures from the perspective of application needs, i.e. focus on the objectives of the architecture rather than the specific manifestation of these in any particular technologies. The descriptions would centre around functional and non-functional aspects, e.g. security, availability, scalability, deployment patterns rather than the specific of how these are implemented in a particular technology.
Patterns and Repository:
Models of best practice and other development knowledge can be articulated using a repository of data, patterns, and methods of creation.
Blue Genet provides mechanisms to model and construct different kinds of knowledge repositories including reference data, application patterns, enterprise patterns, architecture patterns etc.
Blue Genet also provides a framework for articulating generative patterns that can create similar applications, specifications, architectures etc. for the target parameter in question.
This gives the ability to create and maintain aspects of applications, from requirement to maintenance, and reengineering from known and proven patterns.
Patterns of Enterprise Applications
In practice a business application is often an interplay of three key elements:
Domain Models
Enterprise Models
Application Models.
The application models can be classified in many different ways. supplies models for some frequently occurring applications, for example:
Business process management
Integration
Messaging
Classical business applications
Batch processing.
A typical business application uses a combination of these different aspects in an interactive environment.
Blue Genet enables the articulation and modelling of these types of applications in one coherent framework.
As these applications are described their implementation architectures can be selected, designed, or generated using the tool set.
The creation of these applications can work at several different levels of abstraction.
Models of Events and Actions
While an overall application context in an enterprise application can be quite complex abstracts these in a simpler model based on, among others, the notions of
Event triggers
Protocols
Application architectures
Processing elements
Deployment contexts
Locale contexts.
These models enable the linking of business applications and application architectures to specific environments of technologies and deployment.
Events may occur at different locations based on rules. The action to process the event is triggered via protocols and is executed in the application architecture in a deployment context.
Patterns are articulated using these constructs and can generate specific implementation models based on scriptable pattern programs.
Global Software
While not mandatory, the application patterns are usually created ground up for integration, time-zone and locale sensitivities and collaborative frameworks.
This enables articulation and harnessing of knowledge across interactive teams that are potentially distributed globally.
The Blue Genet approach can also facilitate interaction across teams that speak different languages.
Blue Genet delivers outstanding productivity and superior quality. Based on our knowledge, experience and know-how in enterprise software development we regularly deliver high quality enterprise applications globally improving ROI by reducing costs, and time to develop through our technology.
About Cygnus Europe
Cygnus Europe is the European office of Cygnus Software. With offices in India, Japan, USA and Singapore we provide cost effective software products and solutions with or without financial analytics for our customers across the globe.
For further information please contact:
Cygnus Europe Limited
No. 1 Poultry, London, EC2R 8JR, United Kingdom
Voice: +44-20-7643-2209,
Fax: +44-20-7643-2201
E-mail: info@cygnuseurope.com
URL: http://www.cygnuseurope.com
A Resource and Methodology for Designing Requirements
This is a paper exploring A Resource & Methodology for Designing Requirements.
Pooja Wandile, Ranjan Kumar
Cygnus Software, Pune, India poojaw@cygnus.stpp.soft.net, ranjan@cygnus.stpp.soft.net
Abstract
Business applications involve requirement gathering from diverse sources. The business users are usually unfamiliar with the techniques and methodologies of requirement engineering. This leads to frequent reinvention of the wheel and is usually not the optimal solution for the problem at hand. On the other hand he requirement engineering methodologies, in an attempt to be generic, are often abstract and difficult to put in practice. In this paper we propose a methodology for gathering requirements and a framework for a shared, community resource that can facilitate designing requirements, and the standardization process in the practice.
1. Introduction
“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements… No other part of the work so cripples the resulting system if done wrong. No other part is as difficult to rectify later” (Brooks 1987)
Business software remains an expensive proposition for most companies today. The industry has responded by examining the potential for standardization and reuse among other things. In this paper we examine the prevalent approaches briefly and relate the problems encountered in practice. We then present the case of a Requirement Design Resource to facilitate effective design of requirements. Finally, we propose the outline of a methodology that has been effective in our experience of developing business applications. We believe that a wider, community resource may go a considerable way in making software accessible, effective, and less expensive.
2. Prevalent Methods
Information Technology is far too strategic a tool today and its use has been widespread in business. This has been ever increasing and it is defining new approaches to business. Software analysts, designers, and developers are, therefore, called upon to address diverse business requirements.
The prevalent methodologies for designing requirements are, understandably, generic. We look at some of them here.
2.1 Software Engineering
A fairly widespread process of gathering requirements follows the following steps, viz.
Requirements elicitation
Requirements analysis
Requirements negotiation
Requirements documentation
Many techniques have been suggested to assist in different stages, e.g. brainstorming, interviews, workshops, and others.
2.2 The UML Approach
Another well-known process – Rational Unified Process - from Rational Corporation includes the following steps related to business modeling, viz.
· Assess business status
· Describe current business
· Identify business processes
· Refine business process definitions
· Define business process realizations
· Refine roles and responsibilities
· Explore process automation
· Develop a domain model
In this approach the requirements are illustrated using the Unified Modeling Language – UML – diagrams like Use Case Diagrams, Class Diagrams and others.
3. Experiences and Ideas
3.1 Experiences
It would be clear that the representative approaches mentioned above are likely to lead to diverse designs of requirements as the suggested steps are generic and they depend on who designs the requirements and how. Techniques like interviews, brainstorming, workshops may all arrive at different designs.
At the same time insights into effective designs for various needs have also been emerging. It is useful,
therefore, that the prevalent approaches take advantage of these experiences and arrive at standardized designs where possible.
3.2 Problems
Christel and Kang (1992) have presented the different problems encountered during the design of requirement, viz.
Problems of scope
· The boundary of the system is ill defined
· Unnecessary design information may be given
Problems of understanding
Users have incomplete understanding of their needs
Users have poor understanding of computer capabilities and limitations
Analysts have poor knowledge of the problem domain
User and analyst speak different languages
Ease of omitting “obvious” information
Conflicting views of different users
Requirements are often vague and untestable
Problems of volatility
· requirements evolve over time
3.3 Requirement Reuse
Cybulski, J. (1998) has presented a survey of the various requirement reuse approaches and also suggested reuse opportunities in various areas, viz.
Elaboration of Needs and Objectives
· Enterprise Model
Requirements Acquisition
· Information Sources
· Elicitation Skills and Resources
· Document Templates and Standards
· Reuse Across Requirements Documents
· Reuse Within Requirements Documents
· Raw Source Information
· Domain Concepts
· Text Phrases
Requirements Specification and Modelling
· Analytic Techniques
· Analytic Processes
· Analysis By-Products
· Refinement Artifacts
· Adaptation and Integration Processes
· Comments and Annotations
Requirements Model
· Analysis and Specification Patterns
· Generation and Evaluation of Alternatives
· Restricting Problem Domain
· Restricting Solution Domain
· Evaluation and Selection
Requirements Verification and Validation
· Verification Rules
· Validation Trace
4. The Case for a Requirement Design
Resource
Although software is a pervasive tool it is also considered an expensive resource to build, deploy, and maintain. Much of the cost can be traced to the problems related to designing the requirements.
There have been advances and widespread acceptance of various software component technologies over the years. These include, e.g. CORBA, EJB, DCOM and other technologies. Consequently, several component libraries are available for reuse. This has significantly facilitated application development and has reduced the development cycle.
A similar success is not visible in the designing of requirements. There are few standards and the methodologies depend substantially on the specific person involved in design. The patterns used by experienced professionals remain largely unarticulated. The business users, on the other hand, have to participate increasingly in designing these requirements. Thus, the field is developing into collaboration across diverse players. The varied experiences and capabilities across the different players necessitate the need for a collaboration resource.
A scenario like this is better facilitated when experiences of the past, best practices, and designs are made available to the requirement designers. While there has been a substantial development in the design patterns the patterns of requirement have not been articulated as much as the insights accumulated over the years would suggest. For instance, there are several design alternatives regarding design of security in different business applications. However, inexperienced users end up specifying custom requirements that one of the well- known alternatives would have met in the first place. Again, as the audiences for requirement patterns are far more diverse these patterns would preferably require articulation in more diverse concepts, terminologies and notation systems than those articulated by Gamma et al
(1995). It is equally important that a certain degree of interoperability across different notation systems is developed.
Different groups of requirement designers, especially the end-users, are then in a position to assemble their requirements using the requirement patterns articulated in terminologies and notations familiar to them.
Requirements may be classified in terms of the following, viz.
· Generic functional requirements
· Domain-specific functional requirements
· Non-functional requirements
Requirement patterns are useful across all these. Among the generic functional requirements some frequently encountered patterns include, e.g.
· Application Requirements
· Security
· Audit
· Assistance
· Training
· Data and Event Integration
· Business Requirements
· Enterprise Models
· Business Processes
· Business Policies
· Operational Requirements
· Configuration
· Control
· Monitoring
· Troubleshooting Aids
· Environment Requirements
· Access and span of authority
· Presentation, computing, network devices and resources
The domain-specific functional requirements are more complex. However, frameworks have been suggested in various domains to articulate their needs in standard ways. These often include, e.g.
· Business objects
· Business events
· Event-action maps
· Analytics and computation
· Business processes
· Business roles
· Business domain principles and rules
Among the non-functional requirements the patterns often may be classified among, e.g.
· Portability
· Reliability
· Usability
· Maintainability
· Scalability
· Auditability
· Availability
Often assemblies and subassemblies of requirement patterns can be created from constituent requirements of finer granularity. These can be used as templates of application requirements and then elaborated further to include the specific requirements at hand.
It would be necessary to develop pattern notations for articulating and for developing catalogs of requirement design patterns. This standardization would then form the basis of a community resource that can be used to collect and maintain insights as they are discovered.
Finally, it would be important this resource actually facilitates decision-making. That means that relative costs in terms of money, effort, skills, and resources should become clear as different requirement designs are selected.
5. Methodology
We propose that the requirement gathering process should evolve into a systematic process of requirement design.
· Requirements are articulated as far as possible by identifying the key design elements available in the proposed Requirement Design Resource
· Where assembly of requirement patterns can be used as templates they may be selected as the first basis of the requirements
· Where assemblies are not appropriate the specific requirement elements are selected and corresponding patterns are then selected
· The selected alternatives define the context of requirements in terms of, for instance, enterprise entities, resources, business processes, policies and so on
· Subsequently, any specific requirements not covered within the scope
· The requirement context is then refined to include the additional specific requirements
6. In Practice
We have developed in-house resources based on the web on the lines outlined in this paper. Our experience has been that for specific classes of projects we are able to select requirements and match them with corresponding design and implementation elements. Thus, the requirement patterns directly facilitate design and implementation patterns.
We have applied these patterns in banking and finance domains as well as in various e-business development. Our experience has been very positive. Such a resource being available at the community level has significant potential.
7. References
[1] Christel M. G. and Kang K. C. (1992): Issues in
Requirements Elicitation, Technical Report CMU/SEI-
92-TR-12 ESC-TR-92-012.
[2] Brooks, F. (1987): No silver bullet: essence and accidents of software engineering, Computer, Apr., 10-19
[3] Cybulski, J. (1998): "Patterns in Software Requirements Reuse." in AWRE’98. Deakin University, Geelong, p. Submitted.
[4] Rational Corporation, Rational Unified Process, 2000
[5] Gamma, E., R. Helm, R. Johnson, and J. Vlissides
(1995): Design Patterns: Elements of Reusable Object- Oriented Software. Readings, Massachusetts: Addison- Wesley.
Pooja Wandile, Ranjan Kumar
Cygnus Software, Pune, India poojaw@cygnus.stpp.soft.net, ranjan@cygnus.stpp.soft.net
Abstract
Business applications involve requirement gathering from diverse sources. The business users are usually unfamiliar with the techniques and methodologies of requirement engineering. This leads to frequent reinvention of the wheel and is usually not the optimal solution for the problem at hand. On the other hand he requirement engineering methodologies, in an attempt to be generic, are often abstract and difficult to put in practice. In this paper we propose a methodology for gathering requirements and a framework for a shared, community resource that can facilitate designing requirements, and the standardization process in the practice.
1. Introduction
“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements… No other part of the work so cripples the resulting system if done wrong. No other part is as difficult to rectify later” (Brooks 1987)
Business software remains an expensive proposition for most companies today. The industry has responded by examining the potential for standardization and reuse among other things. In this paper we examine the prevalent approaches briefly and relate the problems encountered in practice. We then present the case of a Requirement Design Resource to facilitate effective design of requirements. Finally, we propose the outline of a methodology that has been effective in our experience of developing business applications. We believe that a wider, community resource may go a considerable way in making software accessible, effective, and less expensive.
2. Prevalent Methods
Information Technology is far too strategic a tool today and its use has been widespread in business. This has been ever increasing and it is defining new approaches to business. Software analysts, designers, and developers are, therefore, called upon to address diverse business requirements.
The prevalent methodologies for designing requirements are, understandably, generic. We look at some of them here.
2.1 Software Engineering
A fairly widespread process of gathering requirements follows the following steps, viz.
Requirements elicitation
Requirements analysis
Requirements negotiation
Requirements documentation
Many techniques have been suggested to assist in different stages, e.g. brainstorming, interviews, workshops, and others.
2.2 The UML Approach
Another well-known process – Rational Unified Process - from Rational Corporation includes the following steps related to business modeling, viz.
· Assess business status
· Describe current business
· Identify business processes
· Refine business process definitions
· Define business process realizations
· Refine roles and responsibilities
· Explore process automation
· Develop a domain model
In this approach the requirements are illustrated using the Unified Modeling Language – UML – diagrams like Use Case Diagrams, Class Diagrams and others.
3. Experiences and Ideas
3.1 Experiences
It would be clear that the representative approaches mentioned above are likely to lead to diverse designs of requirements as the suggested steps are generic and they depend on who designs the requirements and how. Techniques like interviews, brainstorming, workshops may all arrive at different designs.
At the same time insights into effective designs for various needs have also been emerging. It is useful,
therefore, that the prevalent approaches take advantage of these experiences and arrive at standardized designs where possible.
3.2 Problems
Christel and Kang (1992) have presented the different problems encountered during the design of requirement, viz.
Problems of scope
· The boundary of the system is ill defined
· Unnecessary design information may be given
Problems of understanding
Users have incomplete understanding of their needs
Users have poor understanding of computer capabilities and limitations
Analysts have poor knowledge of the problem domain
User and analyst speak different languages
Ease of omitting “obvious” information
Conflicting views of different users
Requirements are often vague and untestable
Problems of volatility
· requirements evolve over time
3.3 Requirement Reuse
Cybulski, J. (1998) has presented a survey of the various requirement reuse approaches and also suggested reuse opportunities in various areas, viz.
Elaboration of Needs and Objectives
· Enterprise Model
Requirements Acquisition
· Information Sources
· Elicitation Skills and Resources
· Document Templates and Standards
· Reuse Across Requirements Documents
· Reuse Within Requirements Documents
· Raw Source Information
· Domain Concepts
· Text Phrases
Requirements Specification and Modelling
· Analytic Techniques
· Analytic Processes
· Analysis By-Products
· Refinement Artifacts
· Adaptation and Integration Processes
· Comments and Annotations
Requirements Model
· Analysis and Specification Patterns
· Generation and Evaluation of Alternatives
· Restricting Problem Domain
· Restricting Solution Domain
· Evaluation and Selection
Requirements Verification and Validation
· Verification Rules
· Validation Trace
4. The Case for a Requirement Design
Resource
Although software is a pervasive tool it is also considered an expensive resource to build, deploy, and maintain. Much of the cost can be traced to the problems related to designing the requirements.
There have been advances and widespread acceptance of various software component technologies over the years. These include, e.g. CORBA, EJB, DCOM and other technologies. Consequently, several component libraries are available for reuse. This has significantly facilitated application development and has reduced the development cycle.
A similar success is not visible in the designing of requirements. There are few standards and the methodologies depend substantially on the specific person involved in design. The patterns used by experienced professionals remain largely unarticulated. The business users, on the other hand, have to participate increasingly in designing these requirements. Thus, the field is developing into collaboration across diverse players. The varied experiences and capabilities across the different players necessitate the need for a collaboration resource.
A scenario like this is better facilitated when experiences of the past, best practices, and designs are made available to the requirement designers. While there has been a substantial development in the design patterns the patterns of requirement have not been articulated as much as the insights accumulated over the years would suggest. For instance, there are several design alternatives regarding design of security in different business applications. However, inexperienced users end up specifying custom requirements that one of the well- known alternatives would have met in the first place. Again, as the audiences for requirement patterns are far more diverse these patterns would preferably require articulation in more diverse concepts, terminologies and notation systems than those articulated by Gamma et al
(1995). It is equally important that a certain degree of interoperability across different notation systems is developed.
Different groups of requirement designers, especially the end-users, are then in a position to assemble their requirements using the requirement patterns articulated in terminologies and notations familiar to them.
Requirements may be classified in terms of the following, viz.
· Generic functional requirements
· Domain-specific functional requirements
· Non-functional requirements
Requirement patterns are useful across all these. Among the generic functional requirements some frequently encountered patterns include, e.g.
· Application Requirements
· Security
· Audit
· Assistance
· Training
· Data and Event Integration
· Business Requirements
· Enterprise Models
· Business Processes
· Business Policies
· Operational Requirements
· Configuration
· Control
· Monitoring
· Troubleshooting Aids
· Environment Requirements
· Access and span of authority
· Presentation, computing, network devices and resources
The domain-specific functional requirements are more complex. However, frameworks have been suggested in various domains to articulate their needs in standard ways. These often include, e.g.
· Business objects
· Business events
· Event-action maps
· Analytics and computation
· Business processes
· Business roles
· Business domain principles and rules
Among the non-functional requirements the patterns often may be classified among, e.g.
· Portability
· Reliability
· Usability
· Maintainability
· Scalability
· Auditability
· Availability
Often assemblies and subassemblies of requirement patterns can be created from constituent requirements of finer granularity. These can be used as templates of application requirements and then elaborated further to include the specific requirements at hand.
It would be necessary to develop pattern notations for articulating and for developing catalogs of requirement design patterns. This standardization would then form the basis of a community resource that can be used to collect and maintain insights as they are discovered.
Finally, it would be important this resource actually facilitates decision-making. That means that relative costs in terms of money, effort, skills, and resources should become clear as different requirement designs are selected.
5. Methodology
We propose that the requirement gathering process should evolve into a systematic process of requirement design.
· Requirements are articulated as far as possible by identifying the key design elements available in the proposed Requirement Design Resource
· Where assembly of requirement patterns can be used as templates they may be selected as the first basis of the requirements
· Where assemblies are not appropriate the specific requirement elements are selected and corresponding patterns are then selected
· The selected alternatives define the context of requirements in terms of, for instance, enterprise entities, resources, business processes, policies and so on
· Subsequently, any specific requirements not covered within the scope
· The requirement context is then refined to include the additional specific requirements
6. In Practice
We have developed in-house resources based on the web on the lines outlined in this paper. Our experience has been that for specific classes of projects we are able to select requirements and match them with corresponding design and implementation elements. Thus, the requirement patterns directly facilitate design and implementation patterns.
We have applied these patterns in banking and finance domains as well as in various e-business development. Our experience has been very positive. Such a resource being available at the community level has significant potential.
7. References
[1] Christel M. G. and Kang K. C. (1992): Issues in
Requirements Elicitation, Technical Report CMU/SEI-
92-TR-12 ESC-TR-92-012.
[2] Brooks, F. (1987): No silver bullet: essence and accidents of software engineering, Computer, Apr., 10-19
[3] Cybulski, J. (1998): "Patterns in Software Requirements Reuse." in AWRE’98. Deakin University, Geelong, p. Submitted.
[4] Rational Corporation, Rational Unified Process, 2000
[5] Gamma, E., R. Helm, R. Johnson, and J. Vlissides
(1995): Design Patterns: Elements of Reusable Object- Oriented Software. Readings, Massachusetts: Addison- Wesley.
Subscribe to:
Posts (Atom)