CIS 518 Case Study 1
Case Study 1: Generative Software Development
This assignment consists of two (2) sections: a written report and a PowerPoint presentation. You must submit the two (2) sections as separate files for the completion of this assignment. Label each file name according to the section of the assignment it is written for.
Section 1: Written Report
Read the case study titled, “Generative Software Development” (located in attached). Then, imagine a situation where your organization is considering a generative development process for its new line of software products. You are asked to present a written report to the organization’s CIO about generative software development and its usage.
Write a five to six (5-6) page paper in which you:
1. Define in your own words, what is meant by generative software development, and describe how it contrasts with other software development processes.
2. Describe the benefits of applying the generative development in an organization.
3. Explain the challenges of implementing the generative software development process in an organization.
4. Describe how the challenges faced during the implementation of the generative software development process can be overcome.
5. Examine how this development process might be applied to develop software in the organization.
6. Use at least three (3) quality resources in this assignment. Note: Wikipedia and similar Websites do not qualify as quality resources.
Section 1 of this assignment must follow these formatting requirements:
• Be typed, double spaced, using Times New Roman font (size 12), with one-inch margins on all sides; citations and references must follow APA or school-specific format. Check with your professor for any additional instructions.
• Include a cover page containing the title of the assignment, the student’s name, the professor’s name, the course title, and the date. The cover page and the reference page are not included in the required assignment page length.
Section 2: PowerPoint Presentation
You have also been asked to develop a presentation to be shown at the next shareholder’s convention to explain why the organization has chosen to implement a generative development process.
Prepare a seven to ten (7-10) slide PowerPoint presentation in which you:
1. Summarize the main points in the written report.
2. Create bulleted speaking notes for the presentation to the shareholders in the Notes section of the PowerPoint. Note: You may create or assume any fictitious names, data, or scenarios that have not been established in this assignment for a realistic flow of communication.
3. Use a professional technically written style to graphically convey the information.
The specific course learning outcomes associated with this assignment are:
• Identify and apply the steps in producing the software architecture.
• Use technology and information resources to research issues in software engineering.
• Write clearly and concisely about advanced software engineering topics using proper writing mechanics and technical style conventions.
Chapter 5
Designing
the Architecture
Shari L. Pfleeger
Joanne M. Atlee
4th Edition
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
Contents
5.1 The Design Process
5.2 Modeling Architectures
5.3 Decomposition and Views
5.4 Architectural Styles and Strategies
5.5 Achieving Quality Attributes
5.6 Collaborative Design
5.7 Architecture Evaluation and Refinement
5.8 Documenting Software Architectures
5.9 Architecture Design Review
5.10 Software Product Lines
5.11 Information System Example
5.12 Real-Time Example
5.13 What this Chapter Means for you
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
Chapter 5 Objectives
Examine different types of decomposition
Compare competing designs
Document the design
Verify architecture meets the requirements
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.1 The Design Process
Design is the creative process of figuring out how to implement all of the customer’s requirements; the resulting plan is also called the design
Early design decisions address the system’s architecture
Later design decisions address how to implement the individual units
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.1 The Design Process
Design is a Creative Process
Design is an intellectually challenging task
Numerous possibilities the system must accommodate
Nonfunctional design goals (e.g., ease of use, ease to maintain)
External factors (e.g., standard data formats, government regulations)
We can improve our design by studying examples of good design
Most design work is routine design, solve problem by reusing and adapting solutions from similar problems
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.1 The Design Process
Design is a Creative Process (continued)
Many ways to leverage existing solutions
Cloning: Borrow design/code in its entirety, with minor adjustments
Reference models: Generic architecture that suggests how to decompose the system
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.1 The Design Process
Design is a Creative Process (continued)
Reference model for a compiler
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.1 The Design Process
Design is a Creative Process (continued)
More typically, a reference model will not exist for the problem
Software architectures have generic solutions too, referred to as architectural styles
Focusing on one architectural style can create problems
Good design is about selecting, adapting, and integrating several architectural design styles to produce the desired result
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.1 The Design Process
Design is a Creative Process (continued)
Many tools for understanding options and evaluating chosen architecture, including:
Design patterns: generic solutions for making lower-level design decisions
Design convention or idiom: collection of design decisions and advice that, taken together, promotes certain design qualities
Design principles: descriptive characteristics of good design
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.1 The Design Process
Design Process Model
Designing software system is an iterative process
The final outcome is the software architecture document (SAD)
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.2 Modeling Architectures
Collection of models helps to answer whether the proposed architecture meets the specified requirements
Six ways to use the architectural models:
to understand the system
to determine amount of reuse from other systems and the reusability of the system being designed
to provide blueprint for system construction
to reason about system evolution
to analyze dependencies
to support management decisions and understand risks
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.3 Decomposition and Views
High-level description of system’s key elements
Creating a hierarchy of information with increasing details
Top
level
First level of
decomposition
Second level of
decomposition
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.3 Decomposition and Views
Popular Design Methods
Some design problems have no existing solutions
Designers must decompose to isolate key problems
Some popular design methods:
Functional decomposition
Feature-oriented decomposition
Object-oriented design
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.3 Decomposition and Views
Popular Design Methods
Functional decomposition
partitions functions or requirements into modules
begins with the functions that are listed in the requirements specification
lower-level designs divide these functions into subfunctions, which are then assigned to smaller modules
describes which modules (subfunctions) call each other
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.3 Decomposition and Views
Popular Design Methods
Feature-oriented decomposition
assigns features to modules
high-level design describes the system in terms of a service and a collection of features
lower-level designs describe how each feature augments the service and identifies interactions among features
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.3 Decomposition and Views
Popular Design Methods
Object-oriented decomposition
assigns objects to modules
high-level design identifies the system’s object types and explains how objects are related to one another
lower-level designs detail the objects’ attributes and operations
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.3 Decomposition and Views
Popular Design Methods (continued)
A design is modular when each activity of the system is performed by exactly one software unit, and when the inputs and outputs of each software unit are well-defined
A software unit is well-defined if its interface accurately and precisely specifies the unit’s externally visible behavior
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.3 Decomposition and Views
Architectural Views
Common types of architectural views include:
Dependencies view
Generalization view
Work-assignment view
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.3 Decomposition and Views
Dependencies View
The dependencies view shows dependencies among software units
This view is useful in project planning
Also useful for assessing the impact of making a design change to some software unit
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.3 Decomposition and Views
Generalization View
The generalization view shows software units that are generalizations or specializations of one another
This view is useful when designing abstract or extendible software units
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.3 Decomposition and Views
Work-assignment View
The work-assignment view decomposes the system’s design into work tasks that can be assigned to project teams
Helps project managers plan and allocate project resources, as well as track each team’s progress
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.4 Architectural Styles and Strategies
Pipes-and-Filter
Client-Server
Peer-to-Peer
Publish-Subscribe
Repositories
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.4 Architectural Styles and Strategies
Pipes-and-Filter
The system has
Streams of data (pipe) for input and output
Transformation of the data (filter)
The designer can understand the entire system’s effect on input and output as the composition of the filters
The filters can be reused easily on other systems
System evolution is simple
Encourages batch processing
Not good for handling interactive application
KEY
pipe
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.4 Architectural Styles and Strategies
Client-Server
Two types of components:
Server components offer services
Clients access them using a request/reply protocol
Client may send the server an executable function, called a callback
The server subsequently calls under specific circumstances
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.4 Architectural Styles and Strategies
Peer-to-Peer (P2P)
Each component acts as its own process and acts as both a client and a server to other peer components.
Any component can initiate a request to any other peer component.
Characteristics
Scale up well
Increased system capabilities
Highly tolerant of failures
Examples: Napster and Freenet
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.4 Architectural Styles and Strategies
Publish-Subscribe
Components interact by broadcasting and reacting to events
Component expresses interest in an event by subscribing to it
When another component announces (publishes) that event has taken place, subscribing components are notified
Implicit invocation is a common form of publish-subscribe architecture
Registering: subscribing component associates one of its procedures with each event of interest (called the procedure)
Characteristics
Strong support for evolution and customization
Easy to reuse components in other event-driven systems
Need shared repository for components to share persistent data
Difficult to test
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.4 Architectural Styles and Strategies
Repositories
Two components
A central data store
A collection of components that operate on it to store, retrieve, and update information
The challenge is deciding how the components will interact
A traditional database: transactions trigger process execution
A blackboard: the central store controls the triggering process
Knowledge sources: information about the current state of the system’s execution that triggers the execution of individual data accessors
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.4 Architectural Styles and Strategies
Repositories (continued)
Major advantage: openness
Data representation is made available to various programmers (vendors) so they can build tools to access the repository
But also a disadvantage: the data format must be acceptable to all components
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.4 Architectural Styles and Strategies
Combining Architectural Styles
Actual software architectures rarely based on purely one style
Architectural styles can be combined in several ways
Use different styles at different layers (e.g., overall client-server architecture with server component decomposed into layers)
Use mixture of styles to model different components or types of interaction (e.g., client components interact with one another using publish-subscribe communications
If architecture is expressed as collection of models, documentation must be created to show relation between models
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.4 Architectural Styles and Strategies
Combination of Publish-Subscribe, Client-Server, and Repository Architecture Styles
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.5 Achieving Quality Attributes
Architectural styles provide general beneficial properties. To support specific quality attribute tactics are utilized:
Modifiability
Performance
Security
Reliability
Robustness
Usability
Business goals
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.5 Achieving Quality Attributes
Modifiability
Design must be easy to change
Two classifications of affected software units:
Directly affected
Indirectly affected
Directly affected units’ responsibilities change to accommodate a system modification
Indirectly affected units’ responsibilities do not change, but implementations must be revised
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.5 Achieving Quality Attributes
Modifiability (continued)
Tactics for minimizing the number of software units affected by a change focus on clustering the anticipated changes:
Anticipate expected changes: Identify design decisions that are most likely to change, and encapsulate each in its own software unit
Cohesion: Keeping software units highly cohesive increases the chances that a change to the system’s responsibilities is confined to the few units that are assigned those responsibilities
Generality : The more general the software units, the more likely change can be accommodated by modifying a unit’s inputs rather than modifying the unit itself
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.5 Achieving Quality Attributes
Modifiability (continued)
Tactics for minimizing the impact on indirectly affected units focus on reducing dependencies
Coupling: Lowering coupling reduces the likelihood that a change to one unit will ripple to other units
Interfaces: If a unit interacts with other units only through their interfaces changes to one unit will not spread beyond the unit’s boundary unless its interface changes
Multiple interfaces: A unit modified to provide new data or services can offer them using a new interface to the unit without changing any of the unit’s existing interfaces
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.5 Achieving Quality Attributes
Performance
Performance attributes describe constraints on system speed and capacity:
Response time: How fast does our software respond to requests?
Throughput: How many requests can it process per minute?
Load: How many users can it support before response time and throughput start to suffer?
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.5 Achieving Quality Attributes
Performance
Tactics for improving performance include:
Improve utilization of resources
Manage resource allocation more effectively
First-come/first-served: Requests are processed in the order in which they are received
Explicit priority: Requests are processed in order of their assigned priorities
Earliest deadline first: Requests are processed in order of their impending deadlines
Reduce demand for resources
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.5 Achieving Quality Attributes
Security
Two key architectural characteristics particularly relevant to security: immunity and resilience
Immunity: ability to thwart an attempted attack
The architecture encourages immunity by:
Ensuring all security features are included in the design
Minimizing exploitable security weaknesses
Resilience: ability to recover quickly and easily from an attack
The architecture encourages resilience by:
Segmenting functionality to contain attack
Enabling the system to quickly restore functionality
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.5 Achieving Quality Attributes
Reliability
A software system is reliable if it correctly performs its required functions under assumed conditions
Is the software internally free of errors?
A fault is the result of human error, compared to a failure, which is an observable departure from required behavior
Software is made more reliable by preventing or tolerating faults
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.5 Achieving Quality Attributes
Robustness
A system is robust if it includes mechanisms for accommodating or recovering from problems in the environment or in other unit
Mutual suspicion: each software unit assumes that the other units contain faults
Robustness tactics differ from reliability tactics
Recovery tactics are similar:
Rollback to checkpoint state
Abort a transaction
Initiate a backup unit
Provide reduced service
Correct symptoms and continue processing
Trigger an exception
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.5 Achieving Quality Attributes
Usability
Usability reflects the ease in which a user is able to operate the system
User interface should reside in its own software unit
Some user-initiated commands require architectural support
There are some system-initiated activities for which the system should maintain a model of its environment
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.5 Achieving Quality Attributes
Business Goals
Business Goals are quality attributes the system is expected to exhibit (e.g., minimizing the cost of development and time to market)
Buy vs. Build
Save development time, money
More reliable
Existing components create constraints; vulnerable to supplier
Initial development vs. maintenance costs
Save money by making system modifiable
Increased complexity may delay release; lose market to competitors
New vs. known technologies
Acquiring expertise costs money, delays product release
Either learn how to use the new technology or hire new personnel
Eventually, we must develop the expertise ourselves
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.7 Architecture Evaluation and Refinement
Design is iterative: we propose design decisions, assess, make adjustments, and propose more decisions
Many techniques to evaluate the design:
Measuring design quality
Safety analysis
Security analysis
Trade-off analysis
Cost-benefit analysis
Prototyping
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.7 Architecture Evaluation and Refinement
Safety Analysis
Several techniques during design to identify possible faults
Fault-tree analysis traces backwards through a design
Trees then used to determine which faults to correct/avoid/tolerate
Data-flow graph: depicts the transfer of data from one process to another
Control-flow graph: depicts possible transfer of control among software units
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.7 Architecture Evaluation and Refinement
Safety Analysis (continued)
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.7 Architecture Evaluation and Refinement
Safety Analysis (continued)
Once fault tree is constructed we search for weaknesses
Cut-set tree reveals event combinations can cause failure
Rules for forming cut-set tree:
Assign the top node of the cut-set tree to match the logic gate at the top of the fault tree.
Working from the top down, expand the cut-set tree as follows:
Expand an or-gate node to have two children, one for each or-gate child
Expand an and-gate node to have a child composition node listing both of the and-gate children
Expand a composition node by propagating the node to its children, but expanding one of the gates listed in the node
Continue until all leaf nodes are basic events or composition nodes of basic events
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.7 Architecture Evaluation and Refinement
Safety Analysis (continued)
Once fault is found in design:
Correct the fault
Add components or conditions to prevent
Add components that detect fault and recover from damage
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.7 Architecture Evaluation and Refinement
Trade-off Analysis
Often several alternative designs to consider
professional duty to explore design alternatives and not simply implement the first design that comes to mind
different members of design team may promote competing designs
need a measurement-based method for comparing design alternatives
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.7 Architecture Evaluation and Refinement
Cost-Benefit Analysis
A cost–benefit analysis is a widely used business tool for estimating and comparing the costs and benefits of a proposed change
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.7 Architecture Evaluation and Refinement
Cost-Benefit Analysis and Computing Benefits
A cost–benefit analysis is a widely used business tool for estimating and comparing the costs and benefits of a proposed change
A cost-benefit analysis contrasts financial benefits with financial costs
Costs are one time capital expense
Benefits accrue overtime
Return on Investment (ROI)
ROI = Benefits/Cost
Payback period
the length of time before accumulative benefits recover the costs of implementation
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.8 Documenting Software Architectures
System’s architecture is vital to overall development and serves as the basis on decisions for:
Design
Quality assurance
Project management
The SAD serves as the repository for design information and includes:
System overview
Views
Software units
Analysis data and results
Design rationale
Definitions, glossary, acronyms
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.9 Architecture Design Review
Design review is an essential part of engineering practice
SAD quality is evaluated in two ways:
Validation: making sure the design satisfies all of the customer’s requirements (i.e., is this the right system?)
Verification: ensuring the design adheres to good design principles (i.e., are we building the system right?)
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.9 Architecture Design Review
Validation
Several key people included in review:
The analyst(s) who helped define the system requirements
The system architect(s)
The program designer(s) for this project
A system tester
A system maintainer
A moderator
A recorder
Other interested developers not otherwise involved in this project
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.9 Architecture Design Review
Verification
Judge whether it adheres to good design principles:
Is the architecture modular, well structured, and easy to understand?
Can we improve the structure and understandability of the architecture?
Is the architecture portable to other platforms?
Are aspects of the architecture reusable?
Does the architecture support ease of testing?
Does the architecture maximize performance, where appropriate?
Does the architecture incorporate appropriate techniques for handling faults and preventing failures?
Can the architecture accommodate all of the expected design changes and extensions that have been documented?
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.9 Architecture Design Review
Verification (continued)
Active design review: exercise the design document by using is in ways the developers will use the final document in practice
Passive review process: reading the documentation and looking for problems
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.10 Software Product Lines
Organizations can find success by reusing their expertise and software assets across families of related products
The corporate strategy for designing and developing the related products is based on the reuse of elements of a common product line
A distinguishing feature of building a product line is the treatment of the derived products as a product family; their simultaneous development is planned from the beginning
The family’s commonalities are described as a collection of reusable assets (including requirements, designs, code, and test cases), all stored in a core asset base
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.10 Software Product Lines
Core Asset Base
Candidate elements in a core asset base:
Requirements
Software architecture
Models and analysis results
Software units
Testing
Project planning
Team organization
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.10 Software Product Lines
Strategic Scoping
Product lines are based not just on commonalities among products but also on the best way to exploit them
First, employ strategic business planning to identify the family of products we want to build, using knowledge and good judgment to forecast market trends and predict the demand for various products
Second, scope the plans, so that the focus is on products that have enough in common to warrant a product-line approach to development. That is, the cost of developing the (common) product line must be more than offset by the savings we expect to accrue from deriving family members from the product line
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.10 Software Product Lines
Sidebar 5.8 Product-line Productivity
CelsiusTech AB, a Swedish naval defense contractor, motivated by desperation, transitioned from custom to product-line development. In 1985, the company, then Philips Elektronikindustier AB, was awarded two major contracts simultaneously, one for the Swedish Navy and one for the Danish Navy.
senior managers questioned whether they would be able to meet the demands of both contracts, particularly the promised (and fixed) schedules and budgets, using the company’s current practices and technologies.
Development of the product line and the first system were initiated at the same time; development of the second system started six months later. The two systems plus the product line were completed using roughly the same amount of time and staff that was needed previously for a single product. Subsequent products had shorter development timelines. On average, 70–80 percent of the seven systems’ software units were product-line units (re)used as is.
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.10 Software Product Lines
Advantages of Product-Line Architecture
A product lines promotes planned modifiability
Examples of product-line variability:
Component replacements
Component specializations
Product-line parameters
Architecture extensions and retractions
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.10 Software Product Lines
Product-Line Evolution
Key contributor to product-line success is having a product-line mindset
Company’s primary focus is development and evolution of product-line assets as opposed to individual products
Changes made to improve capability to derive products
Backwards capability
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.11 Information System Example
Piccadilly System
What might be a suitable architecture for the Piccadilly systems?
Key components
A repository of information
Address multiple heterogeneous queries
A typical reference architecture for an information system
n-tiered client-server architecture
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.12 Real-Time Example
Ariane-5 Failure
Inquiry found that the Ariane program had a “culture…of only addressing random hardware failures” and assuming the software was correct
Hardware failures are independent of one another
Software faults tend to be logical
All redundant components will have the same faults
Redundancy in Ariane-5 is likely to recover only from hardware failures
Pfleeger and Atlee, Software Engineering: Theory and Practice
Chapter 5.*
5.13 What This Chapter Means For You
Systems need to be designed based on carefully expressed requirements
Design begins with a high-level architecture, where architectural decisions are based not only on system functionality and required constraints but also on desirable attributes and the long-term intended use of the system (including product lines, reuse, and likely modification)
Keep in mind several characteristics of good architecture as you go, including appropriate user interfaces, performance, modularity, security, and fault tolerance
The goal is not to design the ideal software architecture for a system, because such an architecture might not even exist. Rather, the goal is to design an architecture that meets all of the customer’s requirements while staying within the cost and schedule constraints