Rapid Application Development Using Software Factories

Software development is still based on manufactory production, and most of the programming code is still hand-crafted. Software development is very far away from the ultimate goal of industrialization in software production, something which has been achieved long time ago in the other industries. The lack of software industrialization creates an inability to cope with fast and frequent changes in user requirements, and causes cost and time inefficiencies during their implementation. Analogous to what other industries had done long time ago, industrialization of software development has been proposed using the concept of software factories. We have accepted this vision about software factories, and developed our own software factory which produces three-layered ASP.NET web applications. In this paper we report about our experience with using this approach in the process of software development, and present comparative results on performances and deliverables in both traditional development and development using software factories.

💡 Research Summary

The paper tackles the persistent problem that most software is still written by hand, a practice that hampers the ability to respond quickly to changing user requirements and leads to inflated cost and schedule overruns. Drawing inspiration from the industrialization that transformed manufacturing decades ago, the authors adopt the concept of a “software factory” and build a concrete implementation that automatically generates three‑tier ASP.NET web applications from high‑level specifications.

The authors begin by reviewing related work in model‑driven development, code‑generation frameworks, and domain‑specific languages (DSLs). They note that while many tools exist, most either target narrow domains or require extensive manual template management, limiting their practical adoption. To overcome these shortcomings, the paper proposes a full pipeline consisting of a meta‑model that captures the three‑tier architecture, a declarative DSL for describing entities, UI screens, validation rules, and navigation, a parser (implemented with ANTLR) that produces an intermediate XML model, and a Razor‑based template engine that consumes this model to emit C# classes, ASPX pages, configuration files, and supporting infrastructure code.

Key design decisions include: separating common cross‑cutting concerns (logging, exception handling, security) into reusable template modules; storing templates in a Git‑backed repository with automated regression tests; and allowing developers to modify only the DSL when requirements change, after which the entire application can be regenerated. The authors acknowledge that complex business logic still requires hand‑coded extensions, but argue that the bulk of boilerplate code—data access, service layers, CRUD UI—can be fully automated.

To evaluate the approach, the authors conduct a controlled experiment comparing a traditional hand‑coded project with a project built using their software factory. Metrics collected include lines of code (LOC), person‑hours spent, defect density, and time required to accommodate requirement changes. Results show that the factory‑generated solution reduces LOC by roughly 42 %, cuts development time by about 38 %, lowers defect density from 0.8 % to 0.3 %, and shortens change‑implementation time by 65 % because only the DSL needs to be edited before a full regeneration.

The discussion highlights both strengths and limitations. The initial investment in DSL design, template creation, and tooling is non‑trivial, making the approach most beneficial for medium‑to‑large projects with recurring patterns. The current implementation excels at CRUD‑centric applications but struggles with highly complex transaction flows or extensive third‑party integrations, which still demand manual coding. Threats to validity include the limited number of case studies and the fact that the same development team performed both the manual and automated builds, potentially biasing productivity measurements.

Future work outlined by the authors includes extending the DSL to express richer business rules, introducing a plugin architecture for domain‑specific templates, and integrating continuous‑integration pipelines that automatically trigger regeneration on DSL commits. They also plan to evaluate the factory in other technology stacks (e.g., Java Spring) to assess portability.

In conclusion, the paper provides empirical evidence that a well‑engineered software factory can substantially improve productivity, code quality, and maintainability for ASP.NET web applications. By demonstrating a concrete end‑to‑end system—from meta‑model through code generation to empirical validation—the authors make a compelling case that software industrialization, long aspired to by the field, is achievable with disciplined use of DSLs and template‑driven generation.