TIE-50200 Logiikkasynteesi

Transcription

TIE-50200
Logiikkasynteesi
Lec 14 – Project management
Erno Salminen
Department of Computer Systems
Tampere University of Technology
Spring 2014
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/40
Department of Pervasive Computing
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/40
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/40
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/40
[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
Get technical people involved when 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
See also:


#6/40
Both from customer’s and developer’s side
http://www.youtube.com/watch?v=1GSV2kVkO1w
http://laughingsquid.com/the-expert-a-hilarious-sketch-about-thepain-of-being-the-only-engineer-in-a-business-meeting/
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
 Small details are solved ”automatically” when the common
vision is clear
 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/40
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/40
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
 Aim for MVP (minimum viable product)
 Minimum set of features to gather early feedback
 Release early, releasy often
#9/40
Mng 2c: Badly defined requirements
 Prioritize requirements and changes
1.
These features are absolutely necessary


Bring the biggest revenue
Create biggest losses if they fail
These might be incorporated if schedule
allows
3. These are definitely rejected
 ”Asialliset hommat suoritetaan, muuten ollaan
kun Ellun kanat” – Vänrikki Koskela
2.
 Dumbstriking real-life quote ”Even if things
are lower on the priority list, they are still as
important…”
 Small list of personal duties for a day/week
is a great help
 Relieves memory burden, improves
concentration, helps prioritizing
#10/40
Mng 2d: req’
 However, changes are inevitable
 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!)
 Apply a fast disciplined change
procedure
 Postpone/discard most, accept
only the critical changes
#11/40
Erno Salminen - April. 2011
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
#12/40
Mng 3b: Poor project management


Do not update your organizational structure every month
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
Short sprints
 It is psychologically rewarding
to see progress
 The larger the project, the
greater the gap between the
actual and the planned
delivery date
 In courses, the actual exercise
time is often 20-80% more
than students estimated
#13/40
Actual
Planned
[C. Jones, Social and Technical reasons for
software project failure, J. Defense SW Eng.,
2006] FP=function point, sw complexity metric
Mng 3c: Poor project management

Avoid excess bureaucracy




Be careful with bonus systems



#14/40
“It is easier to be forgiven than granted“ – Stuba
Nikula. Follow this guideline with care 
”Three highly paid managers, in three continents,
wasted many hours of work for deciding, if employee
can attend 150 EUR seminar” – true story
”All important decisions regarding EDA 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 the
productivity of the lamp factory was measured as
kilograms– urban legend or a true story?
Mng 4: Poor estimates of needed
resources


Do not overestimate your (team’s) capabilities
Hofstadter's Law: It always takes longer than you
expect, even when you take into account Hofstadter's
Law.



Remember mythical man-month [F.P. Brooks]




#15/40
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...
 might account 30-50% of work hours
 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 distracting
concentration
 Many tasks, e.g. debugging, require
uninterrupted concentration
 Multitasking reduces productivity by 2040%. Can you afford that?
 [Anderson, Study: Multitasking…,
CNN.com, Aug. 2001]
#16/40
On ”multitasking”
 Many tasks require coordinating with another team member, interrupting the current task





#17/40
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.
On ”multitasking” [refs]
 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




#18/40
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 weekly/daily live reporting instead of written
one every now and then
 Excess reporting is usually a sign that management
does not know what people actually do
#19/40
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… 
#20/40
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
 harddisk failure, 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!
#21/40
What happens if André is fired or quits?
Mng6:
Unmanaged risks
 Acknowledge that
important people may
leave
 Hence, all codes must
have an easy-start
 Anyone can repeat
the basics
 Common repository
 Makefile, testbench,
examples,
cocumentation
 Estimate risk’s
probability and
associated cost
#22/40
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…”
 Preferably no phones, no laptops, no distractions – just the
current topic
 Don’t wait for late comers – it’s their loss, not yours
 Prepare well if you are to present something
 Write down who is responsible for task X and when

Do not use passive voice (bugs will be fixed…)
 Make sure that everyone has access to memos
 Accept and welcome the debate
 Remember to ask ”stupid” questions
 Don’t shoot the messenger
#24/40
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!)…NOT
#25/40
Context7: poor comm + bad req
#26/40
Just poor communication…
http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/6000/300/635
#27/40
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]
#28/40
In MS Wröd


Context 9: Stakeholder politics

Stakeholder (corporate), a person, group,
organization, or system who affects or can be
affected by an organization's actions
 Conflict of interests arise in large consortium



#29/40
Maximizing personal/own group’ profit
Not everyone is honest
Requires diplomacy and negotiation skills
Context 9: Stakeholder politics








#30/40
Opposing all changes vs. useless ”improvements”
Legal and regulatory matters, auditing, certification
”Not invented here!”
”We have always done it that way”
”We can’t optimize that because that makes our
older product look stupid…”
Elop effect: ”Hmm, this is surpising, our sales drop
catastrophically when we just said our product is
crap and new ones are not coming soon”
”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)





#31/40
”We will offshore these jobs and the new people will master
them instantly. No problem.”
”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 have invested much money in this death march and
therefore we’ll continue on and on”
http://3.bp.blogspot.com/_Xq0nPfnJPHQ/S-1MZkeavI/AAAAAAAAAFs/uAbBPBbCxSY/s1600/dilbert.gif
#32/40
http://i.snag.gy/kdu77.jpg
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

#34/40
”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 later slide)
Some steps not repeatable by others than the orig. designer



Many manual, error-prone steps




#35/40
Automate as mush possbile, e.g. with scripts
make, run test, analyze_perf…
Unrecognized vendor-lock





Licenses, EDA tool setup/projetc files, local files, OS,
undocumented tricks…
Creates a single point of failure, e.g. due to long sick leave
Proprietary file format prevents moving to better environment/chip
Design works only with certain (old) tool/OS version
Non-existing/outdated/poor documentation
Poor link between docs and code
No review process
No headers in files (designer, purpose, project…)
Impl 11: Sloppy development
practices (2)









Inadeqaute verfication/test suite
Plain stupidity: ”What do you mean that price list must
be correct? It’s an estimate, get it?” – true story
Ignoring the compiler warnings
Dead code
Inconsistent naming
Not checking return values
Not using assertions
25% of admin time spent going down blind alleys due to
bad msgs [Candea]
Forgetting that code lives forever



Prepare that it will be read and modified many years after
development
”I hope someone else will check it”
”I’ll code this first and test after that”
[Candea, http://resist.isti.cnr.it/free_slides/dependable/candea/Lecture-08_(Manageability).pdf]
#36/40
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…
 Not just for ”ready” files
 Very few things are ready ever. Most things are somewhat ready and
always under development
 Depends on company policy regarding continuous integration
 Helps backup process
 Easy throw-away code prototyping
 Keeps track of your work (how many




#37/40
changes in a week?)
Keeps track who did what
One can go back to see any previous
version
Write reasonable commit log messages
Version control is must for all work
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




#38/40
Obtain early estimates and bounds
Establish the critical choices early
Automate the implementation via synthesis
Carry out a small pilot project first


Separate computation and communication
Separate function and architecture
Remember it’s a proof-of-concept, not final implemtation!
Techniques for this challenge are addressed in
TIE-50506 SystemDesign
Impl 12b: Inability to manage complexity


Many projects have hundreds to thousands of files
“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
Try to make functionality obvious
Try to make misuse hard (e.g. add checks and asserts to
the code)
Dst and source parameters always in the same order
Similar naming convention
Use consistent measurement units


#39/40
If some function users meters as units, no function should
use millimeters
Names should not be too long but they should also be tothe-point
Summary
 Many things can go wrong
 Some things will go wrong
 Often most things go ok
 Ensure that they are the important ones
 Be careful and precise
 Understand the real problem
 Don’t be greedy – Prioritize – Min. viable product
 Prefer real work over bureaucracy
 Remember where the money comes from
 Hopefully these generic lessons help you to
recognize common pitfalls in real life and
avoid them
#40/40
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
http://www.coleyconsulting.co.uk/failure.htm
#42/40
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]
#43/40
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.]
#44/40
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, high
requirement creep drops
productivity by 77%,
skipping inspections by
48%...
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/
#45/40
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
#46/40
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”
#47/40
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
 E.g. ”Eight is beautiful”
#48/40
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
 D. Galorath, Software Project Failure Costs Billions..
Better Estimation & Planning Can Help, Galorath Inc.,
June 2012, [online].
 http://www.galorath.com/wp/software-project-failure-costs-
billions-better-estimation-planning-can-help.php
#49/40

TIE-50200 Logiikkasynteesi

Transcription

Similar documents

TKT-1212 Digitaalijärjestelmien toteutus

How to resolve Error Code 20

Pervasive Information Architecture Heuristics

Towards qualitative assessment of weight lifting exercises using

PDF report

Mobile Life VINN Excellence Centre

Survey on Attitude Towards Pervasive Games

Energy Scavenging for Mobile and Wireless Electronics

extract

Upgrading Btrieve™ 6.15 to Pervasive® PSQL Summit™ v10

PDF (free)

Pervasive Games Field Trials: Recruitment of Eligible Participants

Dominique Guinard

Ambient Kitchen - User Web Areas at the

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

PDF - Mobile Life Centre

What Is New in Pervasive PSQL Pervasive PSQL v11

User`s Guide - Pervasive Software

Status Codes and Messages