The document discusses modernizing agile software engineering practices, including managing code changes, feature-based development, and peer reviewing changes. It recommends adopting copy/modify/merge development using streams rather than check-out/check-in to enable parallel development. Features should be developed in separate streams for isolation. Peer review is important to find defects early, improve quality, and develop skills. Regular merging and rebasing of streams is advised to integrate changes.

1. 1
FUG2016Copyright © Serena Software 2016
WE OWN IT!
Dimensions CM:
Agile Software Engineering Practices
Don Irvine
VP ALM Products

2. 2
FUG2016
Agenda
Why modernize your practices?
Managing code change
Feature based development
Reviewing changes
Embrace CI & DevOps

3. 3
FUG2016
Why modernize your practices?

4. 4
FUG2016
Why modernize?
• Makes your development team comfortable
• If a task or process is cumbersome developers will find a way around it
• New hires more familiar with modern practices
• Will improve your efficiency
• Iterate on development work faster
• Reduce the pain of merge activities
• Will improve your quality
• Catch defects earlier
• Catch deployment issues before production
• Aligned with direction of Serena products

5. 5
FUG2016
Process review
• Opportunity to review your processes
• Existing implementation may be many years old
• Dimensions CM has changed over the years
• Industry best practices have evolved (e.g. agile/iterative development)
• Listen to the users
• What don’t they like about existing development practices
• What gets in their way?
• What do they like about current processes?
• Do some root cause analysis
• What is causing issues you see today?
• Failed compilation, failed deployment, failed testing
• Not meeting requirements/standards
• Serena Professional Services can help

6. 6
FUG2016
Managing code change

7. 7
FUG2016
Check-Out/Check-In - Projects
Check-Out Check-In
Code/build/test
Project
Work Area

8. 8
FUG2016
Problems with Check-Out/Check-In
• When parallel check-out is not allowed
• Development becomes serial
• Other users cannot change the file until the lock is released
• When parallel check-out is allowed
• Can lead to multiple tip revisions
• Which version is the latest?
• When do you merge them?
• Revisions in the project may not have been built/tested
• An extra step for the developers
• They just want to edit the code, not check-out first
• Industry has evolved
• This model was the norm 10-15 years ago

9. 9
FUG2016
Copy/Modify/Merge - Streams
Update
Code/build/test
Deliver
Conflicts? YesNo
Stream Work Area

10. 10
FUG2016
Copy/Modify/Merge - Benefits
• Encourages frequent update
• Finds integration issues sooner
• Encourages local build and test before delivery
• Not able to make direct modifications to the stream
• Enables parallel development
• Improves the speed of development
• No need to wait for other users to check-in first
• Locking is still possible for files in a stream
• For files where parallel development is not possible
• No big merge exercise at end of development
• Smaller incremental merges as each developer delivers

11. 11
FUG2016
Copy/Modify/Merge – Benefits…
• Delivery of multiple files in a single changeset
• Logical unit of change
• Instead of individual file/folder operations
• Gives visibility to the change as a whole
• Single change to be built/reviewed/merged
• Results in simple item pedigree
• Single line of descent in a stream
• Easier to identify where a change was introduced

12. 12
FUG2016
When to use Check-Out/Check-In
• Some situations may mean you need to use check-out/check-in
• When files cannot be merged
• Parallel check-out disallowed, enforces development in serial
• When you need to see which files are being changed
• Checking-out gives some visibility to who is working on what
• But you always know which developers are working on which requests
• When user making the changes cannot perform the merge
• Check-Out/Check-In with parallel check-out
• Create multiple tip revisions
• Other users can perform merge later
• When using Dimensions z/OS
• Our recommendation is to use Streams

13. 13
FUG2016
Feature based development

14. 14
FUG2016
Isolating units of work
• Why separate out pieces of work?
• Agile approach (only include in the release what work is complete)
• Will not be affected by defects/changes introduced by other work
• More stable/release-ready software
• Works best if the features are truly separate
• Code does not overlap with that of other features
• Separate software components
• Something with a well defined interface
Mainline
Feature 1
Feature 2

15. 15
FUG2016
How to isolate units of work?
• Using revised baselines
• Use requests to pick and choose which changes go into your baseline
• Build and test that baseline
• But what if changes overlap?
• Using design parts
• Each feature has its own part
• Baseline each part independently
• Merge baselines together to form a release
• Only works if features are separate components
• Using separate streams
• Features developed in separate streams
• Clear separation from other work
• Easy for developers to understand

16. 16
FUG2016
Using separate streams
• Each development project has a mainline
• Maybe one of these for each parallel release of software
• Maybe your releases also feed up to a single mainline
• Separate stream for features or teams
• Branch off the release stream when development starts
Mainline
Release2
Release1
FeatureX

17. 17
FUG2016
How and when to rebase?
• When to “rebase” or update your Streams from mainline?
• When there is a change you are dependent upon
• You may not need to do this at all
• But the longer you leave this the harder your merge will be
Mainline
HotFix
NextRelease
FeatureX
Hot Fix has
completed so the
team decide to
merge it in.

18. 18
FUG2016
How and when to merge?
• How and when to merge
• When testing is complete
• When another team needs your feature
• When Serena Pulse tells you the health and quality are good
• When a release is complete
Mainline
HotFix
NextRelease
FeatureX
Release has
shipped, so can
be merged to
mainline.

19. 19
FUG2016
Some things to consider
• Each stream may need its own infrastructure
• Separate builds for each feature
• Separate deployment areas might be needed
• Testing tools/infrastructure
• Consider how this effects your requests
• Do you have changes that cross multiple features/teams?
• Create high level requests
• Break them down into the changes needed in each stream
• Applies to incoming defects as well as development change requests
• Each Stream may be a mini-development-project
• With stage gates and deliverables and a timescale for merge
• Some naming convention for your streams
• e.g. <RELEASE>_<FEATURE>

20. 20
FUG2016
What is Peer Review?

21. 21
FUG2016
What is Peer Review?
“Examination of a work product by the author and one or more colleagues”
• Design, Documentation, Source, Configuration Files, Scripts, Models etc
• Complete “change” is examined as a whole
• Comparing previous version of each file with the new version
• Also look at new files, removed files and refactoring
“Q: What's the cheapest way to get rid of bugs?”
“A: Don't put them in in the first place”
• Goal of Peer Review is to:
• Find defects/issues in the deliverables
• Improve the quality of the deliverables
• Verify what was implemented meets expectations/requirements

22. 22
FUG2016
The history of Peer Review
• The Fagan process for software inspection (1976)
• Michael Fagan documented the process of formal software inspection [1]
• Defines formal review in terms of roles, inputs, deliverables, meetings
• Peer Review in an agile environment (2001)
• Often referred to as “lightweight” peer review
• Continuous Review (every delivery is reviewed)
• Pair Programming and XP
• Serena Pulse delivers integrated Peer Review with Dimensions CM
(2014)
• Configurable, controlled & audited, collaborative Peer Review
• Bringing all the information together for the reviewers to do their job
[1] M.E., Fagan (1976). "Design and Code inspections to reduce errors in program development". IBM Systems Journal

23. 23
FUG2016
Types of Peer Review
• Pre-delivery (“over the shoulder” review)
• Before the developer checks-in
• Works best for small local teams
• Good opportunity to ask the author questions
• But no audit trail or accountability
• Not practical if multiple people need to do the review
• Continuous Review (on every delivery)
• Automated review process, after the developer checks-in
• Captures audit trail of the review
• Gives reviewers more time to perform the review
• Can work well with teams of reviewers
• Formal Code Inspection (on entire features/components)
• Scheduled review meeting with stakeholders
• Often involves other artefacts (requirements, test plans, training material)
• Works well for highly regulated industries
• Can be costly to perform

24. 24
FUG2016
Why Perform Peer Review?

25. 25
FUG2016
Cost of finding and fixing issues
• Cheaper to find and fix defects during development

26. 26
FUG2016
Improving Software Quality
"If you know someone is going to look at your code afterwards then you are far
more likely to write it better in the first place.“
• Industry average is 5 bugs for every 100 lines of modified code
• Peer Review can catch 65% of all defects [2]
• "given enough eyeballs, all bugs are shallow“ – Linus Torvalds
• Validates the logic/algorithm of the code
• Catches edge cases
[2] Capers Jones (June 2008). “Measuring Defect Potentials and Defect Removal Efficiency”. Crosstalk Magazine

27. 27
FUG2016
Improving Software Security & Maintainability
• Improving Software Security
• Check for common security issues
• Ensure no backdoors or debug code is left in
• Check that standard encryption and authentication are used
• Improving Software Maintainability
• Compliance to company coding standards
• Identify overly complex logic
• Ensure use of common software patterns
• Reviewer needs to understand the authors code
• Improving Software Compliance
• 21 CFR Part 11, SOX, ISO26262 etc
• Part of your audit trail
• Does the delivery include 3rd party components?
• Is software appropriately licensed?

28. 28
FUG2016
Improving Developers Skills
• Developers learn from one-another during Peer Review
• Peer Review improves your “bus factor”
• More developers familiar with the changes being delivered
• Junior Developer reviewing Senior Developers code
• Learns tips and tricks from the author
• Senior Developer reviewing Junior Developers code
• Can get a feeling for how the junior developer is progressing
• Builds a sense of team spirit
• “we are in it together”

29. 29
FUG2016
How to Perform Peer Review?

30. 30
FUG2016
Peer Review practices
• Review and Inspect all delivered files side by side with previous versions
• If possible perform a pre-delivery review
• Have the author walk through the code change
• Encourage reviewers to ask questions
• How did you test it?
• Did you consider any alternative approaches?
• Did you consider edge cases (errors, empty values/lists, large amounts of data etc)?
• Ask about performance and scalability?
• Ask about security implications of the change if any?
• Author will often spot their own mistakes
• Simply during explaining the logic to the reviewer(s)
• Reviewer should be accountable for the change
• If problems are found after review, ask why it was missed

31. 31
FUG2016
Peer Review Practices…
• Promote constructive criticism
• If a reviewer spots a problem have them suggest a solution
• Don’t make reviewing a “blame game”
• Encourage “good” behaviour, not punish “bad” behaviour
• Avoid nit-picking, focus on the high value comments/feedback
• Good Review takes time
• 150 lines of modified code an hour (~2 lines of modified code a minute)
• Don't stop reviewing just because release is imminent
• Drop a feature rather than risk a defect
• Monitor and tune your review process
• Look at metrics/reports
• Are changes being stuck in the review state for too long?
• Are reviews often failing
• Is it one person who is always failing or always approving?

32. 32
FUG2016
Peer Review Checklist
• Checklist of what needs to be done during review
• Could be reminders to the reviewer as to what to check
• Security, Scalability, Performance
• Complexity, Maintainability
• Compliance to standards/guidelines
• Could be very specific to your application/industry
• Different items might be checked-off by different people
• You may need to keep audit trail
• Who check-off what and when

33. 33
FUG2016
It is not just the code
• All artefacts relating to the change should be reviewed
• Requirements, Design, Models/Diagrams, Scripts, Configuration files
• In addition to the source files themselves
• Information from other tools helps reviewer make decision
• Compiler warnings
• Unit test results
• Static Analysis findings
• Style checker results
• Security analysis tool output
• Tools can help automate large reviews

34. 34
FUG2016
The review team
• Many ways to choose reviewers and sign off the review
• Your choice will depend on
• Size of your team
• Regulatory compliance needs
• Complexity of software etc
• Should reviewers be selected by the author?
• In small agile teams this is probably true
• Can reviewer be selected automatically based on knowledge?
• Change to missile detonation software goes to the expert in that area
• One reviewer or more than one?
• Formal highly regulated reviews may have a “lead” reviewer and a team
• Do all reviewers have to agree?
• Does someone have a “veto” over the status of the review?

35. 35
FUG2016
Use Serena Pulse
• Integrated Peer Review process with Dimensions CM
• Automated post-delivery review
• Side by side comparison of artefacts modified
• Including information from other development tools
• Build tools, Static Analysis tools, Style checking tools etc
• Configurable
• Supports lightweight reviews to large formal team based reviews
• Integrated with your CM Request lifecycle & roles
• Collaborative
• Encourages conversation between reviewers and authors
• Modern look and feel – a tool developers will want to use
• Controlled
• Configurable review checklist with full audit trail
• Metrics & Reports to see trends in your review process

36. 36
FUG2016
Peer Review Summary
Peer Review brings many benefits
improved quality, maintainability, security
Consider using Serena Pulse
Configurable, Collaborative, Controlled
Review your current Peer Review process
Does it meet your regulatory needs?

37. 37
FUG2016
CI & DevOps

38. 38
FUG2016
Continuous Integration
• Build and test every change as it is delivered
• Encourage frequent delivery of work in progress
• Finds issues/problems early
• Issues integrating code delivered with other changes
• Gives confidence you’re building on a solid foundation
• Increases visibility of the health of development
• Use Serena Pulse to drive your CI build
• Pulse can kick off build tool on each delivery
• Shows information from build and unit test results

39. 39
FUG2016
Why do we need DevOps?
• Failed deployments are costly to fix
• Deploy worked in dev but failed in production
• The wrong versions got deployed
• Development don’t know what is running production
• Business typically wants to deliver releases more frequently
• Without sacrificing quality or release content
• Development teams, QA and IT operations typically working in silos
• One team hands-off to the other
• The teams use different processes/environments
• There is lack of communication and collaboration between the teams

40. 40
FUG2016
The DevOps solution
• Automate your path to production
• Consistent/repeatable process for deployment
• Faster deployment execution
• Make environments in Dev/Test similar to production
• Same versions of systems, software, components
• Automate provisioning of environments
• Make deployment process in Dev/Test similar to production
• Automate your deployment processes
• Ideally using Serena Deployment Automation
• Raise visibility of release contents/planning/scheduling
• Ideally using Serena Release Control

41. 41
FUG2016
41
Thank You