Software Team Development Practices based on Java Development Teams at CERN - PowerPoint PPT Presentation

Loading...

PPT – Software Team Development Practices based on Java Development Teams at CERN PowerPoint presentation | free to download - id: 54eb80-MjFjM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Software Team Development Practices based on Java Development Teams at CERN

Description:

Software Team Development Practices based on Java Development Teams at CERN Derek Mathieson, James Purvis, Rostislav Titov CERN * No advantage to collaborate ... – PowerPoint PPT presentation

Number of Views:104
Avg rating:3.0/5.0
Slides: 46
Provided by: dmat4
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Software Team Development Practices based on Java Development Teams at CERN


1
Software Team Development Practices based on Java
Development Teams at CERN
  • Derek Mathieson, James Purvis, Rostislav
    Titov CERN

2
The reality today
  • Failure
  • 31.1 of IT projects will be canceled before they
    ever get completed
  • 52.7 of projects will cost 189 of their
    original estimate
  • More than 50 of software projects fail today.
  • Success
  • Only 16.2 software projects that are completed
    on time and on budget
  • In the large companies only 9 of their projects
    come in on time and on budget.
  • Catastrophe
  • Ariane 5 (7bn dev, 500 million) numerical
    conversion error
  • Mars Climate Orbiter (125 million) metric
    conversion error
  • Mars Polar Lander (165 million) design error

3
Typical Failures
  • User requirements not Met
  • Software unreliable
  • Too late (You took so long that our requirements
    have changed)
  • It works great for me, now deploy it for 10,000
    users
  • You did what I asked. but I didnt say what I
    meant
  • Projects completed by the largest American
    companies have only approximately 42 of the
    originally proposed features and functions.

4
Reasons
  • Unrealistic Schedules
  • When faced with an unrealistic schedule,
    engineering teams often behave irrationally. They
    race through the requirements, produce a
    superficial design and rush into coding.
  • Inappropriate Staffing
  • Changing Requirements During Development
  • Poor-Quality Work
  • There's a saying about software quality If it
    doesn't have to work, we can build it really
    fast.
  • Believing in Magic

5
Project Success factors
Project Success Factors and of Responses Project Success Factors and of Responses Project Success Factors and of Responses
1 User Involvement 15.90
2 Executive Management Support 13.90
3 Clear Statement of Requirements 13.00
4 Proper Planning 9.60
5 Realistic Expectations 8.20
6 Smaller Project Milestones 0 - 7.7
7 Competent Staff 7.20
8 Ownership 5.30
9 Clear Vision Objectives 2.90
10 Hardworking, Focused Staff 2.40
  Other 13.90
Project Challenged Factors and of Responses Project Challenged Factors and of Responses Project Challenged Factors and of Responses
1 Lack of User Inputs 12.80
2 Incomplete Requirements Specifications 12.30
3 Changing Requirements Specifications 11.80
4 Lack of Executive Support 7.50
5 Technology Incompetence 7.00
6 Lack of Resources 6.40
7 Unrealistic Expectations 5.90
8 Unclear Objectives 5.30
  Other 23.00
6
Factors
Cost
Quality
  • Four interdependent factors
  • Not possible to have best of all four
  • Cannot have cheap, high quality, little risk
    built quickly
  • You can achieve 2 successfully and other 2 have
    to be managed
  • Risk and quality are most important The system
    must work and successfully meet user
    requirements. This leaves speed (time) and cost
    (money) to be adjusted accordingly

Risk
Speed
7
The answer
  • Q What is the key to running a successful
    software project?
  • A Dont believe in Magic!
  • There is no silver bullet
  • But there are some step that can be carried out
    at each step in the process

8
Software Development Cycle
  • Analysis
  • Failing to build the right thing
  • Design
  • We didn't have time to do a design."
  • Implementation
  • Do you want it on time or documented?
  • Test
  • It's not a bug, it's a feature

9
Requirements Analysis
  • Writing software from Requirements is like
    walking on water its easier when frozen

10
  • Many projects fail because developers fail to
    build the right thing
  • Grady Booch

11
Analysis
  • State Goal
  • send a man to the moon before end of the decade
    return him safely to Earth, JF Kennedy
  • Specify the problem not the solution
  • Classification
  • M Must o S Should C Could 0 W Would
  • Concept of Operations document
  • This is my understanding of what you want
  • Beware of requirements gold plating
  • 80/20 rule
  • Verifiable use-cases

12
Design
  • One of the things that tools can do is to help
    bad designers create ghastly designs much more
    quickly than they ever could in the past

13
Example Failures
  • Ariane 5 (half billion dollars)
  • Y2K bug
  • F-16 equator
  • Mars Climate Orbiter
  • Mars Polar Lander

14
Reasons
  • Too complex
  • We didn't have time to do a design."
  • Jumping into the coding
  • Architect Someone who knows the difference
    between that which could be done and that which
    should be done.
  • One of the things that tools can do is to help
    bad designers create ghastly designs much more
    quickly than they ever could in the past

15
Good Design Principles
  • Consider alternative approaches
  • Not tunnel vision
  • Traceable to the requirements
  • Correct complete
  • Not reinvent the wheel
  • Use a pattern
  • Adaptability Accommodate Change
  • Maximize Cohesion
  • Minimize Coupling
  • Understandabilty
  • A design must be understandable if it is to
    support modification.

16
Good Bad design
  • Good Design
  • Change in one part of the system doesn't always
    require a change in another part of the system.
  • Every piece of logic has one and one home.
  • The logic is near the data it operates on.
  • System can be extended with changes in only one
    place.
  • Simplicity
  • Bad Design
  • One conceptual change requires changes to many
    parts of the system.
  • Logic has to be duplicated.
  • Cost of a bad design becomes overwhelming.
  • Can't remember where all the implicitly linked
    changes have to take place.
  • Can't add a new function without breaking an
    existing function.
  • Complexity

17
The Cost of Change
Cost
Time
18
Design First
  • Design team (gt1)
  • Design requires different skills
  • Collaborative
  • Informal design reviews
  • Standards based
  • Patterns
  • Maxims
  • Storyboard
  • Metaphor vision
  • Class Responsibility

19
Lessons Learned
  • Its not always right first time
  • Refactoring is OK
  • Keep the vision simple
  • Automate repetitive tasks
  • TEST the design
  • By modifying the problem

20
Design
  • Techniques used at CERN
  • Oracle Designer (ER diagrams)
  • UML (little)
  • Design Patterns (use not abuse)
  • CRC
  • Informal reviews

21
Coding
  • It doesnt matter if I write poor code the
    compiler will tell me if there is problem
  • It doesnt matter if I make a mistake it will
    come out in testing

22
Bugs
  • Experienced software engineers inject one defect
    in about every 10 lines of code.
  • The programmers aren't incompetent or lazy -
    they're just human.
  • All humans make mistakes, but in software, these
    mistakes result in defects.
  • This means that a modest-size program of 100,000
    lines of code typically would start with about
    10,000 defects.
  • Examples
  • INTEL Pentium no more than 80-90 Bugs
  • Cell Phone (200 000 loc) up to 600 errors.
  • Windows-95 10 Mill. loc up to 200 000 errors.

23
Code Review Example
  • Can you understand the following?
  • public class ba
  • public static final String cur USD"
  • public void dep (int i) bal -i
  • public void wit (int i) bal i
  • public String get () return Integer.toString
    (bal) " " cur
  • private int bal
  • And identify the defect?

24
The same code
  • public class BankAccount
  • public static final String CURRENCY USD"
  • private int m_balance
  • public void deposit (int amount)
  • balance balance - amount
  • public void withdraw (int amount)
  • balance balance amount
  • public String getBalance ()
  • return Integer.toString (bal) " " CURRENCY

25
Now imagine you have
  • A multi-domain, multi-lingual horizontal software
    application supporting 10,500 users in 42
    countries composed of

1.2 million Lines of Code 6,000 Java
classes 10,000 HTML templates many other
files
Welcome to EDH!
26
EDH Good Old Days (1991-98)
27
Results
  • Healthy outside, but unhealthy inside
  • Evolution from freedom to Chaos!
  • Development Platform Mac, PC Unix
  • Code C,C,Python, Prolog, ProC, PL/SQL,
    Perl...
  • Comments Spanish, Italian, French
    English...
  • Bugs Y2K dont care
  • Obvious code never reviewed Why would you show
    your code to anybody? Never did at university...
    Results count!
  • Consequence Maintenance became the primary
    resource-consuming activity

28
The authoritarian new days (1998...)
  • Autocratic
  • You will use a PC
  • You will use the chosen IDE
  • You will use Version Control
  • You will develop in Java
  • You will adhere to coding standards
  • You will show your code to others
  • Production Environment is Sacred
  • Scheduled Deploys
  • Team decision, No individual actions
  • No unreviewed code goes live
  • Doesnt sound very motivating? Ironically it is
    more motivating!

29
From University to Industry
Individual Development Practices
Team Development Practices
Uniform development environment
Common set of tools
Single technology choice
Common Code Ownership ( learning)
Quality of the Process
... driven by the members of the team (not
management imposed)
30
Requires Concrete Practices
  • Code Reviews
  • Coding Standards
  • Design Reviews
  • Mentoring
  • Uniform development environment
  • Coherent set of development deployment tools
  • Single language Technology
  • Test procedures, unit testing usability studies

31
Coding Standards why?
  • Why ?
  • 80 of the lifetime cost of a piece of software
    goes to maintenance.
  • Hardly any software is maintained for its whole
    life by the original author.
  • Code conventions improve the readability of the
    software, allowing engineers to understand new
    code more quickly and thoroughly.
  • Cannot review unless you have standards...
  • endless debate was driving too fast? Cannot
    answer without defined speed limits
  • Recommend best practices, avoid bad practices
  • Maintainable reliable software is key
  • Produces
  • Common Code Ownership

32
The essence of code reviews
  • Now we have rules, we can check conformance
    look for defects...
  • Q How many Code reviewers it take to change a
    lightbulb?

33
The essence of code reviews
  • Now we have rules, we can check conformance
    look for defects...
  • Q How many Code reviewers it take to change a
    lightbulb?

A Code reviewers don't change anything....They
just report that it's dark.
34
Code Reviews - guidelines
  • Form
  • Product is guilty until proven innocent
  • Producer is innocent because he/she is not on
    trial
  • More likely to find bugs if you assume they are
    there
  • Evaluate product not producer
  • Emphasize "review" aspect do not "fix it here".
  • Raise problems. Do not discuss solutions

35
Code Reviews - guidelines
  • Format
  • Three people minimum, seven people maximum
  • Roles
  • Author
  • Moderator
  • Scribe
  • Reviewer(s)
  • Preparation
  • Short businesslike (2 hrs max)
  • Not off-site. No telephones or interruptions
  • Donuts or other home goodies
  • Dismiss the guru who wants to demonstrate that
    their way is better

36
Code Reviews - guidelines
  • Management Involvement
  • NONE!
  • Not a manager's status meeting
  • Management is not represented during inspections
  • Inspections must not be used as a tool to
    evaluate workers
  • Not a committee, not a working group, not a
    status report not an appraisal instrument

37
Benefits
  • Primary objective
  • remove defects as early as possible in the
    development process
  • Other benefits
  • Early Testing
  • Project Tracking
  • Educational share best practices
  • Training of new/junior programmers
  • Improved Communication
  • Improved Individual Quality
  • Cross-training
  • Process-improvement
  • Shared Responsibility no individual blame

38
The Yes, buts...
  • I dont have time for this...
  • Good programmers code doesnt need reviewing
  • Its only a minor piece of code
  • Code Changes, then what?
  • 2nd pair eyes rule
  • Pair programming

39
Coding Tools
  • Atlassian JIRA
  • Issue tracking and project tracking
  • EDH every change must have a JIRA
  • Process should be as lightweight as possible
  • Atlassian GreenHopper
  • Agile project management (Scrum)
  • EDH 2-week sprints
  • Atlassian Confluence
  • Documentation (WIKI style)

40
Coding Tools (2)
  • Atlassian Crucible
  • Online code reviews
  • EDH Every production line of code must be
    reviewed
  • Atlassian FishEye
  • Browse version control repository (CVS, SVN)
  • Real-time notifications of code changes
  • Web-based reporting, visualisation and code
    sharing
  • Atlassian Bamboo
  • Continuous integration
  • Atlassian Clover
  • Java code coverage metrics

41
Coding Tools (3)
42
Testing
  • Bugs
  • Standard Software 25 bugs per 1000 lines of
    program. Good Software 2 errors per 1000 lines.
    Space Shuttle Software lt 1 errors per 10000
    lines. Example Handy (Cellular Phone) 200 000
    lines of program up to 600 errors. Windows-95
    10 Mill. lines up to 200 000 errors.
  • Sept 24 2004 Jpeg buffer overrun bug in MS
    windows
  • an attacker who successfully exploited this
    vulnerability could take complete control of an
    affected system, including installing programs
    viewing, changing, or deleting data or creating
    new accounts with full privileges
  • Defects
  • Testing ? Debugging
  • You may have zero bugs, but s/w may not meet
    requirements, scale, respond-in time

43
What do you test?
  • Correctness testing
  • Security testing
  • Reliability testing
  • Stress testing
  • Scalability testing
  • Performance testing
  • Usability testing

44
Testing
  • Software testing is an art requires a tester's
    creativity, experience and intuition, together
    with proper techniques.
  • Most of the testing methods and practices are not
    very different from 20 years ago.
  • Testing is more than just debugging.
  • Testing is expensive. Automation helps.
  • Complete testing is infeasible. Tradeoff
  • Testing, while essential, may not be the most
    effective method to improve software quality.

45
And after that?
  • Sofware Maintenance
  • 80 of lifetime of software
  • The Legacy Crisis
  • The relative cost for maintaining software and
    managing its evolution now represents more than
    90 of its total cost.
  • Example costs
  • Annual software maintenance cost in USA has been
    estimated to be more than 70 billion
  • Y2K 8.38 billion US dollar, 90 million for
    Nokia
  • 50 of their time is spent in the process of
    understanding the code!!!

46
Legacy Code
  •  
  • An average Fortune 100 company maintains 35
    million lines of code
  • These companies add in average 10 each year only
    in enhancements
  • As a result, the amount of code maintained
    doubles in size every 7 years
  • E.g. 70 or more of the still active business
    applications are written in COBOL (at least 200
    billion lines of COBOL-code still existing in
    mainframe computers alone)

47
Types of Maintenance
  • Corrective Maintenance (21)
  • A process that includes diagnosis and correction
    of errors.
  • Adaptive Maintenance (25)
  • Activity that modifies software to properly
    interface with a changing environment (hardware
    and software).
  • Perfective Maintenance (50)
  • Activity for adding new capabilities, modifying
    existing functions and making general
    enhancements.
  • This accounts for the majority of all effort
    expended on maintenance.
  • Preventive Maintenance (4)
  • Activity which changes software to improve future
    maintainability or reliability or to provide a
    better basis for future enhancements.
  • Still relatively rare.

48
Process
  • Unstructured Maintenance
  • only available element is the source code
  • painstaking evaluation of the code, complicated
    by poor internal documentation,
  • things such as program structure, global data
    structures, system interfaces, performance and/or
    design constraints are difficult to ascertain and
    frequently misinterpreted,
  • ramifications of changes to the code are
    difficult to assess,
  • regression tests are impossible to conduct
    because no record of testing exists.
  • Structured Maintenance
  • Begins with an evaluation of the design
    documentation.
  • The impact of required modifications or
    corrections is assessed and an approach is
    planned.
  • The design is modified and reviewed, new source
    code is developed and regression tests are
    conducted.
  • Emergency bug fixes
  • cost more than routine, scheduled corrections.
  • performed under pressure,
  • disrupt the orderly process of delivering new
    releases
  • introduce new errors.

49
Results
  • Maintenance Costs
  • Typical software organizations spend anywhere
    from 40 to 70 percent of all funds conducting
    maintenance.
  • Maintenance-bound organizations result loss or
    postponement of development opportunities.
  • Customer dissatisfaction when requests cannot be
    addressed.
  • Reduction in overall software quality as a result
    of changes that introduce latent errors in the
    maintained software.

50
Your challenge !
  • Come in the 9 of projects on time in budget
  • Engineer your software (design, review
    maintenance in mind)
  • Are you an artist, scientist or engineer?
  • Art or Science?
  • Control the spiraling IT costs improve the
    reputation of the industry

51
Thank You
For More Information
E-mail Rostislav.Titov_at_cern.ch
About PowerShow.com