Software Design and Architecture

Slides:



Advertisements
Similar presentations
Global Analysis and Distributed Systems Software Architecture Lecture # 5-6.
Advertisements

Software Quality Assurance Plan
Systems Analysis and Design in a Changing World
Chapter 8: Evaluating Alternatives for Requirements, Environment, and Implementation.
Object-Oriented Software Development CS 3331 Fall 2009.
What is Software Design?. Systems Development Life- Cycle Planning Analysis Design Implementation Design.
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Designing new systems or modifying existing ones should always be aimed at helping an organization achieve its goals State the purpose of systems design.
Software Configuration Management
MSIS 110: Introduction to Computers; Instructor: S. Mathiyalakan1 Systems Design, Implementation, Maintenance, and Review Chapter 13.
Software Requirements
Notion of a Project Notes from OOSE Slides - modified.
OHT 3.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 The need for comprehensive software quality requirements Classification.
Pertemuan Matakuliah: A0214/Audit Sistem Informasi Tahun: 2007.
EMBEDDED SOFTWARE Team victorious Team Victorious.
Data Structures and Programming.  John Edgar2.
This chapter is extracted from Sommerville’s slides. Text book chapter
SOEN 6011 Software Engineering Processes
CPTE 209 Software Engineering Summary and Review.
Software Testing Lifecycle Practice
Bayu Priyambadha, S.Kom Teknik Informatika Universitas Brawijaya.
1 ISA&D7‏/8‏/ ISA&D7‏/8‏/2013 Systems Development Life Cycle Phases and Activities in the SDLC Variations of the SDLC models.
 To explain the importance of software configuration management (CM)  To describe key CM activities namely CM planning, change management, version management.
Cluster Reliability Project ISIS Vanderbilt University.
Team Mason PFDA Contextual Architecture Oliver Rettig Team Leader Process Manager Planning Manager Lazar Crawford Design Manager Implementation Manager.
ITEC 275 Computer Networks – Switching, Routing, and WANs Week 12 Chapter 14 Robert D’Andrea Some slides provide by Priscilla Oppenheimer and used with.
Principles of Information Systems, Sixth Edition Systems Design, Implementation, Maintenance, and Review Chapter 13.
111 Notion of a Project Notes from OOSE Slides – a different textbook used in the past Read/review carefully and understand.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
16 1 Installation  After development and testing, system must be put into operation  Important planning considerations Costs of operating both systems.
Chapter 14 Part II: Architectural Adaptation BY: AARON MCKAY.
Chapter 7 Applying UML and Patterns Craig Larman
Principles of Information Systems, Sixth Edition Systems Design, Implementation, Maintenance, and Review Chapter 13.
Middleware for FIs Apeego House 4B, Tardeo Rd. Mumbai Tel: Fax:
Software Testing and Quality Assurance Software Quality Assurance 1.
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
Rational Unified Process Fundamentals Module 5: Implementing RUP.
Historical Aspects Origin of software engineering –NATO study group coined the term in 1967 Software crisis –Low quality, schedule delay, and cost overrun.
CEN5011, Fall CEN5011 Software Engineering Dr. Yi Deng ECS359, (305)
Object-Oriented Software Engineering using Java, Patterns &UML. Presented by: E.S. Mbokane Department of System Development Faculty of ICT Tshwane University.
Developing Business/IT Solutions Chapter 12 McGraw-Hill/IrwinCopyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
Module 4: Systems Development Chapter 14: Design And Implementation.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
Principles of Information Systems, Sixth Edition 1 Systems Design, Implementation, Maintenance, and Review Chapter 13.
Workforce Scheduling Release 5.0 for Windows Implementation Overview OWS Development Team.
SWE 513: Software Engineering
Feb. 9, 2004CS WPI1 CS 509 Design of Software Systems Lecture #4 Monday, Feb. 9, 2004.
1 Chapter 12 Configuration management This chapter is extracted from Sommerville’s slides. Text book chapter 29 1.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
CS223: Software Engineering Lecture 2: Introduction to Software Engineering.
What’s Ahead for Embedded Software? (Wed) Gilsoo Kim
Chapter 4 Requirements Engineering (1/3) Yonsei University 2 nd Semester, 2015 Sanghyun Park.
Software Engineering, COMP201 Slide 1 Software Requirements BY M D ACHARYA Dept of Computer Science.
ITEC 275 Computer Networks – Switching, Routing, and WANs Week 12 Chapter 14 Robert D’Andrea Some slides provide by Priscilla Oppenheimer and used with.
Tutorial 4 IT323.  Q1. As a software project manager in a company that specializes in the development of software for the offshore oil industry, you.
ITEC 275 Computer Networks – Switching, Routing, and WANs
Software Configuration Management
Classifications of Software Requirements
Data and database administration
Definition CASE tools are software systems that are intended to provide automated support for routine activities in the software process such as editing.
Chapter 5 – Requirements Engineering
The Development Process of Web Applications
Chapter 18 Maintaining Information Systems
The Systems Engineering Context
Software Architecture
Test Planning Mike O’Dell (some edits by Vassilis Athitsos)
Chapter 9 – Software Evolution and Maintenance
Chapter 7 –Implementation Issues
Software Testing Lifecycle Practice
Presentation transcript:

Software Design and Architecture Global Analysis Muhammad Nasir m.nasir@iiu.edu.pk

Agenda Global Analysis Factor Analysis Developing Strategies Organizational Factors Technological Factors Product Factors Developing Strategies

Global Analysis The purpose of the Global Analysis is two fold. Analyze the factors that influence the architecture And develop strategies for accommodating these factors in the architecture design.

Global Analysis We call it Global Analysis for three reasons: Many factors affect the entire system. So as the whole architecture. Global analysis occurs throughout the architecture design rather than at one point in time. Global analysis considers the factors as group not individually and develop strategies that accommodate all factors. As some factors contradict each other.

Analyzing the Factors The factors that effect the architecture design fall in to three categories. Organizational Factors Technological Factors Product Factors

Organizational Factors Organizational factors constraint the design choices. Some of them, such as development schedule and budget, apply only to a specific product being developed. Other organizational factors are organizational attitudes and software processes that effect every product. If you ignore these factors, the architecture may not be able to be implemented.

Typical Organizational Factors Q1: Management Build Versus Buy Schedule versus Functionality Environment Business Goals Q2: Staff skills, interests, strengths, weaknesses Application domain Specialized implementation techniques Specialized analysis techniques

Typical Organizational Factors Q3: Process and development environment Development platform Development Process and tools Configuration Management Process and Tools Production Process and Tools Testing Process and Tools Release Process and Tools Q4: Development Schedule Time to Market Delivery of features Release schedule Q5: Development Budget Head Count Cost of Development Tools

Technological Factors The Technological factors have a more obvious influence on the architecture. Architecture design choices are limited by the kind of software and hardware, architecture technology, and standards that are currently available. Technology changes over the period of time and product must adapt it and architecture should be designed with flexibility in mind.

Typical Technological Factors T1: General-purpose hardware Processors Network Memory Disk T2: Domain-specific Hardware Domain Specific Hardware Domain Specific Software T3: Software Technology Operating System User Interface Software Components Implementation Language Design Patterns Frameworks

Typical Technological Factors T4: Standards Operating system Database Data Formats Communication Algorithms and Techniques Coding Conventions

Product Factors Product factors are the primary influence on the architecture. This category covers the functional features of your product, and qualities like performance, dependability and cost. These factors may be different in future versions of the product, so your architecture should be designed to support the changes you can reasonably expect.

Typical Product Factors P1: Functional Features Functional Features P2: User Interface User Interaction Model User Interaction Features P3: Performance Sensor data rate Start-up and shutdown times Recovery Time P4: Dependability Availability Reliability Safety Dependability: The trustworthiness of a computing system which allows reliance to be justifiably placed on the service it delivers. Reliability: The term reliability refers to the ability of a computer-related hardware or software component to consistently perform according to its specifications. Safety: Safety is the state of being "safe" (from French sauf), the condition of being protected against physical, social, spiritual, financial, political, emotional, occupational, psychological, educational or other types or consequences of failure, damage, error, accidents, harm or any other event which could be considered non-desirable.

Typical Product Factors P5: Failure detection, reporting, recovery Error Classification Error Logging Diagnostics Recovery P6: Services Software Installation and upgrade Maintenance of domain-specific hardware Software testing Maintenance of Software P7: Product Cost Hardware Budget Software Licensing budget

Global Analysis Activities

Factor Analysis Activities Step 1: Identify and describe the Factors Step 2: Characterize the flexibility or the changeability of the Factors Step 3: Analyze the impact of the Factors

Sample Organizational Factor Table

Factor Analysis - Example Organizational Factor Flexibility/ Changeability Impact O2. Staff Skills Experience in multithreaded application. One in-house developer has this skill. The subject area is too complex to rely on training alone. There is moderate impact on meeting the performance

Factor Analysis - Example Organizational Factor Flexibility/ Changeability Impact O2. Development Schedule Time to market Time to market is two years There is no flexibility There can be a large impact on architecture choice. In commerce, time to market (TTM) is the length of time it takes from a product being conceived until its being available for sale. TTM is important in industries where products are outmoded quickly. A common assumption is that TTM matters most for first-of-a-kind products, but actually the leader often has the luxury of time, while the clock is clearly running for the followers.

Factor Analysis - Example Organizational Factor Flexibility/ Changeability Impact O2. Development Budget Head Count There are 12 developers The organization can hire one or two permanent developers or a large number of contractors There is a moderate impact on meeting the schedule. In commerce, time to market (TTM) is the length of time it takes from a product being conceived until its being available for sale. TTM is important in industries where products are outmoded quickly. A common assumption is that TTM matters most for first-of-a-kind products, but actually the leader often has the luxury of time, while the clock is clearly running for the followers.

Developing Strategies The second global analysis activity is to develop strategies for the architecture design. Developing strategies also has three steps Step 1: Identify Issues and Influencing Factors Step 2: Develop solutions and Specific Strategies Step 3: Identify Related Strategies

Step 1: Identify Issues and Influencing Factors Using the Factor table, Identify a handful of important Issues. An Issue may arise from limitation or constraints imposed by factors. E.g. Aggressive development schedule may take it impossible to satisfy all the product requirements.

Step 2: Develop solutions and Specific Strategies For each Issue develop strategies that address the issue and ensure the implementation of the architecture. Reduce the factor’s influence Reduce the overall time and effort.

Step 3: Identify Related Strategies Whenever a strategy belong to more than one issue, don’t repeat the strategy. Describe it at once and reference it whenever required. Use standard format to describe an strategy i.e. Issue Card

Issue Card

Developing Strategies - Example