Process Related Mistakes
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Process Related Mistakes

on

  • 756 views

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

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

Statistics

Views

Total Views
756
Views on SlideShare
699
Embed Views
57

Actions

Likes
0
Downloads
6
Comments
0

2 Embeds 57

http://www.linkedin.com 48
https://www.linkedin.com 9

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Process Related Mistakes Presentation Transcript

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