1
• 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
What is scrum: • 3 roles • 3 rituals • 3 artifacts 3
• 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
• 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
• 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
• 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
• Alister Cockburn 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
• 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
• 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
Here you can see the drivers of a projects complexity 12
And here you can see the drivers of project uncertainty 13
• 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
• 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
• 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
• Grunner suggests 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
• Yusof, Shukar, and Abdullah created the CuQuP framework 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
• 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
• 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
• 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
• 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
• 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
• 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
Recommend
More recommend
