Call for Papers
Research, position, and experience papers are invited on any topic that addresses the intersection of architecture and implementation. Examples might include:
- Tools and techniques for stimulating design thinking into developers coding activities
- Architecture Prototyping to test and validate quality concerns
- Architecture refactoring tools and techniques
- Processes/practices/tools that support co-development of design and implementation
- Reactive Design vs. Proactive Design
- Evolutionary Architecting and Design
- Assessment techniques and metrics for measuring compliance of architecture against code
- Transforming architectures to source code in model-driven engineering processes
- Tool-support to the various informational and processing needs (e.g., visualization of interactions among architectural and requirements knowledge)
- Traceability between requirements, architectural solutions and implementation
- Industrial studies and empirical studies on architecture prototyping, architecture refactoring, code first design, test driven design
We invite submissions in the following categories:
Position papers (2 to 4 pages)
Short papers state the emerging trends, inspiring new ideas, and ongoing research on any of the topics within the scope of the workshop. For example, position papers could challenge the state-of-the-art; represent initial experience with a particular technique on promoting architecture, implementation, and testing interdependencies. The paper might propose new ways stimulating design thinking during implementation and maintenance.
Full papers (6-8 pages)
Full papers describe and report on the evaluation of activities on integrating software implementation and design, co-development of design, source code and test-cases, and stimulating design thinking in programmers daily activities. For example, a full paper could describe how in practice, requirements engineering, software architecture design and implementation performed together. Case studies of implementing an architecture in one or more mega-projects (e.g. a high speed rail line) or complex products (e.g. a new passenger airplane), or more focused systems and agile environments. Survey papers that review and critique the range of and/or use architecture or design thinking and reasoning are also invited (e.g. a survey of the use of practices in architecture and implementation co-development). Full papers will be evaluated based on the originality and significance of the contribution, soundness of the validation process or quality of the survey procedure, and on the broader applicability of the results.
Experience Reports (4-6 pages)
Experience papers describe empirical experiences with a particular software design practice, techniques used to bring design thinking into developers daily activities, increment design pattern or technique on a large scale system or agile project. Ideally an experience paper not only reports on the actual experience must includes an analysis of the techniques used in the forms of lessons learned that might be applicable to future projects. An experience paper might describe how the notion of briding desing and implementation activities have been examined in a real context or laboratory scenario, or how iterative development of architecture has been applied in practice.
Pedagogical papers (4-6 pages)
Techniques, lesson plans, and assignments for teaching SA deisng, implementation and maintenance topics.
Artifact papers (4 to 7 pages).
Artifact papers are considered as a separate category to encourage researchers to share their design/implementation artifacts. artifact papers should describe an architecture design along with the implementation of that design, deliver a corpus of architecturally significant code, sample implementation of different architectures or architectural choices. This corpus can include architectures of, designs, code, testing artifacts, etc. The data should be made available at the time of submission of the paper for review, but will be considered confidential until publication of the paper.
the format of BRIDGE will provide attendees with an opportunity to become familiar with a new topic and establish a good foundation for discussions about architecture design thinking in the overall context of systems engineering. We intend to make the workshop discussion and interaction oriented. Paper presentations will be used to provoke dialogue and participants may break out into small groups for more detailed discussion. These small groups will be organized around common themes or goals identified either from the papers, or by the participants during the workshop. At the end of the day, there will be a plenary session where the group's report back to the workshop as a whole on the results of their discussion and future work. Results may be used as a basis for continued publications.
- Software Engineers, and Architecture researchers (in particular) working in the development of tools, techniques and methods for the fields,
- Practitioners with experience in the adoption of practices, tools, techniques and methods.
Formatting and Submission Guidelines
All papers must conform, at time of submission, to the ACM Formatting Guidelines. Please visit the Formatting and Submission Guidelines page for paper requirements.
All authors of accepted papers will be asked to complete an electronic IEEE Copyright form and will receive further instructions for preparing their camera ready versions.