A SDLC Software Development Lifecycle It s a set of tools, artifacts, and work practices an organization uses to create software.

Transcription

1 1

2 A SDLC Software Development Lifecycle It s a set of tools, artifacts, and work practices an organization uses to create software. That SDLC is integrated into a workflow process within the organization to get the requirements gathered, the software built, the testing done, the bugs fixed. As an example I m going to talk about scrum 2

3 What is scrum: 3 roles 3 rituals 3 artifacts 3

4 It matters, because companies spend billions of dollars on software each year. The Standish Group (1995) reported that companies spent over $250 billion on application development of approximately 175 thousand projects. Certainly this has expanded greatly in the almost 20 years since. We get a better end product, a better development outcome, and a standardized process where scope expectations are clear, deliverables are clear, and team roles are clear. Organizations that have an intentional software development process have a much better chance of producing software with quality, that meets customers needs, on a repeating basis. Coordination of large teams -We can facilitate large teams working on a project together, but we can only do that if it s done in an organized and efficient manner. 4

5 Was the SDLC used by organizations for project creation the same as for project maintenance? Were the strengths of the SDLC used for project creation consistent with the needs of the team for software maintenance? 5

6 6

7 As I mentioned before, billions, maybe trillions of dollars are spent on software development yearly. Selecting the right methodology can have a significant impact on project cost and quality Picking any methodology reduces cost, risk, uncertainty, disorganization, poor requirements and poor quality 7

8 There are some companies that have no methodology. So they probably can t build repeatable software on larger scale. SDLCS support certifications like ISO9001, CMM Contracts with some governments or other institutions 8

9 AlisterCockburn in his paper Selecting a Project s Methodology talked about reducing the controversy over methodologies, by breaking it down to the dimensions along which they vary. He starts out with Staff size and system criticality. A larger group needs a larger methodology A larger project needs more rigor And more formal methods More defined roles for team members 9

10 A more critical system needs more publicly visible correctness the idea of transparency into the project His definition of criticality was pretty clear-cut. Loss of comfort Loss of discretionary money Loss of irreplaceable money Loss of Life From this principal the team can justify greater development expenses as the criticality increases. A relatively small increase in methodology size or density adds a relatively large amount of project cost For example adding daily standups to improve communication and reduce uncertainty costs 15minutes per day per employee in the project. (3% of the work day) More planning meetings to mitigate the risk of complexity / uncertainty also cost more time.. My favorite quote All methodology is based on fears (Kent Beck) Afraid designers will leave write extensive design doc Afraid programmers will make mistakes hold code reviews 10

11 Todd Little in 2005 wrote a paper titled Context-Adaptive Agility: Managing Complexity and Uncertainty. Using this matrix they categorized projects. Dogs simple projects, low uncertainty Colts simple projects, high uncertainty Cows complex projects, low uncertainty Bulls complex projects, high uncertainty Using this matrix they developed a core set of work practices that were used on every project. Then depending on complexity or uncertainty they added other practices. 11

12 Here you can see the drivers of a projects complexity 12

13 And here you can see the drivers of project uncertainty 13

14 In little s core practices he had Aggregate Product Plan target date, high level prioritized set features, product vision Feature List (must have, should have, could have) Quality agreement set the expectation Continuous integration Expert user involvement Project dashboard 14

15 To the core work practices they added: Colts Add short iterations Daily stand-up meetings Automated unit tests Cows Requirements management Functional specifications of interfaces Critical-Path identification Bulls Colts + Cows Seasoned Project manager Summary: Project SDLC didn t really change (they use Agile, but they add artifacts and rigor based upon complexity & uncertainty. 15

16 Avison& Fitzgerald in their 2005, 3 rd edition, textbook information systems development go into great detail about SDLCs, criteria for selection, and frameworks for doing the selection. You can see from this slide, they have a comprehensive list of criteria for comparing methodologies. 16

17 Grunnersuggests an algorithm that provides a way to compare various methodologies using a framework. He uses this algorithm along with the Avison& Fitzgerald framework to evaluate a sample project comparing 3 different SDLCs The important thing here is: the algorithm that starts with building the selection team, evaluating fameworks, evaluating SDLCs, and ends with presenting the findings. 17

18 Yusof, Shukar, and Abdullah created the CuQuPframework that gives a quantitative comparison of SDLCs for a given project taking into account complexity, uncertainty, and the project phase strengths of each SDLC. They integrated the complexity/uncertainty component from Little (2005) They integrated the phased based weighting from Avison and Fitzgerald (2005) The Cu factor of CuQuP is the weighting of complexity/uncertainty 18

19 Methodologies are weighted based upon their strengths in the 10 phases from Avison& Firzgerald Items that are bright green score a 3 because the methodology covers that phase in great detail. Light green a 2 because it covers that phase in some detail, etc. 19

20 I created and executed a development methodology survey I surveyed 6 development managers or development management consultants. They had a varying amount of experience and education. They were a cross section of companies that build software for internal systems, software for clients, and software to be sold to multiple clients. Using the survey tool below I asked the participants what SDLCs they used and why. What criteria they used to decide how to build their production and maintenance software. 5 of the 6 interviews were done in person. One was done on the telephone. During the interview process I learned additional and supporting information which deepened my understanding of the individuals and their organizations. 20

21 21

22 I got a great cross section of organizations Company A Produces Software as a Service (Saas) electronic medical record. Company B A nationwide retail store. Company C A nationwide transportation company. Company D A medium sized membership organization. Company E Produces regulatory compliance software they license to clients for Osha and like Company F A national airline 22

23 Most organizations do not use different SDLCs for production versus maintenance. This likely due to three factors: Their projects don t vary much. The organizations do not have projects that are significantly different from each other, so going through the selection process each time yields little value for the cost; They don t want to have 2 (or more) processes. Organizations build a process around a particular methodology and cannot easily modify the process to fit other methodologies Development managers are not intimately familiar with SDLC choices that are available to them and so continue to use the status quo methodology. Of the six companies surveyed, only one had different formal SDLCs for project development versus maintenance. That organization is using SCRUM for its project development and KANBAN for its project maintenance. 23

24 Here are the SDLCs being used by the various companies A Scrum B IE (Information Engineering) C Rupp D Waterfall E Scrum F Scrum / Kanban 24

25 Release Cycle: How often products or updates are released? (biweekly, quarterly, when ready, as soon as it can be fixed, etc.) Product type: Is the product a website where they can have several updates, or a machine EPROM where it is costly to have more than one update? Product/Project Risk: What is the risk to the business, users, others if the software doesn t work? Team location: Are the users, developers all in the same location? Team experience: Are the developers experienced in the business domain & software tools to be used? Team Size: How many analysts, testers, developers are on the team? Timeframe from development to release: How long from the time they start is the first deliverable due? It s interesting to see how these criteria compare to Avison& Fitzgerald s list. 25

26 Here you can see the recommended SDLCs for development and maintenance for each organization based upon the survey information. Company A-Using Scrum: recommends Scrum for development Kanban for maintenance Company B -Using proprietary IE: recommends IE for development, Scrum for maintenance Company C Using proprietary Rupp: recommends IE, Rad/Rupp for maintenance Company D- Using Waterfall: recommends Scrum for both Company E Using Scrum: recommends Scrum for both Company F using Scrum / Kanban: Recommends Scrum, Rad for maintenance 26

27 27

28 On Project Maintenance versus development Different SDLCs should be considered. Maintenance is less complex and less uncertain. So it seems logical; maintenance projects with smaller scopes and shorter durations could use a lighter-weight methodology. On SDLC Selection Project complexity and uncertainty are the main drivers for selection of an SDLC. But the quality components and delivery periodicity are also important. Companies selecting an Agile SDLC indicated the regular delivery periodicity was one of the main reasons they selected and use Agile Selecting ANY SLDC is better than not having one. (Even a bad one). Most organizations where using a SDLC methodology that fit them well even though they didn t do a formal SDLC evaluation. On Selection Frameworks Quantitative Evaluation -The selection frameworks make it easier to quantitatively demonstrate to a group that a particular SDLC fits an organization better than another. Best Fit for complexity/uncertainty & quality. Using a selection framework to evaluate the complexity, uncertainty and quality requirements gives you the best fit for an organization. 28

29 A SDLC methodology does not exist in a vacuum. It is surrounded by people, processes, and tools. The implementation an SDLC into an organization is challenging. The analysts, developers, and managers need to be trained to use the methodology. Organizational processes need to be created to handle things like support tickets, rework, requirements gathering, and other activities that support internal and external customers. The savings has to be there for 2 SDLCs to make sense. For an organization to select two SDLCs and implement them into their organization could be difficult. Although a lighter weight methodology might make sense, it has to be weighed against additional overhead incurred by having more processes surrounding the additional SDLC, additional training, and possibly additional capital outlays for more tools. The bottom line is it depends. The decision is not clear-cut. Organizations should thoughtfully evaluate the methodology they are using now and determine if it is meeting their needs. If the reduction in overhead, by using a different maintenance SDLC, outweighs the additional cost of having additional processes, then it probably makes sense to use the right tool for the job. 29

30 30