Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Process Related Mistakes


Published on

I have conducted this training at LN Technologies about the common mistakes we commit in Software Development Process.

  • Be the first to comment

  • Be the first to like this

Process Related Mistakes

  1. 1. Classic Process Related Mistakes Enumerated<br />Presented by: Faiza Yousuf<br />
  2. 2. Process<br />A process is a structure imposed on the development of a software product. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. <br />There are proven processes within the software engineering discipline that can be applied to improve software quality and lower development costs. <br />2<br />
  3. 3. Why these mistakes are called as “Classic”?<br />We choose ineffective development practices and bad results are all so predictable that they are called as classic mistakes.<br />Developers, managers, and customers have good reasons to make decisions and the lack of experience and sometimes stubbornness makes these mistakes happen.<br />The result is easy to predict and a slower development is all we get.<br />3<br />
  4. 4. 1. Overly Optimistic Schedules<br />Under scoping project.<br />Undermining effective planning.<br />Abbreviating critical development activities.<br />Puts pressure on technical team.<br />4<br />
  5. 5. 2. Insufficient Risk Management<br />Most common mistake that results in disasters.<br />Risk management is critical and it requires special skills to identify and create mitigation plans.<br />One thing goes wrong and it changes the project from rapid to slow.<br />5<br />
  6. 6. 3. Contractor Failure<br />Contracting out pieces of a project when they are too rushed to do the work in-house.<br />Out sourced work is mostly late, of unacceptably low quality and fails to meet specifications.<br />Need to manage contractor relationship carefully to avoid bad ends.<br />6<br />
  7. 7. 4. Insufficient Planning<br />Planning can determines a project's fate.<br />For achieving rapid development, have to plan for that initially.<br />Planning shouldn't be over optimistic or too loose that it wastes out precious resources (includes cost, efforts and time).<br />7<br />
  8. 8. 5. Abandonment of planning under pressure<br />Made plans but abandon them when run into schedule trouble.<br />Abandoning a plan is not an issue as far as you have a balanced substitute.<br />Most of the time, substitute isn’t prepared and code-and-fix mode is used that can cause a project failure.<br />8<br />
  9. 9. 6. Wasted time during the fuzzy front end<br />“Fuzzy Front End” is the time before the project starts.<br />So much time wasted in approval and budgeting and then aggressive scheduling is done to cope up with the time loss.<br />It’s easier to save time here than to compress a development schedule.<br />9<br />
  10. 10. 7. Shortchanged upstream activities<br />Cutting out nonessential activities (they think them as non essential).<br /> Requirements analysis, architecture and design are easy targets as they directly don’t produce code.<br />“Jumping into coding” results in all too predictable mistakes.<br />10<br />
  11. 11. 8. Inadequate design<br />Rush projects undermine design by not allocating enough time for it.<br />It creates pressure-cooker environment that makes thoughtful design considerations difficult.<br />Design emphasis on expediency* than quality and it needs time consuming cycles before completing the system.<br />* "Expediency is suitability for particular circumstance or situation.”<br />11<br />
  12. 12. 9. Shortchanged quality assurance<br />Eliminating design and code reviews, test planning and performing perfunctory* testing for achieving perceived schedule advantage.<br />When a module/phase is completed, it’s too buggy to release or if it’s released, client is too angry with the quality.<br />Short-cutting a day of QA activity early is likely to cost you 3 to 10 days of activity downstream.<br />* Perfunctory is lacking interest, care, or enthusiasm and hasty.<br />12<br />
  13. 13. 10. Insufficient management controls<br />Providing timely warnings of impeding schedule slips.<br />Once the project ran into trouble, controls get abandoned.<br />Before you can keep a project on track, you have to see whether its on track or not.<br />13<br />
  14. 14. 11. Premature or too frequent convergence<br />For convergence, improving project performance, final documentation, incorporate final help-system hooks, polishing the installation, etc. are required.<br />On rush projects, there is a tendency to force convergence early.<br />Early and extra convergence attempts don’t benefit the project, they waste time and prolong schedule.<br />14<br />
  15. 15. 12. Omitting necessary tasks from estimates<br />Need to keep records of the previous projects, to avoid forgetting less visible but necessary tasks.<br />These tasks always adds up later and that disturbs the estimates.<br />Omitted effort often adds about 20% to 30% to a development schedule. <br />15<br />
  16. 16. 13. Planning to catch up later <br />Many projects simply plan to catch up later, but they never do.<br />Learning increases as project builds and it needs to be reflected in the schedule.<br />Re estimation mistakes arises from product changes, and it effects the time need to build it.<br />16<br />
  17. 17. 14. Code-like-hell programming<br />Loose, all-as-you-go coding is not a route to rapid development.<br />Developers when over-motivated, reason that they can overcome obstacles but it’s far from truth.<br />Mostly its an old code-and-fix paradigm combined with an ambitious schedule and that combination never works. It’s a perfect example of “Two wrongs can’t make a right”<br />17<br />
  18. 18. Thank you!<br />18<br />