MIKE BRUNSI thought that this was an interesting quote to open on, since Systems Analysis and Design, and the methodologies used to achieve these goals, seems to cause so many disagreements and headaches. You may be wondering, at this point, why we even care. Can’t we just get to coding and figure out the details as we move along? Herein lies the problem – how do we manage the process of making software – do we structure our projects, or do we adopt an agile or iterative method of doing things? We know that analysis matters – “the quality of work performed by the systems analyst can have a tremendous impact on… productivity… 50% of the errors…in a system… [are] errors of systems analysis” (Yourdon 111), but does it matter when it’s performed? The preceding quote would seem to argue for a careful, perhaps structured approach, where an original model of what the system should do is constructed and used to manage the development effort. However, “…the effort required to construct [and use] the model must be less than the communication value that arises from its use.” (West 168) All too often, it seems, the effort expended in carrying out a structured, or formal, analysis and design methodology results in less value creation than effort expended in creating and using it. In some cases, at least, the process of generating documentation and models from scratch doesn’t seem worth it when we compare effort put in and time lost to value received.
Put another way: “…the idea of handcrafting complex products seems ludicrous given our understanding of modern manufacturing techniques. Yet that is precisely how we continue to build complex software systems.” (Taylor 91) However, at least when we conduct analysis, this may be necessary. The topic of whether any methodology can be ‘correct’ will be explored in detail in the following pages.
In this paper, we will attempt to determine a set of ‘best methodological practices’, especially when developing software or systems using object-oriented technology. Specifically, we will focus on what, if any, methodology is best, and will describe differing systems development philosophies that advocate them.
Systems Analysis
“Systems analysis is…the study and separation of a group of
interacting, interrelated, or interdependent business functions,
processes, activities, or elements forming a complex whole into its
constituent parts (the procedures which govern them) for individual
study” (Modell 8)
Methodologies
“…methodology – a fixed set of processes, activities, and tasks which will produce a design when accomplished.” (Modell 10)
Systems Development Philosophies
Three different philosophies exist regarding how to develop information
systems. The first, and oldest, is the plan-driven philosophy,
exemplified by the Waterfall Method, which is one version of the
Systems Development Life Cycle (SDLC). The SDLC seeks to develop an
architectural plan for an information system or software project up
front, based upon defined system requirements, which is then used to
divide labor among employees and facilitates the management of the
project throughout the rest of the phases of the project. Perhaps the
most popular, and current, incarnation of this philosophy is the
Structured Analysis methodology.
On the other extreme exists what are collectively called ‘lean’, ‘agile’, or ‘evolutionary’ development techniques. This philosophy states that it is improbable that we can know all requirements for something as complicated as a system or software package up front, and that we should therefore develop it piece by piece in close collaboration with business users. Complicated can be taken to mean not only a large project, but also a system that exists in an environment that is subject to constant change or where requirements are hard to define. Ironically, however, large projects in large organizations are hard to complete using this methodology. A belief central to the core of this philosophy, and therefore methodology, is that better, more creative people working in close collaboration with each other develop better software and systems in a shorter amount of time. The methodologies generally dismiss any sort of preplanned or predetermined requirements analysis or design efforts, preferring to develop architecture on the fly. However, the end product must have a coherent and consistent architecture (Booch, Maksimchuk and Engle 248); an incoherent architecture can be one of the dangers associated with this method. This philosophy is exemplified by the Agile Method, Rapid Application Design, and Xtreme Programming.
Finally, the iterative development philosophy seeks a middle ground. It recognizes that some sort of predetermined architectural planning is often necessary, especially for large projects or those that are completed in large organizations, while attempting to incorporate the flexibility inherent in lean or evolutionary development. The software or system development project is broken down into modules, which are then completed in an iterative fashion. The most difficult modules are analyzed, designed, developed, and tested first, paving the way for follow-on modules. One of the goals of the iterative methodology is organizational learning, which is why difficult modules or those that have poorly defined requirements or are otherwise risky are completed up front. This necessitates that the most time-consuming analysis and design is completed prior to the majority of development efforts, however, the whole system is not mapped out prior to the commencement of coding or testing. This allows the iterative development methodology to have some flexibility not inherent in the traditional SDLC methodologies, while not being as radical as the lean methods and still embracing documentation and management controls.
End State
Regardless of the development philosophy chosen and corresponding
methodology implemented, we are principally concerned with results. For
the analysis stage, we want to know: “… (1) if there is a problem to be
addressed, (2) if there is a feasible solution to the problem, and (3)
if developing a solution to the problem is cost-beneficial to the user
and the firm as a whole.” (Modell 17) Whether we know all three answers
before development is started or closer to completion may not depend on the methodology chosen if the project is large and complex.
For the project as a whole, we tend to define success as: ‘Completing a project on time, within budget, and with the required functionality’. The remainder of this paper will focus on what, if any, methodologies enable this end-state.
While the waterfall method has largely been discredited due to its
inherent inflexibility and the high failure rate of projects that use
it, structured analysis and design techniques are still very much in
use today. The general steps of the software development lifecycle are
as follows:
(Zim Systems Ltd)
The Waterfall Methodology
A general outline of the steps in the waterfall method is shown below (Duarte):
Planning/Project Preparation in the model above consists of two distinct activities that are often grouped together because they occur in concert. These two activities are project planning and approval and the beginning of requirements analysis. During the planning phase in a large organization, a business group or user approaches a centralized IT planning authority and seeks permission to have an IT project started. The user justifies the project by detailing what benefits would be realized by completing the project. To determine estimated financial benefits, at least a rudimentary amount of business analysis must be done. During the Analysis phase, the requirements of the new system are determined and the processes that occur currently are mapped out. This phase greatly involves the user of the proposed software or system. As more is learned about the system, a better estimate of the system cost is determined. The next phase is Design, which is shown in the Analysis/Blueprint box in the above diagram. In design, we first attempt to map out an ideal solution to our problem independent of the actual technology, programming language, and hardware we will use to implement it. Then we take the technological constraints of our equipment into consideration and refine the design even further. During Development, the software solution is coded, or programmed. During Testing, the software is tested to ensure that any and all ways the user might manipulate the system work; this phase involves the user a great deal, as well. Finally, the solution is implemented as an addition to or part of the organization’s information system. After implementation, the IT staff is responsible for maintaining the system in working order. If a need for any large change is discovered during the testing phase (one of only two where the user is directly involved) or later during maintenance, a change can be requested, and the process starts again.
The Waterfall Method is primarily focused on command and control, especially in terms of finances, as well as providing a means for division of labor. Given that focus, its strength is its consistency. That consistency enables communication among dispersed workgroups with differing levels of skill. One way this is facilitated is with a large amount of documentation. Communication also provides for a division of labor within a project. It facilitates management control because there are defined steps that occur in a sequential order; that is, a structure exists that a non-technical manager can understand.
Its weaknesses, however, are numerous. The methodology itself is quite similar to assembly-line manufacturing techniques. Unfortunately, when an assembly line is employed in a factory the design is already set and we are just making copies of a fully functional prototype. In systems development, we are designing brand new one-of-kind systems (Yourdon, Modern Structured Analysis 82). There are also issues that are specifically related to the sequential progression of events found in the Waterfall Method. Specifically, every part of the system that’s developed must work perfectly in order to have a working system. Also, as a direct result, the biggest problems are found last – during the latter stages of testing when using this methodology. (82) This means the biggest delays are encountered at the end of the project when the schedule is likely to be the tightest. It is also inflexible in practice – analysis tends to finish when time is up, not when it’s done. Furthermore, “We rarely do a complex job right the first time, but we are very good at making repeated improvements …” (84) If we aren’t allowed to return to previous steps, we can’t clean up our old work. There are even more problems: “It rarely delivers the solutions that managers want, It requires specialized personnel…development must be centralized…It’s difficult to execute… [and most importantly] it takes too long…” (Taylor 76). Given these issues, we clearly require something else.
Structured Analysis and Design
(Yourdon, www.yourdon.com)
Structured Analysis and Design is a natural evolution of the original ‘Waterfall’ Method. It still completes the same processes as the traditional SDLC, and still has the same controls, but acknowledges that learning (especially about requirements) occurs throughout a project. According to Ed Yourdon, structured analysis allows for a range of project management styles. One can choose to be wholly conservative, completing only one activity at a time – the waterfall method, wholly radical, working on all activities simultaneously, or somewhere in between. It is adaptable and flexible (Yourdon, Modern Structured Analysis 94). He goes on to say:
“…the radical approach is most suitable for thinly disguised research and development efforts…[or when] something must be working on a specific date and in situations where the user’s…[requirements]…are subject to change. The conservative approach, on the other hand, tends to be used on larger projects, in which massive amounts of money are being spent and for which careful analysis and design are required to prevent…disaster.” (97)
While structured analysis is very similar to the waterfall method on the surface – there is a philosophical difference. Structured analysis allows for flexibility and tailoring to the task at hand, whereas the traditional waterfall method does not. Variations on the Structured Analysis theme are very popular to this day in many large organizations.
Given its common heritage with the Waterfall method, the two methodologies share most of the same strengths. The Structured Analysis methodology provides a means for division of labor and facilitates the management of complex projects. This becomes especially important when working on large projects with large amounts of people. They both revel in documentation. This documentation is, in and of itself, a communications tool, facilitating an understanding of the project by geographically segmented groups and groups that change over time. While there is a set of steps in Structured Analysis, they aren’t meant to typically be completed in sequence. This adds a level of complexity to Structured Analysis that isn’t present in the Waterfall Method, making structured analysis much more powerful, but also more difficult to manage.
There are criticisms of the Structured Analysis method as well. Those who promote lean or evolutionary methods claim that the method itself and the documentation it produces are a crutch to be used when good people are not or will not be made available: “The only consistently reliable approach to software development is…good people.” (West xxi). Furthermore, the process is a form of control, primarily intended to keep costs in check. However, Demarco posits an interesting question – ‘Are we focusing our efforts in rewarding places?’ Further: “...strict control is something that matters a lot on relatively useless projects and much less on useful projects.” (Demarco, Software Engineering: An idea whose time has come and gone?) Also, an early critique of traditional methodologies stated that they were not adaptable to object orientation, as they tend to be data-driven (Graham). However, Object Modeling Technique, as depicted in Object-Oriented Software Technology in Telecommunications, is just an adaptation of the traditional SDLC, tailored for object-oriented software development, with less emphasis on data and more on the objects in the domain to be modeled (Mamais, Perdikeas and Venieris 62). This adaptation would seem to nullify that point.
(Nobisk, LLC)
It is hard to select a specific evolutionary or rapid application development methodology as an exemplar since the popular ones are in many ways very similar. Some of these ‘methodologies’ include Agile Development, Rapid Application Design, Lean Development, and Scrum. I will however, go into detail on each of these methods, and instead only generalize about a generic model.
These methods consist of doing some minimal planning and analysis and then jumping straight into the design, development, and testing cycles. Small amounts of functionality are modeled, coded, and tested and then sent to the user for review. Based upon feedback from the user, changes are made, and the development process continues until an acceptable system is completed. The system is developed in an iterative fashion, but there isn’t driven by a plan-based methodological process.
These techniques emphasize better people with greater freedoms and creativity in place of structure or methodologies. “…the profession of software development has relied on an implicit promise: ‘Better tools, methods, and processes will allow you to create superior software using average human resources.’” (West xx) Collaboration is key, and development teams must be located with business users in order to be effective. These techniques see little value in documentation and modeling unless it has immediate benefits in the here and now: “Model when you must, what you must, and only what you must (151).” They model only what absolutely has to be done, and correctly point out that modeling may not accurately represent the real environment: “The real world is far fuzzier, flexible, and illogical than any formal method can accommodate (162).” Documentation is also looked upon as a possible impediment to forward progress: “…we have come to value…Working software over comprehensive documentation…”. Planned software development is suspect as well: “…we have come to value…Responding to change over following a plan…”, and rigorous methodologies are seen as impediments to communication (Manifesto for Agile Software Development).
The strengths of agile or rapid methodologies lie mainly in their responsiveness. These methodologies allow small teams of IT professionals to quickly create a small to medium-sized software solution to a business problem. They are particularly useful when business requirements are vague or otherwise hard to define or a particular user isn’t sure of what they want.
There are significant drawbacks to this collective methodology in many of today’s large corporations, however. The first set of problems result mainly from the lack of a defined plan. First of all, many organizations are not able to conduct IT development from a central location. Even if they were, their business users are usually spread over disparate locations. This lack of collocation prohibits the kind of intimate communication necessary to make agile methods succeed. Furthermore, large organizations creating large software systems often find a structured methodology that results in detailed plans necessary from a coordination and communication standpoint. The process and associated documentation facilitates communication about the project. Put another way, “…you can’t build a successful, high-quality, maintainable system if you don’t know…what it is supposed to do (Yourdon, Modern Structured Analysis 112).” Also, the lack of documentation produced during the development process in agile methods is dangerous. Since documentation is left to the end of a project, there is a tendency for it not to get done. Unfortunately, this makes a system far more difficult to maintain. Due to poor documentation practices, “noboby knows what most of the major [legacy] computer systems are doing today (124).”
Iterative development methodologies, in contrast to agile or rapid application design methods, exhibit many of the same controls as the traditional software development lifecycle methods. However, iterative development does not seek to analyze and design an entire software project up front, before any organizational learning can occur in development. A generalized iterative development methodology would first have us do some preliminary analysis and design work. Then we would organize our project based upon the requirements we know, at that time, into modules of the project, with an associated useable functionality that is to be developed. This is one of the keys of iterative development – we develop ‘chunks’ of a project that can stand, to some extent, on their own. These modules are testable, functional, and ultimately usable, assuming they do not rely on functionality in other modules that still needs to be developed. This aspect of the methodology may, depending upon the nature of the development effort, allow us to rollout functionality to the user as it is developed. The riskiest, most difficult, or least defined parts of the project are attempted first to allow the organization to gain a better understanding of the requirements that must be satisfied in order to be successful. This new understanding, based upon experience, is then fed back into the analysis phase of the development effort, resulting in an updated design. The project continues in this fashion until completion, but analysis and design efforts become less of the overall total amount of work on any given module as the project progresses. Eventually, towards the end of a project, the focus is shifted away from analysis and design and towards coding, testing, and integration of modules.
The most popular and best understood type of iterative development methodology is likely Rational Unified Process, which is the most used type of Unified Process (UP) Methodology. The UP methodology has also been adapted to agile principles, in OpenUP/Basic. It is important to note that both plan-driven, documentation-producing styles and agile versions of the iterative development methodology exist. Iterative development methodologies have also been around for much longer than many IT professionals give them credit for. In fact, Iterative Development principles were in use on large software development projects as early as the 1960s (Larman and Basili), although no academic classification of Iterative Development existed at that time.
The greatest strength of the iterative design methodologies is that they do not seek to set, or freeze, requirements up front. These are allowed to evolve, to an extent, throughout the life of the project as coding and testing work are completed. Also, towards the more conservative end of the spectrum, they allow for a good deal of command and control style management, a la Structured Analysis and Design. On the other hand, agile-slanting versions of the methodology allow for very great flexibility, perhaps the best characteristic of the agile or rapid application design methodologies.
Weaknesses of the iterative methodologies can include any of those associated with the traditional methodologies or the agile methodologies, depending on the chosen style’s ‘flavor’. There are also problems specific to the iterative development methodology. Coordination of efforts, though less of a problem than in agile methods, is still an issue. Also, cost can become problematic with iterative development if too many iterations are allowed to occur. Finally, all but the most conservative (plan-based) versions of iterative development require a great deal of user feedback to facilitate analysis in the next module of development. Users may not be available if the IT staff is not collocated with the business customer, making feedback cumbersome or expensive if either party must travel to the other. Another consideration is the productivity and expertise that the business loses when business staff are pulled away from their normal duties (Bruns, Ilia).
It is sometimes difficult to determine whether a methodology is traditional, iterative, or agile. Depending upon the individual creating or classifying the methodology, some development methods may be labeled as iterative, when, in their conception, they were intended to be completed without a strict structure. Other times, methodologies may share some of the command and control aspects of more traditional methodologies, and require analysis up front, but propose an iterative design-code-test cycle. As if to add to the confusion, many agile methods consider themselves iterative. As you may have guessed, there are many variations on a theme.
Oddly enough, we find that more flexible methodologies – those that specify what but not how – such as Structured Analysis and Unified Process, can be used as a methodological framework that supports a strict and structured or iterative to somewhat agile software development philosophy and its associated techniques. Because these methodologies prescribe what needs to be done, but are not directive about how to do them – unlike the Waterfall Method – they can accommodate wide-ranging project management styles.
Management style is the main idea here. We find that many large corporations still use some sort of plan based methodology that produces a good deal of documentation due to four things: (1) these methodologies fit the organizational culture of the company, (2) they are needed to facilitate the management of a set of professionals with diverse skills that are (3) located in different geographical areas, and are (4) working on large or very complex projects.
Conversely, rapid application development methodologies work quite well for (1) small teams, (2) working on small to medium sized projects, where (3) requirements are poorly defined and are likely to change, and (4) the user is not all that sure of what they want. However, it is hard to scale these methods up to meet the human resource demands of particularly large development projects. Even iterative development may have too many human resource demands in a very large organization where workers are not centrally located, or on a true systems development project where over 100 individual applications may be developed in concert (Bruns, Ilia).
So which one is the right one for our project? It would seem from the above statements that none are. But we haven’t claimed that any particular methodology is wrong (outside of Waterfall); rather, we have simply stated that they may not be appropriate for certain types of development projects.
When determining what methodology to employ, we need to consider what kind of project we are working on and what kind of organization we are, espcially in terms of culture, and, to a lesser extent, size. We can envision these this as a project/culture table in the form of a Descartes Plane, for which I must acknowledge inspiration from Booch’s Project Continuum (Booch, Maksimchuk and Engle).
Where the project is very large, complex, and/or politically risky, we naturally have a better candidate for a more traditional plan-based methodology. This is also true when an organization’s culture is more conservative and when the organization is generally large (in terms of personnel and geographic area). These types of projects paired with large organizations become a natural fit for traditional methodologies.
At the other end of the spectrum, when a project is smaller, requirements are poorly defined, and results are needed immediately, we have a prescription for more agile methods. These methodologies also tend to work best when the organization is more progressive. If we can throw in business users who are collocated with the IT staff, and are available to assist in development efforts, we have a natural fit for Agile or Rapid Application development methods.
When a project falls somewhere in the middle – that is, it is medium-sized, in a moderatly progressive organization, and with requirements that will be tougher to determine, we may have a candidate for plan-based iterative development. The key here really tends to be whether or not business users will made available to test and assess each iteration. If they can’t be spared, or the cost can’t be justified, then we may have to resort to more traditional methods.
The preceding cases are relatively straight-forward, and can be thought of as existing along a continuum. However, what if our project and organizational culture don’t match up? While an organization as a whole may be very large and conservative, they may have a project that is ideally suited to agile methods. It may be small, the IT staff and business users may be collocated, and it may exist in an environment that constantly changes. What then? It depends on the people available. If flexible, experienced people can be found that are willing to experiment with management styles, the organization may surely try out an agile methodology, and might well benefit from the experience. However, if the people involved aren’t up to a new style, it would be best to let them stick with what they know. At the other end of the spectrum, a very progressive organization may find itself in charge of a large, complex, and risky project that involves users and devlopers at multiple, distant sites. The decision still depends on the people involved, but in this case, managing a large number of them across multiple locations will dictate that the organization employ a plan-based approach with more management controls that produces more documentation.
The key is that organizations must be flexible in how they manage software development – management styles are driven by projects and people, not the other way around.
The Situational Leadership Model
(12manage.com)
Parallels can be drawn between our situation and Situational Leadership Theory (picture above), which states that we manage people based upon their experience level and need for supervision and the relative importance of the particular endeavor we undertake. It is important to note that it is the leader that adapts in this theory, just as the process must adapt to the organization and project in our situation. Situational Leadership dictates that the situation that the group finds itself in must be taken into consideration by the leader. The situation includes the task at hand, the environment we find ourselves in, and the skill level of the individual leader (or manager). This is quite similar to our project/culture table.
The real question we face in systems development, then, is much more akin to the question asked in situational leadership theory: ‘what situation do I find myself and my team in?’ That is, it’s not whether there exists a cookie-cutter approach that works for all systems development, but rather ‘how should this individual system development project be managed based on the overall situation’?
Bruns, Ilia. Interview. Michael Bruns. 7 November 2009.
Chimera Consulting. Situational Leadership model. 1999. 8 November 2009
Demarco, Tom. "Software Engineering: An idea whose time has come and gone?" July/August 2009. IEEE Software. 8 November 2009
—. Structured Analysis and Systems Specification. Upper Saddle River, NJ: Prentice Hall, 1978.
Duarte, Efren. Avocera: The future of Business Technology Optimization. 2 March 2009. 8 November 2009
Graham, Ian. Object-Oriented Methods. London: Pearson Education Ltd, 2001.
Larman, Craig and Victor Basili. "Iterative and Incremental Development: A Brief History." June 2003. ieeexplore.ieee.org. 9 November 2009
Louis, Iman. Systems Development Life Cycle. 1 December 2007. 8 November 2009
Mamais, G, M Perdikeas and I Venieris. Object-Oriented Software Technology in Telecommunications. West Sussex, England: John Wiley & Sons, Ltd, 2000.
Manifesto for Agile Software Development. 2001. 8 November 2009
Modell, Martin. Data-Directed Systems Design. New York: McGraw-Hill, Inc., 1990.
Nobisk, LLC. Nobisk. 8 November 2009
Taylor, David. Object-Oriented Information Systems: Planning and Implementation. New York: John Wiley & Sons, Inc., 1992.
West, David. Object Thinking. Redmond, WA: Microsoft Press, 2004.
Wikipedia.org. 2007. 8 November 2009
Yourdon, Edward. Modern Structured Analysis. Englewood Cliffs, NJ: Prentice Hall, 1989.
—. www.yourdon.com 2007. 8 November 2009
YouTube.com. 25 April 2008. 8 November 2009
Zim Systems Ltd. Zim Systems Limited. 2009. 8 November 2009