1 Architecture Development Process Dynamics in MBASE Cyrus Fakharzadeh Center for Software Engineering University of Southern California Nikunj Mehta Center for Software Engineering University of Southern CaliforniaArchitecture Development Process Dynamics in MBASE Introduction Many models of software processes focus on issues concerning specific aspects of a software development life cycle. In this report, we describe a process model for architecture development in the Model-Based Architecting and Software Engineering (MBASE) approach. This approach involves creation of four kinds of models i.e. product, process, property and success models, and their integration in an ongoing fashion. The architecture of a system forms the blue print for building the system and consists of the most important abstractions that address global concerns. Architecture is centric to many modern life cycles such as Rational Unified Software Development Process (USDP) and MBASE. The MBASE approach comprises four distinct phases, each delimited by a milestone or an anchor point. Early phases of MBASE consist of identifying the requirements for the system and defining the system architecture. During each phase the architecture of a system is successively refined to cover a larger system scope. These anchor points involve consensus building among the system stakeholders for commitment to move forward. Our model studies the dynamics of architecting processes in MBASE during its early phases i.e. Inception and Elaboration. The model also studies the impact of RAD factors such as collaboration and prototyping on the process of architecting. The models described here show that initial completion rates for the requirements identification and architecture development activities significantly impact the number of approved items. Prototyping factors such as IKIWISI and collaboration also significantly affect the rates of completion and approval. The model also describes a declining curve for staffing analysts and a linear growth for architecting and design personnel. The model behavior is similar to Rational USDP in terms of the effort distribution curves of the process. The purpose of this study is to understand the dynamics of architecture development processes. This understanding will help for better planning of future projects. The model would be useful for the designers of CS 577 and similar courses at USC that use the MBASE approach for developing software. The model has been calibrated for the CS 577 projects using effort data reported by the student team members. It is possible to extend the calibration to non-CS 577 projects by appropriately calibrating the model for resource factors such as productivity and completion durations of various tasks. Background Software process modeling involves studying various aspects of a software development life cycle. These life cycle models can be broadly categorized as sequential and concurrent. Various models of sequential life cycles have been created that study various issues such as hiring policies, effects of inspection and effects of staff learning. Modern software development life cycles have focused on concurrent activities and involve parallel execution of various software development tasks. The Spiral model [Boehm 81] of software development is an example of such a life cycle and involves successive refinements of the software models through incremental growth. MBASE (Model-Based Architecting and Software Engineering) is a hybrid life cycle approach which involves four phases each with a possibly different growth mode i.e. sequential or evolutionary. The MBASE approach involves creation and integration of product, process, property and success models. MBASE is also an architecture centric approach and the architecture is constantly integrated with other models as describe before. The architecture of a system is a blue print that identifies the most important abstractions of the system that address global system concerns. An architecture proves to be a starting point for the process models and supports the required property models.3The process of architecting is still not a very well understood one and involves varying degrees of method, theft and intuition. However, it is possible to model the concurrence relations among requirements and architecture activities. The process involves constant integration of the various models and requires that QA and coordination with other activities be performed on an ongoing rather than discrete basis. The Product development model by Ford and Sterman provides a model for concurrent product development that considers the effect of inter-phase and intra-phase concurrency. Appendix D shows the model we have produced. Appendix E shows the source code for our model. The Architecture Development Process Model Our model simulates the two major activities of the front end of a software development project namely requirements elicitation and architecture design. It also models the prototyping tasks in the development process as a supporting activity. The two activities are modeled separately in the model and a generic process structure is chosen to describe the internal dynamics of each activity with customizations performed to accommodate each activity’s characteristics. The resource allocation in a concurrent model cannot be described by a static relationship with progress. Instead the required resources are often dictated by resource availability. Once hired, these resources are dynamically allocated to various tasks based on the backlog of tasks of that kind. The performance of this system model is measured in effort levels and the number of items produced. The three sub systems of this model are process structure, resources and performance. Top level subsystem interactions are described in the Figure 1. The flow of products between project activities is described in the project network diagram in Figure 2. Figure 1 Subsystem interactions Links between activities of the project are distinguished as carrying products of an activity or returning errors from the following activity. The inter-activity interactions arise from the following: • Requirements activity produces requirement descriptions that are available to the architecture activity • Architecture activity produces artifacts that are used in downstream activities but these downstream activities are not modeled. • Architecture design reveals
View Full Document
Unlocking...