[note -- the two figure images have been lost to the internet black hole, but they were

fairly simple diagrams that could be replaced with a quick google image search... or intermediate-level mspaint skillz ;-)] Robert Mathenia SG150: Project 1 February 17, 2008

Software engineering is a discipline wherein certain techniques / methods are employed to improve the quality of software development. As the field grew larger and more complex, the use of a methodical approach became all but necessary in order to consistently achieve fewer defects, shorter delivery times, and better value in software products. Many software development methodologies now exist – too many to count, and a big challenge facing software engineers is that of selecting a proper methodology or combination of methodologies and using them wisely (Chapman). Discussed herein are five of the most recognized software development methodologies, their efficiencies/ inefficiencies, and their relationships to one another. These methodologies are almost telescopic in nature, as they are largely built on and derived from each other. In most real-life software development projects, no single method is employed; rather, a combination of methods usually serves development interests best, and some of these combinations are explored within. Object orientation is probably the single most pivotal advancement in software development methodology. It allows software systems to more closely model the real world by representing the world as a system of interacting objects. This methodology was conceived relatively early on in the history of digital computers, but has been only gradually adopted. The reason for this is that in order for the methodology to work, modeled objects must encapsulate their data as well as the operations that act on that data, which means more computing memory, storage, and processing power is necessary. Computer hardware prices have steadily decreased since the inception of object orientation, contributing to its widespread adoption. The main benefits of object orientation are threefold: 1) Maintainability – A system of interacting objects is less complex (to the programmer) than a structural code collection (in which the acting pieces are more closely tied to one another), therefore it takes less time and is generally easier to modify code. Verification of correct coding procedure is also simplified for the same reason. 2) Reusability – Unique objects that are encapsulated with their own data and operations can be used with little or no modification in multiple applications 3) Productivity gains – The above principles can be directly mapped to a contemporary object-oriented programming language, which makes transitioning from modeling to inception nearly seamless. This saves time, and time is money (Bray). Object orientation is based on (and often closely coupled to) Object-Oriented Analysis (OOA). OOA provides the basis for Object-Oriented Design (OOD) via the creation of classes, which are akin to templates that generate objects. In OOA/OOD, classes are used to define particular objects, and protocols for communication between these objects are provided in the form of methods. Methods are also defined within classes and are thus part of the object. Since an object's data and the operations that work on that data are encapsulated in a single entity, the transition from model to programming code requires less effort. In this way, analysis and design are more closely related in object orientation than

in structured programming. Two distinct phases comprise OOD: high-level, where larger more basic objects are conceptualized and organized; and low-level, where the particular objects' attributes, methods and specific composition are addressed (Bray). This principle further illustrates the marriage of analysis and design inherent in object-orientation. Companies have notably reaped significant benefits from the integration of object orientation in software design. In its large project known as the Call Attempt Data Collection System (CADCS), AT&T Bell Labs saw a 30% decrease in development time and a 20% decrease in development staff effort after adopting object orientation. However, this increase in productivity only occurred after the incorporation of three- to six-month long pilot projects for training (Bray). The disadvantage to object orientation is that thoroughly trained developers are necessary in order to fully reap productivity improvements. If training is not sufficient, the learning curve involved in adopting object-orientation could be costly and provide little value. Object orientation provides the best returns when its goal is the design of reusable software systems. Without significant reuse potential, object orientation ends up being more costly than more traditional methodologies such as structural or procedural programming (Bray). The principle of reuse potential becomes important in methodologies that are largely based on object orientation, such as the Rapid Development methodologies. Most notably of these (and which will be discussed later) is eXtreme Programming, wherein the core practices are built on object-orientation (Zagarrio). The inherently close relationship between analysis and design in object orientation practically begs for a standardized way of modeling objects and their interactions, and this standardization is embodied in the Unified Modeling Language (or UML). UML is akin to blueprints used by architects in a construction project – with UML, a model (or collection of different types of models) of a software application can be generated to serve as a blueprint in software development. Since the vast majority of software design processes begin with a model, UML is closely tied to object-orientation ("Practical UML"). UML is not a methodology in itself, but rather a paradigm or framework designed for compatibility with contemporary object orientation methodology. UML has significantly affected the evolution of methods that are based on objectorientation. This is made evident by various changes in the methodology that were explicitly made to take advantage of updated notation in newer versions of UML. UML has played a big role in advancing the progress of model-driven technologies, with the Rational Unified Process (also known as RUP) being a prime example of this ("Unified Modeling Language"). Modeling is facilitated in UML through the use of various types of diagrams. A class (the framework or definition of an object), for example, is represented as a rectangle divided into three parts: the topmost contains the name of the class, the middle section contains the attributes, and the bottom section is comprised of the class's methods (see Figure 1). Figure 1: Diagram of a class The class diagram is not the only diagram UML is capable of creating; in fact, in the newest version of UML (UML 2.0) there are thirteen different types of diagrams spread across three categories. The distribution of diagram types is as follows: The first category, Structure Diagrams, consists of class, component, composite structure, deployment, object, and package diagrams. The second category, Behavior Diagrams, consists of activity, state machine, and use case diagrams. The final

category, Interaction Diagrams, consist of communication, interaction overview, and UML timing diagrams. All these diagrams can be organized under a hierarchy, as depicted in Figure 2: ("Unified Modeling Language") .. Figure 2: Diagram hierarchy in UML ("Unified Modeling Language") Despite UML's virtually unanimous industry acceptance, some criticisms of its alleged deficiencies have surfaced: 1) UML is too large and/or complex, resulting in redundant or infrequently used diagrams, 2) Difficult for newcomers to adopt due to complexity, 3) UML seems to represent some systems better than others. This implies that any given programming language used to implement UML models would cap off at some level of efficiency in those situations that UML does not accurately model. 4) UML is aesthetically inconsistent and displeasing. There seems to be no pattern or practical reason behind the various shapes used to represent different diagrams/models (boxes sometimes, clouds other times) 5) UML strives for total compatibility and generality in modeling, which can make it feel weighed down and bloated ("Unified Modeling Language"). As we have seen, UML produces models wherever object orientation happens to be practiced. The combination is prevalent because the software development methodology feeds off of the modeling process, and vice versa. In practice, the methodology and the modeling language are inextricably intertwined. Rapid Application Development (or RAD) is essentially a sort of revved-up occurrence of object orientation and UML in action. In traditional software development, many requirements are documented along the way in a process, and the quality of the resulting product is measured as "the degree to which the system conforms to written specifications". Since most large software development projects never satisfy every single written requirement, the quality of the resulting product comes under scrutiny. RAD addresses this issue by redefining the concept of quality to mean "the degree to which a system meets business requirements" (Zagarrio). RAD is an evolutionary, iterative approach to software development, with each iteration in the process resembling an entire (yet smaller-scoped) development project. Evolution of prototypes in RAD is directed by a set of guidelines: - The customer specifies requests, the developer makes changes - Designers review the prototype - Customer determines whether the prototype follows requests and suggests new requests - Meetings are arranged between developers and designers to discuss secondary requests, and which requests may be sacrificed According to Giuseppe Zagarrio's "Rapid Software Development Methodologies", Rapid Application Development embodies three basic principles: "1) In certain situations, a usable 80% solution can be produced in 20% of the time that would have been required to produce a total solution. 2) In some cases the customer's requirements can be completely satisfied even if the functional requirements are not completely satisfied. 3) In some cases a system can work with a sufficient level of functionality even if functions are not all required ones" (Zagarrio).

All of these seemingly stringent formalities are really not such – in practice, the principles of RAD are a little more general and malleable: release only documentation that is absolutely necessary, use models as much as possible, and work closely with the customer (Zagarrio). Skipping publishing of unnecessary documentation saves time and money, and keeping close communication with the customer / client helps ensure a better understanding of requirements. This in turn leads to the application being designed correctly early on, serving to diffuse or eliminate problems, or at the very least preventing problems from compounding beyond control. The act of rapidly developing a software product often results in lack of reusability. RAD facilitates reuse by building from the generic to the specific. In other words, base classes are given priority in design. Modification and new functionality is achieved through class inheritance (Zagarrio). So, if a "car" object is needed, a base class of "vehicle" would probably be designed, and then the class "car" would be based on the vehicle class. This way, if at a later time trucks or boats are needed, they could be based on the already written vehicle class. Rapid Development often uses CASE (Computer Aided Software Engineering) tools to expedite the design process. There are some problems with this: - Programming code is not 100% testable because of lack of visibility of thirdparty code, - Costs can increase due to licensing constraints of CASE tools, - Customer satisfaction can decrease if secondary requirements are set aside when CASE cannot provide for them (Zagarrio). If programmers depend too much on CASE tools, the resulting application might not be as testable as desired because the implementation of the CASE tools themselves are involved, but invisible (and therefore unable to be included in testing). CASE also has its own limits, so some things may be overly difficult or near-impossible to implement using a given CASE toolset. If the development team is forced to rely on a CASE toolset, and that toolset does not provide for the specified requirements, the customer could end up dissatisfied. RAD should not be used for mission- or life-critical situations where the best performance is required (eXtreme programming is preferred in these situations). RAD is ideally employed in the case of a standalone application, or to get an early compromise between customer and developer (Zagarrio). Even though RAD is based on and operates in the larger framework of object orientation and UML, RAD itself can be generalized into an entire group of methodologies, and when this is the case, is often referred to as Rapid Application Methodologies (or RAM). RAM consists of (but is apparently not limited to): Rapid application development (as discussed above), Agile Modeling, and eXtreme Programming (Zagarrio). In eXtreme Programming, also known as xp, development time is reduced by employing standardized programming practices which allow for constant testing. This is in direct contrast to Rapid Development, which focuses on reduction of development time through the use of third-party software (Zagarrio). It can be speculated that xp's standardized programming practices are more controllable than RAD's thirdparty software use, which may in turn lead to a tighter more satisfactory product. Much as in RAD, in xp the customer is involved, but to an even greater degree. The customer is considered part of the team so that necessary changes can be made quickly and effectively (Zagarrio). This method has the advantage of instant

feedback, but the disadvantage of the responsibility of an in-house client. For the benefits to be maximized with this setup, communication must be open, honest and sincere. The final constituent of RAM, Agile Software Development, is a sort of general paradigm that encompasses many development methods. The main goal in these methods is risk minimization through development iterations. Even though at the end of an iteration the project may not be functional enough to justify release, release is the goal of every iteration, and every iteration is in itself an entire project. Agile employs a customer-centric approach, giving preference to face-to-face communication over written documents, and the focus is on working software as the main measure of progress ("Agile software development"). Agile Modeling is a support to design, not a formula or method in itself. It employs a set of principles divided into two groups (core and other) in order to reduce problems into models. For a model to be officially considered Agile, the core principles must be adhered to. Agile Modeling's values include communication, simplicity, feedback, courage, and humility (these are very similar to the values of xp, probably due to Agile often being in support of xp). The core principles of Agile modeling are: 1) Model with a purpose 2) Maximize stakeholder investments 3) Travel light 4) Multiple models 5) Rapid feedback 6) Assume simplicity 7) Embrace change 8) Incremental change 9) Quality work 10) Software is primary goal 11) Enabling next effort is secondary goal (Zagarrio) The advantages of agile modeling are similar to those of RAD and xp, due mostly to its heavy involvement with those disciplines. Due also to this relationship, the main disadvantage of Agile speaks as well to xp and other RAMs: In the case of inaccurate feedback, problems can be compounded quickly and lead to an unworkable solution ("Agile software development"). This is why communication is so important in these Rapid methodologies – it does not matter how close the customer / client is kept to the development process: if the feedback from the customer to the developer (or vice versa) is inaccurate but is mistaken as accurate and then acted upon, the mistake could spiral into a large problem the likes of those that sometimes occur with traditional methodologies (such as the waterfall method). And in these problem scenarios where RAM is employed, there is not even documentation with which to gain some footing. Another area in which a developer may encounter problems with agile modeling is that of working with and incorporating large data systems. Data system specialists often require exacting, complete specifications. If these specs are not prepared correctly, the development comes to a standstill until the data can be negotiated. For this reason, agile modeling is not well-suited for systems that rely on large, relational, legacy databases ("Agile software development"). Common to all software development projects, regardless of methodology employed, is the fact that every application embodies one or more patterns. These pattern may be similar to patterns found in other software development projects, and so may be adopted from project to project. This is the central tenet to Design Patterns. Design patterns address the problem of unique techniques for every

software design problem by providing general solutions that are documented in a way that does not attach them to any particular problem. Design patterns are like templates that are made to expedite solutions to common problems in software design. The use of patterns in design allows developers to attach well-understood names and terminology to software interactions. This way, design patterns lend themselves to improvement over time, where ad-hoc designs do not ("Design pattern (computer science)"). Design patterns can be categorized into three groups: creational, structural, and behavioral ("Design patterns in C and VB.NET"). Each particular pattern is composed of several sections: structure, participants and collaboration. These combined sections describe a "micro-architecture" which includes classes, methods, and their relationships. Micro-architectures are used by developers in design patterns, facilitating uniform structure and organization ("Design pattern (computer science)"). The main advantage to design patterns is that they speed up the development process. They also serve to provide a tested and proven framework for development, since the pattern has been previously used. Early issues that can cause big problems later are often revealed through reuse of design patterns. Design patterns are numerous, and exist for a variety of specific domains in software design, such as user-interface design ("Design pattern (computer science)"). Two examples of design patterns are the Singleton and the Façade. The Singleton applies in situations where only one object of a class is needed. A second client class is used to interact with the singleton. The class has absolute control over the number of instances that can be created, via a method that returns a reference to the instantiated object. The Singleton design pattern keeps the responsibility of keeping track of objects off the programmer, and can be extended (it is refactorable in xp lingo) to keep track of a different number of objects. The Façade pattern helps in situations where a collection of classes needs to be grouped under a common interface class (rather than interfacing complexly among themselves). An example of the Façade in action is in the case of modeling a room. The room has several objects, such as chair, table, desk, bed, etc. Incorporating a Façade pattern, an interface that allows all the objects in the room to interact in room-like ways would be created. In this case, a room class would have methods such as "organizeRoom()" wherein the objects in the room would be changed via one interface call instead of many. Compilers often employ the Façade pattern in design ("Design Patterns Tutorial"). A problem with design patterns is the tradeoff of performance for flexibility, because design patterns introduce a greater number of possible outcomes which can complicate designs. It is also argued (to a lesser degree) that design patterns do not promote software reuse because they are not components in themselves. Currently, patterns must be integrated into each application from scratch, and some seek to address through "componentization" of the patterns ("Design pattern (computer science)"). The very nature of software development involves problem solving, and an essential component of problem solving is pattern recognition. Therefore, design patterns (or some offshoot thereof) are destined to walk hand-in-hand with software development. And like design patterns, we have seen that some software development methodologies are inseparably bound to each other. A developer would not start a large object-oriented project without first creating one or more UML diagrams, most applications developed using a rapid methodology are immersed in object orientation, and rapid-methodology designed applications probably would not have been nearly as rapidly designed without an agile model. All this leads to the

conclusion that the methodologies explored herein overlap each other to the point of all-inclusiveness and that in practice the best is borrowed from all methodologies in all applicable areas.

WORKS CITED "Agile software development." Wikipedia. 2008. Wikipedia.org. 16 Feb 2008 . Bray, Mike. "Object-Oriented Design." Carnegie Mellon Software Engineering Institute. 27 OCT 1997. Carnegie Mellon Software Engineering Institute. 16 Feb 2008 . Chapman, James. "Software Development Methodology." Infinite Spiritual Discovery. 01 JAN 2007. 17 Feb 2008 . "Design pattern (computer science)." Wikipedia. 2007-08. Wikipedia.org. 16 Feb 2008 . "Design patterns in C and VB.NET." data & object factory. 16 Feb 2008 . Kurotsuchi, Brian. "Design Patterns Tutorial." Cal Poly Computer Science Department. 1996. Cal Poly State University. 16 Feb 2008 . "Practical UML." CODE GEAR From Borland. 01 DEC 2003. Borland Software Corp. 17 Feb 2008 . "Unified Modeling Language." Wikipedia. 2008. Wikipedia.org. 17 Feb 2008 . Zagarrio, Giuseppe. "Rapid Software Development Methodologies." Norwegian University of Science and Technology Department of Computer and Information Science. NTNU. 16 Feb 2008

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.