TKT-1212 Digitaalijärjestelmien toteutus

Transcription

TKT-1212
Digitaalijärjestelmien
toteutus
Lec 14 – Project management
Erno Salminen
Department of Computer Systems
Tampere University of Technology
Spring 2013
What variables define ”success” and
”failure”
1. Scope and quality – user gets the job done
2. Scedule – it is ready on time
3. Budget – it is cheap enough
 IT project statistics [Chaos 2009]
 32% Succeeded - delivered on time, on budget,
with required features and functions
 44% Challenged - late, over budget, and/or with
less than the required features and functions
 24% Failed - cancelled prior to completion or
delivered and never used
[http://community.ca.com/blogs/theitgovernanceevangelist/archive/2009/05/04/understanding-project-failure-rates.aspx]
#2/35
Why talk about failure?
 There is not exact formula for success
 However, there are quite exact predictors for
failure
 Interactive part: list 5 reasons for project
failure with your partner
 Most of the following notes may seem
obvious when written out. Nevertheless, such
simple mistakes do occur in real life
#3/35
Sources
 R.N. Charette, Why software fails [software
failure],Spectrum, IEEE, Vol. 42, Iss. 9,
Sept. 2005, pp. 42 - 49.
 N. Holmes, The Data Doughnut and the
Software Hole, Computer, Vol. 39, Iss. 6,
June 2006, pp. 100 - 99.
 Coley consulting, Why projects fail
 http://www.coleyconsulting.co.uk/failure.htm
 W.S. Humphrey, Five reasions why software
projects fail, Computer World, May 2002,
 http://www.computerworld.com/s/article/71209/Why_Projects_Fail
#4/35
Failure reasons fall into 3 categories
1. Project management –related
2. Context–related
3. Implementation-related

Note that only category 3 is technical
matter

Most could be avoided with common
sense and more or less human-science
 Although, the cited surveys discuss SW
projects, the discussion may be
generalized to HW and HW/SW projects
as well
[R.N. Charette, Why software fails [software failure],Spectrum, IEEE,
Vol. 42, Iss. 9, Sept. 2005, pp. 42 - 49. ]
#5/35
[N. Holmes, The Data Doughnut and the Software Hole,
Computer, Vol. 39, Iss. 6, June 2006, pp. 100 - 99.]
Mng 1: Unrealistic or unarticulated
project goals


Get the end users involved
You must infiltrate technical people to the meeting
where the goals and requirements are captured


There is no free lunch: ”If you choose A, you
cannot have B” – R. Colwell





Do you want a good car or a cheap car?
Do we optimize performance or power?
Most simple thing, often forgotten
Don’t be too greedy
“Is it feasible?”

#6/35
Both from customer’s and developer’s side
http://www.youtube.com/watch?v=1GSV2kVkO1w
Management 1b: unclear goals
 Remember also the self-evident showstoppers
 ”evident to one’s self and to nobody else” - A. Bierce
 ”Oh, I forgot to mention that our Gizmo must cost less
than 1€...”
 Hence, aim for quantifiable goals
 Goals that are unambiguously met or not
 E.g. ”This projects cuts expenses by 8%. Expenses
are calculated as...”
 Motivate your workers to aim for the common
goal
 Reward them for success
 Don’t reward bonuses for regular or bad performance
 Motivation can also go terrible wrong: meaningless
”Company values” just worsen things
#7/35
Mng 2: Badly defined requirements
 Critical step in the project
 Poor requirement
Fig: [J.P. Bowen, M.G. Hinchey, Ten
Commandments of Formal Methods ...Ten Years
Later, Computer, Vol. 39, Iss. 1, Jan. 2006, pp. 40
– 48]
document creates
 Ambiguity for the design -
which way to choose?
 Contradictory goals – which
one is right?
 Most customers are
inexperienced in
requirement capture
 Get your most experienced
engineers involved
#8/35
Mng 2b: Badly defined requirements
 Review and validate requirements thoroughly
 Speak up if the requirements do not make sense
 Get acceptance on black-and-white
 Track their consequences – what other parts are
affected, how this can be verified in end product…
 Remember: Even if product meets the specification, it
may not meet customer’s wishes
 Late changes to requirements are also
problematic
 The sooner the better; the less the better
 e.g. Pentium bug: optimize area just before tape-out
 E.g. legendary ”Eight is beautiful” – Ken Kutaragi (Cell
processor was a success, nonetheless!)
#9/35
Mng 2c: Badly defined requirements
 However, changes are inevitable
 Apply disciplined change procedure
 Postpone/discard most, accept only the critical
changes
 Prioritize requirements and changes
1.
These features are absolutely necessary


2.
3.
They bring the biggest income
They create biggest losses if they fail
These might be incorporated if schedule
allows
These are definitely rejected
”Asialliset hommat suoritetaan, muuten
ollaan kun Ellun kanat” – Vänrikki Koskela
 Dumbstriking real-life quote ”Even if things
are lower on the priority list, they are still as
important…”
#10/35
Mng 3a: Poor project management
 Information hiding seldom pays off
 Give reasons to decisions
 Tell what exactly was promised to the
customer
 Everyone should have access to the
requirements and code database
 Don’t forget where the money
comes from
 Ensure that everyone knows in
which project they are involved in
 Ensure that project is properly
ended and not just fading within
time
 Do not update your organizational
structure every month
#11/35
Mng 3b: Poor project management

Long projects are also more late


Split to small projects instead of ”sqeezing”
Settle few milestones that have to be met

Convert the huge last week’s panic into several but smaller
mid-week panics
 The larger the project, the
greater the gap between the
actual and the planned
delivery date
Actual
Planned
#12/35
[C. Jones, Social and Technical reasons for software project
failure, J. Defense SW Eng., 2006]
Mng 3c: Poor project management

Avoid excess bureaucracy




Be careful with bonus systems



#13/35
“It is easier to be forgiven than granted“ – Stuba
Nikula. Follow this guideline with care 
”Three managers, in three continents, wasted
many hours of work for deciding, if employee can
attend 150 EUR seminar”
”All important decisions [regarding tools] are
made at least 2 organization steps above the
level where the consequences are understood”
”No. I won’t sell you this spare part, because then
we wouldn’t have any in stock, and what if
someone wants to buy one? ” – true story
”We’ll give you a 50% bonus because that is
what you got last year. – But this year was a
great success, bonus should be 100% –Hmm,
we’ll pay according to the net profit of Division E
–But I work in Division B!” – true story
Soviet chandeliers tore the ceilings because
factory productivity was measure as kilograms–
urban legend or a true story?
Mng 4: Poor estimates of needed
resources


Do not overestimate your (team’s) capabilities
Everything takes longer than you think



Remember mythical man-month [F.P. Brooks]




#14/35
Many tasks won’t finish sooner with more workers
Often they are more late (managing overhead grows)
Compare digging a well and trench
However, one ”super-designer” may account 5-10
regular engineers in certain tasks


Especially verification (e.g. 40-80% of project’s time)
Comments regarding the exercise work, anyone?
They are rare! Make them feel comfortable, bake them
cookies etc.
Ensure that project has enough resources right
from the start. Otherwise, you’ll be late from day
one
Mng 4b: needed resources
 Account the other duties of the labor
 administrative tasks, other projects, vacations...
 Most people are productive when they can
concentrate on one thing at a time
 Task switching takes time
 Even if the pending task is
small, it is in the back in the
brain and distracts
concentration
 Multitasking reduces productivity
by 20-40%. Can you afford that?
[Anderson, Study: Multitasking…, CNN.com, Aug. 2001]
#15/35
On ”multitasking”
 Many tasks require coordinating with another team member, interrupting





#16/35
the current task of the assisting member. In this atmosphere, it is not
unusual for developers to fail to recall the need to perform a specific task,
known as prospective memory failure. In addition, productivity is negatively
affected:
Czerwinski’s study [3] showed that tasks which resumed after interruption
were more difficult to perform and took twice as long.
O’Conaill’s study [15] found 40% of interrupted tasks are not resumed at all
[during the same day]
Further research [13] observed 57% of tasks were interrupted, and the time
spent working uninterrupted was very small.
A recent study [12] of software engineers working at Microsoft indicated
that 62% of developers surveyed believed recovering from interruptions
was a serious problem.
Opportunities for breakdowns in communication are possible across
numerous boundaries [11]. A large divide exists in communicating between
managers and programmers. The reasons for this are several: technical
inexperience, differing personality types, team structures,and personnel
removal. Moreover, programmers are often buffered from upper
management concerns, budget constraints, schedule concerns, and task
priorities.
Erno Salminen - April. 2011
On ”multitasking”
 Citation on previous slide taken from Chris Parnin and Carsten Görg,
Design Guidelines for Ambient Software Visualization in the Workplace,
VISSOFT 2007: 18-25. 2006
 References:
 [3] M. Czerwinski, E. Horvitz, and S. Wilhite. A diary study of task switching




#17/35
Erno Salminen - Nov. 2008
and interruptions. In CHI ’04: Proceedings of the SIGCHI conference on
Human factors in computing systems, pages 175–182, New York, NY, USA,
2004. ACM Press.
[15] B. O’Conaill and D. Frohlich. Timespace in the workplace: dealing with
interruptions. In CHI ’95: Conference companion on Human factors in
computing systems, pages 262–263, New York, NY, USA, 1995. ACM Press.
[13] G. Mark, V. M. Gonzalez, and J. Harris. No task left behind? Examining
the nature of fragmented work. In CHI ’05: Proceedings of the SIGCHI
conference on Human factors in computing systems, pages 321–330, New
York, NY, USA, 2005. ACM Press.
[12] T. D. Latoza, G. Venolia, and R. Deline. Maintaining mental models: a
study of developer work habits. In ICSE ’06: Proceeding of the 28th
international conference on Software engineering, pages 492–501, New York,
NY, USA, 2006. ACM Press.
[11] H. Krasner, B. Curtis, and N. Iscoe. Communication breakdowns and
boundary spanning activities on large programming projects.Empirical studies
of programmers: second workshop, pages 47–64,1987.
Mng 5: Poor reporting of the project’s
status
 Bit boring, but essential
 No reason to make things look nice – be realistic
and honest
 Seek trade-off between being a yes man and a
negative creep
 Report concisely
1.
2.
3.
4.
What has been done?
How do you know it works?
What has not been done although planned? Why?
What will happen next?
 Opt for live reporting instead of written one
 Excess reporting is usually a sign that
management does not know what people
actually do
#18/35
Mng 5: Poor status reporting
http://blogs.warwick.ac.uk/images/steverumsby/2007/02/15/dilbert2007916360215.gif
http://space.mit.edu/cxc/local/dilbert_status_report.jpg
P.S. Dilbert would be most funny if it was fictional. Unfortuantely, it is a documentary comic… 
#19/35
Mng6: Unmanaged risks
 Mother nature is a bitch and Murphy was an
optimist
 Prepare for the delays
 You don’t exactly what it is, but it will happen
 part delivery, manufacturing, vacations, bugs, higher
priority tasks, sick leave, vacations, damaged
equipment...
 What if COTS does not work as expected?
 What if our subcontractor goes out of business
within 5 years?
 Question: How does a large project get to be one
year late?
 Answer: One day at a time!
 React early!
#20/35
What happens if André is fired or quits?
Mng6:
Unmanaged risks
 Acknowledge that
important people
may leave
 Hence, all codes
must have an easystart
 Makefile
 Testbench
 Examples
 Documentation
 Estimate risk’s
probability and
associated cost
#21/35
Reasons related to
context
Context 7: Poor communication
 Poor communication among customers,
developers, and users
 Right hand does not know what the left one is
doing
 Make sure that each meeting has agenda and
concise written conclusion




”Today, we’ll decide…”
Prepare well if you are to present something
Make sure that everyone has access to those memos
Who is responsible of doing X by which date?

Do not use passive voice
 Accept and welcome the debate
 Remember to ask ”stupid” questions
 Don’t shoot the messenger
#23/35
Context 7: Poor communication
 Gets worse when number of stakeholders grows
 Do not underestimate the power informal
communication and face-to-face meetings, such
as coffeebreaks
 Locate the team members near to each others
 Some prefer ”war rooms” [Teasley, IEEE Tran SW
eng, 2002]
 I really like waiting for others in meetings,
especially looking at computer booting, projector
setup, looking at file browsing and guessing the
file version, waiting the slide show setup (it’s
F5!)…
#24/35
Context7: poor comm + bad req
#25/35
Just poor communication…
http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/6000/300/635
#26/35
Context 8: Commercial pressure
Rush to the market
Feature explosion for marketing purposes (aka.
scope creep)


Complicates development and maintenance, overhead
(area, mem. footprint, runtime, power)
Overoptimizing the
price
 Challenger
shuttle O-ring…
 Insufficient
resources
 Using cheap and
poor EDA tools
Fig. 1 [R. Boecker et al., Reducing the Gap
Between What User Know and What They need to
know, in. Universal Usability, 2002]
#27/35
In MS Wröd


Context 9: Stakeholder politics







#28/35
Stakeholder (corporate), a person, group,
organization, or system who affects or can be
affected by an organization's actions
”Not invented here!”
”We have always done it that way”
”We can’t optimize that because makes our
older products look stupid…”
Elop effect: ”Hmm, surpising, our sales drop
catastrophically although we only said our
product is crap”
”Are you absolutely sure that it does not
infringe any existing patent?”
”Despite its novelties, we oppose your
suggestions for optimization [because it may
bring cutdowns in our budget in a long run]”
Elop effect: [http://communities-dominate.blogs.com/brands/2011/08/coiningterm-elop-effect-when-you-combine-osborne-effect-and-ratner-effect.html]
Context 9: Stakeholder politics (2)




#29/35
”At the moment, we can’t hire anyone to send the bills”
”No, I cannot serve the paying customer because I’m
making reports about our sales”
”We won’t sell your application at our store. And that is
just because. And we will sue your sorry ass if you
complain”
”We will offshore these jobs and the new people will
master them instantly. No problem.”
http://3.bp.blogspot.com/_Xq0nPfnJPHQ/S-1MZkeavI/AAAAAAAAAFs/uAbBPBbCxSY/s1600/dilbert.gif
Reasons related to
implementation
Impl 10: Use of immature technology

Or technology unfamiliar to the developers or
vendors



Project’s success should not hinge on the
adequate performance of new technology
A project can be based on an emerging technology



thoughtful assessment that such a technology has
extraordinary potential
differential value achieved by being an early adopter
Even in these cases, first carry out pilot projects
that provide experience with the technology

#31/35
”Make sure that simple things work...”
limit the scope of its implementation to minimize potential
damage
Impl 11: Sloppy development practices












No version control (see next slide)
Poor documentation
No headers in files (designer, purpose, project…)
Inconsistent naming
No review process
Ignoring the compiler warnings
Not checking return values
Not using assertions
25% of admin time spent going down blind alleys due to
bad msgs [Candea]
”I hope someone else will check it”
”I’ll code this first and test after that”
Plain stupidity: ”What do you mean that price list must
be correct? It’s an estimate, get it?” – true story
[Candea, http://resist.isti.cnr.it/free_slides/dependable/candea/Lecture-08_(Manageability).pdf]
#32/35
Impl 11b: must use version control
 Use version control (Git, SVN, ...)
 Works well with text: .txt, .c, .h, .vhd, .tex, .java, .html.,
xml, .csv, .py…
 Teaches one to take logically consistent steps in a
project
 Add files, update, commit, check log…
 Helps backup process
 Easy throw-away code prototyping
 Keeps track of your work (how many changes in a
week?)
 Keeps track who did what
 One can go back to see any previous version
 Version control is must for all work
#33/35
Impl 12: Inability to manage complexity


Limit the scope
Divide-and-conquer, separation (orthogonalization)
of concers




Reuse everything you can
Model-based design, model-driven engineering





#34/35
Separate computation and communication
Separate function and architecture
Obtain early estimates and bounds
Establish the critical choices early
Automate the implementation via synthesis
Carry out a small pilot project first
Techniques for this challenge are addressed in
TKT-2431 SoC Design
Impl 12b: Inability to manage complexity

“The most important aspect of any design is how it
is partitioned. The second most important aspect of
any design is its interfaces.” – M. Keating




Minimize coupling between modules
Dst and source parameters always in the same order
Similar naming convention
Use consistent units




#35/35
If some function users meters as units, no function should
use millimeters
Try to make functionality obvious
Names should not be too long but they should also be tothe-point
Try to make misuse hard (e.g. add checks and asserts to
the code)
Another views
Why projects fail [Coley Consulting]
 1. Lack of User Involvement
 2. Long or Unrealistic Time Scales
 3. Poor or No Requirements
 4. Scope Creep
 5. No Change Control System
 6.Poor Testing
#37/35
Five reasons why software projects
fail [W.S. Humhrey, ComputerWorld]
1. Unrealistic schedules
2. Inapproriate staffing
 “The only way to complete an engineering project
rapidly and efficiently is to assign an adequate
number of people and then protect them from
interruptions and distractions.” Agreed!
3. Changing requirements during development
4. Poor-quality work
5. Believing in magic
[http://www.computerworld.com/s/article/71209/Why_Projects_Fail]
#38/35
Another view of the schedule factors
Each bar denotes a factor used in schedule estimation.
For example, very capable personnel may bring up to 4.18x reduction
in schedule (cost). Such factors have been refined in COCOMO II and
other similar estimation methodologies.
[B.W. Boehm, Improving Software Productivity,
Computer, Vol. 20, Iss. 9, Sept. 1987, pp. 43 - 57.]
#39/35
Erno Salminen - Nov. 2008
Productivity
factors
 Table shows the best
and worst differences
to nominal
development
 Decrease factor is
usually larger than
increase
 It is much easier to
mess up than being
extra productive
 E.g. trying reuse
crappy SW is doomed,
having no inspections
by 48%, high
requirement creep by
77%...
From: P. Goldberg, Producing Production Quality
Software - Lecture 14, New York Univ., 2005, online
http://www.cs.nyu.edu/artg/Producing_Production_Qualit
y_Software/Fall2005/
#40/35
Further reading on project management
 Robert P. Colwell, The Pentium Chronicles:
The People, Passion, and Politics Behind
Intel's Landmark Chips, Wiley-IEEE
Computer Society, 2005
 Author is former chief IA32 architect for
Pentium II, III, and 4 microprocessors
 Brilliant stuff
#41/35
R. Colwell, Pentium Chronicles
 ”The very essence of engineering is the art of
of compromise, of trading-off one thing to
another”
 ”The act of codifying one’s thinking unfailingly
reveals conceptual holes, mental vagueness,
and outrigth errors”
 ”Nothing will ever be attempted if all possible
objections must be first overcome”
 One must take some risks
 ”You cannot run a project from ten thousand
feet”
#42/35
Further reading on project management (2)
 David Shippy and Mickie Phipps, The Race
for a New Game Machine, Kensinkgton
Publishing Corporation, 2008
 Designing Cell processor at
Sony/Toshiba/IBM Design Center (STI)
 Chip used in Playstation3 and
Xbox 360
 Authors lead the development of
the new PowerPC processor
 Brilliant stuff
#43/35
Further reading
 History's Worst Software Bugs (Wired)

http://www.wired.com/news/technology/bugs/0,2924,69355,00.html
 Software Horror Stories (Nachum Deshowitz, Tel Aviv
University)
 http://www.cs.tau.ac.il/~nachumd/horror.html
 Failure Rate (collection of failure rate statistics from IT surveys)
 http://www.it-cortex.com/Stat_Failure_Rate.htm
 The DailyWTF
 http://thedailywtf.com/
 More on management's role in IT project failures: the failure
rate of IT projects is quite high (John Glaser)
 http://www.allbusiness.com/technology/306312-1.html
#44/35

TKT-1212 Digitaalijärjestelmien toteutus

Transcription

Similar documents

MNG Gold Liberia Inc. - The Executive Mansion

MNG Gold Liberia Inc. Job Announcement (1 Position)

PDF report

TIE-50200 Logiikkasynteesi

Franz Schubert Impromptus, Moments Musicaux, Klavierstücke for

KICKS AND GEAR RUNS THIS KICKS AND GEAR

Lectures 2-4: Introduction to System design, VHDL Basics

Pimp my memory - Temple University

[email protected] [email protected]

Exchange Report

Studs Terkel, with Tony Parker

ce1"f[,Caf~ w~re. ra.Y8I~ 1336.

Redalyc. Upper Jurassic ammonites and bivalves from the Cucurpe

Document 6588895