Software Architecture As a Driver to Project Management

Anar Huseynov
Master of Software Engineering Carnegie Mellon University Pittsburgh, PA, USA anar@ahuseynov.com

Abstract Software architecture documentation and design are typically created during design phase of the software development lifecycle (SDLC) after the requirements are elicited. However, this represents a missed opportunity to use software architecture as a tool to drive the project management activities and better elicit requirements, identify risks and manage design and implementation phases. This paper is illustration of the usage of the latter approach in the Studio project at Carnegie Mellon University. Keywords- software architecture, project management, requirement, design and implementation phase activities

I.

INTRODUCTION

A. Program Description Master of Software Engineer program is a 16-month long program designed for an experienced software engineers and is specifically targeted to mastering software engineering practices that could scale to large projects and teams. The goal of the program is to target all aspects of software development lifecycle (SDLC) from requirements to maintenance phases by offering courses relevant to each phase of the SDLC. The students also partake in 16-months long Studio project, which gives them an opportunity to apply the practical and theoretical knowledge gained from the courses in a real world experience as a four to five member team. B. Project Context Bosch Research and Technology Center (RTC) has tasked my team, HandSimDroid, with building a solution that would allow models developed in Ptolemy, an open-source modeling and simulation tool, to be run in real-time, manipulated, and operated using a user-configured layout on Android-powered devices. Robert Bosch GmbH is a worldwide corporation that designs and develops embedded systems for automobiles. Because of the inherent complexity of modern engine systems and necessary precision to ensure safe operation, Bosch uses model-driven development. These systems are currently modeled by the various business units using a tool called ASCET that is developed by a Bosch subsidiary, ETAS. Though ASCET has sufficient capabilities for their current operations, the Bosch RTC has been researching additional capabilities that could be incorporated into the ASCET toolkit. Ptolemy, developed by an open-source community primarily at the University of California at Berkeley, provides users with the ability to simulate real-world activity and perform advanced analysis on models [3]. However, Ptolemy needs some additional enhancements to fully support the goals of Bosch RTC. Unfortunately, the current desktop solution of Ptolemy does not lend itself to more portable applications where the user is on the move, changing model inputs/outputs and parameters, observing actual engine conditions, and providing immediate feedback. There are also limitations to the handheld devices, namely the screen real estate, processing power, battery life, and available memory, particularly on tablets and phones,

Software architecture documentation and design are typically created during design phase of the software development lifecycle after the requirements are elicited. However, based on my experience obtained from Studio project, I found out that starting the design activities early could drive the whole project forward in all phases of the development process including early stages of requirements process and during software construction phase. This is especially true for cases when the project from the beginning has a known a set of constraints that can help stakeholders elicit, analyze and document requirements. By keeping project constraints in perspective, stakeholders could identify requirement that are not well specified, ensure that the scope is within allocated time budget, and also limit search space of potential design approaches. Software architecture practices can help in identifying risks and driving software development management activities towards mitigation or impact reduction of those risks. In this paper, I would focus on typical risk statements that arise during software development life cycle that are identifiable by using software architecture documentation and analysis techniques. I would also include my reflection with regards to effectiveness of dealing with these issues and try to tie these ideas with best software engineering practices I learned throughout the program. In order to give readers some context, the next two sections will provide high-level overview of the program and project followed by the paper organization.

when compared to their desktop counterparts. That being the case, the simulation must provide only the displays appropriate to the end-user and, because the needs can vary greatly between engineers, must be laid out in a highly configurable manner. With these extensions in place, Bosch RTC will be able to demonstrate Ptolemy running on an Android device with a user-specific layout with a goal of reducing operational costs of designing and configuring an embedded system on the go. C. Paper Organization The paper is organized as a reflection of application of software architecture practices during each phase of the software development from requirements to implementation. The primary focus is to distill typical risks and issues identifiable via software architecture and solvable using software development management processes. The second section of the paper has a focus on a requirements phase and illustrates architectural approaches used by the team to elicit and analyze requirements, identify and solve challenges and later on sign off on a project scope with the client. The third section will concentrate on activities we have performed during design phase with a focus on risk analysis and mitigation. The last section primarily deals with implementation activities such as analysis of static view to subdivide tasks and usage of dynamic views as an input for identifying and managing technical and operational risks. The paper concludes with high-level reflection that highlight the most important take-away from the project and provides general recommendation that one could use in a project with a similar configuration. II. REQUIREMENTS

each stakeholder, Bosch and Berkeley, is technically inclined, and is an active contributor to the Ptolemy project, each of them had certain design in mind for our project even before our requirement elicitation process was complete. As its usually case, if you have design in mind while eliciting requirements, its possible to that the requirements are not correct such that the final product might not solve the actual problem that our stakeholders might have envisioned [1].

A. Approaches Three aspects of project influence software architecture design the most [6]: Quality attributes Business and Technical Constraints High Level Functional Requirements

In our particular case, since we were developing on top of an existing system, we had a technical constraints imposed by the design of the system. Moreover, we also had business constraints of fixed schedule and resources. Although business constraints were well defines, the technical constraints were like a black box due to large size of the Ptolemy project and lack of domain knowledge. Consequently, it was very hard for us to elicit requirements and ensure that they fit within the constraints. Generally, the correct solution to a design problem can be illustrated as an intersection between business and technical constrains, quality attributes and architecturally significant functional requirements. Since we were lacking one of the variables of the equation, we had a risk of eliciting wrong requirements, over-scoping our project or designing a wrong thing. In order to mitigate these risks, we decided to execute the following two processes in parallel: Establishing business context and drivers for the project A set of small experiments in order to gain domain knowledge and identify technical constraints and possible design solutions

While eliciting and analyzing requirement, the team was faced with the following major challenges: Our primary clients from Bosch RTC were researchers, and as with any research project the end goal is never well defined. Consequently, the team faced a challenge of trying to find a balance between what our clients want and what the system can support and what we can do within allocated time frame. The team was lacking domain knowledge in Ptolemy. Ptolemy is very complex piece of software with more than half of million KLOC of Java code [9]. Understanding how the system works is no a small feat. Consequently, the team had a challenging time eliciting and analyzing requirements from stakeholders that were very technical and required very specific features to be added to Ptolemy. The project is done in collaboration with Ptolemy maintainers from University of Berkeley. Since

1) Establishing Business Context and Drivers Contextual design was the first requirement elicitation technique we tried. The process is primarily used to improve existing system but also provides an important insight on how an organization operates [2]. Although Contextual Design was the first elicitation activity we tried, we didnt identify as many requirements compared to other requirement elicitation techniques we tried later on. However, the most important take-away from this process was the business context and drivers which is understanding of how Bosch operates and what vision it has towards our project. By observing how researcher at Bosch operate, and by drawing several cultural and interaction models, we were able identify the driver and vision which was reduction of operational costs of configuring embedded systems. Numerous requirements that our clients

were giving to us were actually possible ideas to this solve this problem, not actual set-in-stone requirements. Based on this activity, we were able to identify functional and non-functional requirements that were architecturally significant and remove architecturally insignificant ones from our analysis since it was just a noise from a design perspective. This helped us limit design solution search space and obtain high level view of potential quality attributes. We also reduced impact of a risk of designing a wrong thing, which is a common reason for software failure as identified by Curtis [1]. All components of his failure model, the thin spread of domain knowledge, conflicting and fluctuating requirements, and communication breakdown were present during start of our project. Establishment of business context was a good foundation for mitigating this risk. By establishing business context, we were able to conduct much more effective and focused subsequent requirement elicitation and analysis activities, which helped us solve the first challenge identified above with regards to a greenfield project. My hypothesis that the reason subsequent requirement elicitation activities were much more effective is the improved understanding of the business goals which helped us conduct the processes in a holistic manner. This hypothesis coincides with ideas presented in paper by Clements and Bass with regards to what requirement specification document need to contain and what an architect needs to design an effective solution [8]. 2) Experiments After we established high-level functional requirements, we started working on the second missing component in the list of the architectural drivers, which were unknown technical constraints imposed by the design of Ptolemy, Android and underlying hardware of handheld devices. Since our clients from Bosch and Berkeley were technical, both of them provided certain insight and potential design solutions to the problem. However, due to lack of domain knowledge, we were not able to evaluate effectiveness of either approach from architectural perspective. Accepting either approach would be too risky because it imposes constraints on project scope and affects viability of certain functionality by fixating us to a certain architectural pattern. To mitigate this risk, we conducted a set of small software experiments that targeted each potential solution with a goal of gathering preliminary quality attribute scenario metrics, obtaining domain knowledge and narrowing down the set of potential architectural patterns. At that time, we were not using ACDM method; however, this approach is similar to the one defined in ACDM [7]. With results at hand, we were able to eliminate certain design solutions proposed by our stakeholders by convincing them that either the quality attribute requirements would not be met, or increase of project complexity would lead to reduced scope and potentially lower quality due to technical immaturity of the proposed solution. This activity was very important because development team is working with stakeholders that have technical knowledge and in order to manage their expectation, we had to justify our proposals very carefully

using objective quality attribute metrics obtained from the experiments. B. Conclusion Taken as a whole, software design and architecture practices should not be postponed after the requirements phase is completed but rather needs to be a driver to the requirement elicitation and analysis. Depending on the project context, it could help in identifying business drivers, identifying constraints, managing customer expectations and potentially narrowing down design solution space, which ultimately helps in specifying project scope and plan. III. DESIGN

After the requirements were stabilized, Quality Attribute Workshop (QAW) and creation of notional architecture diagrams kick started the design phase of the project. During this phase, the team identified the following risks: The team has an uneven distribution of domain knowledge, which might lead to delays during implementation, task estimation and integration problems. Due to large code base of the Ptolemy, many aspects of the design were not verified to be implementable as conceived in the diagrams, which might potentially lead to problems with implementation of the design. Estimation of implementation phase tasks was not granular enough to warrant completion within schedule, which might lead to problems in achieving minimal threshold of success.

A. Approaches As one could see, the risk are quite general and could be applicable to most software project with a brand new team and greenfield project. As a result, I believe the processes that we applied to mitigate those risks can be generalized to most project that have similar characteristics. Our solution to this problem was to conduct further architectural decomposition in order to increase domain knowledge across the board and verify certain lower level aspect of the design via experimentation. By executing these proposes, we envision to enter into a period of certainty when the team could comfortable break down the problem into manageable tasks, estimate and then create a meaningful implementation schedule based on those estimations. To illustrate the point, I will provide project specific examples that helped us tackle each of the points. We used Architecture Centric Design Method (ACDM) to drive our design activities. Main approach employed by ACDM is an iterative analysis and decomposition of the software architecture with a focus towards the highest priority and the most complex quality attribute scenarios [5, 7]. In our case, from a static perspective, it was extensibility and

maintainability of the system, which is typically a case with open source projects. Our challenge was to port the system to Android without creating a separate fork of the project. This means we had to make certain changes to the codebase, and then contribute those changes back to the repository without breaking other unrelated subsystems. The usual problem with porting and code changes is that the changes can be non-local and crosscutting. During our design analysis phase, we used tool called Lattix that helped us verify our hypothesis that the changes are local and ensure that the work could be completed within allocated time frame [10]. This is just an example how design activity influence our project management in general because it helped us not only verify our design solution but also ensure that the solution could be implemented within the schedule. Problem of uneven knowledge distribution is a typical in any new team that has different experience level and skillset. To even out the space, the typical solution is to formally document the design and divide up design tasks more or less evenly to ensure everybody gets a chance to be involved in design. However, after everything is done the risk of uneven distribution still remains in place because its hard to quantitatively assess comprehension of the domain knowledge. Our solution to this problem was to create a short-answer quiz based on Ptolemys and our system design to ensure that the domain knowledge of each team member is adequate. This illustrates another point of usage of design activities as a driver for project management. Because we used ACDM approach in our design phase, we continuously iterated over our design, and at the end of each iteration made go or no-go decision based on software architecture review. After several iterations, we were able to make a go decision such that everybody was comfortable enough in implementing the design as documented. At this point, we entered period of certainty and, thus were able to estimate tasks that were black boxes for us before. B. Conlusion In conclusion, I would like to emphasize that design phase should not viewed with the only focus on software design but should be a driver for improving functional and non-functional requirement specifications, estimation of tasks and associated schedule, and managing operational and technical risks that could be exhibited in the implementation phase. IV. IMPLEMENTATION

threshold of success. Its also vital to manage and contain quality problems especially in modules with high dependencies because quality problems will leak through them. Consequently, its possible to summarize the challenges as the following risk statements: Implementation phase has the highest concentration of risks; unplanned tasks caused by a problem might prevent the team from achieving minimal threshold of success since the project is schedule driven and most of the work needs to be concludes by the end of the implementation phase. Team has little experience working together on software integration activities; quality and integration problems might affect the schedule and project success.

A. Approaches In order to mitigate the above stated risks, the team used the following approaches: Use incremental release model by prioritizing modules that have the highest value for the client and minimal dependencies on other components. Use lower level static and dynamic view decomposition diagrams as a way to identify dependencies and integration points between team member tasks, and also target quality assurance practices to ensure defects dont leak to other components.
HandSimDroid Scope Model Designer (Vergil) Save Read
Model UI Layout File

1) Incremental Release Model

UI Designer (Homer)

Save

Read Read Load & Run

Ptolemy Server (ptserver)

Android Client (ptdroid)

Since our project was a schedule driven, implementation phase was the most challenging part because it had the highest concentration of risks that we either potentially had not identified or mitigated. Consequently if any of the risks turn into problems, our schedule could be affected quite significantly along with the threshold of success. Moreover, its the first time when the team has to work together in a manner where task division and subsequent integration is quite complex compared to previous phases where the tasks didnt have that many dependencies between each other. Figuring out low-level schedule and task ordering is very important technique for minimizing the risk of not achieving minimal

Legend

Application

XML File

Data Flow

Scope

Figure 1: Context Diagram of HandSimDroid System In order to minimize risk of not achieving threshold of success, the team opted to develop the system in an incremental release fashion which is similar to an incremental software development process [11]. This means we had to identify the

dependencies between modules and develop them in an order that allows incremental releases. From the context diagram in Figure 1, one could see that Ptolemy Server component has the most dependencies, and thus could be developed first since it is prerequisite for the Android Client. Although UI Designer could have been developed first too, the team opted to start with Ptolemy Server since it had the highest complexity. The team wanted to have an option to drop one of the modules in the worst case if there is not enough time but still achieve minimal threshold of success, which was demonstration of a model on the handheld. This was a strategic decision we were able to make by analyzing business context of the project and architectural diagrams. The diagrams were of high importance when we were making the dependency case to the client and helped us manage their expectations and prepare them accordingly in case of any problems that could affect the project. We believed it was a right solution because of the high concentration of risks in the implementation phase and also historical data from previous Studio teams. 2) Dependency Analysis for Integration and Quality Assurance

The start of implementation phase was quite a bumpy ride for us because we had trouble integrating different modules together. Since we were developing the most complex piece of the system first, this is not surprising given inexperience of the team working together. Although we followed best practices of object oriented programming and used dependency model as a way to partition the module, the integration was still very complex. As one knows, dynamic views typically dont help in software construction since the perspective has a focus on runtime objects; however, in our case, we realized that we have many dynamic dependencies, which could be identified by roughly mapping dynamic objects to their static equivalents. The reason for the integration problems was concurrency and synchronization problems that showed up only after we put different parts together. As one could see from the Figure 2, there are many threads that interact with each other in a nontrivial way possibly causing race conditions and deadlocks. After initial hiccup with the integration, we identified the root cause of the problem and solved it using continuous integration and automated testing which also helped us mitigate the quality leak risk identified above. With that said, one could conclude that software architecture was again the driver for identifying and/or solving project management problems.
Legend

Proxy Model Infrastructure Sources Proxy Sinks Proxy Attributes Proxy Sources A Sinks B

A sends a token to B Android using Ptolemy Handheld lter connector A A sends a remote token to B A B Process B Ptolemy Server

Monitoring System

Token Batch

Attribute Change Listener Token Listener

Blocking Queues

Token Publisher

A sends an MQTT message to B A Ptolemy Server Hessian Servlet MQTT Broker B

A sends attribute change token to B A B

Ptolemy Simulation Engine

Proxy Model Infrastructure

Token Listener

Token Publisher Monitoring System

A blocks B's thread A B

Multiplicity

Blocking Queues

Attribute Change Listener

Token Batch

A sends synchronous command to B (http)

Object

Proxy Sources

Actors

Proxy Sinks

Thread

New Modied Existing Component Component Component

Figure 2: Dynamic view of Ptolemy Server [4]

V.

CONCLUSION

In conclusion, I would like to highlight the benefit of using software architecture practices as a driver for managing software development. Performance of requirements elicitation activities, defined by number of requirements gathered, improved significantly after we captured the business context and drivers, which are a vital component of software architecture documentation. Identifying and enumerating technical constraints helped us in finalizing requirement list and negotiating scope and selection of architectural pattern. Design phase activities were mostly focused on architecture decomposition. However, due to limited time frame for the phase and practicality purposes, one need to make strategic decision regarding which view needs to be decomposed down. Architecture reviews and risks identified during this process helped us in making these decisions. One of the risks was uneven distribution of domain knowledge, which was mitigated via formal documentation and subsequent quiz to assess knowledge comprehension. Static views are typically used in software construction phase for the purposes of task allocation and integration; however, in our case, this was not enough due to numerous cases of dynamic dependencies due to concurrency issues. Careful analysis of a dynamic perspective helped us in identifying those cases. Taken as a whole, software architecture is a tool that one could use to identify risks in the project and help you drive

your software development management activities with focus on risk mitigation or risk impact reduction. REFERENCES
[1] B. Curtis, H. Krasner, N. Iscoe, A field study of the software design process for large systems, Communication of the ACM, November 1988. [2] H. Beyer, K. Holtzblatt, Contextual Design: Defining CustomerCentered Systems, Morgan Kaufmann, 1997. [3] C. Brooks, E. A. Lee, X. Liu, S. Neuendorffer, Y. Zhao and H. Zheng, Heterogeneous Concurrent Modeling and Design in Java (Volume 2: Ptolemy II Software Architecture), 2008. [4] Team HandSimDroid, Master Design Plan for Ptolemy on Android, 2011 [5] A. J. Lattanze, Architecting Software Intensive Systems: A Practitioners Guide, 2008. [6] L. Bass, P. Clements, R. Kazman, Software Architecture in Practice [7] A. J. Lattanze, Architecture Centric Design Method, A Practical Architecture Design Method for Software Intensive Systems, ICSOFT, 2009. [8] P. Clements, L. Bass, Relating Business Goals to Architecturally Significant Requirements for Software Systems, SEI Technical Note, 2010. [9] Ptolemy II Code Analysis, Ohloh:Root, http://www.ohloh.net/p/12005/analyses/latest [10] Lattix DSM, http://www.lattix.com/ [11] R. Pressman, Software Engineering: A Practitioners Approach, McGraw-Hill, 2001