1 No Silver Bullet Brooks rides again…. 2 Essential Difficulties What are these “essential difficulties” that Brooks is referring to? Complexity Conformity.

Slides:



Advertisements
Similar presentations
Why Use Test Driven Development (TDD)?.  Why the need to change to TDD.  Talk about what TDD is.  Talk about the expectations of TDD.
Advertisements

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
INFO415 Approaches to System Development: Part 1
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
INFORMATION TECHNOLOGY IN BUSINESS AND SOCIETY SESSION 20 – HOW SOFTWARE IS MADE SEAN J. TAYLOR.
Software Processes Coherent sets of activities for specifying, designing, implementing and testing software systems.
Framework is l Reusable Code, often domain specific (GUI, Net, Web, etc) l expressed as l a set of classes and l the way objects in those classes collaborate.
Applied Software Project Management INTRODUCTION Applied Software Project Management 1 5/20/2015.
The Mythical Man-Month by Fred Brooks (I) Published 1975, Republished 1995 Experience managing the development of OS/360 in Central Argument –Large.
No Silver Bullet - Essence and Accident in Software Engineering By: R. Adam Mead.
No Silver Bullet “There is no single development, in either technology or management technique, which by itself promises even one order-of magnitude improvement.
No Silver Bullet Essence and Accidents of Software Engineering By Frederick P. Brooks Frederick P. Brooks Presentation by Yan Qi
Software Engineering.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 8 Slide 1 Software Prototyping l Rapid software development.
Reasons to study concepts of PL
Agile Modeling and Prototyping
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
SOFTWARE CRISIS SOLUTIONS? © University of LiverpoolCOMP 319slide 1.
SM3121 Software Technology Mark Green School of Creative Media.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Questions from a patient or carer perspective
Programming. Software is made by programmers Computers need all kinds of software, from operating systems to applications People learn how to tell the.
The Pentium: A CISC Architecture Shalvin Maharaj CS Umesh Maharaj:
Problems with reuse – Increased maintenance costs; lack of tool support; not-invented- here syndrome; creating, maintaining, and using a component library.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 8 Slide 1 Software Prototyping l Rapid software development to validate requirements l.
Rapid Prototyping Model
Mixed-level English classrooms What my paper is about: Basically my paper is about confirming with my research that the use of technology in the classroom.
Essence and Accident in Software Engineering By: Mike Hastings.
CSI315 Web Technology and Applications
No Silver Bullet – Essence and Accident in Software Engineering.
Could You Use More Traffic?. If you’re like most marketers, the answer to this question is… YES!
6-January-2003cse Introduction © 2003 University of Washington1 Introduction CSE 403, Winter 2003 Software Engineering
Software Processes Sumber dari : cc.ee.ntu.edu.tw/~farn/courses/SE/ch4.ppt.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 8 Slide 1 Software Prototyping l Animating and.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
No Silver Bullet. CS460 - Senior Design Project I (AY2004)2 No silver bullet "No Silver Bullet" –– a paper by Fred Brooks, Professor of Computer Science.
1 Welcome to CS 362 Applied Software Engineering What happens after (and during) design? Testing, debugging, maintaining programs Lessons for software.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 1 Software Processes (Chapter 3)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 1 Software Processes l Coherent sets of activities for specifying, designing,
Industry SDLCs and Business Climate. Justin Kalicharan Credentials Director and Senior Technology Officer Over 14 years of coding experience in various.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 8 Slide 1 Software Prototyping l Rapid software development to validate requirements.
Lecture 3 Software Engineering Models (Cont.)
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Chapter 22 Developer testing Peter J. Lane. Testing can be difficult for developers to follow  Testing’s goal runs counter to the goals of the other.
Documentation. Your documentation must fit the needs of your audience. It’s always better to say one thing that is useful, as opposed to many things that.
“No Silver Bullet”. No Silver Bullet  "No Silver Bullet" –– a paper by Fred Brooks, Professor of Computer Science at University of North Carolina in.
CS5103 Software Engineering Lecture 02 More on Software Process Models.
1 Team Skill 1 - Analyzing the Problem Continued and Product Features and Challenges Sriram Mohan.
WATERFALL DEVELOPMENT MODEL. Waterfall model is LINEAR development lifecycle. This means each phase must be completed before moving onto the next!!! WHAT.
Lecture 10 More Innovation SE3821 Software Requirements and Specification Dr. Rob Hasker (based on slides by Dr. Brad Dennis)
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
P51UST: Unix and SoftwareTools Unix and Software Tools (P51UST) Version Control Systems Ruibin Bai (Room AB326) Division of Computer Science The University.
ANU COMP2110 Software Design in 2003 Lecture 10Slide 1 COMP2110 Software Design in 2004 Lecture 12 Documenting Detailed Design How to write down detailed.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Software Engineering, 8th edition. Chapter 4 1 Courtesy: ©Ian Sommerville 2006 FEB 13 th, 2009 Lecture # 5 Software Processes.
By David Sanders Title Explanation  Werewolves are quite terrifying, simply because they transform unexpectedly into horrors. To kill werewolves,
Continuous Improvement. Start Simple and Continually Improve E.g., Gmail Labels 1.
PRESENTATION 2 CS 5391 Survey of Software Engineering Chang-Ho Lee No Silver Bullet: Essence and Accidents of Software Engineering By Frederick P. Brooks,
Team Skill 1 - Analyzing the Problem
Fred Brooks - A Software Engineering Icon - “No Silver Bullet”
The Effects on Development
Software Processes.
Informatics 43 – March 31, 2016.
Teaching slides Chapter 1.
Paul Ammann The Agile Heresy: What Drives Traditional Software Engineering, and Why Agile Turns it Upside Down Paul Ammann.
UFCE8V-20-3 Information Systems Development SHAPE Hong Kong 2010/11
Programming.
LASER HAIR REMOVAL MACHINE. INTRODUCTION Removing hair has never been easier with the use of the laser hair removal machine that does the process effortlessly.
Presentation transcript:

1 No Silver Bullet Brooks rides again…

2 Essential Difficulties What are these “essential difficulties” that Brooks is referring to? Complexity Conformity – To rules made by humans. – Zip up your jacket! Changeability – “All successful software gets changed.” – See Slide 13 Invisibility

3 High Level Languages “The most a high-level language can do is furnish all the constructs the programmer imagines in the abstract program.”

4 Time-sharing/Unified Programming Environments Note that he includes Unix in this list – An original reason for the popularity of Unix – Came with common tools that could use each other. Like in pipes and filters. Time-sharing on Unix at the University of Wisconsin, 1978

5 Will a new programming language (like Ada) save us? Brooks predicts that Ada’s greatest contribution will be “training programmers in modern software design techniques.”

6 AI AI-1, solving difficult problems using specialized techniques (pretty difficult to generalize) AI-2, expert systems duplicating the skills of the expert (maybe offering suggestions) – The rules are the important part AI-3 Data al la Star Trek

7 Graphical Programming Languages A good way to see the overall argument Buffalo’s objection – “Can it show merge sort?”

8 Bigger advances yet Buy vs. build – At NCR in the 1970’s, we built 100 text editors! Requirements refinement and rapid prototyping / incremental development “Agile”!

9 Great Designers “The differences are not minor – it is rather like Salieri and Mozart. Study after study shows that the very best designers produce structures that are faster, smaller, simpler, cleaner, and produced with less effort. The differences between the great and the average approach an order of magnitude.” And they need great offices…

10 Like at Facebook

11 Update – 2007 OOPSLA David Parnas: People have a “very natural tendency to look for easy answers to hard questions, designing software is hard and it will always be hard.” New technologies are often over-hyped: “they have to kind of paint it as a silver bullet because otherwise people won’t listen.” Desire for people to seek better tools rather than “actually learning the trade.” Dave used the metaphor: “there is an old saying: ‘the poor workman blames his tools’ - people are poor workmen, I think most programmers are poor workmen.” Dave also said that people are looking for silver bullets to avoid learning the trade.

12 Update – 2007 OOPSLA Linda Northrop: The boundary between developers and those that we have, I think inappropriately called users, and our accidental innovations, help little. To wrestle future werewolves we still need great designers, and I think we still have far too few, and we still need to cultivate an atmosphere of hard work but also an inner- disciplinary perspective that takes us uncomfortably out of our coding world. Our world [is focused on] “the technology push”. I think the reason we have the technology push is because we don’t do the hard work to understand the needs of who we are trying to address.

13 Does all software change? Software started out being build like everything else that’s engineered. Really soon, though, we discovered it was easier to change most software. Everyone took advantage of that: – Customers asking for more, after delivery. – Developers relying on being able to fix things. – Generations of successful products, installed over the top of themselves. There’s really “S-Type” and “E-Type” – see CSSE 375 and “Lehman’s Laws.”

14 Improve on the “Essential” part? Yes – some of it will be discovered to be “accidental” Getting better requirements, in Agile – This began as “how startups work.” Domain-specific languages – The main apps only need to be tailored. Features like “auto-completion” As software engineering matures, some things will become “routine.”

15 Automatic programming? Means two things: 1.“Higher level” – with underlying features assumed. 2.Only have to write the requirements – code is then generated. – You get this somewhat with parameters.

16 Expert systems? A typical silver bullet try. You write a bunch of rules about the domain, and the application pops out at you in response, a surprise! Great for prototyping. Works best with small systems. Debugging is a bear!