SDLC Smashup
Download as PPTX, PDF2 likes520 views
The document discusses the evolution of software development methodologies, emphasizing the importance of collaboration, customer involvement, and adapting processes to organizational needs. It highlights the iterative nature of development processes like Waterfall, RUP, and Agile, advocating for standardized tools to enhance versatility across teams. The conclusion ties back to the significance of learning from past experiences to effectively tackle future challenges in software development.
SDLC Smashup
- 1. SDLC Agile Smashup Keynote Lester Martin, Enterprise Architecture Sep 24, 2012
- 2. Why We’re Here & What We’re Going To Do (S)mashup our various agile practices, tools and experiences – Nobody follows an agile methodology (oxymoron?) EXACTLY – We all do things a bit differently; this includes tools Benefit from this collaboration – Find out what is available for all to use – Share our own best practices – Encourage each other to try something new & to refactor mercilessly – Foster new conversations & relationships Have some fun! 2
- 3. The Sky is Falling!! NASA has determined that Asteroid 2004 NM4 (aka Apophis) will come “scarily close to Earth on April 13, 2029, but it will not hit” – ¼ mile wide which would yield in “localized or regional” (take out something like Texas), but isn’t considered an extinction event – Come within 18,600 miles of Earth and be visible to the naked eye 3
- 4. What Do We Do?? We blow it up of course, but HOW? Like all good problems, we solve it with software, but still… HOW? Stream a movie from Netflix!?!? Einstein said, “If I had only one hour to save the world, I would spend fifty- five minutes defining the problem, and only five minutes finding the solution” But… is he right? 4
- 6. We Use a Software Development Process Check out Barry Hawkin’s How We Got Here, And What To Do About It & Supplement as I’m liberally cherry-picking his work – We’ve had Waterfall for as long as we’ve had computers, but then came RUP, then XP and Scrum, and now Lean/Kanban – Interestingly enough, each enjoying successively shorter seasons of favor as the de facto choice As Barry says, “Process is but a framework to facilitate the collaboration of a group of people to produce a desired outcome. It is not a substitute for culture, technical excellence, discipline, and product strategy” – So… how did we get here?? 6
- 7. Waterfall Dr Winston Royce published “Managing the Development of Large Software Systems” in 1970 – Often cited as the source of the “Waterfall Process” – Like all the classical history of our profession (ex: Codd’s RDBMS paper), this one deserves our attention – Paper expressed personal views based on successful projects for “spacecraft mission planning, commanding and post-flight analysis” – Royce wanted to share the prejudices that were based on experience – Introduced a “more grandiose approach to software development” which we still all cringe at today… 7
- 8. Grandiose Approach to Software Development 8
- 9. But Wait… There’s (ALWAYS) More!! Royce immediately follows up with a diagram that illustrates how these steps relate to one another in an iterative process People have historically latched on to the last diagram Royce explicitly says his next diagram “portrays the iterative relationship between successive development phases” He implies that any given step of the process is iterating with the steps immediately before and after, though sometimes even more that that. 9
- 10. Waterfall – Part Deux 10
- 11. Waterfall – Change Causes Catastrophe 11
- 12. Testing/Validation Drives Change Royce was right to realize that testing & validation were the change agents and recommended these steps to prevent issues 1. Program Design Comes First (especially on cross-functional points) 2. Document the Design (a sound/disciplined approach to development) 3. Do It Twice (throw away first impl and rebuild with lessons learned) 4. Plan, Control and Monitor Testing (who can disagree with that) 5. Involve the Customer (Royce sounds like an Agilist to me) “For some reason what a software design is going to do is subject to wide interpretation even after previous agreement. It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. To give the contractor free rein between requirement definition and operation is inviting trouble.” 12
- 13. Then Came the Rational Unified Process Rational/IBM gave us RUP with its best practices 1. Develop iteratively, with risk as the primary driver 2. Manage the requirements 3. Employ a component-based architecture 4. Model software visually 5. Continuously verify quality 6. Control changes Burdensome and was enforced w/costly & cumbersome tools Focused on mitigating, if not avoiding, change through rigor Most tried to use all instead of piece-mealing its building blocks 13
- 14. Hungrily Followed with Agile Thoughts and Approaches In 1994, XP began to be practiced and Scrum followed in 1995 – XP put focus on technical practices – Scrum shoots for repeatable levels of throughput 2001 brought us the Agile Manifesto with its Values – Individuals and interactions over process and tools – Working software over comprehensive documentation – Customer collaboration over contract negotiation – Responding to change over following a plan And then Lean & Kanban (from the good folks at Toyota manufacturing) with their respective core practices 14
- 15. Now Everyone Gets It 15
- 16. It Is What It Was –or – It’s Still a Good Idea! There’s value from the past Processes are more evolutionary than revolutionary – There are few new ideas, mostly new expressions From the beginning, we need customer involvement/commitment Testing & Validation are still critical Tools are just enablers 16
- 17. What To Do About It Pursue understanding Don’t make process a religion Realize the primacy of culture Commoditization of excellence is a myth Embrace hard work, dispel myths of ease – Work is still hard – Internal adoption levels vary Use consultants sparingly “Start; the rest is easy” – George W. Jenkins (founder of Publix) 17
- 18. Rigidity Drives Agility? Yes, it does, but we need a nicer word – how about Versatility? If we every want to focus on business problems and not just technical problems we have to accepted that – there will NEVER be a SINGLE WAY to do EVERYTHING, but – VERY OFTEN there is a GOOD ENOUGH way to do MOST things Yes, “tools are just an enabler”, but using the same tools (as much as possible) is a giant enabler to Versatility Versatility benefits – Organizations get things done quicker w/ smaller teams & simpler envs – Employees as we can more quickly work to other teams & applications 18
- 19. What About the (metaphorical) Asteroid?? Well… we’ve spent a lot of time fighting over software development processes & tools… Fortunately, Apophis missed up Unfortunately, it is swinging back in 7 more years for another Friday the 13th potential impact in 2036 Let’s get to work… – Let’s be agile – Let’s be versatile – This time, let’s get Bruce Willis! – And the needed eclectic team!! 19
- 20. SDLC Tools Backdrop and Go-Forward Approach Limited SDLC Tools Standards – High Costs: every team selecting, purchasing, deploying/leveraging and supporting their own set of tools from a variety of vendors – Limited Versatility: team members understand well their own SDLC tools selection, but do not have leverageable skills across the enterprise Standardize on Tools Across Programming Models – Cost is not the primary criteria in determining a standard set of tools, but it is a very important one Utilize a “pay as you grow” financial approach instead of a giant up-front charge – Increase versatility amongst PM, BA, QA and architect/developer roles in all of our business units and across development technology stacks 20
- 22. SDLC Components
- 23. SDLC Components – Project Management Domain
- 24. SDLC Components – Development & Build Domain
- 25. SDLC Components – Testing Domain
- 26. Traceability
- 27. Cornerstone The cornerstone of an SDLC process is capturing Work – Issues, Bugs, Tasks, Stories, etc Work Items should reference requirements for new work being done Multiple ways for defects to be turned into Work Items – Manually or from the integrated test case management platform Build systems should be able to record failures as Work Items Source code commits will be bi-directionally linked to the Work Items they are implemented for 27
- 28. Reference Implementation (Standards) – Visualization
- 29. Reference Implementation (Standards) – Tabular Java .NET *nix C/C++ Mainframe Documentation Confluence + Gliffy TBD Confluence + Gliffy Confluence + Gliffy Requirements Confluence + Gliffy GreenHopper TBD Confluence + Gliffy GreenHopper Confluence + Gliffy GreenHopper Work Items JIRA Team Foundation Server JIRA JIRA Agile GreenHopper Team Foundation Server GreenHopper GreenHopper Develop Eclipse Visual Studio Eclipse and other *nix editors TSO SCM SVN Team Foundation Server SVN CA Endeavor Build Jenkins + Sonar Team Foundation Server Jenkins CA Endeavor Repository Nexus Nuget Nexus CA Endeavor Code Viewer/Diff FishEye Visual Studio FishEye CA Endeavor Code Review Crucible TBD Crucible Internal tools Test Case Management Zephyr TBD Zephyr Zephyr Functional Testing Selenium soapUI Selenium soapUI MSTest soapUI Internal tools Performance Testing JMeter JMeter MSTest JMeter Internal tools Automated Testing JUnit MSTest CppUnit Internal tools Finance PPM (iNav) PPM (iNav) PPM (iNav) PPM (iNav)
- 30. PPM/iNav is Still Important While runtime integration is technically possible, this standards list does not dictate any specific S2S integration strategy – Primarily due to no single (or small number of) project execution strategy & process that would facilitate a straightforward implementation These tool selections do not improve/degrade user/team experiences of leveraging PPM/iNav for formal time reporting on projects that are rollups of details kept in more granular project execution tools
- 31. Adoption Strategy & Next Steps Fully operationalize tools in Q3 – Production environment; backed up and supported – No charge for current rollout (trying to keep it that way) – EA & IT Tools Administration eating their own dog food by using tooling for projects Early adopters; International has been the most active and is driving adoption Work with Security to identify proper tools and update standards Encourage additional teams to migrate to new tools Maintain a heat map identifying adoption status by application 31
- 32. Maturity & Acceptance of SDLC Tools by Domain Project Management (Confluence, JIRA, GreenHopper, etc) – 50 Confluence sites & 24 JIRA projects (not counting TAS environment) – Investments in Rally by some teams & many others utilizing basic tools Develop & Build (SVN, Jenkins, Nexus, FishEye, etc) – Many teams utilizing these original devcentral components – Way too many teams not using CI and even some teams not using any formal source code control system Testing (Zephyr, *Unit, Selenium, JMeter, etc) – New standards in this space with limited usage – EA partnering with the QA COE effort to introduce these tools 32
- 33. What’s Next for the Smashup? An action-packed 1 ½ days of great content and great leaders 33
- 34. What Happened to Apophis?? We got the right team, we focused on the right problem, we learned from past mistakes, we used the right process & tools and we saved the Earth!! “If there’s hope for humanity, it’s in software. And it’s equally true that if there’s Hope for software, it’s in our humanity” Max Goff 34
Editor's Notes
- #4: That’s REAL close… geosynchronous satellites orbit at 22,300 miles!! Do you trust the government anyway? Maybe the isn’t a panic-squashing conspiracy, but can they really crank numbers out this good? Heck, we can’t even balance our budget or reduce our debt and we’re talking about a Texas-killing rock heading our way!?!?
- #5: Great flick! Who doesn’t love Morgan Freeman and/or a movie about an asteroid slamming into the Earth?
- #6: Who doesn’t love a good Dilbert cartoon that fits?!?!
- #7: Barry Hawkins’ work published under Creative Commons Attribution 3.0 United States License.
- #8: Dr Royce never introduced the word “waterfall”. This really was a great example of being collaborative.
- #9: Yep… we’ve seen it before too many times…
- #13: Program to a contract As much as you need, but no more Refactor mercilessly Continuous integration & testing Leverage your active & engaged business partner Commit, Integration, Test and Validate; EARLY & OFTEN
- #14: Embrace change!!
- #15: “That is, while there is value in the items on the right, we value the items on the left more”
- #16: Gotta have the obligatory Dilbert cartoon
- #17: We’re just building upon ourselves here. Today is always based on yesterday, but hopefully refined from real lessons.
- #19: This is TOUGH one for RYO-focused teams to accept and support
- #22: Every project is run slightly different, so don’t want to lock anyone into a restrictive process. That said, most projects follow this high-level process.
- #23: Descriptions of these components and their interactions are found in the standards document. Notably missing is Security Testing (including white & black box static code analysis and code intrusion scanning) as Security is running a complementary project that will integrate with this one. EA will update this standards doc based on that outcome.
- #27: The tools can enable traceability, but people have to stitch these things together – requires an amount of discipline