Thomas BISKUP

Jorge MARX-GOMEZ

Tuning Software Product Lines with Conceptual Programming (CP) for Individual Software Projects in Small to Medium-Sized Enterprises

Modern modeling techniques like MDA (Model Driven Architecture), MDSD (Model Driven Software Development), DSL (Domain Specific Languages) and others try to simplify the software development process and reduce project risks. Nonetheless 70% of all software problems run into problems due to incomplete requirements, exaggerated expectations from users or too little actual involvement of domain experts during the specification phase. But must we be contend with the state of affairs?

Software Product Lines offer one approach to standardize the development of flexible and powerful applications for specific domains. Selected features are implemented as configurable extension points within a framework for a standard software system. Software variants are derived from a reference architecture thus allowing a continuing evolution of the overall architecture with corresponding yields concerning overall software quality and cost structures.

In this paper we introduce model driven software development (MDSD) with a very specialized domain focus as a means to increase the flexibility of software product lines especially as far as their use is concerned for small to medium-sized enterprises.

Keywords: Software Product Lines, Conceptual Model Driven Software Development, Domain Driven Design, Agile Modelling

1. Problems in SOftware Projects

First we will examine the most pressing problems of current software projects. We focus on small to medium size enterprises (SME) actively engaging in individual software development and we will stress the additional problems originating from the way we develop software today. Finally we will hint at a possible solution.

1. Generic Problems of Software Problems

Case studies e.g. by the Standish Group [11] on the success and failure of IT projects indicate that - although total failures are slowing decreasing - IT projects still run into problems in about 50% of the time (see figure 1 for recent numbers). Analysis of the causes for those problems shows that four of the top 10 reasons are connected to requirements analyis - or the lack thereof (see figure 1).

Rank	Reason	%
1	Incomplete Requirements	13.1
2	Lack of User Involvement	12.4
3	Lack of Resources	10.6
4	Unrealistic Expectations	9.9
5	Lack of Executive Support	9.3
6	Changing Requirements	8.7
7	Lack of Planning	8.1
8	Didn't Need It Any Longer	7.5
9	Lack of IT Management	6.2
10	Technology Illiteracy	4.3

Fig. 1. Reasons for failed IT-Projects (taken from [11])

In-depth requirements analysis requires a thorough understanding of the underlying methodologies, a firm grasp of the problem domain and the ability to structure requirements in such a way that changes can be dealt with effectively (see [3], pp 503-552). Interesting is also that technological reasons are ranked very low on the list - thus improvements in the area of technology, formalism and related research areas does seem to be far less important than the optimization of project communication, interaction with domain experts on the customer side of a project and the ability to deal with changing requirements. Large companies usually deal with these problems by trying to introduce large-scale and formal project management schemes (e.g. RUP) and by using enormous resources to deal with the complexities of projects. Interestingly the numbers for project successes and failures from do not differ much across company sizes. This leads us to conclude that resource allocation alone is not really the way to go in order to further improve overall project quality. The same seems to hold true as far as the usage of state-of-the-art technologies and enterprise development tools (often restricted due to costs and required skills to large companies) go - there is no discernable influence on the project successes either.

Fig. 1. Success and Failure of IT Projects (taken from [8])

2. Specific Problems for Small and Medium Size Enterprises

The European Union defines the important role small and medium-sized companies play in the EU market like this [4]: “Micro, small and medium-sized enterprises (SMEs) play a central role in the European economy. They are a major source of entrepreneurial skills, innovation and employment. In the enlarged European Union of 25 countries, some 23 million SMEs provide around 75 million jobs and represent 99% of all enterprises.” Considering that e.g. in Germany in 2002 all roughly 2.9 million SME companies [6, p. 16] registered spent in 2001 about 20.62 billion € on IT products and services [12, p. 3], one easily sees that the average IT budget per company is rather small in size. Basically this means that individual IT projects for small and medium-sized enterprises more often than not will be strained due to limited resources, short milestones and the pressure to quickly yield tangible results (and many of them are individual development projects as [14, p. 10] indicates). On the other hand speedy projects require optimized tools for the effort at hand, a sound understanding of the problem domain and a way tro quickly map requirements to executable systems. Combined with the pressure to quickly adapt both company processes and the underlying software to changing market conditions ([13, pp.1]), SMEs are under a special pressure to survive in a globalizing market.

In the following section we will indicate four main directions into which project management and software engineering techniques will need to develop in order to accommodate the special needs of SMEs. Due to the limited space of this paper we sadly will only be able to hint at specific solutions for the individual directions.

2. Conceptual Model Driven Software Development (CMDSD)

In our research we so far have determined four main directions into which software development will need to move in order to further improve project quality. These directions in combination result in a special form of customer and domain focused variant of model driven software development (MDSD, [10]) which we have named Conceptual Model Driven Software Development (CMDSD) in order to stress the importance of focusing the conceptual views of our customers. Combined with methods from Agile Modelling [1] and Extreme Programming [2] we are currently defining a new methodology named Conceptual Programming (CP). CMDSD is the tool-related underlying philosophy which drives the project related methodologies which we consequently named Concept Driven Project Management (CDPM). Due to space limitations we will focus on the main directions of CMDSD for the rest of the paper. More information about the other parts of CP and CDPM will be published in future papers.

CMDSD and consequently the whole methodology of CP is driven by four main paradigm changes which in their sum are much more effective as each individual part as we will explain shortly:

1. From architecture- and technology-centered methodologies to pure customer-oriented approaches

2. From generic to domain-specific modeling

3. From manual coding of programs to automated software generation

4. From prescriptive to integrated agile project management methodologies

Keep in mind that the effective combination is the true strength of the CMDSD approach.Individually most of the ideas presented are known but so far no serious attempts have been made to integrate all of them into one methodology. When correctly combined these concepts are extremely effective as preliminary studies from our current projects indicate and as we will illustrate in the sections below. Note that due to space constraints we only can hint at the large picture painted in our research - a lot more material will appear in future publications.

1. Towards Customer-Oriented Approaches

Today most research in software engineering is concerned with increasing the precision of formal models or with increasing the expressiveness of programming languages, etc. We believe - backed by studies like [11] - that these questions are important but of secondary concern. As [5] indicates we need to better understand the problem domains of our customers. Additional formalisms will be of little help in this venue. Increased domain understanding and a focus on communication skills are more important lest we will not be able to gather the important data that is necessary to model with precision. Thus we require total customer commitment in our approach and willingly abstract from specific technological or formal questions. In our research (to be published in future works) we provide algorithms and methods in order to reduce the complexity of models without limiting their expressiveness so that domain experts without a formal background in modeling can cooperate effectively with expert modelers in order to build software systems together (an approach we have named Conceptual Pair Programming).

2. Towards Domain-Specific Modeling

In order to increase the understandability of models we strongly believe that we have to move away from universal and generic modeling techniques like the UML [9]. Rather we focus our attention on building highly domain specific models that use both the imagery and the domain language of the domain in question. This enables domain experts to easily understand our models and thus they can quickly integrate into mixed project teams. Additionally the verification of modeling efforts is simplified due to the domain specific presentation we use. By doing so we build upon the successes of domain driven design [5]. Additionally it has been long recognized that abstraction is a powerful mechanism in order to reduce complexity - we apply domain-specific models in order to abstract details that so often plague generic modeling languages and rather rely on domain-specific black box implementations for proven best practices in the domain.

3. Towards Automated Software Generation

The high abstraction levels of domain-specific models explained in the section before in turn allow the implementation of very powerful software generation algorithms that take best practices from given domains and codify them. Just take the example for the domain “web site management” and imagine the technical details hidden beneath the model element “high performance website”. Technically dozens if not hundreds of different algorithms and settings will be applied to a “high performance website” but not to a “low volume website” - and all this can be inferred from the domain-specific meaning of a single term! When applied consequently across the range of possible domain elements, it becomes rather easy to provide a large number of highly abstract components that in turn can be combined to build powerful and flexible systems by automated code generation tools.

Please not that we do not believe that 100% automation is possible. Depending on the domain in question much less will be possible. But we stress that almost all te infrastructure can be removed from the modeling efforts since technical infrastructure questions usually are answered with standardized blueprints and best practices once a problem domain has stabilized. For special functionality we propose the usage of highly specialized interfaces based on the strategy pattern from the “Gang of Four book” [7]. In our view programming languages are as precise and formal a means to model complex individual functionality as any other formal language - with the advantage that programmers will feel more comfortable with them and do not need to learn new formalisms. When combined with the lesseons learned in domain-driven design it becomes possible to provide expressive libraries for domain-specific functionality which in turn might even allow non-IT domain experts to express their requirements in a programming language ([5]).

Another immediate benefit of a dedication to automated software generation is that rapid prototyping [13, p.146-147] becomes effective. Rapid prototyping has proven its exceptional value for small and medium projects many times and thus is another important building block for our approach.

4. Towards Agile Project Management

Agile methods have a good reputation for small and medium-sized project teams. As we already have seen that requirements engineering is a major factor in project success it seems natural that we focus on methodologies that have been build specifically for a context of rapidly changing requirements. Scientific research [3] so far seems to indicate that agile methods are highly effective at reducing the risks of uncertain requirements in projects. Given the analysis results presented in the introduction agile aspects become a must-have demand for our CP methodology.

5. The Power of Integration

As explained above we believe that the successful integration of the four main directions defined above yields new insights on how to further improve software project success rates: Customer-centric modeling approaches put the project team into the optimal mindset in order to focus on domain-related questions and not minute technological issues. Domain-specific modeling eases the integration of domain experts without strong IT background skills into the project team and gives them a lot more responsibility during the modeling, design and verification phases. Additionally it increases the probability of spotting broken designs and analytical misunderstandings. The focus on generative techniques increases the amount of time available for analysis and modeling since the tedious parts of programming (e.g. manual coding) are reduced to the minimum necessity. Finally the intermixing with agile methods guarantees that change both in the overall context as well as in requirements can be faced in the most effective way. Clearly the sum of the parts is a lot more valuable than the (already highly effective) individual paradigms.

3. Software Product Lines

Software Product Lines build upon the foundation of a domain specific (and even product specific) software reference architecture with flexible extension and configuration points which in turn can be used to derive customer specific products. Software Product Line development uses a two-pronged approach: one track is concerned with developing the reference architecture in an evolutionary process, the other track focuses on deriving products for individual customers from the product line. Both tracks are connected by feedback loops: The reference architecture development benefits from the experiences when deriving specific products, product development in turn profits from the evolving reference architecture and experiences collected with other product derivation projects.

4. Conceptual Programming

Our approach of Conceptual Programming (CP) builds upon the experiences of Software Line Development and Model Driven Software Development (MDSD): We define an approach completely governed by high level models which are defined in terms of the customer domain. The models are simplified so far that domain experts without prior IT experience nonetheless can work with IT experts and cooperatively define models. The models are so rich in nature that applications within highly focused domains can be automatically generated from those models. Due to the domain specific way in which the models are build customers become actively involved in the modeling process. This reduces the problems we have identified in the introduction as misunderstandings in the requirements analyses phase become less frequent. Additionally the model driven generation process allows for rapid prototyping which helps even more in reducing problems with requirements as domain experts can directly validate their models against working prototypes. To cope with the dual nature of Software Product Line development explained above we separate Conceptual Programming (CP) into two methods: Conceptual Model Driven Software Development (CMDSD) is concerned with building model based reference architectures for highly focused domains which satisfy our requirement of allowing automated software generation for these domains. Archetypes are defined for domain specific applications and described completely within the model structure of the CMDSD tool. These archetypes serve as the basis for deriving more complex and specific products by modifying the archetypical models. Concept Driven Project Management (CDPM) describes how CMDSD tools can be used to derive individual products from the underlying product line while working very closely with customers in an agile projects process. The focus of CDPM lies on getting domain and IT experts to work together very closely throught the project. We achieve this by defining the method of Conceptual Pair Programming, a technique derived from Pair Programming in the Extreme Programming Approach (see [2]). Conceptual Pair Programming utilizes the simplicity of highly abstract and domain specific models which serve as a common language for both IT and domain experts. This approach reduces the communication chain between customer and solution developer which in turn reduces the risk for communication errors.

The following illustration shows the interaction between CMDSD and CDPM:

Fig 1. Combining CMDSD and CDPM

5. Conclusion

In this paper we have analyzed the core problems of IT projects today. We have shown that communication and domain understanding are the most pressing topics to be optimized in order to improve overall project successs rates while new technologies and formal methods only play the role of an underdog. Additionally we have stressed the specific problems of small and medium-sized companies. Based on this analysis we have illustrated how four underlying paradigm shifts can be utilized to derive a specialized variant of Software Product Line development allowing for individual software projects even for small companies. Further research will focus on our integrated method of Conceptual Programming (CP), which unites the principles, values and methods of Conceptual Model Driven Software Development (CMDSD) and Concept Driven Project Management (CDPM) in order to harvest the resulting synergies with a special focus on SME IT projects.

REFERENCES

1. Ambler, Scott W.: Agile Modeling, John Wiley & Sons, 2002

2. Beck, Kent; Andres, Cynthia: Extreme Programming Explained - Embrace Change, Addison-Wesley, New York, 2005

3. Erdogmus, Hakan; Favaro, John: Keep Your Options Open: Extreme Programming and the Economics of Flexibility, In: Marchesi, Michele; Succi, Giancarlo; Wells, Don; Williams, Laurie: Extreme Programming Perspectives, Addison-Wesley, New York, 2003

4. European Comission: The new SME definition — User guide and model declaration, European Comission, 2003

5. Evans, Eric: Domain-Driven Design - Tackling Complexity in the Heart of Software, Addison-Wesley, New York, 2005

6. Institut für Mittelstandsforschung (Hrsg.): SMEs in Germany, Facts and Figures 2004, http://www.ifm-bonn.org/ergebnis/sme-2004.pdf, 2004

7. Gamma, Erich; Helm, Richard; Johnson, Ralph E.: Design Patterns. Elements of Reusable Object-Oriented Software, Addison-Wesley, New York, 1995

8. Hartmann, Deborah: Interview: Jim Johnson of the Standish Group, http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS

9. Object Management Group (OMG), UML, http://www.uml.org/, 2006

10. Stahl, Thomas; Völter, Markus: Modellgetriebene Softwareentwicklung. Techniken, Engineering, Management, Dpunkt Verlag, 2005

11. Standish Group (Edtrs): The CHAOS Report (1994),
    http://www.standishgroup.com/sample_research/chaos_1994_1.php

12. Statistisches Bundesamt (Hrsg.): Volkswirtschaftliche Gesamtrechnungen, http://www.destatis.de/download/d/veroe/iktvgrinvest.pdf, März 2004

13. Taylor, David A.: Business Engineering with Object Technology, John Wiley & Sons, Inc., 1995

14. TechConsult GmbH (Hrsg.): IT im Mittelstand - Sicherung von Marktanteilen unter gestiegenem Wettbewerbsdruck. Deutschland 2005-2007.

8

Thomas BISKUP, Jorge MARX-GOMEZ

9

How to Simplify Software Projects with Conceptual Model Driven Software Development (CMDSD)

Logistyka 1/2007

---