{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

L01 - Intro - EE 361 Fundamentals of Software Engineering 1...

Info iconThis preview shows pages 1–5. Sign up to view the full content.

View Full Document Right Arrow Icon
EE 361 Fundamentals of Software Engineering L1 – January 11, 2008 Introduction 1
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Fundamentals of Software Engineering Why even consider software engineering (part 1)? Suppose that you are working for a company that provides landscaping services across a large metropolitan area. Your boss asks you to manage the development of a new billing system you’ve assembled a great team of developers and acquired all the state of the art technologies and tools your team has talked at length with the accounting manager and written a detailed set of requirements you’re set to go – should be no problem six months later project is late and over budget developers have been working overtime for weeks and one has already quit and you don’t think you are any closer to completion the accounting team keeps claiming that the software doesn’t do what they need and they keep sending through “change requests” the accounting group sends a continual flood of bug reports so what went wrong? whatever it was it is something that most companies get wrong L1 – January 11, 2008 Introduction 2
Background image of page 2
Some Facts and Figures: According to the Standish Group research (report in 2001); only 28% of software projects in 2000 succeeded entirely 23% were cancelled the rest (some 49%) were “challenged” they were late (by 63% on average) over budget (by 45%) lacking features (33%) or all of the above The New Zealand Ministry of Justice had a $42 million Case Management System that was $8 million over budget and a year late when rolled out in 2003. Of the 27 benefits expected of the system, only 16 have been realized. Reportedly, the only challenges faced by the developers were those common to large and complex systems!! L1 – January 11, 2008 Introduction 3
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Fundamentals of Software Engineering So, to repeat, why even consider software engineering? Software development is hard It’s important to make a distinction between “easy” systems One developer, one user, experimental use only and “hard” systems Multiple developers, multiple users, products for the marketplace Our experiences with “easy” systems (as “hard” as you find they are to develop) are very misleading The techniques don’t scale up very well Let’s consider an analogy If you’re building a bridge over a little creek, the job is easy. You can find some boards or tree trunks, lay other boards across them, and you have the job done If you’re building a bridge over the St. Lawrence River, this clearly is not going to work -- the techniques don’t scale up!
Background image of page 4
Image of page 5
This is the end of the preview. Sign up to access the rest of the document.