CPSC 871 John D. McGregor MSumS1 Summary – the business of software engineering.

Slides:



Advertisements
Similar presentations
Configuration management
Advertisements

Prescriptive Process models
Chapter 13 Review Questions
System Integration Verification and Validation
1 Software Processes A Software process is a set of activities and associated results which lead to the production of a software product. Activities Common.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Product, Services, and Brands: Building Customer Value
1 Software Testing and Quality Assurance Lecture 15 - Planning for Testing (Chapter 3, A Practical Guide to Testing Object- Oriented Software)
8 Systems Analysis and Design in a Changing World, Fifth Edition.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Configuration Management
Software Life Cycle Model
Domain-Specific Software Engineering Alex Adamec.
Computer Systems & Architecture Lesson Software Product Lines.
Chapter 9 – Software Evolution and Maintenance
This chapter is extracted from Sommerville’s slides. Text book chapter
Chapter : Software Process
SEI´S Software Product Line Tenets Linda M. Northrop Software Engineering Institute IEEE Software July/August 2002.
CPSC 871 John D. McGregor Processes – a first iteration Module 1 Session 1.
Capability Assessment Process
CPSC 871 John D. McGregor MSumS2 Summary – technical issues in software engineering.
RUP Implementation and Testing
Cloud Computing 1. Outline  Introduction  Evolution  Cloud architecture  Map reduce operation  Platform 2.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
1 Process Engineering A Systems Approach to Process Improvement Jeffrey L. Dutton Jacobs Sverdrup Advanced Systems Group Engineering Performance Improvement.
Understand Application Lifecycle Management
 To explain the importance of software configuration management (CM)  To describe key CM activities namely CM planning, change management, version management.
CPSC 372 John D. McGregor Process Module 1 Session 1.
From Use Cases to Test Cases 1. A Tester’s Perspective  Without use cases testers will approach the system to be tested as a “black box”. “What, exactly,
Configuration Management (CM)
Creator: ACSession No: 16 Slide No: 1Reviewer: SS CSE300Advanced Software EngineeringFebruary 2006 (Software Quality) Configuration Management CSE300 Advanced.
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.
Coming up: Software Engineering: A Practitioner’s Approach, 6/e Chapter 5 Practice: A Generic View copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
Software Engineering - I
Fifth Lecture Hour 9:30 – 10:20 am, September 9, 2001 Framework for a Software Management Process – Life Cycle Phases (Part II, Chapter 5 of Royce’ book)
A Use Case Primer 1. The Benefits of Use Cases  Compared to traditional methods, use cases are easy to write and to read.  Use cases force the developers.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Software Product Line Material based on slides and chapter by Linda M. Northrop, SEI.
CPSC 371 John D. McGregor Session 32 This is it..
Chapter Eight Product, Services, and Brands: Building Customer Value Copyright ©2014 by Pearson Education, Inc. All rights reserved.
Rational Unified Process (RUP) Process Meta-model Inception Phase These notes adopted and slightly modified from “RUP Made Easy”, provided by the IBM Academic.
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 5 Practice: A Generic View Software Engineering: A Practitioner’s Approach, 6/e Chapter.
Configuration Management CSCI 5801: Software Engineering.
CSE 303 – Software Design and Architecture
Solution Supply Chains Jack Greenfield. Overview Learning from Other Industries Mass Customization in Software Development Implementing Supply Chains.
1 Chapter 12 Configuration management This chapter is extracted from Sommerville’s slides. Text book chapter 29 1.
CPSC 871 John D. McGregor Module 8 Session 1 Testing.
Process Asad Ur Rehman Chief Technology Officer Feditec Enterprise.
CPSC 871 John D. McGregor Module 6 Session 2 Validation and Verification.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Rational Unified Process Fundamentals Best Practices of Software Engineering Rational Unified Process Fundamentals Best Practices of Software Engineering.
Introduction to ITIL and ITIS. CONFIDENTIAL Agenda ITIL Introduction  What is ITIL?  ITIL History  ITIL Phases  ITIL Certification Introduction to.
CPSC 875 John D. McGregor C21 – A Platform Strategy.
Software Engineering Process - II 7.1 Unit 7: Quality Management Software Engineering Process - II.
CPSC 372 John D. McGregor Module 8 Session 1 Testing.
Chapter 25 – Configuration Management 1Chapter 25 Configuration management.
Software Project Configuration Management
CIM Modeling for E&U - (Short Version)
Chapter 11: Software Configuration Management
Chapter 18 Maintaining Information Systems
Systems Analysis – ITEC 3155 Evaluating Alternatives for Requirements, Environment, and Implementation.
Chapter 25: Architecture and Product Lines
Model-Driven Analysis Frameworks for Embedded Systems
Chapter 9 – Software Evolution and Maintenance
Chapter 11: Software Configuration Management
Chapter 2: Development process and organizations
Chapter 2: Building a System
Building a “System” Moving from writing a program to building a system. What’s the difference?! Complexity, size, complexity, size complexity Breadth.
Presentation transcript:

CPSC 871 John D. McGregor MSumS1 Summary – the business of software engineering

A Third Iteration First iteration – Went through process in detail – Setup and worked through an example app Second iteration – Looked at special topics – Implementation of app Third Iteration – Consolidation – A detailed summary and case studies

Outline of summary The big, high-level picture Contexts, business models and domains Types of applications Types of development processes An example Practice by practice

Your scenario The third iteration will dig into your scenario Take a minute and write a couple of sentences about your app. Who is the target audience? What are they like? For wireless charging, right now, we are targeting people who are pioneers. They are less interested in a smooth interface and more on control and access to the internals.

Ecosystem Business – Friend and foe interact directly or indirectly – Supply chains intersect – Prices and new features are indirect interactions Technical – Domain sets certain constraints on process – Life critical, mission critical, …

Ecosystem - 2 The canonical ecosystem scenario is a large organization (keystone) in discussions with other members of their ecosystem (niche players) decides to contribute a significant amount of code to the public domain. They establish a foundation that will own the IP of any contributed code and any code created as part of the foundation activity.

Ecosystems overlap and get fuzzy at the edges Automotive Consumer electronics The overlap is where culture clashes happen. The fast paced consumer electronics market and the slower, more conservative automotive market. This affects the qualities that are valued.

Ecosystem - 3 Whether there is a foundation, there are collaborative ventures among organizations An ecosystem will encompass a market Indirect influence will happen between organizations with the customer as the connection. Requirements volatility will depend upon the market and the domain.

Ecosystem - 4 Business models – Software to order – Bid on jobs – Software for market – In-house development staff Business strategy – One product at a time – Roadmap – Software product line

Case study - Hadoop Originated at Google Transferred to Apache Foundation In an area of intense research and development interest Since joining the Apache Foundation – Sub-projects of Hadoop have been promoted to independent top level projects – The ecosystem has exploded

Hadoop Supply Chain

Hadoop - 3 Hadoop is the infrastructure for Big Data analysis techniques Central architecture is Map/Reduce where algorithms are mapped to nodes that contain data, the algorithm massages the data and sends the result to an aggregator who aggregates results from several nodes and then sends the aggregated results to the next level of aggregation.

Software Product Line Management – Identifies a set of similar products – Or determines a line of business – Organizes the work force Organization – Core asset/product teams – Each person does some of both – Rotation between types of teams

Software Product Line - 2 Core asset team – Broad product line-wide view – Creates a product line architecture – Creates configurable assets to fit in the product line architecture – Accepts requests for new features/defect repairs – Maintains a set of priorities for quality attributes – Maintains a set of priorities for products

Software Product Line - 3 Product development teams – Focus on one product – One set of quality attribute priorities – A small set of product-specific requirements – Possibly multiple ways of satisfying a given product line requirement

Software Product Line - 4 A software product line might be the development strategy for a member of an ecosystem. If the member has responsibility for a particular kind of asset there might be a product line that produces variants on that asset. The ecosystem may define a product line.

Software product line If we are the in-house development team there will be multiple models of vehicles to address. If we are in the after-market there will be all the models of all of the manufacturers.

Software Product Line Case Study – Cummins Engines

A single product Most fundamental unit Organization must have a strategy by which this is profitable In some cases only way to profit is through product line Product is built through a combination of assembly and construction

Assembly Size of the pieces – May be a data structure from C++ Template Library – May be a browser component – May be an sdk Purchase commodity items Create unique, product-specific assets

Construction Use languages, tools to build pieces – Craftsman approach – “normal” approach – Hacking approach Choose appropriate levels of quality – What are the risks? – What are the costs?

Tracking assets Versions, releases, builds – Build – a single pass through compilation, binding and provisioning; happens many times a day – Release – a published build, e.g. nightly build for an open source project; happens at most n times a day; automated test suite is passed – Version – a polished release that has significant new functionality from previous version; test suite passed – Product – a set of envisioned features delivered incrementally over several releases

A single release Each product goes through an evolution of multiple versions.

Certification - Personal IEEE – software engineering certification Oracle, Microsoft, etc Certificates in specific areas such as systems engineering

Certification - Organization Capability Maturity Model, Integrated 5 levels: initial, managed, defined, quantitatively managed, optimizing Independent “registrars” are licensed to evaluate and rate an organization Measuring conformance to the standard for each level

Certification - Product Conformance to rules/regulations FAA, FDA, etc For wireless charging maybe the Good Housekeeping Seal of Approval Usually focus on the process rather than doing testing on their own Independent testing labs for product features such as Bluetooth compatibility

Summary The wireless charging app needs to be engineered to meet the rigorous standards of the automotive industry but should have the bells and whistles of a consumer product. A product line approach will help handle the many models of cars available.