PaperlayerView exact revision on arXiv

Source-linked AI summary

Tailoring Architecture Centric Design Method with Rapid Prototyping

Nitish M. Devadiga

arXiv:1706.01602v1cs.SE

TL;DR

Design-stage customer changes could send ACDM back to stage 1, motivating a tailored process with rapid prototyping. The paper embeds prototyping in ACDM and reports that time spent in later prototype iterations almost reduced by 60%.

  • Problem

    Customer requirement changes at the design stage had required restarting ACDM from stage 1 in the authors’ small-scale projects and assignments.

    Source: §I · p. 1

  • Method

    The paper embeds rapid prototyping in ACDM stage 1 and uses it informally for experiments in stage 6, refining prototypes with user feedback and analysis.

    Source: A. RAPID PROTOTYPING · p. 3, Stage 1: Rapid Prototyping… · p. 4

  • Results

    Time spent on prototype 1 was highest, while time spent in the next two iterations almost reduced by 60%.

    Source: D. OBSERVATIONS · p. 5

  • Takeaways & Limitations

    The paper concludes that rapid prototyping can reduce project time impact by reducing iterations of the whole process or a subprocess.

    Source: §V · p. 7

Abstract

from arXiv · show

Many engineering processes exist in the industry, text books and international standards. However, in practice rarely any of the processes are followed consistently and literally. It is observed across industries the processes are altered based on the requirements of the projects. Two features commonly lacking from many engineering processes are, 1) the formal capacity to rapidly develop prototypes in the rudimentary stage of the project, 2) transitioning of requirements into architectural designs, when and how to evaluate designs and how to use the throw away prototypes throughout the system lifecycle. Prototypes are useful for eliciting requirements, generating customer feedback and identifying, examining or mitigating risks in a project where the product concept is at a cutting edge or not fully perceived. Apart from the work that the product is intended to do, systemic properties like availability, performance and modifiability matter as much as functionality. Architects must even these concerns with the method they select to promote these systemic properties and at the same time equip the stakeholders with the desired functionality. Architectural design and prototyping is one of the key ways to build the right product embedded with the desired systemic properties. Once the product is built it can be almost impossible to retrofit the system with the desired attributes. This paper customizes the architecture centric development method with rapid prototyping to achieve the above-mentioned goals and reducing the number of iterations across the stages of ACDM.

I. INTRODUCTION

The paper tailors ACDM with rapid prototyping to improve product development through greater investment in requirements and analysis. It addresses customer-driven design-stage restarts, uncertain requirements, and inaccurate early estimates.

I. INTRODUCTION

  • Engineering processes are adapted to project needs in organizations, while defense projects tend to follow prescribed standards more strictly.The paper notes that military standards are revised for optimization, rework, and flexibility.Source: §I · p. 1
  • The paper proposes tailoring ACDM with rapid prototyping and investing more time in requirements and analysis for a higher-quality deliverable.The process is framed for the entire system, including software, hardware, systemic properties, and components.Source: §I · p. 1
  • The authors’ PSP experience suggested that more requirements and design effort coincided with less development time, higher product quality, and fewer defects.This is presented as an observation from adopting PSP with other students, not as a controlled causal finding.Source: §I · p. 1
  • Design-stage customer changes had required restarting ACDM from stage 1; the authors say initial rapid prototyping mitigates this rework.The authors observed this during three months of small-scale projects and assignments.Source: §I · p. 1
  • The authors report that customers may not fully know their product requirements, motivating rapid prototyping.They describe this as an industry-wide observation and draw on their own experience.Source: §I · p. 1
  • Prototypes should not become final products because they lack the quality and systemic properties required of production systems.Source: §I · p. 1

5. In a traditional engineering processes, total estimates

  • Early estimates are described as highly inaccurate; solidifying requirements through ACDM with rapid prototyping is presented as a basis for better estimates.The passage says estimates can draw on requirements, resource availability, skills, and historical data.Source: §5 · p. 2

II. VERIFICATION

The paper reports that investing time in requirements and design improved project quality by reducing development time and defects. Its observations also describe increasing planning and design time and decreasing development time and defect counts.

II. VERIFICATION

  • Planning time increased from the first to the last assignment, and design time rose gradually across assignments.The planning-time trend is described as linear; the figures depict changes from 1B to 7B.Source: §II · p. 2, Figure 1 · p. 2, Figure 2 · p. 2
  • The authors report that increased planning and design time reduced coding time, which they also describe as development time.They attribute the reduction to more thorough analysis.Source: §II · p. 2, Figure 3 · p. 2
  • Defect counts were described as decreasing across programs in the defect/program graph.The figure caption labels a decrease in defects from 1B to 7B.Source: §II · p. 2, Figure 4 · p. 2
  • The authors conclude that thorough requirements analysis and design improve overall project quality by reducing development time and defects.Source: §II · p. 2
  • The authors attribute the overall quality improvement to reduced development time and defects after thorough requirements analysis and design.Source: §II · p. 2

III. REVISED ENGINEERING PROCESS

The section distinguishes prototypes used to elicit requirements from those developed iteratively toward a final product. It describes rapid prototyping as an early, lower-effort approach and places it in two ACDM stages.

A. RAPID PROTOTYPING

  • A prototype is an executable model that reflects a selected subset of system properties, such as display formats, computed results, or response times.Source: A. RAPID PROTOTYPING · p. 2
  • A throw-away or rapid prototype supports requirements elicitation and user feedback, then is discarded or kept only as a reference rather than used as the final product.Source: A. RAPID PROTOTYPING · p. 2
  • An evolutionary prototype is developed through continued iteration, with features added according to requirements until a stable final product is achieved.Source: A. RAPID PROTOTYPING · pp. 2–3
  • Rapid prototyping creates prototypes with less effort than an operational implementation and emphasizes early development for customer requirements, feedback, and analysis.Source: A. RAPID PROTOTYPING · p. 3
  • In this paper, rapid prototyping is embedded in ACDM stage 1 and used informally for experiments in stage 6.Source: A. RAPID PROTOTYPING · p. 3

B. ARCHITECTURE CENTRIC DESIGN METHOD (ACDM)

ACDM uses architectural design to refine system designs and drivers while addressing systemic properties alongside functionality. The proposed tailoring adds rapid prototyping early to capture requirements and architectural drivers, reducing costly re-iteration and supporting estimates.

B. ARCHITECTURE CENTRIC DESIGN METHOD (ACDM)

  • ACDM uses architectural design to explore and refine system design and architectural drivers, while identifying technical risks early.It is a design method for organizations and teams building software-intensive systems.Source: B. ARCHITECTURE CENTRIC DESIGN METHOD… · p. 3
  • Performance, modifiability, and availability must be designed into the architecture alongside stakeholder functionality because they may be impossible to retrofit later.ACDM addresses these systemic properties through its architectural design process.Source: B. ARCHITECTURE CENTRIC DESIGN METHOD… · p. 3

C. ACDM with RAPID PROTOTYPING

  • The tailored method makes preengineering part of the process, using early prototypes to elicit requirements and gain technical insight while informally identifying architectural drivers.The revised process is illustrated in Figure 6.Source: C. ACDM with RAPID PROTOTYPING · p. 3
  • Rapid prototyping at the initial ACDM stage is intended to solidify requirements and mitigate restarting the process when customers change requirements during design.The proposal also identifies approximate estimates after Stage 1 and tighter development time and cost estimates as benefits.Source: C. ACDM with RAPID PROTOTYPING · p. 3

Period of Uncertainty

During the period of uncertainty, rapid prototyping elicits and refines requirements and architectural drivers before formal architecture evaluation and production decisions. The process carries prototypes into experiments as throw-away tools, then moves to production once the architecture is established.

Stage 1: Rapid Prototyping requirements elicitation and informal architectural driver’s identification

  • Analysts and developers build and iteratively modify a high-level prototype with stakeholder feedback to refine functional and non-functional requirements and informally identify architectural drivers.The prototype sequence continues until its changes are acceptable against client requirements, schedule, resources, and cost.Source: Stage 1: Rapid Prototyping… · pp. 3–4

Stage 2: Establish project scope

  • In Stage 2, the team plans expected iterations for Stages 3–6; Stage 1 prototyping helps organize and consolidate architectural drivers, while clear requirements support approximate project estimates and fewer iterations.Source: Stage 1: Rapid Prototyping… · p. 4

Stages 3–4: Create/Refine and Evaluate the Architecture

  • Stage 3 creates and refines the architecture, while Stage 4 evaluates its fitness; formalizing Stage 1’s informal architecture document is described as less time-consuming and less prone to change.The authors say this can reduce iterations across Stages 3–6.Source: Stage 1: Rapid Prototyping… · pp. 4–5

Stage 5: Production Go/No-Go Decision

  • Stage 5 makes a production go/no-go decision from the evaluation, allowing ready parts to proceed while others receive further refinement.The decision is made with attention to dependencies among system parts.Source: Stage 1: Rapid Prototyping… · p. 5

Stages 6–8: Plan and Execute Experiments, Production Period of Planning, and Production

  • Stage 6 uses throw-away prototypes to experiment on architecture concepts and risks, not to develop the product; once architecture is established, production planning and implementation follow.The period of certainty supports higher-fidelity estimates and schedules, followed by detailed design, construction, and testing.Source: Stage 1: Rapid Prototyping… · p. 5

D. OBSERVATIONS

The observations report that the tailored process shifts effort toward requirements and design, while the compared projects using it had lower development time and fewer defects than the project not using it.

D. OBSERVATIONS

  • The next two rapid-prototyping iterations took almost 60% less time than prototype 1, which required the most time.Figure 8 presents the time taken for rapid prototyping.Source: D. OBSERVATIONS · p. 5, Figure 8 · p. 5
  • The process required more time for requirements and design, while the observations describe reduced development time.Figure 9 is titled “Time taken Requirements and Design.”Source: D. OBSERVATIONS · p. 5, Figure 9 · p. 5
  • Projects 2 and 3, which used the proposed process, took less development time than Project 1, which did not use it.The comparison assumes the programs had almost similar difficulty and developers were proficient in coding; the informal architectural document helped formalize and refine the architecture document.Source: D. OBSERVATIONS · p. 5
  • The observations report fewer defects in Projects 2 and 3 than in Project 1, including fewer defects across phases.Figure 12 is identified as showing defects per phase.Source: D. OBSERVATIONS · p. 6, Figure 12 · p. 6, Figure 11 · p. 6

A. SCALABILITY

The tailored process is presented as applicable beyond software, with its greatest benefits expected on large, complex, technically risky projects. Its viability depends on project scale, resources, and available time.

A. SCALABILITY

  • The process is presented as applicable to many software/hardware projects, not only software development.Source: A. SCALABILITY · p. 6
  • The process targets secure, robust products delivered to strict deadlines, while deadline slippage is common when risks are not mitigated.Slippage often occurs late in development or during debugging; the discussion cites literature.Source: A. SCALABILITY · p. 6
  • The process is viable according to project lifespan, available resources, and available time.Smaller projects may limit introductory research or development to control scale and cost.Source: A. SCALABILITY · p. 6
  • Large projects may benefit most because early and ongoing prototyping helps mitigate technical and requirements-related risks.The process is described as especially useful as project size, complexity, and technical risk increase.Source: A. SCALABILITY · p. 6

B. PROTOTYPING

Prototyping supports requirements work and customer access to an early system, with rapid prototypes valued particularly for demonstration rather than code reuse.

B. PROTOTYPING

  • Prototyping is useful for eliciting requirements.Source: B. PROTOTYPING · p. 6
  • Rapid prototypes let customers see and access the system's functionality and user interface.Source: B. PROTOTYPING · p. 6
  • Although prototyped code can be reused, rapidly prototyping a system for customer demonstration is described as more useful.Source: B. PROTOTYPING · p. 6

C. MANAGEMENT ISSUES

The process can be used with teams of any size, but team coordination and communication remain necessary, especially on large teams.

C. MANAGEMENT ISSUES

D. LESSONS LEARNT

The paper presents experimentation and prototyping as ways to learn about feasibility, failures, and project profiles, while concluding that rapid prototyping can reduce iteration-related time impact and support more accurate planning.

D. LESSONS LEARNT

  • Experiments are intended to test the value and implementation feasibility of new ideas, especially as project size, complexity, and technical risk increase.Source: D. LESSONS LEARNT · p. 6
  • Analyzing failed experiments can identify why results were poor and which areas need attention and effort.The authors report that prototyping or experimentation commonly produces unusable systems.Source: D. LESSONS LEARNT · p. 6
  • Successful or failed experiment results can help estimate a system's design and development profile when schedule, resources, and cost are critical.Source: D. LESSONS LEARNT · p. 6

V. CONCLUSION

  • Rapid prototyping in ACDM can reduce project time impact by reducing iterations across the whole or a sub-process.Source: §V · p. 7
  • Better specifications are argued to mitigate maintenance costs, and up to 50% of maintenance requests shortly after delivery are reported as resulting from misspecification.The passage notes that this does not eliminate maintenance costs.Source: §V · p. 7
  • Considering prototyping extent, design and review formality, and early customer involvement can produce a more precise development-phase profile and schedule estimates.Source: §V · p. 7
Loading 1706.01602v1…