Architectural Design Resolution Analyzed SRS Architectural Design Process Develop Architectural Design Alternatives Evaluate Architectural Alternatives.

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

Configuration Management
Requirements Specification and Management
1 Information Systems Development (ISD) Systems Development Life Cycle Overview of Analysis Phase Overview of Design Phase CP2236: Information Systems.
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Alternate Software Development Methodologies
Tietojärjestelmien peruskurssi Software engineering Malin Brännback.
Introduction To System Analysis and Design
Software Quality Metrics
© Prentice Hall CHAPTER 9 Application Development by Information Systems Professionals.
Chapter 6 Database Design
SE 555 Software Requirements & Specification Requirements Management.
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
Fundamentals of Information Systems, Second Edition
©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart 18-1 Accounting Information Systems 9 th Edition Marshall.
SE 555 Software Requirements & Specification Requirements Validation.
1 SOFTWARE QUALITY ASSURANCE Basic Principles. 2 Requirements System Design Detailed Design Implementation Installation & Testing Maintenance SW Quality:
7.2 System Development Life Cycle (SDLC)
9 1 Chapter 9 Database Design Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel.
1 Computer Systems & Architecture Lesson 1 1. The Architecture Business Cycle.
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Introduction to Software Testing
© 2006, Cognizant Technology Solutions. All Rights Reserved. The information contained herein is subject to change without notice. Automation – How to.
Data Structures and Programming.  John Edgar2.
CORE 1: PROJECT MANAGEMENT Overview TECHNIQUES FOR MANAGING A PROJECT Communication Skills Active Listening Mirroring Paraphrasing Summarizing Clarifying.
This chapter is extracted from Sommerville’s slides. Text book chapter
Web Development Process Description
S/W Project Management
System Analysis & Design Introduction: System Analysis and design course intents to help students understand its importance in developing systems that.
INFORMATION SYSTEM APPLICATIONS System Development Life Cycle.
What is Software Engineering? the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software”
CLEANROOM SOFTWARE ENGINEERING.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Architecture Business Cycle
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
What is a life cycle model? Framework under which a software product is going to be developed. – Defines the phases that the product under development.
Week 4 Lecture Part 3 of 3 Database Design Samuel ConnSamuel Conn, Faculty Suggestions for using the Lecture Slides.
A GENERIC PROCESS FOR REQUIREMENTS ENGINEERING Chapter 2 1 These slides are prepared by Enas Naffar to be used in Software requirements course - Philadelphia.
Principles of Information Systems, Sixth Edition Systems Design, Implementation, Maintenance, and Review Chapter 13.
 CS 5380 Software Engineering Chapter 2 – Software Processes Chapter 2 Software Processes1.
Testing Workflow In the Unified Process and Agile/Scrum processes.
1 CS 426 Senior Projects Chapter 3: The Requirements Workflow [Arlow & Neustadt, 2005] January 31, 2012.
INFO 637Lecture #51 Software Engineering Process II Defining Requirements INFO 637 Glenn Booker.
Approaching a Problem Where do we start? How do we proceed?
Software Development Cycle What is Software? Instructions (computer programs) that when executed provide desired function and performance Data structures.
Lecture 7: Requirements Engineering
SYSTEMS ANALYSIS AND DESIGN LIFE CYCLE
Introduction to Software Development. Systems Life Cycle Analysis  Collect and examine data  Analyze current system and data flow Design  Plan your.
University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 systems analysis 1 what is systems analysis? preparation of the system’s requirements/definition,
1 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Use cases.
Software Life Cycle The software life cycle is the sequence of activities that occur during software development and maintenance.
Software Requirements: A More Rigorous Look 1. Features and Use Cases at a High Level of Abstraction  Helps to better understand the main characteristics.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
A Metrics Program. Advantages of Collecting Software Quality Metrics Objective assessments as to whether quality requirements are being met can be made.
CASE (Computer-Aided Software Engineering) Tools Software that is used to support software process activities. Provides software process support by:- –
Principles of Information Systems, Sixth Edition 1 Systems Design, Implementation, Maintenance, and Review Chapter 13.
Software Engineering Lecture # 1.
1 Chapter 12 Configuration management This chapter is extracted from Sommerville’s slides. Text book chapter 29 1.
Software Requirements Specification Document (SRS)
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Product Design Alternative Generation, Evaluation, and Selection.
Chapter 3: The Requirements Workflow [Arlow and Neustadt, 2005] CS 426 Senior Projects in Computer Science University of Nevada, Reno Department of Computer.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
System Development Life Cycle (SDLC). Activities Common to Software Projects Planning : Principles Principle #1. Understand the scope of the project.
 System Requirement Specification and System Planning.
The Development Process of Web Applications
Chapter 6 Database Design
Information Systems Development (ISD) Systems Development Life Cycle
System Analysis and Design:
Presentation transcript:

Architectural Design Resolution Analyzed SRS Architectural Design Process Develop Architectural Design Alternatives Evaluate Architectural Alternatives Select Architectural Resolution Finalize Software Architectural Document SAD [selected ] [else ]

Various Alternatives to Generating Architectural Design 1.Develop Functional Components –Based on transforming SRS functions and data requirements 2.Determine/Modify Components Based on “Quality Attributes”: maintainability, reusability, performance, availability & security (non-functional attributes) –Based on transforming non-functional SRS requirements 3.Modifying Existing Architecture (for follow-on releases) –Based on existing architecture as a starting point and transforming it to satisfy the new system 4.Elaborate an Architecture Style (chapter 15) –Based on an existing architectural style and elaborate on that style 5.Transform a Conceptual Model (chapter 11-Destailed Design) –Based on viewing the SRS problem description as a solution description and transforming that to fit the new system from scratch

Architectural Design (team or individual activity?) In software engineering, many activities are performed as a team effort --- for –Productivity –Quality –Morale and General Acceptance But for Architectural Design: 1.Better done as an individual first 2.Bring together all the individual architectural design suggestions 3.Evaluate the alternatives

Determine Functional Components (Using the “AquaLush Irrigation System” Example in textbook – p.82 and p.164) AquaLush Product Vision: The AquaLush Irrigation system will use soil moisture sensors to control irrigation, thus saving money for customers and making better use of water resources. AquaLush Major Product Features (from requirements): 1. - Monitor water usage and limit usage (by moisture level) to amounts set by users 2. - Allow users to specify times when irrigation occurs 3. - Be operated from a simple central control panel 4. - Have a web-based simulator 5. - Allow users to monitor parts and schedule repairs What would you list as major “functional components ?” (e.g.) 1. user interface to initialize, set-up, monitor and control the irrigation system 2. sensor inputs processing 3. water irrigation control 4. web-based simulator 5. parts monitor and repair

Determining Functional Components from SRS (page 289 – 291textbook solution) 1. configure the program at startup 2. controlling irrigation (manually and automatically) 3. providing a user interface 4. allowing users to monitor and repair system > User Interface > Irrigation Control > Monitor and Repair > Startup Do the functional components and the relation “lines” make sense to you? (Should there be a line between User Interface and Startup ?) From page 180 From page 289

Determining Functional Components (page 289 – 291textbook solution for product) 1. configure the program at startup 2. controlling irrigation (manually and automatically) 3. providing a user interface 4. allowing users to monitor and repair system > User Interface > Irrigation Control > Monitor and Repair > Startup AquaLush Parts Status AquaLush Configuration > Note that Monitor and Repair component can use the Data Store to communicate with Irrigation Control component, without a line between them. How initialized?

Component Responsibilities There needs to be some description of each component’s responsibilities: –User Interface: interacts with control panel hardware and implements control panel interface; obtains data from Monitor and Repair –Monitor and Repair: Obtains data from Parts Status to pass on to –Irrigation Control: Controls valve, reads sensors; reads clock; implements irrigation cycles; --- –Startup: reads the configuration data of valves, zones, etc. and send them to Irrigation Control & (also alternatively also include Monitor Repair) ---- –Parts Status: a database that keeps track of all failed and repaired parts, etc. –Configuration: a database of all the installed parts of valves, sensors, etc. of the customer’s Aqualush system

Determining Functional Components (page 293 textbook - for adding web- simulator) > Simulating User interaction > Irrigation Control > Monitor and Repair > Startup AquaLush Parts Status AquaLush Configuration > Simulating Valves and sensors Same initialization problem?

Determining Components based on “non-Functional” or “Quality’ attributes AquaLush has the following non-functional (NF) requirements: –Reusability : design must be used in the product, web- simulator, and future versions –Hardware adaptability: design should consider adaptability to multiple valve types, sensor types, keypads, and screen display types –Reliability: must not fail “often” in normal usage –Modifiability: accommodate future changes in irrigation strategy (formula) Note that reliability of not failing “often” is a nebulous and subjective statement

NonFunctional: Reusability Attribute Requires components to be cohesive and loosely coupled so that they can be reused. Consider each component for these: –Would you subdivide User Interface/interaction component into several subcomponents (interface to Irrigation Control and to Monitor and Repair separately)? –Would you separate out Irrigation Control component into a) manual and b) auto subcomponents? - etc. Irrigation Control Manual controlautomatic control

NonFunctional : Hardware Adaptability & Modifiability Requires the component to have device adaptability also implies –separate cohesive subcomponents –low coupling subcomponents, each representing different device –hide the device specific internals and keep the interface unchanging In AquaLush, the Irrigation Control has interfaces to multiple devices. In AquaLush, Monitor and Repair component and Startup component has interface to a data-store Virtual Device Interface valve sensorkeypad display Screen buttons Everything inside the Device Interface components are device dependent, but hidden from outside; all interfaces to outside of the component should stay stable May change algorithm based on different sensors How would you design a single read/write “interface” ?

NonFunctional: Reliability and other components Reliability may be argued many ways: –Small cohesive module is by definition more reliable –Add user interface to control irrigation both manually and automatically AND also have direct control of the devices User Interface Irrigation Control manualauto Virtual Device Interface valveSensordisplay keypad Screen buttons Agree with all the interaction lines ? Do we need a new component ? Emergency Control Designer’s view of providing reliability ---- “ not fail often in normal usage”

Design Alternatives Design alternatives are good to have and can improve the design: –Generate and document these alternatives as the design is getting formulated –Combine some of the parts of the generated design alternatives from: Functional Components Non-functional Components –Try to alter and fit to an existing Design Style, if applicable

Architectural Design Resolution Analyzed SRS Architectural Design Process Develop Architectural Design Alternatives Evaluate Architectural Alternatives Select Architectural Resolution Finalize Software Architectural Document SAD [selected ] [else ]

Evaluating Architecture Alternatives What does one look at when evaluating architecture? –Would the architecture result in a system that will satisfy: 1.Functionality requirements 2.“Quality” (non-functional) requirements –Maintainability –Reusability –Performance –Availability –Reliability –Security –Would the architecture result in a system that will Have “great” user experience or user interface Delight the customer and the users We can not tell what will happen since the architecture is not code, we can only “guess” whether the architecture will most likely meet the above conditions

An Architecture Evaluating Technique Utilize a “profile,” which is a set of scenarios generated to fit the characteristics of interest. (e.g.) –Usage profile is a set of scenarios that describes the user requirements (sometimes known as regular “business” workflow) –Reliability profile is a set of scenarios that portrays the non- functional requirement of how a system behaves under adverse situations –Performance profile is a set of scenarios that portrays the non- functional requirements of how a system behaves under time limit constraints or capacity limit constraints – etc. Each architecture alternative is evaluated by going through the scenarios in the profile and assessing whether the architecture, if implemented, would satisfy the profile.

Developing Profiles with “utility tree” A utility tree is a tree whose each sub-tree is a “profile” and the leaves of the sub-tree are the scenarios for that profile Utility tree Functionalities Irrigation control (automatic) Irrigation control (manual) Maintenance repair Hardware adaptability Valve type modification Adding new valve types 1. The profiles are generated, using SRS and some brainstorming 2. The scenarios within each profile are also developed using SRS, ‘team’ brainstorming, and prioritizations. 3. Within each profile, keep the number of scenarios to 3 to Each scenario should include: - initial state - activity flow involving actors and the product - post activity state * * think of special circumstances and non-traditional scenarios, too

Another Architecture Evaluating Technique Build a “prototype” of part of or the complete software product to evaluate certain aspects (functional and non-functional) of the product. –Advantages: Can provide measurements Can provide experiential feedbacks –Disadvantages: Prototypes takes resources Prototypes takes time Much of the prototyping and profiling techniques are aimed at evaluating the architecture against the “basic” design principles (discussed earlier) : - feasibility, - adequacy, - economy, and - changeability

Selecting Alternatives How do we select the architecture from the various alternatives ? –Evaluate the Pros and Cons of each of the alternatives By Number of pros and cons By Weights of pros and cons –Multi-dimensional analysis table (p. 306 of text): A Column of scenarios –Weight for each scenario (use normalized weight so each is a fraction of the total and the total is 1) A Column for each architectural alternative –Rate all the scenarios for that alternative ( e.g. 1-5) –Score the scenario by multiplying the scenario weight and the rate –Sum the scores for that alternative Compare the total score for each of the architectural alternatives

Architectural Design Resolution Analyzed SRS Architectural Design Process Develop Architectural Design Alternatives Evaluate Architectural Alternatives Select Architectural Resolution Finalize Software Architectural Document SAD [selected ] [else ]

Finalizing The Architectural Design This step ensures that the selected architecture does satisfy the various functional and non-functional requirements (and possibly may delight the users) and is clearly documented. –Architectural design satisfying the “basic” design principles of: Feasibility Adequacy Economy Changeability –Also, The SAD document itself is Well formed (organized) Complete (include all the components/relationships/descriptions) Clear (understandable by others) Consistent (no conflicting information) (from chapter 8 of text) Think about these for your assignment 4

Design Review in Finalizing the SAD A Review is an examination and evaluation of the work by qualified and affected stakeholders There are many different types of “reviews”: 1. Desk Check – by the author 2. Walkthrough – informal review by team members 3. Inspection – formal review by a trained inspection team with moderator 4. Audit – review conducted by experts who are not part of the team 5. Active Review – inspection by experts who answer specific aspects of the design (this allows pinpoint reviews and is less costly) A “Formal inspection” requires 3 formal steps: - preparation - conducting the inspection - rework and inspection “closeout” report