Reengineering Software Development Process


Published on

An Independent Study Project for my Post Graduation.

Published in: Technology
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Reengineering Software Development Process

  1. 1. REENGINEERING SOFTWARE DEVELOPMENTPROCESS (AN INDEPENDENT STUDY PROJECT) Researcher: Faiza Yousuf (CT-06/2010-11) Research Advisor: Dr. Wahabuddin Usmani CSIT Department, NED University of Engineering and Technology, Karachi.
  2. 2. AGENDA December 8, 2012 Introduction Software Development Life Cycle Models Process Reengineering Case Studies Survey Conclusion 2
  3. 3. INTRODUCTION December 8, 2012 The Problem?  Over 61 % of the projects that were analyzed were deemed to have failed by the respondents. More than three quarters blew their schedules by 30% or more; more than half exceeded their budgets by a substantial margin.  Incorrect methodologies or Ad-hoc processes .  Generalization is never a smart approach.  Processes depends on type of work and people. 3
  4. 4. SOFTWARE DEVELOPMENT MODELS VS.METHODOLOGY December 8, 2012 A software development model lies on top of the methodology used by the organization. A model doesn’t tell us how to do things or what processes or artifacts should be there, rather it outlines the type of things which should be done. They just tell us about the sequence of life cycle phases. It is a structure for developing software products and includes processes, methods and tools and is totally dependent on the nature of software solution. It is a systematic and disciplined approach which follows a defined sequence of steps and produces required deliverables. 4
  5. 5. December 8, 2012 5WATER FALL
  6. 6. WATER FALL (CONTINUED) December 8, 2012 Advantages Disadvantages Product vs. Project Based 6
  7. 7. December 8, 2012 7INCREMENTAL
  8. 8. INCREMENTAL (CONTINUED) December 8, 2012 Advantages Disadvantages Product vs. Project Based 8
  9. 9. SPIRAL / PROTOTYPING December 8, 2012 9
  10. 10. SPIRAL / PROTOTYPING (CONTINUED) December 8, 2012 Advantages Disadvantages Product vs. Project Based 10
  11. 11. AGILE DEVELOPMENT MODEL December 8, 2012 11
  12. 12. AGILE MANIFESTO December 8, 2012 Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. 12
  13. 13. AGILE ASKS FOR THE FOLLOWING December 8, 2012 Know your goals Know your team Know your stakeholders Spend time on planning and design Promise low and deliver high Iterate! Increment! Evolve! Stay on track Cope with change Test Early, Test Often Keep an open mind! 13
  14. 14. AGILE (CONTINUED) December 8, 2012 Advantages Disadvantages 14
  15. 15. AGILE – FEATURE DRIVEN DEVELOPMENT December 8, 2012 15
  16. 16. AGILE – TEST DRIVEN DEVELOPMENT December 8, 2012 16
  17. 17. AGILE – EXTREME PROGRAMMING December 8, 2012 17
  18. 18. December 8, 2012 18AGILE - SCRUM
  19. 19. PROCESS REENGINEERING December 8, 2012 A process is a collection of interrelated work tasks initiated in response to an event that achieves a specific result for the customer of the process. There are many different spins on the Process Reengineering definition. Although each definition is slightly different, all have the same overarching theme: the radical redesign of business processes to achieve dramatic improvements in productivity and performance. The two key words are radical and dramatic. Radical redesign means getting rid of existing processes and procedures and inventing new ways. Dramatic improvement means a quantum leap in performance. 19
  20. 20. NEED FOR PROCESS REENGINEERING December 8, 2012 Optimization: It means creating efficient work procedures to get maximum benefits. Automation: Its about getting the human effort less and the chances of human error even lesser. Automation is about optimizing productivity and getting more work done with the same human resource. 20
  21. 21. RISKS ASSOCIATED WITH REENGINEERING December 8, 2012 There are two types of risk identified in the implementation of Process Reengineering: Technical Risk, which is a fear that the process changes will not work, and Organizational Risk, by far the greatest risk, which is the possibility of corporate culture reaction against the changes. 21
  22. 22. REENGINEERING THE HUMAN RESOURCE December 8, 2012 Resistance from Foundation workers / Process implementers.  Routine work gets challenging.  Change makes people uneasy.  New things will add up in daily tasks.  Extensive learning will be required.  Skill up drills will add up in the schedule.  Attitude shift is required.  They will need leaders rather than managers. Change required in Management.  Be mentors rather than managers.  Listen, understand and resolve.  At times, be strict and have a zero tolerance policy. 22  Forgive and understand in the early times.
  23. 23. PHASES OF REENGINEERING December 8, 2012 Begin Organization Change. Build the Reengineering Organization. Identify Reengineering Opportunities. Understand the Existing Process. Reengineer the Process Blueprint the New System. Perform the Transformation. 23
  24. 24. CASE STUDIES December 8, 2012 CASE STUDY 1  Company: A  Observers role: Project Manager  Company Size: Medium (51-150 employees)  Company Type: Project Based (Small - Medium Sized Web Projects)  Methodology Used: Waterfall 24
  25. 25. CASE STUDIES – CASE STUDY 1 (CONTINUED) December 8, 2012 Team Structure  Project Manager  UI/UX Team Lead  UI/UX Team  Technical Lead  Technical team  Quality Engineer Current Processes 25
  26. 26. CASE STUDIES – CASE STUDY 1 (CONTINUED) December 8, 2012 Problem Identified  Incorrect model is being chosen which is creating issues for the team.  Accommodating feedback is tough and constant change requests create chaos.  Proper documentation is not done due to less time and no Quality related process are implemented.  Manual processes and no use of tools which causes lots of manual effort and frustration for the team.  No standards being implemented for the phases of life cycle.  Too many reviews by TLs, and no authority or accountability is given to the programmers/developers/designer.  Scope creep is a norm and schedule slip happens in every single process.  Re-work because of fixes and change requests from client.  Friction within the team, blame games, etc. 26  Unhappy and frustrated clients.
  27. 27. CASE STUDIES – CASE STUDY 1 (CONTINUED) December 8, 2012 Solution  Scrum was the best fit.  Team was trained and one pilot project was done initially for testing the methodology.  Project Manager became Scrum Master, Technical Lead became Project Owner and rest of the team works as a Cross functional team.  Attitude shift was required so by doing different activities, team was able to take things positively.  Project Managers became servant-leader and facilitators to listen and understand the problem and suggest quick resolutions to the upper management.  Tools were implemented, Asana for Project Management and GIT for Configuration Management. 27
  28. 28. CASE STUDIES December 8, 2012 CASE STUDY 2  Company: B  Observers role: Project Manager  Company Size: Small (1-51 employees)  Company Type: Product Based (Medium sized products, mostly research based)  Methodology Used: Spiral/Prototyping 28
  29. 29. CASE STUDIES – CASE STUDY 2 (CONTINUED) December 8, 2012 Team Structure  Project Manager  Quality Engineer  Creative Head  Creative Team  Technical Head  Technical Team Current Processes 29
  30. 30. CASE STUDIES – CASE STUDY 2 (CONTINUED) December 8, 2012 Problems Identified  No cross functional teams  Loss due to non agile methodology with a research based product.  Time boxed approach was needed.  Vertical hierarchy created too many hand offs.  Manual processes and no use of tools.  Scope creep and schedule slip happens very often.  No communication procedures were there, most communication happened verbally. 30
  31. 31. CASE STUDIES – CASE STUDY 2 (CONTINUED) December 8, 2012 Solution  Hybrid of Spiral and Scrum was implemented.  Company was a start-up with less number of employees so they took advantage of a clean slate opportunity.  Tools were implemented, office 365, Team Foundation Server and GIT was implemented with a zero tolerance policy.  Risk Analysis along with technical feasibility was given the highest priority.  CTO (the idea generator) was taken as a customer and feedback was taken and implemented on every iteration.  Scrum team was formed and artifacts were created according to the Scrum standards. 31
  32. 32. SURVEY December 8, 20121. What are the most used methodologies in the current times and what are their pros and cons? A survey is done for this purpose and most of the companies are working on either Waterfall or Agile methodologies.2. What is the main cause behind software solution failure? Survey gave an insight on all of the common failure reasons and most of these are related to requirement engineering.3. Should process reengineering be considered by organizations to lessen the chaos? Out of the 50 Software Professionals, most of them answered Yes, as customization is the need of current era. 32
  33. 33. SURVEY (CONTINUED) December 8, 20124. Can we use agile in a controlled environment? Surprisingly, most people agreed on altering Agile to fit in a controlled environment.5. Which agile methodology is more controlled and has better management support? SCRUM was apparently the most favored Agile methodology.6. Which process should be reengineered first in the whole Software Development Process? Requirement engineering is considered as one of the most difficult phases of software development and one of the biggest causes of software failure. Hence, it should be 33 reengineered first.
  34. 34. CONCLUSION December 8, 2012 The basic idea behind this research is to check whether or not the current development process suits the organization and is keeping your business running and clients happy. If there are issues and the results are disastrous, it is the right time to reengineer your development process and create a new one which suits you completely. It is clearly being concluded that not every methodology works in every environment and before choosing the process to do something, we have to study the work that is being done through the process. In most of the cases, incorrect methodology was chosen and the result was a disaster. 34
  35. 35. December 8, 2012 35 THANK YOU!