CPSC 371 John D. McGregor Session 32 This is it..

Slides:



Advertisements
Similar presentations
Software Architecture in Practice (3 rd Ed) Understanding Quality Attributes Understanding the following: How to express the qualities we want our architecture.
Advertisements

May 2, May 2, 2015May 2, 2015May 2, 2015 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific University, Azusa, CA.
CPSC 872 John D. McGregor Session 22 Architecture Design, cont’d.
7.1 A Bridge to Design & Construction
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
Project Management – An Overview Project as a metaphor – a way to approach a series of activities Contexts – construction managementt, IT development,
Software Testing and Quality Assurance
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
Requirements Analysis Concepts & Principles
COMP 350: Object Oriented Analysis and Design Lecture 2
Agile Process: Overview n Agile software engineering represents a reasonable compromise to conventional software engineering for certain classes of software.
An Agile View of Process
An Overview of Agile L e a d i n g C h a n g e T h r o u g h C o l l a b o r a t i o n.
Kanban “Signboard”.
Scrum Fundamentals: Analyst to ‘Agilist’ By Louis Molnar (C) IAG Consulting 2009 The Agile Business Analyst By: Louis Molnar.
Software Development Process
S/W Project Management
CPSC 871 John D. McGregor Processes – a first iteration Module 1 Session 1.
CPSC 371 John D. McGregor Session 22 Process. Specification and design problem solution specification implementation specification.
Requirements Analysis
CPSC 871 John D. McGregor Module 1 Session 2 Requirements Elicitation/analysis.
1. 2  Have a basic understanding of the fundamental principles of object-oriented software development.  Understand a selection of the design patterns.
RUP Implementation and Testing
1 Chapter 5 Practice: A Generic View Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
1 Chapter 5 Software Engineering Practice. 2 What is “Practice”? Practice is a broad array of concepts, principles, methods, and tools that you must consider.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Coming up: Software Engineering: A Practitioner’s Approach, 6/e Chapter 5 Practice: A Generic View copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Programming in Java Unit 3. Learning outcome:  LO2:Be able to design Java solutions  LO3:Be able to implement Java solutions Assessment criteria: 
Some Sub-Activities within Requirements Engineering 1.Prototyping 2.Requirements Documentation 3.Requirements Validation 4.Requirements Measurements 5.Requirements.
AGILE SOFTWARE DEVELOPMENT PROCESSES Cheruku Smitha.
Software Life Cycle Models. Waterfall Model  The Waterfall Model is the earliest method of structured system development.  The original waterfall model.
Software Engineering Saeed Akhtar The University of Lahore Lecture 7 Originally shared for: mashhoood.webs.com.
CPSC 372 John D. McGregor Module 2 Session 1 More on requirements and the Investment Decision.
1 Introduction to Software Engineering Lecture 1.
Chapter 2 Iterative, Evolutionary, and Agile You should use iterative development only on projects that you want to succeed. - Martin Fowler 1CS
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
© Bennett, McRobb and Farmer Avoiding the Problems Based on Chapter 3 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design.
Roles in Software Development using Domain Specific Modelling Languages Holger Krahn, Bernhard Rumpe, Steven Völkel Software Systems Engineering Technische.
Object-Oriented Software Engineering using Java, Patterns &UML. Presented by: E.S. Mbokane Department of System Development Faculty of ICT Tshwane University.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 5 Practice: A Generic View Software Engineering: A Practitioner’s Approach, 6/e Chapter.
© 2007 BigVisible Solutions, Inc. All Rights Reserved Training Solutions Agile Training Game v
By Germaine Cheung Hong Kong Computer Institute
CPSC 371 John D. McGregor Session 7 Business Models.
Software Engineering Lecture # 1.
Software Engineering Jon Walker. What is Software Engineering? Why do we call it Software Engineering? Why not just call it programming or software development?
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
1 The Requirements Problem Chapter 1. 2 Standish Group Research Research paper at:  php (1994)
Requirement Engineering
CPSC 371 John D. McGregor Session 10 Requirements analysis methods.
AGILE - IMPLEMENTATION (C) CLARION TECHNOLOGIES. ability to move quickly and easily…. AGILE MEANING (LITERALLY)
Testing Overview Software Reliability Techniques Testing Concepts CEN 4010 Class 24 – 11/17.
Introduction to Software Engineering 1. Software Engineering Failures – Complexity – Change 2. What is Software Engineering? – Using engineering approaches.
CPSC 872 John D. McGregor Session 18 Evaluating Specification.
CPSC 872 John D. McGregor Session 31 This is it..
Kanban in Real World. ScrumMaster and Agile Ambassador at Trainer at Former developer.
Process 4 Hours.
Software & Software Engineering Pertemuan-4 Dosen :Kundang K Juman
Agile Software Development
Systems Analysis and Design
System Modeling Chapter 4
Introduction to Software Engineering
COMP 350: Object Oriented Analysis and Design Lecture 2
Agile Process: Overview
John D. McGregor Module 6 Session 1 More Design
Chapter 5 Understanding Requirements.
Chapter 4 System Modeling.
Presentation transcript:

CPSC 371 John D. McGregor Session 32 This is it.

The company is ready to begin development of a new product. We are at ground zero. How do we begin? Look to our process for new product development

Process

Specification and design problem solution specification implementation specification

Analysis Analysis is an attempt to understand We try to decipher what an acceptable solution will look like A team has some prior experiences that provide some starting points

Domain analysis Domain analysis is an examination of the broader set of ideas within which the problem is framed. The process by which a software engineer learns enough background information so that he or she can understand the problem and make good decisions during requirements analysis and other stages of the software engineering process

Context diagram Establishes the scope OBD II wireless OBD I wifibluetooth laptop Insurance rating system Cell phone

Use cases

QFD – House of Quality

Feature models

Configurations

Value chains How will we deliver value to customers? OBD to cell phone is a local app that uses bluetooth or USB The cell phone is the driver so the operating company is the principal capturer of value Cell phone to cloud is wireless/cellular connection so again the operator is in control Cloud provider captures value in storage fees

Business models purpose, business process, target customers, offerings, strategies, infrastructure, organizational structures, trading practices, and operational processes and policies.

Rationale for business models Because the business model affects the structure of the system and how we deliver value to customers A rapidly changing domain that is happy with approximations needs frequent releases A more slowly changing domain that requires accuracy needs more careful attention before a release.

Requirements User requirements have been identified through elicitation; written in the language of the customer Product requirements have been identified through domain analysis; written in the language of domain experts “Derived” requirements are constructed by making these other requirements more explicit; written in the language of the developer

Requirements Correct – Accurate representation of needed behavior Complete – Includes all needed behaviors Consistent – No requirement contradicts another

Structuring requirements Abstraction Partitioning – break system into parts such as ODB, phone, and cloud Projection – break system into views – such as data flow from car to cloud

Fault analysis

Error models How are errors to be handled?

Time points Abstract omits specific type information Concrete refers to actual types Type – a definition; a spec Instantiation – a realization of one instance of a type that will be populated with specific instances for each of its data members Design time – specifies what resources it will need Runtime – an instance bound to real resources

Quality attribute scenarios Source of stimulus: cell phone Stimulus: begin reading from bus Environment: OBD dongle is plugged in Artifact: data stream Response: Data begins to be transferred Response measure: data transferred at a rate equal to the read rate

Hazards

Eliciting requirements at scale – KJ Method Affinity groups - commonality must be's, satisfiers, and delighters.

Cyber-physical systems feedback control loop

Process

Agile Individuals and interactions over Processes and tools Working software over Comprehensive documentation Customer collaboration over Contract negotiation Responding to change over Following a plan That is, while there is value in the items on the right, we value the items on the left more.

Kanban It uses a work-in-progress limited pull system as the core mechanism to expose system operation (or process) problems and stimulate collaboration to continuously improve the system. It is rooted in four basic principles: Start with existing process Agree to pursue incremental, evolutionary change Respect the current process, roles, responsibilities and titles Leadership at all levels

CAS

V model

Increasing complexity in V&V

Car OBD Phone Cloud