Awesome by Design
()
About this ebook
Many of today’s complex problems have no solution – only compromises, controversies, and contention. Although complexity is arguably, an interpretation there can be little doubt of the ominous caliber of complex systems. We don’t solve complex systems problems, we design solutions based upon how we define and analyze the problem and its parameters.
Designing a solution is a subtle but fundamental shift in professional practice from solving a problem. This is not semantic jostling but more a paradigmatic shift from solving as a terminus toward engagement as a continuum; it is a calculus more than a conclusion.
Awesome by Design argues the software design and development process is not only a design exemplar it is a quintessential cognitive surrogate for problem engagement. The core of the design process lies with eliciting requirements that guide the design. Thus, it is the art and science of eliciting requirements that drives what the solution must accomplish.
Read more from Steven M. Price
Guitar Mathematics Rating: 2 out of 5 stars2/5Organizational Pathology Rating: 0 out of 5 stars0 ratingsTransdisciplinarity: Promise and Practice Rating: 0 out of 5 stars0 ratingsThe Workscape Renaissance Rating: 0 out of 5 stars0 ratingsFrom Tailgate to Table Rating: 0 out of 5 stars0 ratingsThe Problem is 'The Problem' Rating: 0 out of 5 stars0 ratings
Related to Awesome by Design
Related ebooks
Software architecture A Complete Guide - 2019 Edition Rating: 0 out of 5 stars0 ratingsEvent-driven programming The Ultimate Step-By-Step Guide Rating: 0 out of 5 stars0 ratingsProgramming the Network with Perl Rating: 0 out of 5 stars0 ratingsChaos Engineering A Clear and Concise Reference Rating: 0 out of 5 stars0 ratingsJava Reflection Complete Self-Assessment Guide Rating: 0 out of 5 stars0 ratingsBusiness rules A Complete Guide Rating: 0 out of 5 stars0 ratingsSemantic Modeling In Formal English Rating: 0 out of 5 stars0 ratingsTest Cases A Complete Guide - 2021 Edition Rating: 0 out of 5 stars0 ratingsRegression testing A Complete Guide - 2019 Edition Rating: 0 out of 5 stars0 ratingsJump Start Web Performance Rating: 0 out of 5 stars0 ratingsManaging Technical Debt A Complete Guide - 2021 Edition Rating: 0 out of 5 stars0 ratingsjQuery UI 1.7: The User Interface Library for jQuery Rating: 0 out of 5 stars0 ratingsIan Talks Java A-Z Rating: 0 out of 5 stars0 ratingsProfessional JavaScript for Web Developers Rating: 0 out of 5 stars0 ratingsReal-World Solutions for Developing High-Quality PHP Frameworks and Applications Rating: 3 out of 5 stars3/5The Web Performance Collection Rating: 0 out of 5 stars0 ratings“Mastering Relational Databases: From Fundamentals to Advanced Concepts”: GoodMan, #1 Rating: 0 out of 5 stars0 ratingsCakePHP 1.3 Application Development Cookbook Rating: 0 out of 5 stars0 ratingsInstant Magento Performance Optimization How-to Rating: 0 out of 5 stars0 ratingsAdministrating Solr Rating: 0 out of 5 stars0 ratingsBeginning Spring Rating: 0 out of 5 stars0 ratingsSoftware Craftsmanship A Complete Guide - 2020 Edition Rating: 0 out of 5 stars0 ratingsJava Complete Self-Assessment Guide Rating: 0 out of 5 stars0 ratingsSpeech-to-Text Second Edition Rating: 0 out of 5 stars0 ratingsBeginning DotNetNuke Skinning and Design Rating: 0 out of 5 stars0 ratingsADFS A Complete Guide - 2020 Edition Rating: 0 out of 5 stars0 ratingsWeb Design And Development A Complete Guide - 2020 Edition Rating: 0 out of 5 stars0 ratingsIntroduction to Reliable and Secure Distributed Programming Rating: 0 out of 5 stars0 ratingsSocial Media Data Mining and Analytics Rating: 0 out of 5 stars0 ratings
Computers For You
Mastering ChatGPT: 21 Prompts Templates for Effortless Writing Rating: 5 out of 5 stars5/5The Insider's Guide to Technical Writing Rating: 0 out of 5 stars0 ratingsCreating Online Courses with ChatGPT | A Step-by-Step Guide with Prompt Templates Rating: 4 out of 5 stars4/5Grokking Algorithms: An illustrated guide for programmers and other curious people Rating: 4 out of 5 stars4/5The ChatGPT Millionaire Handbook: Make Money Online With the Power of AI Technology Rating: 0 out of 5 stars0 ratingsSQL QuickStart Guide: The Simplified Beginner's Guide to Managing, Analyzing, and Manipulating Data With SQL Rating: 4 out of 5 stars4/5How to Create Cpn Numbers the Right way: A Step by Step Guide to Creating cpn Numbers Legally Rating: 4 out of 5 stars4/5Deep Search: How to Explore the Internet More Effectively Rating: 5 out of 5 stars5/5CompTIA Security+ Get Certified Get Ahead: SY0-701 Study Guide Rating: 5 out of 5 stars5/5Procreate for Beginners: Introduction to Procreate for Drawing and Illustrating on the iPad Rating: 0 out of 5 stars0 ratingsUltimate Guide to Mastering Command Blocks!: Minecraft Keys to Unlocking Secret Commands Rating: 5 out of 5 stars5/5Artificial Intelligence: The Complete Beginner’s Guide to the Future of A.I. Rating: 4 out of 5 stars4/5CompTIA Security+ Practice Questions Rating: 2 out of 5 stars2/5Elon Musk Rating: 4 out of 5 stars4/5Remote/WebCam Notarization : Basic Understanding Rating: 3 out of 5 stars3/5Mindhacker: 60 Tips, Tricks, and Games to Take Your Mind to the Next Level Rating: 4 out of 5 stars4/5The Invisible Rainbow: A History of Electricity and Life Rating: 4 out of 5 stars4/5The Professional Voiceover Handbook: Voiceover training, #1 Rating: 5 out of 5 stars5/5Dark Aeon: Transhumanism and the War Against Humanity Rating: 5 out of 5 stars5/5Network+ Study Guide & Practice Exams Rating: 4 out of 5 stars4/5Everybody Lies: Big Data, New Data, and What the Internet Can Tell Us About Who We Really Are Rating: 4 out of 5 stars4/5What Video Games Have to Teach Us About Learning and Literacy. Second Edition Rating: 4 out of 5 stars4/5
Reviews for Awesome by Design
0 ratings0 reviews
Book preview
Awesome by Design - Steven M. Price
Awesome by Design
Requirements Elicitation and Analytics for Solution Development
By
Steven M. Price
Copyright © 2017 Steven M. Price
All rights reserved.
Distributed by Smashwords
Thank you for downloading this ebook. This book remains the copyrighted property of the author, and may not be redistributed to others for commercial or non-commercial purposes. If you enjoyed this book, please encourage your friends to download their own copy from their favorite authorized retailer. Thank you for your support.
Ebook formatting by www.ebooklaunch.com
Table of Contents
1. ELICITING REQUIREMENTS: THE CASE FOR CLARITY AND CONSENSUS
THE EMPIRICAL EVIDENCE OF NEED
THE ANALYST: AN INTRODUCTION AND EXPLANATION
THE LIMITS OF ELICITATION
THE QUANDARY OF METHODOLOGY
THE LIFECYCLE MINDSET
THE CHALLENGE OF ELICITATION
HOW THIS BOOK IS ORGANIZED
2. THE ORGANIZATIONAL ECOSYSTEM
THE ENTERPRISE TECHNOCRACY
THE PATHOLOGY OF ORGANIZATION
THE CULTURE OF THE ORGANIZATION
THE DOMINANT COALITION
THE NATURE OF WORK IS CHANGING
THE WORKFORCE ACTORS ARE CHALLENGING
UNDERSTANDING ORGANIZATIONAL CHANGE AND TRANSITION
THE HEALTHY ORGANIZATION ARCHETYPE
3. THE DESIGNED SOLUTION
TARGETS OF OPPORTUNITY AND THE NEED FOR CHANGE
DESIGN THINKING
THE ARTIFACTS OF DESIGN
EVALUATING TECHNOLOGY OPTIONS
ASSESSING ARCHITECTURAL POSSIBILITIES
THE ENTERPRISE DATA MODEL
THE DATA AND INFORMATION INTERPLAY
VALIDATED SYSTEMS ARE DIFFERENT
THE TESTING STRATEGY
THERE ARE NO PERFECT SOLUTIONS
4. THE NATURE OF REQUIREMENTS
REQUIREMENTS TEND TO EVOLVE OVER TIME
UNDERSTANDING FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS
THE POSSIBILITY OF TACIT REQUIREMENTS
UNDERSTANDING GOALS AND OBJECTIVES
POWER DYNAMICS
ORGANIZATIONAL TURBULENCE
HOW MUCH INFORMATION?
THE CHALLENGES OF ARTICULATION AND REPRESENTATION
ENSURING REQUIREMENTS COMPLETENESS
5. THE DYNAMICS OF THE ELICITATION PROCESS
THE NOTION OF INTERVENTION
THE ACTORS IN REQUIREMENTS ELICITATION: ROLES AND RESPONSIBILITIES
DESCRIBING THE PROBLEM SITUATION
THE PROBLEM WITH PROBLEM DEFINITION
APPRECIATING APPRECIATIVE INQUIRY
OUR INFORMATION PROCESSING PREFERENCES
EXPLORING PERSONAL EPISTEMOLOGY
OUR PERSONALITY PRECEDES US
THE ROLE OF ARGUMENTATION
PAYING ATTENTION TO HOW THINGS ARE SAID
SOMETIMES IT’S ABOUT WHAT IS NOT SAID
THE VALUES WE CHERISH
WORKING WITH SUBJECT MATTER EXPERTS
ENGAGING COMMUNITIES OF PRACTICE
INDIVIDUAL DYSFUNCTION
THE LIMITS OF STRUCTURED INQUIRY
THE CHALLENGE OF REPRESENTATION
6. REQUIREMENTS TO UNDERSTAND TECHNOLOGY INFRASTRUCTURE
THE INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY
UNDERSTANDING THE SERVICE CATALOG
PERFORMANCE AND SERVICE LEVEL AGREEMENTS REQUIREMENTS
SYSTEMS MONITORING
EXAMINING THE CONNECTIVITY MODEL
THE INFRASTRUCTURE ENVIRONMENTS
AVAILABILITY MANAGEMENT REQUIREMENTS
CAPACITY MANAGEMENT REQUIREMENTS
INFORMATION SECURITY MANAGEMENT REQUIREMENTS
IT SERVICE CONTINUITY MANAGEMENT REQUIREMENTS
UNDERSTANDING RELEASE MANAGEMENT
CHANGE AND INCIDENT MANAGEMENT
THE INFRASTRUCTURE CHALLENGE
7. REQUIREMENTS ELICITATION TO UNDERSTAND PROCESS
UNDERSTANDING THE BUSINESS MODEL AND MISSION
THE PROCESS IMPERATIVE
EVERYTHING IS A SYSTEM - REALLY
ESTABLISHING THE CONTEXT FOR SOLICITATION
UNDERSTANDING RELATIONAL PARADIGMS
THE COUPLING CONNECTION
THE ILLUSION OF CONTROL
A PROBABLE NETWORK STRUCTURE
INTERACTIONAL DYNAMICS
SYMPTOMS AND ADVANCED DIAGNOSTICS
BUSINESS RULES AND PROTOCOLS
COMPLETING USER STORIES AND USER NARRATIVES
COMPLETING USE CASES
THE PROBLEM WITH PROCESS
8. REQUIREMENTS ELICITATION TO UNDERSTAND INTERFACES
THINKING IN TERMS OF STYLE
THE SOLUTION STORYBOARD AND NAVIGATIONAL SCHEMA
USER-CENTERED DESIGN
ESTABLISHING THE VISUAL CONTEXT
WINDOW CONTROLS
MODAL DESIGN
THE NOTION OF USABILITY (UX)
ACCOMMODATING EXPERTS AND NOVICE USERS
DEVELOPING REPORTS AND FORMS
DEVELOPING CONTENT
ERROR MESSAGES AND WARNINGS
INTERFACE CHALLENGES ON THE HORIZON
9. REQUIREMENTS ELICITATION FOR NON-FUNCTIONAL REQUIREMENTS
REUSABILITY REQUIREMENTS
PORTABILITY REQUIREMENTS
INTEROPERABILITY REQUIREMENTS
MAINTAINABILITY REQUIREMENTS
TESTABILITY REQUIREMENTS
FLEXIBILITY AND SCALABILITY REQUIREMENTS
THE USABILITY FACTOR
SOLUTION DOCUMENTAITON AND KNOWLEDGE TRANSFER
THE FALLACY OF NON-FUNCTIONAL
ABOUT THE AUTHOR
REFERENCES
1 Eliciting Requirements: The Case for Clarity and Consensus
The case for analytical clarity and consensus is born of necessity because ours is a world of complex systems and the problems they spawn. Complex systems and complex problems are not new. They are the source of many current challenges and the catalyst for those emerging on the horizon.
Complex system problems are the problems of contemporary society of which exemplars abound wherever ‘the system’ and its human counterpart collide. Very often, the technology precipitates the collision. These problems do not have a single correct solution or answer - they cannot.
When problems get to a certain level of complexity there are no solutions - only compromises, controversies, and contention. Although complexity is arguably, an interpretation there can be little doubt of the ominous caliber of complex systems. We don’t solve complex systems problems, we design solutions based upon how we define and analyze the problem and its parameters.
Designing a solution is a subtle but fundamental shift in professional practice from solving a problem. This is not semantic jostling but more a paradigmatic shift from solving as a terminus toward engagement as a continuum; it is a calculus more than a conclusion. Thus, the solutions we seek are becoming more elusive.
Awesome by Design argues the software design and development process is not only a design exemplar it is a quintessential cognitive surrogate for problem engagement. The core of the design process lies with eliciting requirements that guide the design. Thus, it is the art and science of eliciting requirements that drives what the solution must accomplish.
The argument suggests adopting the thinking and methodological rigor of the elicitation process is an excellent analytical platform. Where else do technology, process, and people converge so elegantly?
Software design and development serves as an example of how knowledge work in its full plumage involves several players and processes. Software is the exemplar for the problem solving and design that is the hallmark of today’s knowledge workers. Thus, we have a cognitive and collaborative endeavor, through elicitation, to increase performance and productivity by leveraging technology.
The beauty of combining the cognitive influence of design with the practical influence of developing software is its pragmatic approach. The word ‘awesome’ has many meanings. It can mean to inspire awe, it can describe something that is mesmerizing, or it can be a feeling of wonderment.
The notion of ‘by design’ is a popular cliché that describes how ‘something’ that turns our right does so ‘by design’. When we think of positive events or outcomes, they can be fortuitous luck or they can be the result of hard work. In this case, ‘design’ is a conscious attempt to improve or create something new through design - it is our way of developing solutions or products.
The following sections outline many of the key issues that formulate the case for clarity and consensus. On one hand, clarity of requirements is imperative for understanding. On the other hand, consensus as to what the requirement must achieve and agreement on presentation is equally as important.
The Empirical Evidence of Need
The literature is replete[1] with reasons for software design and development projects failure. Although understanding why failure occurred such as unmanaged expectations, little comes from the linear cause-and effect pronouncements. Intuitively, most of us can pinpoint a defining moment or series of events that cascade into failure.
The literature is also replete with numerous methods and models used to improve software design and development. Oddly, the larger majority of these methods and models are variations on a theme. The theme being a logical, orderly progression of thought, purpose, and action that can be directed to improved performance.
Another shocking revelation (not really that shocking) is that information technology professionals themselves author the majority of the literature. In this sense, professionals define themselves by their own admission or perhaps by job title.
On one hand we have the academics who must ‘publish or perish’ as part of their mandate. They tend to craft well-researched narratives and generally reinforce each other’s academic interests. On the other hand, industry has produced aspiring authors who fervently want to share their insight and experience.
The net result of examining all aspects of the literature suggests there is a large volume of fragmented material and disconnected understanding of how the design process works. Invariably we have someone who is technology literate trying to draw upon multiple disciplines, outside their own, to espouse their view or make a reasoned argument.
The empirical evidence strongly suggests there is a need to understand the complexities of requirements elicitation. There is a large body of commentary linking ‘bad’ requirements with solution shortfalls or failures. In effect ‘bad’ requirements lead to bad solutions - hmmm this seems intuitive.
The conventional approach of gathering and examining solution requirements is Requirements Engineering (RE)[2]. The process evolves through elicitation, analysis, specifications, and validation. This depiction of RE leverages a review and approve approach common among project management methodology.
The focus of Awesome by Design is the most contentious and complex aspect of design - eliciting requirements. As an operative definition, design constitutes anything created, configured, or contrived as part of a solution.
The rationale suggests if requirements are clearly articulated and represented, then subsequent phases or tasks leading to a solution are satisfied. Surely there is no guarantee that perfect requirement equate to perfect results; they merely contribute.
The complexity of the elicitation process has been under served in the both the literature and in professional practice. The dominant problems of requirement elicitation are exactly those of the human-technology interaction.
The human component exemplifies the complexity of human behaviors and characteristics that make all of us who we are. The technology component is that of the complexities that technology tries to remove from the human condition; namely the tasks that can be more effectively and efficiently conducted by technology.
Thus, we find, with all complex systems problems, a condition that eludes us but that we recognize as complex. The problem of course is do we have the appropriate range of skills and competencies to engage complex systems? Arguably, we do not.
Awesome by Design contends that most treatments of the requirements elicitation process trivialize the complexities of human behaviors and characteristics. In doing so, the reliance on models and proprietary methods tend to diminish the importance of clarity and consensus.
Readers are encouraged to examine and explore the depth and breadth of Awesome by Design in comparison to other competing authors. Awesome by Design diverges slightly from the dominant foci of cause and effect to rejuvenate the notion of ‘there is a correct way’ - we just have to find it. In doing so, what constitutes profession practice becomes more malleable to the organization and environment we all face.
The Analyst: An Introduction and Explanation
Throughout Awesome by Design, the Analyst is prominent. In this regard, the Analyst is a surrogate for the knowledge work practitioner; an intellectual placeholder if you will. Thus, readers are encouraged develop their own practice strategies and garner useful tools and techniques. After all, we are all Analysts at heart.
One must realize that each of us brings a different perspective to the problem arena. Our level of education and experience heavily counterbalances the cognitive and psychological diversity. Oddly, even the proper mix of each can still fall woefully short in the heat of battle.
The role of the Analyst takes on special meaning when eliciting the problem situation and solution, assessing opportunities, and formulating design criteria. In this regard, the Analyst is an interpreter and a navigator. The interpreter translates the business needs into technical language and the navigator surveys the project terrain to coordinate and synchronize efforts.
Ironically the role, and for that matter the moniker, Analyst is an anachronism. It is old school classical thinking based on a mechanistic management model. In today’s technology-centric business enterprise there has never been a greater need for big picture or holistic thinking. In general terms, the Analyst remains:
1) Intermediary between the technology savvy and the decidedly non-technology business types
2) Interpreter of complex business needs into a technology-driven solution
3) Interrogator of business types to transform their contorted ideas and seemingly disconnected logic into a language and platform understandable by the technology types
Keeping these role perspectives in mind, the Analyst is reminded that paying attention to the solution pathway is both a control mechanism and powerful diagnostic tool. Although many renditions of what the Analyst is, the role is unmistakably a facilitator role.
The number of permutations that are possible when contemplating technology solutions can be overwhelming. The decision to proceed, to make a change by leveraging a technology solution is daunting because there are so many possible solution pathways.
Clearly, there is a predictable trajectory of thoughts, possibilities, and requirements that precede a solution. At times a pattern, other times free association. It is important for the Analyst to appreciate how these trajectories occur and why keeping track of our relative position in them is so helpful.
The brilliance of Stephen Covey’s fifth habit of highly successful people needs no introduction. Seek first to understand, then be understood
is the penultimate expression of the solution requirements development process. The elegance of this truth cannot be overstated.
The solution requirements development process is largely an interpretive mechanism. One party has a business need or goal that another party must satisfy. The problem of course is the clarity of what is expressed, how it is captured and interpreted, and the ultimate task of explaining ‘what’ and ‘how’.
The challenge of articulation and representation is common to many complex problems faced in our organizational society. There always seems to be more variables than time or space to describe them. The number of moving parts in this complex puzzle remains troublesome and elusive.
The Limits of Elicitation
The elicitation process is many things, but simple is not one of them. By and large, elicitation is a communication process. Elicitation initiates a question and response repartee or perhaps a one-sided lecture. In either case, the exchange must produce a fundamental understanding of what requirements will produce a desired solution.
The inherent weakness comes from problem formulation. In a sense that which is problematic has spurred the desire to make a change from the current condition to a new condition, i.e. a solution to a perceived problem. Unfortunately, identifying and defining problems is not challenged very often - those who have the problem always seem to know best.
What we find during elicitation is a gradual disclosure of issues, ideas, and influences that have led to some condition or perhaps opportunity that warrants further consideration. The primary Actor within Awesome by Design is the Analyst; a knowledge worker with unique skills and analytical prowess. The Analyst at this point is a sounding board, a voice of reason, and an interpreter.
Like all communications, there is a message, a messenger, and a media that interacts between the players. The operative premise is that when a message is sent is can be interpreted and understood as it was intended. This is not always the case. An example might include the various levels of technical jargon in common use that may not be mutually understood.
Thus, the communication between the principal and the agent begins many of the issues and concerns that elicitation suffers. In a principal-agent relationship, the agent acts on behalf of the principal. Logically each has a vested interested in a favorable outcome. In this case, the Analyst is an agent for the principal.
A follow on to the message is its assessment among the parties involved. Analysis takes things apart to analyze them, to understand how their structure affects function. Conversely, synthesis is about putting things together. Synthesis focuses on function to reveal why things operate as they do.
Therefore, analysis yields knowledge and synthesis yields understanding. The former enables us to describe, and the latter, to explain. Quite often, this simple sequence is not understood and the misinterpretation begins early in the process. Thus, paralysis by analysis often stunts the larger picture of synthetic thinking.
Elicitation involves a host of players. Some may be very charming and insightful, others not so. Invariably chemistry develops between those who are investigating the problem encircling those with a problem. This is very much like a repair technician that answers an off-hours distress call - always appreciated and eternally grateful.
It can be said that the limitations of elicitation are those of the human condition. The very foibles we suffer as a species propagate into our interactions and understanding, only to be used as again, as interpretation allows. Thus, many of the limits of elicitation are of our own doing.
The Quandary of Methodology
As one could imagine there are numerous methods employed for requirements elicitation. Clearly, there is no single technique for elicitation - it is and always will be a combination of methods that will prevail[3]. It is worth noting that the techniques fall conveniently into a few categories.
1) Traditional: Traditional methods typically involve questionnaires, surveys, interviews, and examination of existing documentation to investigate.
2) Prototyping: This method creates early versions or renditions of the final solution to help examine how the final version will appear and function.
3) Group Techniques: Group techniques tends to involve active dialog typically facilitated using brainstorming, joint requirements planning, and idea capture
4) Contextual Techniques: Establishing context or observing how participants operate in action provides an understanding of working conditions and constraints.
5) Cognitive Techniques: These techniques involve more manipulation of the process such as protocol analysis that allows the User to describe what they are doing and why as a dialog or explanation.
6) Model-Driven Techniques: Models illustrate aspects of the solution, often diagrammatically, that allows participant to comment and conjecture using shared space.
The quandary of methodology comes from over-reliance on any one approach; possibly to the exclusion of others. Awesome by Design contends that clear communication is often a multichannel proposition. For example, a brilliant dialog can often be amplified when a diagram is also presented to gain mutual understanding.
The Analyst should carefully consider the audience in selecting the elicitation method. Again, at issue is not so much the method as what the intended result needs to be. This is one contributor to the case for clarity and consensus.
The Lifecycle Mindset
The ability to observe and identify patterns is a valuable skill. However, one must be careful with judging whether a pattern is actually something repeatable and permanent. Empirical research, anchored by statistics, has found a surprising number of patterns in the world. The natural expansion is to model the pattern and describe its components and their relational dynamics. Thus, we have the lifecycle.
Lifecycles are valuable as a management paradigm. It becomes a way to organize people and resources sequentially into a coordinated effort. Almost any key initiative involves a lifecycle of some kind. Our lifecycles have become our mindset and our mantra.
The real trouble with the lifecycle mindset is not realizing the lifecycle is not the process; it is an abstraction of process conveniently laid out in a diagram of some kind. Remember the map is not the terrain just as the lifecycle is not the problem; it is a mnemonic. All of us must understand the mantra of the lifecycle. Some initial observations for the Analyst to consider.
1) Lifecycles strive for repeatability and predictability of the process they model. This is a probable throwback to equating designed artifacts to those that must eventually be ‘manufactured’. In this sense, lifecycles ensure a smooth manufacturing process with definable phases, steps, or deliverables.
2) Many organizations are obligated to manage their processes or projects using a defined lifecycle. Naturally, they adopt the practices of their industry and the procedures that match their organizational culture and talent pool.
3) The lifecycle is not the process itself - it is a model of the process. The problem with modeling process is the high degree of variability between and within processes. There really are no clear demarcations between phases and stages; there is considerable overlap. In addition, the process is a metaphorical map that allows the user to take many paths.
So why is there an issue with sequential or perhaps ad hoc process? Does it not follow that our mind is programmed to take small steps as part of a larger, holistic analysis? Both are good questions that set the stage for evaluating problem solving using a lifecycle approach.
There are several lifecycle models in use within contemporary technology-driven organizations. The real difference on the surface is how formalized is the process within the organization (the notion of maturity) and how effective is the process for the type of solutions being design and developed?
Drawing any comparison between the lifecycle models is futile; they are simply different representations of a process. What does offer value is relating the lineage of these models as our technologies continue to evolve. The merit is not the model but understanding how the process of design and development evolves.
Thus, the following encapsulations are presented as a backdrop to inform the Analyst how different models operate or more specifically how each constraints the elicitation process. Each model is cyclic, attempting to capture the critical steps found in the design and development process.
1) Waterfall Model: