Popular Pitfalls In Sdlc Phases 1


Published on

In a standard waterfall LC model for software development, what all could go wrong. An indpendent view of the same.

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Popular Pitfalls In Sdlc Phases 1

  1. 1. Popular Pitfalls in Software Management Strategies A IT industry Practitioner’s Perspective R.Ramkumar D.Ae.Tech., B.Com, HSM, PGDBA, CSQA, CISA, PMP
  2. 2. Agenda <ul><li>My Introduction </li></ul><ul><li>Objective </li></ul><ul><li>Software Engineering Evolution </li></ul><ul><li>Where industry lacks? </li></ul><ul><li>SDLC Phase-wise challenges </li></ul><ul><li>How do we address them? </li></ul><ul><li>Q & A session </li></ul>
  3. 3. My Introduction <ul><li>Name: R. Ramkumar ‘Ram’ </li></ul><ul><li>Education: </li></ul><ul><ul><ul><ul><ul><li>Aeronautical Engineer </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Commerce Graduate, </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>PG Honors qualification in IT and </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>PG Diploma in Business Administration </li></ul></ul></ul></ul></ul><ul><li>Experience: </li></ul><ul><ul><ul><ul><ul><li>15+ years in Information Technology </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Worked in premier IT organizations like HCL, Polaris, TVS </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Worked in KPMG as ISO / ISMS Auditor </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>First ISMS Auditor in India to represent KPMG </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Done around 500 audits in India, US, UK, China, Singapore etc. </li></ul></ul></ul></ul></ul><ul><li>Other qualifications: </li></ul><ul><ul><ul><ul><ul><li>Certified Software Quality Analyst </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Certified Information Security Auditor </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Project Management Professional </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>ISO 9001:2000 Lead Auditor </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>ISO/IEC 27001:2005 Lead Auditor </li></ul></ul></ul></ul></ul>
  4. 4. Objective <ul><li>Learn where industry stumbles, predominantly </li></ul><ul><li>Stress on management perspective and touch upon technical perspective </li></ul><ul><li>Patterns of failure listed </li></ul><ul><li>Pitfalls  ‘Potential’ risks </li></ul><ul><li>Intent to increase awareness </li></ul>
  5. 5. Software Engineering Evolution <ul><li>Software Engineering at very nascent level </li></ul><ul><li>Rules for developing software evolving </li></ul><ul><li>Popular ones: - </li></ul><ul><ul><ul><li>CMMI </li></ul></ul></ul><ul><ul><ul><li>ISO 90003:2004 </li></ul></ul></ul><ul><ul><ul><li>Agile </li></ul></ul></ul><ul><li>Software Services / Product – different rules </li></ul><ul><li>The time to reckon has come </li></ul>
  6. 6. Need of the hour Decreasing margin, dollar value Increasing overheads Software Performance Predictability 
  7. 7. Where Software Industry Lacks? 
  8. 8. Where Software Industry Lacks? <ul><li>Success in one project is not ‘generally’ replicatable in another project </li></ul><ul><li>Arriving at average ‘Productivity’ figures are misleading </li></ul><ul><li>Effort estimates are not common between two teams for similar activity </li></ul><ul><li>Metrics is a major grey area Eg. NCSLOC </li></ul><ul><li>Interoperability of team members with steep learning curve </li></ul>
  9. 9. SDLC Phase-wise challenges 
  10. 10. Phases in SDLC <ul><li>Requirements </li></ul><ul><li>Design </li></ul><ul><li>Construction </li></ul><ul><li>Testing </li></ul><ul><li>Delivery </li></ul><ul><li>Maintenance </li></ul>Across different LC models Waterfall Iterative V Model 
  11. 11. Requirements Phase 
  12. 12. Requirements Phase <ul><li>Objectives </li></ul><ul><ul><li>To understand ‘what’ the client wants </li></ul></ul><ul><ul><li>To understand the domain intricacies </li></ul></ul><ul><ul><li>To decide the best suited technology </li></ul></ul><ul><li>Pitfalls </li></ul><ul><ul><li>Team does not contain Business Analyst </li></ul></ul><ul><ul><li>Team provides less time for Requirements phase </li></ul></ul><ul><ul><li>User feels “All told” Team feel “All understood” </li></ul></ul><ul><ul><li>Technology is based on Team’s “comfort factor” </li></ul></ul><ul><ul><li>Testing team not involved at this phase </li></ul></ul>
  13. 13. Requirements Phase Major Contributor 
  14. 14. Design Phase <ul><li>Objectives </li></ul><ul><ul><li>To decide on “how to” deliver the solution </li></ul></ul><ul><ul><li>To decide the “Application Framework” </li></ul></ul><ul><ul><li>To analyze the impact on various other interfaces </li></ul></ul><ul><li>Pitfalls </li></ul><ul><ul><li>Weak design </li></ul></ul><ul><ul><ul><li>Does not withstand user load, data load </li></ul></ul></ul><ul><ul><ul><li>Not flexible to change </li></ul></ul></ul><ul><ul><ul><li>Interface in-compatibility </li></ul></ul></ul>
  15. 15. Design Phase (contd.) <ul><li>Pitfalls </li></ul><ul><ul><li>Least time spent on designing </li></ul></ul><ul><ul><li>Design with low knowledge on requirements </li></ul></ul><ul><ul><li>Vetting of design not effectively done </li></ul></ul><ul><ul><ul><li>Internal reviews of design very weak </li></ul></ul></ul><ul><ul><ul><li>Client concurrence on design very rare </li></ul></ul></ul><ul><ul><li>Scalability not addressed </li></ul></ul><ul><ul><ul><li>Environments the application should work not properly addressed </li></ul></ul></ul><ul><ul><li>Low appreciation to product design </li></ul></ul><ul><ul><li>Design document rarely updated </li></ul></ul>
  16. 16. Design Phase (contd.) <ul><li>“ We Try to solve the problem by rushing through the design process so that enough time will be left at the end of the project to uncover errors that were made because we rushed through the design process ……….” </li></ul><ul><li>-Glenford Myers </li></ul><ul><li>The moral : Do not rush through Design </li></ul>
  17. 17. Construction Phase <ul><li>Objective </li></ul><ul><ul><li>To implement the design </li></ul></ul><ul><ul><li>To create maintainable source code </li></ul></ul><ul><li>Pitfalls </li></ul><ul><ul><li>Developers modify the design </li></ul></ul><ul><ul><li>Source code is not ‘clean’ </li></ul></ul><ul><ul><ul><li>Non-compliance to coding standards </li></ul></ul></ul><ul><ul><ul><li>Junk code accumulation </li></ul></ul></ul><ul><ul><ul><li>No source code Headers / Active Comments </li></ul></ul></ul>
  18. 18. Construction Phase <ul><li>Pitfalls </li></ul><ul><ul><li>Construction on non-baselined requirements </li></ul></ul><ul><ul><li>Bad tinkering of generated source code </li></ul></ul><ul><ul><li>Near nil peer reviews of source code </li></ul></ul><ul><ul><li>Bad naming conventions, decreasing traceability </li></ul></ul><ul><ul><li>Memory leaks, Security Threats and other performance issues rampant </li></ul></ul>
  19. 19. Testing Phase <ul><li>Objectives </li></ul><ul><ul><li>To validate whether application addresses all User Requirements </li></ul></ul><ul><ul><li>To validate technical performance </li></ul></ul><ul><ul><li>To validate all possible conditions are addressed </li></ul></ul><ul><li>Pitfalls </li></ul><ul><ul><li>Tester enters late in the project cycle </li></ul></ul><ul><ul><li>Test environment does not fully simulate end user environment </li></ul></ul><ul><ul><li>Test cases are not comprehensive </li></ul></ul><ul><ul><li>Testing is seen as a ‘not-so-great’ job </li></ul></ul>
  20. 20. Testing Phase <ul><li>Pitfalls </li></ul><ul><ul><li>Root causes of defects not identified </li></ul></ul><ul><ul><li>Root cause could be:- </li></ul></ul><ul><ul><ul><ul><li>Bad requirements gathering </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Inconsistent design </li></ul></ul></ul></ul><ul><ul><li>Fixing of defects leading to more defects </li></ul></ul><ul><ul><li>Taking defects reporting very personally (!) </li></ul></ul><ul><ul><li>Instability of testing team </li></ul></ul>
  21. 21. Delivery Phase <ul><li>Objectives </li></ul><ul><ul><li>To delivery the committed application with committed functionalities </li></ul></ul><ul><ul><li>To make defect free and on time delivery </li></ul></ul><ul><ul><li>To have minimum issues during acceptance testing </li></ul></ul><ul><li>Pitfalls </li></ul><ul><ul><li>Manpower ramp up while delivery date nears </li></ul></ul><ul><ul><li>‘Good-news-only Syndrome’ for the customer </li></ul></ul><ul><ul><li>Panic grips the entire Project Team </li></ul></ul>
  22. 22. Delivery Phase <ul><li>Pitfalls </li></ul><ul><ul><li>If there is a flare-up in the delivery </li></ul></ul><ul><ul><ul><li>Project goes in full throttle </li></ul></ul></ul><ul><ul><ul><li>Revenue leakages happen in various channel </li></ul></ul></ul><ul><ul><ul><ul><li>Client visits </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Video / Tele Conferences </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Long hours of working </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Early pickup and Late vehicle drops to team members </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Further additional strengthening of the team </li></ul></ul></ul></ul><ul><ul><ul><li>No proper accounting for many of the above referred revenue leakages </li></ul></ul></ul>
  23. 23. Delivery Phase 
  24. 24. Delivery Phase – My Study  Prime Contributor
  25. 25. Maintenance Phase <ul><li>Objectives </li></ul><ul><ul><li>To change the application without impairing existing functionalities </li></ul></ul><ul><ul><li>To add new functionalities to the existing application </li></ul></ul><ul><ul><li>To fix any historical defects of the application </li></ul></ul><ul><li>Pitfalls </li></ul><ul><ul><li>Developers do not like this ‘tinkering’ job </li></ul></ul><ul><ul><li>Impact on the rest of the application is not known </li></ul></ul><ul><ul><li>The source repository of the current source is ambiguous viz. on-site and off-site team </li></ul></ul>
  26. 26. Maintenance Phase <ul><li>Pitfalls </li></ul><ul><ul><li>Regression testing is missed out </li></ul></ul><ul><ul><li>Existing source not understandable, leading to huge re-work </li></ul></ul><ul><ul><li>Any deficient design is carried forward for want of huge extra effort to do permanent fix </li></ul></ul>
  27. 27. Solution – That Matters <ul><li>There should be SYSTEM in place </li></ul><ul><li>A mechanism to know compliance to this SYSTEM should be established </li></ul><ul><li>EFFECTIVENESS of this SYSTEM should be measured </li></ul><ul><li>ACTION to be taken where the SYSTEM lacks in providing RESULTS </li></ul>
  28. 28. Solution – The PDCA Approach  Establish Process Monitor & Review process Implement & operate the process Maintain & improve the process Act Do Plan Check
  29. 29. Solution – That Matters <ul><li>Tighter integration between the plan and check </li></ul><ul><li>In practice improved co-ordination between QA and QC teams </li></ul><ul><li>Key formula  “Processes that deliver” </li></ul><ul><li>Never encourage system violation, even if gives instantaneous gratification </li></ul><ul><li>Ensure that “All are same before the law” to ensure compliance to system </li></ul>
  30. 30. Solution – The Approach <ul><li>Take good practices from Standard Software Engineering Literature </li></ul><ul><li>Adopt guidelines of ISO 90003:2004 </li></ul><ul><li>Practice the process </li></ul><ul><li>Enhance with CMMI Level 2/3 practices </li></ul><ul><li>Practice the processes again and mature </li></ul><ul><li>Enhance with CMMI Level 4/5 practices </li></ul>
  31. 31. Summary <ul><li>Indian IT industry is still evolving its system </li></ul><ul><li>There are many potential landmines that we could place our foot upon </li></ul><ul><li>It’s only “Effective System” that will help in bring in sanity </li></ul><ul><li>“ Effective System” has to evolve by monitoring results </li></ul><ul><li>Consistent Quality Delivery is the key to long term success </li></ul>
  32. 32. Case Studies Two interesting cases 
  33. 33. A Troubled Project <ul><li>Software Project “Antigua” was done for radar imaging software. </li></ul><ul><li>John & Bill who were veteran Technical Leads were sent by ForeStone Software for study </li></ul><ul><li>The first requirements study was completed with 30% less effort than planned </li></ul><ul><li>When John & Bill presented the requirements to the customers, customers were thrilled. “You got it right” exclaimed the IT director of “Antigua” </li></ul><ul><li>When the design was completed and construction was over for the first three modules, an interim release was made. </li></ul><ul><li>The CEO of ForeStone software was able to hear bomb explosion in his email. The first delivery has really “Bombed” at client’s place. The same IT Director was screaming “This is not what you committed” </li></ul><ul><li>What went wrong? How to solve this? </li></ul>
  34. 34. The SureFire Customer <ul><li>Customer representative David sent yet another mail telling “This is not what I meant when we wanted an easy interface…” </li></ul><ul><li>JohnAshton Software CEO Ronnie was reading it red faced. Project is already consumed 70% of the effort and client is yet to freeze the requirements. An earned value analysis told that there would be not less than 180% effort over run </li></ul><ul><li>Product team has already started developing some of the modules by now. This thought made Ronnie sweat further. </li></ul><ul><li>Money paid by the client was a paltry 25% of the total value. Meanwhile Legal came up about clauses on penalty for any overshooting of schedule. </li></ul><ul><li>What went wrong? What is the solution? </li></ul>
  35. 35. Q & A <ul><li>The floor is yours…! </li></ul>Thanx for your Patience. Thanx to VIT 