Talking About Concerns... James D. Herbsleb School of Computer Science Carnegie Mellon University.

Slides:



Advertisements
Similar presentations
Software Re-engineering
Advertisements

Ch 3 System Development Environment
Software Processes Coherent sets of activities for specifying, designing, implementing and testing software systems.
ArchE Presented By Samanvitha Ramayanam. TOPICS 1. Introduction 2. Theoretical assumptions 3. ArchE as an expert system 4. Overall flow of ArchE 5. Key.
Software Engineering 1 Evolutionary Processes Lesson 11.
4.1 Blended approaches: Information Engineering IMS Information Systems Development Practices.
Design Activities in Usability Engineering laura leventhal and julie barnes.
Architecture is More Than Just Meeting Requirements Ron Olaski SE510 Fall 2003.
11 3 / 12 CHAPTER Databases MIS105 Lec14 Irfan Ahmed Ilyas.
Introduction to Databases Transparencies
Chapter 1 Assuming the Role of the Systems Analyst
Chapter 2: IS Building Blocks Objectives
1 Computer Systems & Architecture Lesson 1 1. The Architecture Business Cycle.
ES305: Virtual Tools in Engineering Design: The Eng. Design Process James Carroll, Associate Professor Electrical and Computer Engineering.
Galin, SQA from theory to implementation © Pearson Education Limited Chapter 13 CASE Tools and their Effect on Software Quality.
CSC230 Software Design (Engineering)
GROUP COMMUNICATION. PURPOSE OF GROUP COMMUNICATION To share and exchange information and ideas To collect information or feedback on any project/policy/scheme.
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Case Studies Instructor Paulo Alencar.
Robots at Work Dr Gerard McKee Active Robotics Laboratory School of Systems Engineering The University of Reading, UK
Software Reengineering 2003 년 12 월 2 일 최창익, 고광 원.
Software Re-engineering
Human Interface Engineering1 Main Title, 60 pt., U/L case LS=.8 lines Introduction to Human Interface Engineering NTU Seminar Amy Ma HIE Global Director.
Introduction to Systems Analysis and Design Trisha Cummings.
Supporting the CCSS in the Science Classroom through the Science and Engineering Practices of the Next Generation Science Standards (NGSS) John Spiegel.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
Chapter 5 Teaching with Software Tools: Beyond the Basic Programs
UML - Development Process 1 Software Development Process Using UML (2)
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Does Distributed Development Affect Software Quality???? An Empirical Case Study of Windows Vista Christian Bird, Premkumar Devanbu, Harald Gall, Brendan.
9/14/2012ISC329 Isabelle Bichindaritz1 Database System Life Cycle.
Sharad Oberoi and Susan Finger Carnegie Mellon University DesignWebs: Towards the Creation of an Interactive Navigational Tool to assist and support Engineering.
Kesting Ventures® Corp. 1 KVC Knowledge Planning Market Value System Modules and Programs.
1 James Herbsleb Carnegie Mellon University The Architecture of Coordination The author gratefully acknowledge.
Role-Based Guide to the RUP Architect. 2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout.
OBJECT ORIENTED SYSTEM ANALYSIS AND DESIGN. COURSE OUTLINE The world of the Information Systems Analyst Approaches to System Development The Analyst as.
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
Lecture 3 Software Engineering Models (Cont.)
1-1 System Development Process System development process – a set of activities, methods, best practices, deliverables, and automated tools that stakeholders.
Synthetic Cognitive Agent Situational Awareness Components Sanford T. Freedman and Julie A. Adams Department of Electrical Engineering and Computer Science.
Approaching a Problem Where do we start? How do we proceed?
1 Systems Analysis and Design in a Changing World, Thursday, January 18, 2007.
Information Systems Engineering. Lecture Outline Information Systems Architecture Information System Architecture components Information Engineering Phases.
ANKITHA CHOWDARY GARAPATI
McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 2 Information System Building Blocks.
2-1 A Federation of Information Systems. 2-2 Information System Applications.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University IWPSE 2003 Program.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
CSPC 464 Fall 2014 Son Nguyen.  Attendance/Roster  Introduction ◦ Instructor ◦ Students  Syllabus  Q & A.
The NRC Framework for K-12 Science Education and the Next Generation Science Standards Tom Keller, Senior Program Officer Board on Science Education National.
Computer Vision as an Engineering Problem. A Hierarchical Layer Model. A presentation by Amit Benbassat.
Modern Systems Analysis and Design Third Edition Chapter 2 Succeeding as a Systems Analyst 2.1.
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
Knowledge is fixed and need only to transfer from teacher to students is based on constructive and transformation process through learning process Learning.
Software Design. Introduction Designing engineering encompasses the set of principles concepts and practices that lead to the development of a high quality.
Chapter 1 Assuming the Role of the Systems Analyst.
Visual Analytics for Cyber Defense Decision-Making Anita D’Amico, Ph.D. Secure Decisions division of Applied Visions, Inc.
CS223: Software Engineering Lecture 34: Software Maintenance.
The Components of Information Systems
Chapter 7: Software Engineering
Enabling Team Supervisory Control for Teams of Unmanned Vehicles
Architecture Components
The Components of Information Systems
Ontology Reuse In MBSE Henson Graves Abstract January 2011
Chapter 2 – Software Processes
Chapter 13 Quality Management
Chapter 7 –Implementation Issues
Software Fundamentals
Information System Building Blocks
Software Re-engineering and Reverse Engineering
Presentation transcript:

Talking About Concerns... James D. Herbsleb School of Computer Science Carnegie Mellon University

What is Modularity? Thanks, Mary! Thanks, Dick!

Why Modularity? Software modularity does not matter... at all Except... To the extent it modularizes work Work modularity aids human understanding Work modularity simplifies coordinating people and teams

Parnas: Expected Benefits of Modularity Reduce need for coordination “separate groups would work on each module with little need for communication” Simplify comprehension “it should be possible to study the system one module at a time” These effects lower the cost of change “it should be possible to make drastic changes to one module without a need to change others” Parnas, D. L. On the Criteria to be Used in Decomposing Systems into Modules. Communications of the ACM, 15, 12 (1972), , p

Vision... “a vivid mental image; ‘he had a vision of his own death’” * “an Explanation of Life Founded upon the Writings of Giraldus and upon Certain Doctrines Attributed to Kusta Ben Luka” * “a thought, concept, or object formed by the imagination” ** “direct mystical awareness of the supernatural“ ** *wordnetweb.princeton.edu/perl/webwn **Merriam-Webster Dictionary

6 Proportion of dependencies that cross-cut Number of language-based modularizing mechanisms 100% Cognition and coordination problems

7 Proportion of dependencies that cross-cut Number of language-based modularizing mechanisms 100% Cognition and coordination problems Traditional modularity

8 Proportion of dependencies that cross-cut Number of language-based modularizing mechanisms 100% Aspects Cognition and coordination problems

9 Proportion of dependencies that cross-cut Number of language-based modularizing mechanisms 100% ??? Cognition and coordination problems

10 Proportion of dependencies that cross-cut Number of language-based modularizing mechanisms 100% Cognition and coordination problems Traditional modularity Consensus view at Recife

11 Proportion of dependencies that cross-cut Number of language-based modularizing mechanisms 100% Cognition and coordination problems Aspects Consensus view at Recife

12 Proportion of dependencies that cross-cut Number of language-based modularizing mechanisms 100% Cognition and coordination problems My view (mildly exaggerated) Dystopian vision: Modularity alone will never fix the problem.

13 Approaching the Gray Area... Organizational design, work assignment, and tools set up to bring the right dependencies to the attention of the right people so they can act appropriately

14 Two Examples... Organizational design and work assignment –Lessons from feature-driven development Using information from the environment –Learning from human activity

15 Feature-Driven Development Unit of functionality in end-user terms Feature is the unit of development managed by a project Features tend to cut across traditional software entities Work often overseen by “feature manager” Developers associated with component, assigned to work on particular features

16 The Study Setting –Software for automotive navigation system –1195 features –32 months of activity –179 engineers in 13 teams –1.5 M LOC, 6789 source files, 107 architectural components –Organization had 5 years of prior experience with feature-driven development Architects prepare feature development specification

Odds Ratios from Regression Assessing Factors Driving Feature Integration Failures From Cataldo, M. & Herbsleb, J.D. (2011). Factors Leading to Integration Failures in Global Feature-Oriented Development: An Empirical Analysis. Proceedings, International Conference on Software Engineering (to appear). What Causes Integration Failure?

From Cataldo, M. & Herbsleb, J.D. (2011). Factors Leading to Integration Failures in Global Feature-Oriented Development: An Empirical Analysis. Proceedings, International Conference on Software Engineering (to appear). Ownership Matters!

Odds Ratios from Regression Assessing the Impact of Cross-Feature Interactions on Integration Failures From Cataldo, M. & Herbsleb, J.D. (2011). Factors Leading to Integration Failures in Global Feature-Oriented Development: An Empirical Analysis. Proceedings, International Conference on Software Engineering (to appear). Destructive Feature Interaction

From Cataldo, M. & Herbsleb, J.D. (2011). Factors Leading to Integration Failures in Global Feature-Oriented Development: An Empirical Analysis. Proceedings, International Conference on Software Engineering (to appear). Co-location Doesn’t Scale

Broader Lessons Organizational arrangements matter! Effects can be quite large Effects often are not commonsensical

Inferring Dependencies from Traces of Human Activity Prior work Use files changed together as measure of dependencies Can generate a measure of coordination requirements Validated in a number of settings Can we generalize from “files changed together” to “entities discussed together”?

A Brief Digression/Analogy

Text Analysis: Field Robotics Project Lunar X Prize competition

Text Analysis: Field Robotics Project Lunar X Prize competition No automatically collected version or change data Constantly shifting component boundaries and interfaces Can we use text analysis to derive dependencies?

Steps Collected data 25 all-hands meetings About 10,000 words each Developed code book 6 field robotics articles

Code Book

Steps Collected data 25 all-hands meetings About 10,000 words each Developed code book 6 field robotics articles Manual coding of decision discussions Tested inter-rater reliability QAP correlations.80

Text Pre-Processing

Steps Collected data 25 all-hands meetings About 10,000 words each Developed code book 6 field robotics articles Manual coding of decision discussions Tested inter-rater reliability QAP correlations.80 Created thesaurus

Link Identification Co-occurrence of terms Human coding: same decision Selected sliding window size Size 15 had best agreement with hand coding Threshold established QAP correlations comparable to human- human agreement (~.8) Sets of links based on topics

Optics External relations Structure Sensors Planning software Requirements Mission specific effectors Mobility effectors Perception software Communications Testing

Thermal Structure Power Mission specific effectors Thermal models Structural models Thermal system Prototype fabrication

Avionics Mission operations Mission-specific effectors Propulsion Power Thermal system Lander Launch vehicle Mobility effectors Perception software Shared/general computing Prototype fabrication Planning software Structure

Concluding Vision The gray area – work that cross-cuts language constructs – is here to stay Use organizational tactics Use computations over artifacts generated by development activities Explore new data sources, including documents and conversation Activities reveal knowledge Analysis can often make it actionable