The Software Factory: Making the most of software reuse

Problems inherent in software development are addressed by Software Factory architecture using design models, patterns and domain-specific languages.

SQDM shares an article on Software Factories written by Griffin Caprio and published at TechTarget.

Software development has always been a costly and time-consuming process. Specialized requirements and lack of skilled resources are just two of the difficulties facing companies today. Pressure to deliver software, on time and within budget, have pushed developers to look for a way to increase value delivered, while decreasing development time.

For many years now, efficient reuse of existing assets, either through object-oriented programming, component-based development or patterns-based architecture, has been one of the core objectives for the IT industry as a whole. Software reuse is seen as a means to combat many of the problems facing development teams. However, for many years and several different technology paradigms, this level of reuse has eluded the industry as a whole.

Four chronic problems with software development, each of which impede a teams’ ability to gain valuable insight and reuse from existing domain knowledge and experience. These problems are:

Monolithic Development
Monolithic development means the creation of software in such a way as to make it difficult or even impossible, to utilize the resulting artifacts outside of a narrowly defined scope. Several projects, several teams, all building isolated applications, without concern for what anyone else may be doing, or what, if any, domain knowledge they are embedding within the application. This results in large, inflexible applications that are of little use to anyone outside the original, intended audience.

Copious Granularity
Typical software development for business applications consists of a strikingly similar set of features and functionality. For example, many business applications read data from a database, present it to the user, allow the user to modify the data in some way, and then allow the user to persist the change back to the database. Even though this is an over simplification of most applications, the basics still remain the same across projects. It begs the question of why developers use such fine-grained tools as standard programming languages like C# and VB .NET for representing such basic patterns?

Part of the reason is the immaturity of modeling tools and languages. While a language such as UML is suitable for documenting software architecture, it is inadequate for allowing implementation to be derived from such models. UML lacks the extensibility required for generating large amount of code, and also lacks the breadth required to represent all aspects of software, including databases and user interfaces.

Process Immaturity
–  Controlling complexity at the expense of change -many “traditional” processes would fall under this heading, including RUP and Waterfall
–  Controlling change at the expense of complexity -most “agile” methodologies would fall under this heading, including Scrum and XP

Before a process can be tuned for software reuse, it must mature because automation can only automate well-defined processes.

One-off Development
Software development projects within a company are usually so focused on the bottom line and delivery time, that overall architecture is placed on the back burner as “lofty” or “academic”. Little regard is taken to analyze and evaluate existing assets, and very little time is dedicated to ensuring that new produced assets are reusable within other contexts. This results in many development efforts within a single company that create various amounts code and valuable assets for use within the company’s domain.

Projects rarely perform post-mortems where reusable components are identified, documented, and packaged in such a way as to become reusable by other projects.

These four problems, as well as the industry’s’ misunderstanding of how to apply reuse with the current economic model, paint a pretty bleak picture as to the future of software development as an industry, especially compared to other more mature industries, such as manufacturing. Luckily, this is where the Software Factory comes into play.

Software Factories: The Solution?
When creating software within a specific vertical, knowledge about that vertical is frequently embedded in the software being developed. Unfortunately, this knowledge remains hidden inside the software; unable to be reused outside of the original scope of the software that contains it. This means reuse of this knowledge is next to impossible. This is where Software Factories look to step in with methods and procedures to harvest that knowledge, turning that knowledge into reusable production assets for a company.

A Software Factory are about collecting existing, specialized knowledge about a certain domain and applications built within that domain. Factories use that knowledge to create a blueprint for other applications of a similar type. That schema can then be tweaked and configured to produce semi-functional to functional applications. In short, Software Factories means application generation from valuable, and reusable production assets that exist within an organization.
Before delving into what makes components comprise a Software Factory, let’s first take a look at a look at the current state of the IT industry as compared to other industries.

Read the entire article here.

For more than ten years, SQDM -Software Quality Driven Management- has provided companies with professional consulting services, specialized in different areas of Information Technology.
By eliminating unnecessary analysis and not reinventing the wheel, SQDM’s Software Factories focus on the essential: respond to project requirements on time, employing proved quality standards.

Call SQDM and know testimonials and benefits that a professional software factory can bring to your business.