SEintro1

Software Engineering

Introduction (The Product)
James Gain (jgain@cs.uct.ac.za) http://people.cs.uct.ac.za/~jgain

Objectives 
Of the course: 
To cover the process, methods and tools of Software Engineering  Emphasise the unfortunate necessity of SE practices  Prepare you for the CS2 project 

Of this lecture: 
Explain the nature of the beast  Face the ³software crisis´  Consider the three tug-of-war aspects of software development  Debunk some widely held myths about software

Fred Brooks in The Mythical Man-Month . like the poet. including:  Programs  Documents  Data  Software products may be developed for a particular customer (bespoke) or for a general market (generic)  Most software is still custom-made rather than being assembled from existing components  ³The programmer. works only slightly removed from pure thought-stuff´ .The Nature of Software  Software is a set of items that form a ³configuration´.

Complexity  Software is inherently complex because:  Number of execution paths grow exponentially with size  Interdependence of scattered parts  Can be reduced but not eliminated  Simplifying techniques of Maths and Physics (where complexity = noise) don¶t always apply  Consequences:  One person cannot understand a project in its entirety  Makes management difficult  Complicates maintenance .

. Each loop can execute up to 20 times There are 10^14 possible paths in this 15 line program! .then.Explosion of Execution Paths Two nested loops containing four if..else statements.

Conformity  Cases of Conformity:  Must often conform to existing systems  Even when building from scratch software is regarded as a second class citizen (most conformable component)  Inherent:  Cannot be removed by redesign because it depends on the interface to humans and hardware  Consequences:  Interfaces will invariably add complexity to an otherwise simple design .

Changeability  There will always be pressure to change software:  Software models reality. users will want it extended  Software is easier to change than hardware  Successful software survives beyond the lifetime of the hardware for which it was originally written  Consequences:  Constant change degrades quality  Becomes progressively more expensive with lateness in the lifecycle . so must software  If software is useful. as reality changes.

but:  Generally non-planar (crossing edges)  Generally not hierarchical  Cannot embody every aspect in a single visual  Cannot easily identify oversights  Consequences:  Software designs are difficult to understand and communicate . molecules) cannot be effectively visualized  Yes there are graphing techniques (UML). circuits.Invisibility  Software (unlike architecture.

Exercise: Beyond the Ivory Tower  University is not the Real World  CS pracs are not like real software projects  Give 5 or more important ways in which they differ: The Real World TM 1. You must almost always work within a team (Johnny must play well with others) 3. People can be bankrupted and even die (with safety critical systems) if your software fails 2. Your program will have to live longer 5. complexity and time span of software projects are much larger . The cost. Poor performance means losing your job (not just a poor mark) 4.

software is digital 3. Most of the cost of software is in design not manufacture . When bridges break they are redesigned and rebuilt from scratch (imagine doing that every time your Operating System crashed) 2. Software does not ³wear out´ 4.Exercise: Beyond Bridge Building  A NATO study group coined the term Software Engineering in 1967  They believed that software would benefit from the philosophies and techniques of traditional engineering  But building software is not like building bridges  Give 4 (or more) important ways in which they differ: 1. Bridges are analog.

Lifetime of Software .

over budget and with residual faults. this isn¶t really changing  software productivity has improved 6% per year (on average over 30 years)  Unlike Hardware  Moore¶s law: processor speed/memory capacity doubles every two years Hardware ³Productivity´ Software Time (10 years) . Less a crisis.The Software Crisis  Often software is delivered late. more a chronic affliction  Worse.

object orientation.No Silver Bullet  Software development is like a Werewolf (mostly calm but just wait for the full moon)  We need a silver bullet to provide a one shot solution  Fred Brooks in his essay ³No Silver Bullet´ postulates that:  Despite the promise of high-level languages. integrated development environments and Artificial Intelligence  There will never be a single order of magnitude breakthrough in productivity improvement  Because of the intrinsic nature of software  Question for the day: Is reusability (and open source) the new silver bullet? .

Software that overruns on time usually overruns on budget (you had to pay more salaries)  You can have it fast.The Three-legged Stool Three There are three axes of software development:  Schedule (how long will it take to develop)  Cost (how expensive is it to develop)  Quality (indefinable excellence of the final product)  Software Management is largely devoted to predicting. cheap or good. Pick any two .g. controlling and measuring these axes  Interrelated  A change in one axis affects the others  E.

.Timeliness  Because of software complexity. it is very difficult to schedule  Also programmers are notorious for underestimating coding time  Generally fail to consider the time needed for testing and debugging  Rule of thumb: double programmer¶s time estimates (without telling them)  Software engineering is concerned with developing software in a timely manner.

where maintenance may be many times more expensive than development  Software engineering is concerned with costeffective software development . software for a PC usually costs more than the hardware  Software costs more to maintain than it does to develop  Especially for systems with a long life.Cost  Software costs often dominate system costs  For instance.

Quality  Need to deliver the functionality required by the user  But also be:  Maintainable (can evolve to meet changing needs)  Dependable (error free and reliable)  Efficient (don¶t waste system resources)  Usable (must be easily mastered by the target users)  Software engineering is concerned with producing quality software .

intercommunication or training  Cost depends on the number of people and number of months.The Man-Month Myth Man Managers are under pressure. add people to finish on time  Implies that people and time are interchangeable  Reality:  Mongolian horde assumes that tasks can be perfectly partitioned with no sequential constraints. tend to grasp at myths  Man-Month Myth:  Mongolian Horde approach works  If a project is running late. Progress does not  Brooke¶s Law: Adding people to a late software project makes it later (from ³The Mythical Man-Month´) .

The Chameleon Myth  Myths held by customers often lead to false expectations and. ultimately. dissatisfaction  Chameleon Myth:  Changing requirements can be easily accommodated at any time because software is flexible  Reality:  Impact depends on the lateness of the change  Changes are far easier during analysis (1x cost) than maintenance (60-100x cost) .

The Maintenance Myth  Early attitudes to programming have become entrenched  Maintenance Myth:  Once the program is written and it works our job is done  Reality:  You can¶t walk away without careful documentation  Because 60-80% of effort occurs after software is first delivered .

Relative Cost of Software Phases .

Sign up to vote on this title
UsefulNot useful