intro to the course - knox collegefaculty.knox.edu/jdooley/sdwebpage/slidesinpdf/l1intro.pdf ·...

Intro to Development 1

Software Developmentand Professional Practice

Intro to the Course


Unless otherwise expressly stated, all original material of whatever nature created by John F. Dooley and included in this web site and any related pages, including the site's archives, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

http://creativecommons.org/licenses/by-nc-sa/3.0/

http://creativecommons.org/licenses/by-nc-sa/3.0/

Intro to Development

• Software Development

• It’s not as easy as it looks.....

3


“Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any -- no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware. We cannot expect ever to see twofold gains every two years.”

Frederick J. Brooks, Jr. “No Silver Bullet”, IEEE Computer, April, 1987


“Wicked problems are problems that are fully understood only after they are solved the first time.” Rittell and Webber, Dilemmas in a general theory of planning, 1983

Software is a wicked problem… DeGrace and Stahl, “Wicked Problems, Righteous Solutions, A Catalogue of Modern Software Engineering Paradigms.”, Prentice-Hall 1980


“As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.”

-- Maurice Wilkes, designer of the EDSAC computer andinventor of microprogramming, on programming, 1949


A man is flying in a hot air balloon and realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts: "Excuse me, can you tell me where I am?”

The man below says: "Yes you're in a hot air balloon, hovering 30 feet above this field.”

"You must be a software developer," says the balloonist.

"I am," replies the man. "How did you know?”

"Well," says the balloonist, "everything you have told me is technically correct, but it's of no use to anyone.”

The man below says, "You must work in business as a software development manager."

"I do," replies the balloonist, "but how did you know?”

”Well," says the man, "you don't know where you are or where you are going, but you expect me to be able to help. You're in the same position you were before we met but now it's my fault."


We are not going to do this...


Software development has been, is, and will likely remain fundamentally hard. Building quality systems involves an essential and irreducible complexity, which is why the entire history of software engineering can be characterized as one of rising levels of abstraction. As such, the task of the software development team is to engineer the illusion of simplicity. Nonetheless, software-intensive systems can amplify human intelligence, but they cannot replace human judgment; software-intensive systems can fuse, co-ordinate, classify, and analyze information, but they cannot create knowledge. In other words, not everything we want to build can be built: there exist pragmatic theoretical and technical limits that make software development hard if not impossible. Furthermore, not everything we want to build should be built: there exist moral economic, social, and political limits that govern human industry. From fundamental to human, these are the factors that define the limits of software, factors that separate our vision from execution.

- Grady Booch (in a blurb from a talk, "The Limits of Software")

And a final word….


what is software development?(one view)

Software development is a • cooperative,• finite,• goal-directed,• resource-limited,• group• game of invention and communication.

(attributed to Alistair Cockburn)


Programming

• We’ll spend this term talking about how to write programs– small programs and big programs

• We’ll talk about design, coding, debugging, and testing– a lot

• So then how is “programming” defined??


OK, so what is Programming, really?

• well, I think it’s really like a making recipe:– you take a problem– you add knowledge of data structures and algorithms,

– you add a set of heuristics about solving problems in general,

– you add experience at solving other problems like this one (usually called patterns),

– you add a language that’s appropriate to the problem domain,

– you add a set of tools that increase your efficiency and productivity

– and you implement a solution to the problem. (stir, and heat on a low simmer until done)


• and like a recipe, it’s never quite the same twice– because you’re always tempted to muck about with it…

• But like a recipe,– you get better the more you do it, and

– your variations lead to something interesting and new.


• Dooley <soapbox>– Software engineering, and– Software development– and what’s the diff?


Why study software development?

• Society has become increasingly dependent on software systems.

• Failures in software systems can be dangerous and costly

• Software design & development is a hard problem


Software Development Crisis?

• The Standish Group in its “Chaos Reports” says (1994, ’96, ’98, ’00, ’02, ’04, ’06, and ’10):

– About 25% of all large* software development projects are cancelled before they go into production.

– More than 50% of the rest are delivered late (by about half) and over budget (sometimes by 2X or more) or with unacceptable quality. (The Standish report says they are “challenged”)

– Oh, and the rest “fail”

– Many organizations do not follow well-known development & management “best practices”


Is development a problem only for large projects?

• Even smaller projects are often late, over budget, and have too many defects.

• Why???– SW implementation is hard– Management is hard– Interfaces are hard– Requirements analysis is hard– Communication is hard– Estimating size and time is hard– Too many people who make schedules / promises don’t

understand how hard it is to develop quality software.– (yes, software development is a wicked problem)


Why does this happen?• Software developers are generally not taught how to work in

teams.

• Too many people want to equate software with manufacturing.

– “Just follow this process to the letter and out will pop a piece of quality software.” - NOT!

– Too many people want to equate software development with traditional engineering practices - but software is not a building, or a bridge, or even an integrated circuit. IMHO software is fundamentally different.

– It’s so easy to change and so hard to get right.


software development (another view)

“Software engineering: the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.”

IEEE Computer Society, 1993.


Crisis? I don’t think so…

• One more thing….– where does the “crisis” data come from?– http://www.standishgroup.com/sample_research/chaos_1994_1.php

• and what is the Standish Group in the business of doing?

• insert skeptical hat here…

– Take a look at Robert Glass’ columns in IEEE Software on the Chaos Report (2005)

– And take a look at the Jan/Feb 2010 IEEE Software article by Eveleens and Verhoef

http://www.standishgroup.com/sample_research/chaos_1994_1.php

http://www.standishgroup.com/sample_research/chaos_1994_1.php


Solution to the problem??

• What might you need to do SD well?– a small, well integrated team– good communication

– a plan that everyone buys into

– a process that everyone buys into– to be flexible

– to know where you are at all times– to be brave enough to say “Hey, we’re behind!”

– the right tools and the right practices for this project.

– to realize that you don’t know everything you need to know at the beginning of the project.


My Perspective• I think that writing a complex piece of software

with zero defects is one of the most challenging intellectual exercises you can do.

• I believe that small, highly motivated and empowered teams are the most productive.

• Process flexibility, communication and ownership are key to project successes.

• I also think that despite the “failure” numbers a heck of a lot of software gets written and released every year.


SD Needs Effective Development and Management Practices

• Einstein defined insanity as “repeating the same process and hoping for a different result.”

• To avoid this, you need to select the right practices for the project - no one process or practice fits all projects.


</soapbox>


Software Engineering Overview

Software EngineeringTwo Sides of the Coin

Project Management Software Development

Project Planning Software LifecycleManaging People and Teams Development ProcessRisk Management Requirements GatheringRequirements Management Requirements AnalysisEstimation and Scheduling Architectural DesignProject Tracking Detailed DesignConfiguration Management Design LanguagesManagement Tools Design PatternsQuality Assurance ImplementationMetrics and Data Gathering Coding and DebuggingRelease Management Reviews and InspectionsSoftware Process Definition TestingSoftwware Process Improvement Software Tools

We’ll largely stay over here…


What’s next?

• Generally, we’ll cover– process– design– construction– debugging– testing– with some ethical and professional practice

discussions thrown in.


Design

• Design style (object design, data structure)

• Fundamental design concepts (information hiding, encapsulation, inheritance, data structures, algorithms)

• Design approaches (structured, object-oriented, exception handling, i18n, I/O, database design)


Construction

• Coding practices and standards (quality, style)• Data concepts (scope, persistence, binding time)• Use of data types (predefined and custom)• Controls (loops, Boolean, conditionals)• Error detection (assertions)• Code packaging rules and conventions …• Reading code is key• Debugging practices are also key


Construction - 2

• Unit Testing and debugging

• Integration strategy (incremental, big bang, evolutionary)

• Code tuning strategies

• Programming language nuances

• Construction tools (code generation, source code control)


Quality Assurance

• Better QA reduces cycle time!

• Error-prone modules are 4x as expensive to develop and maintain

• Testing catches some defects– Testing will not catch all defects.– Reviews/Inspections can catch defects earlier -

when they’re cheaper.• XP says - review and test continuously


Quality Assurance - 2

• Technical reviews– Code reading - informal peer review– Walkthroughs/reviews

– Inspections - formal reviews after coding and unit test

• The goal is to find defects long before system testing

intro to the course - knox collegefaculty.knox.edu/jdooley/sdwebpage/slidesinpdf/l1intro.pdf ·...

Documents