Embed Size (px)
Citation preview
CSE 403, Spring 2006, Alverson
Software Projects – the challenges we face
CSE 403, Spring 2006
MiscellaneousYour pitch and LCO does not need to include a business case analysis. Focus on the technical end, and feasilibity wrt technical challenges/time/resources.
Another grading comment …
Turn in assignments using “turnin” (turnin –c cse403 –p lco file1.doc file2.ppt)
About Wed/Thurs/Fri:o All presentations, submitted Tue night, will be loaded onto a laptop by us
and you will be able to run them from that laptop. LCO’s will also be posed on the web for you to peruse.
o Everyone needs to take part in the presentations -- not just one member per team.
o Teams should plan on a 5 minute presentation – rehearse!o The order of presentations will be announced on Wed in class. o As you listen to the presentations, be thinking about whether you would like
to work on the project. Why, why not? Project preferences will be due Sat 11:59pm (survey link on web).
CSE 403, Spring 2006
Readings“Rapid Development”, Steve McConnello Chapter 3 – 3.3 Classic Mistakes
CSE 403, Spring 2006
OutlineWhat is a software project?What makes a project successful?What’s our track record?Is software different?Do we now have all (any) of the answers?
CSE 403, Spring 2006
What is a software project?Projects are a balance of three dimensions, with the goal of producing a successful deliverable
FEATURES
TIME RESOURCES ($$)
SOFTWAREDELIVERABLE
CSE 403, Spring 2006
What is essential to a project?
Risk InvestmentPositive payoff
Take a risk and make an investment in order to get a positive payoff
Look at the prior question from another angle
CSE 403, Spring 2006
What makes a project successful?
On time deliveryFeature set completeReliablePerformantMeets expectationsOn budgetTeam survives without burnout (!)Ability to evolve (maintainable, enhanceable)
What are your ideas? What would make your 403 project successful?
CSE 403, Spring 2006
So…what’s our track record?What would you guess is the percentage of
software projects that fail (i.e., that don’t accomplish their goals)?
0 – 20%20-40%40-60%60-80%80-100%
CSE 403, Spring 2006
And the answer is …
05
101520253035404550
0-20% 20-40%
40-60%
60-80%
80-100%
05
1015202530354045
0-20% 20-40%
40-60%
60-80%
80-100%
Historically, nearly 85% of software projects fail
Past undergrad 403 guess
Past grad 590ET guess
CSE 403, Spring 2006
Details from the Standish report
Successful Challenged Failed
16% 64% 20%
84%
Why do you think this is the case??
CSE 403, Spring 2006
Chief reasons for software project failures: UGrad answers
o Insufficient planningo Too “rosy” assumptions o Poor communicationo Changes to the requirementso Changes in the context (funding, priorities)o Doing something without a clear customer baseo Competitiono Entrepreneurial nature of software
CSE 403, Spring 2006
Chief reasons for software project failures: Grad answers
o Cost overrunso Changing of requirementso Misunderstanding of requirementso Poor understanding of goalso Over-ambitious goalso Lack of clear specificationo Poor planning/researcho Lack of a reasonable & structured software/feature
plano No commercial market for end producto Complexity of software
There are a lot of ways that things can go wrong!
CSE 403, Spring 2006
Chief reasons/Classic Mistakes from RD
Rapid Development, p 49
CSE 403, Spring 2006
Chief reasons for software project failures: professionals’ answers
The majority of software projects fail…o not because of technical deficiencies or
problemso but because of underestimating the human
aspects of development, including:the relationship with the customersregular and explicit communication between all
stakeholders – managers, developers, testers, marketing, sales, customers
CSE 403, Spring 2006
More from the Standish data
54% of features were rarely or never used! That effort could have been productively spent elsewhere!
Why?
Features Used in a Typical System
Never 45%
Rarely 19%
Always 7%
Often 13%
Sometimes 16%
CSE 403, Spring 2006
Is Software Different?(from Other Engineering Disciplines)
Breakout session!
Rows 1&2: Arguments in favor
Rows 3&4: Arguments against
Rows 5&6: Arguments in favor
Hand in your notes so we can capture in the slides later!
CSE 403, Spring 2006
Sp06 403 – Arguments in favorLow overhead of actual implementationNew professionHighly technicalHighly market drivenShorter release cyclesLower material investmentSoftware is customer centricLife cycles are longer due to maintenanceWay cooler!Don’t require large groupsTechnology changes faster
CSE 403, Spring 2006
Past arguments in favorTesting the quality of software is hardero So many cases, so many paths, …o Unlike bridges and buildings where everything can
be tested using known proceduresMuch higher rate of failureo May also have to do with the immaturity of the
disciplineCustomers have a greater roleFrantic rate of technological changeSoftware is easier to copy
CSE 403, Spring 2006
Sp06 403 – Arguments againstSame type of development cycles (spec, dev, release, etc)Still trying to generate a productStill process of “creating” from ground upStart with customer demand, require feedbackAlways breaking new groundStill need to meet deadlines and requirements (performance, reliability)Work in groups
CSE 403, Spring 2006
Past arguments against
Software developers still need to plan, execute, test, and sell their products
CSE 403, Spring 2006
More questions to consider:Is software less reliable?Does it break differently?Is the environment of use of software different?Is the culture of software development different?and more…
Is Software Different?(from Other Engineering Disciplines)
Do these differences justify/explain our dismal success rate?
CSE 403, Spring 2006
Have we learned from our mistakes?We’re starting to!Driving forces behind the evolution of software development
o Software becomes a business and a professionNo longer just a hobbyStandards
o Best practices get distilled over timeLifecycle processesDesigning for change, for test, for leanness, …
o Productivity tools appear that aid developerso Economic and societal trends play an increasingly important role
