CS Software Engineering Process and Practice Welcome! Leon Sterling and Ed Kazmierczak {leon,

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 What do Defence simulators, Kazaa, water irrigation and Traffic cameras have in common?

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 Overview of lecture Content of 341 (~15 mins) Context of 341 (~15 mins) Logistics of 341 (~15 mins) Slippage (5 mins)

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 What is Software Engineering? - a shed analogy A handy person can build a backyard shed. Does the same approach scale to building a 30 floor office building? An engineer can program a simple controller. Does the same approach scale to build an air-traffic control system?

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 What is Software Engineering? Software Engineering is a discipline applied by teams to produce high-quality, large-scale, cost- effective software that satisfies the users’ needs, and can be maintained over time Software Development is a weaker term where standards, tools, processes, etc. may not be applied Another version in text, pp. 2-4

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 Software development is not perfect Standish report, p. 142 Examples of famous failures in the text, e.g. Therac-25, Ariane crash Customs software Other engineering projects have similar problems, e.g. Multiplex

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 Standish Report - March 2003 The Standish Group International, Inc. announces the general availability of its renowned CHAOS research study for The study has commenced every two years since 1994 with data having been accumulated from a major survey on project success and failure. The latest batch provides insight into 13,522 Information Technology projects. The 2003 CHAOS Chronicles report shows some major improvements since the first CHAOS report. Project success rates have increased to just over a third or 34% of all projects. This is a 100% plus improvement over the 16% rate in Project failures have declined to 15% of all projects, which is more than half the 31% in Challenged projects account for the remaining 51%. Showing further improvements, fifty-one percent of challenged projects have a lower overrun ratio than in In fact, forty-six percent of this fifty-one percent had a cost overrun of less than 20% of the estimate. This is a 5% increase over the 2000 numbers and a three-fold increase since This was a major contributor to our estimate of a 43% average overrun cost, down from 180% in The lost dollar value for US projects in 2002 is estimated at $38 billion with another $17 billion in cost overruns for a total project waste of $55 billion against $255 billion in project spending. In 1994, The Standish Group estimated US IT projects had a waste of $140 billion ($80 billion in failed projects) against $250 billion in project spending. However the report does not show all good news. Time overruns have significantly increased to 82% from a low of 63% in the year In addition, this year's research shows only 52% of required features and functions make it to the released product. This compares with 67% in the year Standish Group International, Inc. is a research advisory firm built on a solid foundation of primary research techniques. For more information, visit Contact The Standish Group International, Inc

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 Key stakeholders (Text, pp ) Customer Developer User

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 An engineering perspective Is software engineering really engineering?

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 Process is essential

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 What is a process? A set of ordered tasks A series of steps involving activities, constraints, and resources that produce an intended output of some kind (Chapter 2)

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 Overview of 341 Content Process Project Planning and Scheduling Requirements Elicitation and Analysis Architectural and System Design Detailed design has been addressed in 254

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 Context at Melbourne Formal Software Engineering introduced relatively late, i.e. third year Common engineering Overlap with CS degree Professional subject in BCS (originally) Companion for 340

Software Engineering Lecture 1: Overview Lecture Semester 1, Context continued … Hard subject to teach Process is viewed as a burden Unlike other CSSE subjects, i.e less technical Little experience to fall back on Largest CSSE subject in Semester 1, 2006

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 Processes you have seen CVS 255 project last semester Submit procedure Industrial experience … Running example throughout the subject- teaching 341!

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 Make up of class Straight BE(SE) Combined BE(SE) Mechatronics CS B.Sc. Others

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 Subject schedule See information on the Web

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 Logistics of 341 Lecture schedule - 24 lectures, 11 tutes NOT EVENLY DISTRIBUTED Project Assessment Textbook and notes Tutes

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 Teaching Process of 341 Teaching team Leon, Ed, tutors Student reps - Volunteers? Regular meetings Clear roles and responsibilities Peer review of teaching materials Management of risks

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 Teaching process issues Communication Management Quality attributes What is quality? (mention it shortly) Consistency Perception of organisation Innovation - valued by teachers rather than students

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 Weekly process Friday a.m. Slides for next week’s lectures and tutorial questions posted Monday, Tuesday, Thursday lectures (Amended if necessary) Tutorials - be prepared! Keep log of activities

Software Engineering Lecture 1: Overview Lecture Semester 1, 2006 Outcomes of subject Specific skills Able to use project management structures High level design skills Critique requirements Communication within a team Knowledge of key software engineering concepts