1 What Should Software Engineering Consist of? An Industry Experience Perspective Paul E. McMahon, Principal PEM Systems

Slides:



Advertisements
Similar presentations
Microsoft Operations Framework (MOF) 4.0
Advertisements

The design process IACT 403 IACT 931 CSCI 324 Human Computer Interface Lecturer:Gene Awyzio Room:3.117 Phone:
SEP1 - 1 Introduction to Software Engineering Processes SWENET SEP1 Module Developed with support from the National Science Foundation.
Ray C. Rist The World Bank Washington, D.C.
1 © 2003 Natural SPI Acquiring Process Expertise & Tools: A Fact-Based Methodology Acquiring Process Expertise and Tools: A Fact-Based Methodology.
SOCIAL MEDIA FOR CONSUMER INSIGHT Chapter Chapter Objectives  Describe the types of data used in social media research  Explain the different.
W5HH Principle As applied to Software Projects
Process Improvement.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 28 Slide 1 Process Improvement.
SWE Introduction to Software Engineering
Fundamentals of Information Systems, Second Edition
1 Introduction to System Engineering G. Nacouzi ME 155B.
SE 555 Software Requirements & Specification Requirements Validation.
Week 13: Micro-Theories Quiz Theories Coaching activity Cognitive resources theory Vroom Normative Model Team Task.
Fundamental of Software Project Management Team Assignment 1 – K15T2 – Team 07.
Project Execution.
Change Request Management
SOFTWARE QUALITY ASSURANCE Asst. Prof. Dr. Selim BAYRAKLI Maltepe University Faculty of Engineering SE 410.
Release & Deployment ITIL Version 3
The design process z Software engineering and the design process for interactive systems z Standards and guidelines as design rules z Usability engineering.
Chapter : Software Process
“It’s not our differences that divide us, it’s our judgments about each other that do.” (Meg Wheatly)
CPTE 209 Software Engineering Summary and Review.
Software Project Management Lecture # 8. Outline Chapter 25 – Risk Management  What is Risk Management  Risk Management Strategies  Software Risks.
Capability Maturity Model. Reflection Have you ever been a part of, or observed, a “difficult” software development effort? How did the difficulty surface?
Thirteenth Lecture Hour 8:30 – 9:20 am, Sunday, September 16 Software Management Disciplines Process Automation (from Part III, Chapter 12 of Royce’ book)
Software Project Management Lecture # 8. Outline Earned Value Analysis (Chapter 24) Topics from Chapter 25.
Fourteenth Lecture Hour 9:30 – 10:20 am, Sunday, September 16 Software Management Disciplines Project Control and Process Automation (from Part III, Chapter.
1 REQUIREMENT ENGINEERING Chapter 7. 2 REQUIREMENT ENGINEERING Definition Establishing what the customer requires from a software system. OR It helps.
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.
Introduction to Software Engineering LECTURE 2 By Umm-e-Laila 1Compiled by: Umm-e-Laila.
S S I E M E N S C O R P O R A T E R E S E A R C H 1 SCR SE Architecture Requirements Engineeering Theory vs. Practice Bob Schwanke STRAW ‘03.
Centro de Estudos e Sistemas Avançados do Recife PMBOK - Chapter 4 Project Integration Management.
Service Transition & Planning Service Validation & Testing
Software Project Management Lecture # 7. Outline Project Scheduling.
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,
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.
Product Research Product development marketing research serves several goals: new product design and market validation research, or assessing existing.
10/16/2015Bahill1 Organizational Innovation and Deployment Causal Analysis and Resolution 5 Optimizing 4 Quantitatively Managed 3 Defined 2 Managed Continuous.
1 Knowledge & Knowledge Management “Knowledge is power” to “Sharing K is power” Yaseen Hayajneh, PhD.
Georgia Institute of Technology CS 4320 Fall 2003.
Welcome to ND System Solutions Ray Bareiss VP of Engineering ND System Solutions.
Integrated Risk Management Charles Yoe, PhD Institute for Water Resources 2009.
The Roadmap to Software Factories Tools, Patterns and Frameworks.
Assessing the influence on processes when evolving the software architecture By Larsson S, Wall A, Wallin P Parul Patel.
Software Engineering - I
Fundamentals of Information Systems, Second Edition 1 Systems Development.
 Copyright ProcessVelocity, LLP Slides intended for informational purposes only. CMM and Capability Maturity Model are registered in the U.S. Patent.
ANKITHA CHOWDARY GARAPATI
1 The Good, the Bad, and the Ugly: Collecting and Reporting Quality Performance Data.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Software Engineering Chapter: Computer Aided Software Engineering 1 Chapter : Computer Aided Software Engineering.
SOFTWARE ENGINEERING. Objectives Have a basic understanding of the origins of Software development, in particular the problems faced in the Software Crisis.
Software Project Management Lecture # 9. Outline Chapter 25 – Risk Management  What is Risk Management  Risk Management Strategies  Software Risks.
The Software Engineering Process Discussion Slides.
1 Summary and Analysis of Position Statements Assessment Track Paul E. McMahon (sitting in for Watts Humphrey)
+ Informatics 122 Software Design II Lecture 13 Emily Navarro Duplication of course material for any commercial purpose without the explicit written permission.
1 1 Effective Administration of Commercial Contracts Breakout Session # Session D06 Name: Holly Walker, CPCM Corporate Learning Solutions and Contract.
© NALO Solutions Limited NALO Solutions, presents the – Revenue Collector App Using Mobile Phones to gather Revenue SOFTWARE ENGINEERING.
Class 6 Highlights Project Management: Control, Auditing & Closure, Ethics & Social Responsibility.
Configuration Control (Aliases: change control, change management )
CSC 480 Software Engineering Team Issues. Essence of a Successful Team To be successful, teams must  Plan their projects  Track their progress  Coordinate.
Change Request Management
CSSSPEC6 SOFTWARE DEVELOPMENT WITH QUALITY ASSURANCE
Software Project Management
Presentation transcript:

1 What Should Software Engineering Consist of? An Industry Experience Perspective Paul E. McMahon, Principal PEM Systems

2 Cost Improvement Theory CMMI Level Industry Experience Observation Theory indicates as CMMI maturity rises so should productivity Experience beyond level 3 In some organizations is the reverse Is theory underlying CMMI wrong?

3 Position and Challenge Position –CMMI model based on solid theory –Not doing adequate job bridging theory to practice Challenge: –This is where Software Engineering & SEMAT should help

4 TDP Reqts Desgn Sw VerDoc Measures Derived Meas Decision Aids Communication Stakeholders Tasks Task Resp Progress Track Developer Reviewer Approver Customer Kernel Core Sub-elements Decision Aids Derived Meas Paper presents 4 Core element kernel supporting position Focus here is Motivation..

5 1 st Kernel Element: Technical Data Package (TDP) TDP is “center-piece” of the kernel –Think of this as whatever the customer is buying –Kernel must be “customer product centric” Motivation: –Goal to satisfy customer –Everything else must be justified in terms of contribution to goal

6 2 nd : Simple Stakeholder element Based on clearly defined roles & responsibilities Motivation: –Common root cause of immature software practices today is failure to involve right people at right time –This is where Teamwork fits in the kernel –People need help with “decisions” related to who to involve and when –This is where Software Engineering (and SEMAT) should help

7 TDP Reqts Desgn Sw VerDoc Measures Derived Meas Decision Aids Communication Stakeholders Tasks Task Resp Progress Track Decision Aids Developer Reviewer Approver Customer Kernel Core Sub-elements Note: Appropriate Teamwork based on roles & responsibilities Decision Aids..In context of product..

8 3 rd : Communication Think of this element as project management –Must be “integrated”, not an interface Motivation: –Another common cause of “immature practices” is failure to communicate current accurate task status, including decisions faced and risks –People need help articulating options, potential consequences & rationale for decisions –This is another area where Software Engineering (and SEMAT) can help

9 TDP Reqts Desgn Sw VerDoc Measures Derived Meas Decision Aids Communication Stakeholders Tasks Task Resp Progress Track Decision Aids Developer Reviewer Approver Customer Kernel Core Subelements Note: Integrated, Not an “interface” Decision Aids..In context of product..

10 4 th : Measurement Measurement is another example where failing to “bridge” theory to practice Watts Humphrey provided solid theory in “A Discipline for Software Engineering” written over 15 years ago –Importance of “deriving” context specific measures emphasized Yet today some CMMI level 5 organizations continue to collect “standard measures” that are not providing the intended value

11 We Can Do Better & We Are Better There exist great organizations that are doing it right today –E.g. some have automated parts of their software process through domain-specific solutions and tools simplifying their most common occurring decisions

12 TDP Reqts Desgn Sw VerDoc Measures Derived Meas Decision Aids Communication Stakeholders Tasks Task Resp Progress Track Decision Aids Developer Reviewer Approver Customer Note: Domain-Specific, Product-Specific, Project-Specific..In context of product..

13 What Does it Mean to “Engineer” Software? Alistair Cockburn has suggested when we think of “engineering” software we should think about the “decisions” and “tradeoffs” Software Engineering should provide more help in “how-to engineer software” –Not to give you the answers (e.g. object-oriented) –But to help with the “reasoning process” to find the right answer given your specific project and product conditions People need better “decision-guidance”

14 How SEMAT Can Help Cost Transferring Theory To Practice CMMI Level Industry Experience Total Life Cycle Cost Investment Cost Poor investment decisions Better Investment decisions Need Better “Decision-Guidance” based on Real Factors Specific to Environment faced

15 Position Summary Caution against developing a “new theory” We are further ahead than many realize Challenge: Extract what we know works along with the reasoning process behind it & then institutionalize it as part of what it means to “engineer software” by making better decisions