mary shaw, “prospects for an engineering discipline of software”. ieee software 7(6), pp. 15-24,...
Post on 05-Jan-2016
226 Views
Preview:
TRANSCRIPT
Mary Shaw, “Prospects for an engineering discipline of software”. IEEE Software 7(6), pp. 15-24, Nov.-Dec. 1990
Mary Shaw, “Continuing prospects for an engineering discipline of software”. IEEE Software 26(6), pp. 64-67, Nov.-Dec. 2009
CS professor at CMU since 1972
Chief scientist of SEI 1984-7
Co-director Sloan Software Industry Ctr. 2001-6
Fellow of the ACM, IEEE, AAAS
Software Engineering
A label applied to a set of current practices for software development
Not really an engineering discipline But has a potential to become one Insights by comparing with other engineering
disciplines
So What Is Engineering?
Creating cost-effective solutions To practical problems By applying scientific knowledge To build things In the service of mankind
So What Is Engineering?
“Engineering relies on codifying scientific knowledge about a technological problem domain in a form that is directly useful to the practitioner, thereby providing answers for questions that commonly occur in practice. Engineers of ordinary talent can then apply this knowledge to solve problems far faster than they otherwise could. In this way, engineering shares prior solutions rather than relying always on virtuoso problem solving.”
Development of Engineering
Technological progress
craft
commercialization
engineeringproduction
science
Development of Engineering
Technological progress
craft
commercialization
engineeringproduction
science
Amateurs and virtuosos Knowledge does not propagate Waste of materials Small scale production Little commercialization
Development of Engineering
Technological progress
craft
commercialization
engineeringproduction
science
Skilled craftsmen Training in operational procedures Concern for cost and materials Large scale production Manufacture for sale
Development of Engineering
Technological progress
craft
commercialization
engineeringproduction
science
Educated professionals Use scientific analysis and theory Enabling of new applications Specialized market segments
The Situation with Software
Technological progress
craft
commercialization
engineeringproduction
science
rare cases
data structuresalgorithms
early large systems (SABRE)most startups
most software production
structured programmingTools (IDE)
state machines
lifecycles
The Situation with Software
Technological progress
craft
commercialization
engineeringproduction
science
rare cases
data structuresalgorithms
early large systems (SABRE)most startups
most software production
structured programmingTools (IDE)
state machines
lifecycles
typically called“software engineering”
Terminology
• What we call “software engineering” is actually tools, technology, and management practices
• Calling this “engineering” diverts attention from what needs to be done
• Need to focus on creating the theory and science for a real engineering discipline
Path to True Engineering
Define body of knowledge needed by experts 50,000 chunks of information 10 years of learning Attempt to start this: the IEEE Software Engineering
Body of Knowledge (SWEBOK)
Path to True Engineering
Define body of knowledge needed by experts Make this knowledge accessible
Finding it should be easier than deriving it anew: this has happened with Internet search
Documentation of libraries etc. Wikis, howtos, forums, and crowdsourcing –
extensiveness and currency at the price of authority, accuracy, and organization
Path to True Engineering
Define body of knowledge needed by experts Make this knowledge accessible Repetition and reuse
Design patterns Libraries, templates Integrated environments “Cut and paste” examples from the web?
Path to True Engineering
Define body of knowledge needed by experts Make this knowledge accessible Repetition and reuse Professional specialization
Nobody can master everything Specialization in technologies like real-time,
numerical computing Specialization in application areas like vision or
transportation Specialization in problem classes like HCI and
adaptive systems
Path to True Engineering
Define body of knowledge needed by experts Make this knowledge accessible Repetition and reuse Professional specialization Improve coupling between science and
commercial practice
Measuring Progress
• The “software development problem” will never be “solved”
• We will always build systems at the edge of our capabilities
• Progress is measured by the expansion of this edge,
• And by the growth in the number of classes of problems that are solved routinely
Philippe Kruchten, “Putting the 'engineering' into 'software engineering'”. Australian Softw. Eng. Conf., pp. 2-8, 2004
Developer of several large systems, e.g.
Canadian air traffic control system
Professor of SE, Univ. British Columbia
Developer of the Rational Unified Process
Software Engineering definition
According to IEEE Standard 610.12: “the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software”
Science: unconstrained study of laws, trends, and models, with emphasis on rigor and formalism
Engineering: perform trade-offs and compromises to make products with given level of quality under constraints of time, money, personnel, and legacy
Differentiating Characteristics
Software is different from other engineering disciplines:
No fundamental theory Computer science doesn't really help understand
software Compiled code is unstructured and brittle: a bug in
one place causes effects elswhere Software engineering limited to using best practices
Differentiating Characteristics
Software is different from other engineering disciplines:
No fundamental theory Ease of change
Much more so than bridges etc. But hard to do rigorously and take all ramifications
into account
Differentiating Characteristics
Software is different from other engineering disciplines:
No fundamental theory Ease of change Rapidly evolving technology
Can't consolidate body of knowledge Can't benefit from many years of experience Need to continuously retrain engineers
Differentiating Characteristics
Software is different from other engineering disciplines:
No fundamental theory Ease of change Rapidly evolving technology Negligible manufacturing cost
Easy to re-deliver a fix, so no pressure to get it right the first time
Differentiating Characteristics
Software is different from other engineering disciplines:
No fundamental theory Ease of change Rapidly evolving technology Negligible manufacturing cost No borders
Easy to outsource: don't need to ship goods
Consequences I
Waterfall model doesn't work It does in other fields where things don't change
Need to use iteration and incrementation Accommodate change Validate by execution and use, because theory
doesn't exist
Consequences II
Composability doesn't work Even if components are good, we don't know
whether their composition will be Again due to lack of theory And to the fact that technology changes rapidly
Possibly alleviated by architecture and model-driven design
A True Profession
Define and teach the body of knowledge What works in practice
Professional certification programs Liability and responsibility for products Shift from an inner focus (playing with
technology) to an outer focus (satisfying user needs)
Peter J. Denning and Richard D. Riehle, “Is software engineering engineering?”. Comm. ACM 52(3), pp. 24-26, Mar 2009
Worked on Multics at MIT
Inventor of the working set model for paging of virtual memory
Writer on the computing profession
Professor at several universities
President of the ACM 1980-1982
Aspects of Computing
Widely accepted: Mathematical aspects of computer science Scientific aspects of computer science Computer hardware engineering
Controversial: Software engineering
Do software development practices deliver reliable, dependable, and affordable software?
Learn from Other Engineers
Predictable system behavior Software often exhibits surprising behavior (bugs)
Design tolerances What the system can tolerate usually unspecified
Failure probability Hard to manage software risks
Separate design from implementation In software there is little specialization
Four Roles
Software architect Gather requirements and create specifications with
full system view Software engineer
Create economic and effective system design, address conflicts and constraints
Programmer Convert engineering design into working tested code
Project manager Handle coordination, schedule, and resources
Capers Jones
Software engineering Best Practices
McGraw-Hill, 2010
Software consultant
Promoter of function points
Collector of software data
Author of data-packed books
The 2008 Financial Crisis
For many years software was a booming industry Fast growth was achievable This masked many problems Due to the crisis investments dried out The software industry was put under pressure to
be efficient This requires focus and identification of best
practices Management more than technical
Best Practices
Software project staffing: How to do downsizing and layoffs Keeping motivation and morale Selection and hiring decisions Career planning and development Cultivating and using specialists Training managers Using contractors and outsourcing Software engineering certification
Best Practices
Software project management: Early sizing and scope Selecting software methods and tools Executive management support Canceling or saving troubled projects Software project organization Metrics and measurement Tracking milestones
Best Practices
Software management: Software configuration management Libraries and reuse Software change control (before release) Software quality assurance Internal software standards Deployment and customization Updates and releases Termination of legacy applications
Best Practices
Software properties: Software security and protection against hacking Software performance Complying with international standards Software warranties
Best Practices
The customers: User involvement in project Training customers and users Customer support after deployment
Best Practices
The classics: Software architecture and design Risk / cost / value analysis Communication in software projects Software reusability and certification Testing and inspection
From Craft to Solid Engineering
• Software security improvement Resilient applications, secure languages
• Software quality improvement Defect prevention and removal
• Software measurement improvement Need true picture of economics of development and
maintenance
• Maintenance and renovation of legacy applications Including reconstructing requirements and design
top related