Waterfall Development

Say the words "waterfall development" to most people and chances are they're going to be thinking of a bunch of condos under Niagara Falls. Imagine their surprise, then, when you tell them that waterfall development is actually a software developmentmodel which involves a phased progression of activities leading to the release of a software product. This article provides a quick and dirty introduction to the model, explaining what it is, how it's supposed to work, and why it can fail.

Overview

Waterfall development isn't new -- it's been around since 1970 -- but most developers still only have a vague idea of what it means. Essentially, it's a framework for software development in which development proceeds sequentially through a series of phases, starting with system requirements analysis and leading up to product release and maintenance. Feedback loops exist between each phase, so that as new information is uncovered or problems are discovered, it is possible to "go back" a phase and make appropriate modification. Progress "flows" from one stage to the next, much like the waterfall that gives the model its name.

A number of variants of this model exist, with each one quoting slightly different labels for the various stages. In general, however, the model may be considered as having six distinct phases, described below:

1. Requirements analysis: This first step is also the most important, because it involves gathering information about what the customer needs and defining, in the clearest possible terms, the problem that the product is expected to solve. Analysis includes understanding the customer's business context and constraints, the functions the product must perform, the performance levels it must adhere to, and the external systems it must be compatible with. Techniques used to obtain this understanding include customer interviews, use cases, and "shopping lists" of software features. The results of the analysis are typically captured in a formal requirements specification, which serves as input to the next step.
2. Design: This step consists of "defining the hardware and software architecture, components, modules, interfaces, and data...to satisfy specified requirements" (Wikipedia). It involves defining the hardware and software architecture, specifying performance and security parameters, designing data storage containers and constraints, choosing the IDE and programming language, and indicating strategies to deal with issues such as exception handling, resource management and interface connectivity. This is also the stage at which user interface design is addressed, including issues relating to navigation and accessibility. The output of this stage is one or more design specifications, which are used in the next stage of implementation.
3. Implementation: This step consists of actually constructing the product as per the design specification(s) developed in the previous step. Typically, this step is performed by a development team consisting of programmers, interface designers and other specialists, using tools such as compilers, debuggers, interpreters and media editors. The output of this step is one or more product components, built according to a pre-defined coding standard and debugged, tested and integrated to satisfy the system architecture requirements. For projects involving a large team, version control is recommended to track changes to the code tree and revert to previous snapshots in case of problems.
4. Testing: In this stage, both individual components and the integrated whole are methodically verified to ensure that they are error-free and fully meet the requirements outlined in the first step. An independent quality assurance team defines "test cases" to evaluate whether the product fully or partially satisfies the requirements outlined in the first step. Three types of testing typically take place: unit testing of individual code modules; system testing of the integrated product; and acceptance testing, formally conducted by or on behalf of the customer. Defects, if found, are logged and feedback provided to the implementation team to enable correction. This is also the stage at which product documentation, such as a user manual, is prepared, reviewed and published.
5. Installation: This step occurs once the product has been tested and certified as fit for use, and involves preparing the system or product for installation and use at the customer site. Delivery may take place via the Internet or physical media, and the deliverable is typically tagged with a formal revision number to facilitate updates at a later date.
6. Maintenance: This step occurs after installation, and involves making modifications to the system or an individual component to alter attributes or improve performance. These modifications arise either due to change requests initiated by the customer, or defects uncovered during live use of the system. Typically, every change made to the product during the maintenance cycle is recorded and a new product release (called a "maintenance release" and exhibiting an updated revision number) is performed to enable the customer to gain the benefit of the update.

Advantages

The waterfall model, as described above, offers numerous advantages for software developers. First, the staged development cycle enforces discipline: every phase has a defined start and end point, and progress can be conclusively identified (through the use of milestones) by both vendor and client. The emphasis on requirements and design before writing a single line of code ensures minimal wastage of time and effort and reduces the risk of schedule slippage, or of customer expectations not being met.

Getting the requirements and design out of the way first also improves quality; it's much easier to catch and correct possible flaws at the design stage than at the testing stage, after all the components have been integrated and tracking down specific errors is more complex. Finally, because the first two phases end in the production of a formal specification, the waterfall model can aid efficient knowledge transfer when team members are dispersed in different locations.

Criticisms

Despite the seemingly obvious advantages, the waterfall model has come in for a fair share of criticism in recent times. The most prominent criticism revolves around the fact that very often, customers don't really know what they want up-front; rather, what they want emerges out of repeated two-way interactions over the course of the project. In this situation, the waterfall model, with its emphasis on up-front requirements capture and design, is seen as somewhat unrealistic and unsuitable for the vagaries of the real world. Further, given the uncertain nature of customer needs, estimating time and costs with any degree of accuracy (as the model suggests) is often extremely difficult. In general, therefore, the model is recommended for use only in projects which are relatively stable and where customer needs can be clearly identified at an early stage.

Another criticism revolves around the model's implicit assumption that designs can be feasibly translated into real products; this sometimes runs into roadblocks when developers actually begin implementation. Often, designs that look feasible on paper turn out to be expensive or difficult in practice, requiring a re-design and hence destroying the clear distinctions between phases of the traditional waterfall model. Some criticisms also center on the fact that the waterfall model implies a clear division of labor between, say, "designers", "programmers" and "testers"; in reality, such a division of labor in most software firms is neither realistic nor efficient.

Customer needs

While the model does have critics, it still remains useful for certain types of projects and can, when properly implemented, produce significant cost and time savings. Whether you should use it or not depends largely on how well you believe you understand your customer's needs, and how much volatility you expect in those needs as the project progresses. It's worth noting that for more volatile projects, other frameworks exists for thinking about project management, notably the so-called spiral model...but that's a story for another day!

Hotel Software- a Complete Hotel Management Solution

The hospitality business needs to handle numerous processes simultaneously without missing out on anything. For any kind of hospitality endeavor be it a five-star hotel or a small sized motel, Hotel Software (HS) is a must-have that provides improved and better service to its customers. This type of software help you increase revenue and customer satisfaction by creating a better and stronger link between your business and your customers and partners.

Software developers across the world have been adding new and advanced features in the modern technology wonders to make things easier for those, who are involved in hotel management. Hotel software is wide-ranging software suite comprised of integrated modules for numerous features of hotel management. The significant modules in the hotel management software comprise hotel reservation software, hotel management system, hotel booking software (billing system), hotel reception and front desk software and hotel accounting software. With these modules, the HS assist you manage reservations, bookings, room stays, room planning, guests, accounts, agents, pricing plans, check-in/ check-out, basically front office and back office hotel operations. In short, this software is designed to help administrator or operator to track all records at just one mouse click. Fully featured, easy to install and use, hotel management software have now come at affordable rates ensuring exceptional guarantee, service and support.


Because of the growing demand of Hotel Software, a number of software development companies have focused on the platform bringing easy to use software for meeting all types of requirements and demands. They guarantee you competent hospitality services and you can modify the features that you wish for. If you are looking for such software companies to improve administration of your hotel and get a good profit, you will surly find a lucrative deal on the internet or reachus@woodappleunik.com to know more. 


There are many websites which allow you to download hotel management software without paying a single penny. Whether you're a motel owner who needs to automate the reservation process, a bed and breakfast owner who wants to get out from under the paperwork of a manual tracking system or a vendor who needs to turn guest history into additional sales, these companies have the complete solution that you need.


www.woodappleunik.com

Code Comprehension

I’ve been thinking a lot this week about code and documentation—more precisely, I’ve been thinking about code as documentation. The idea of "self-documenting code" is certainly not a new one. When, as a relatively inexperienced developer, I first read about self-documenting code in Steve McConnell’s Code Complete, it was a revelation to me. My first real-world experience with programming was maintaining and debugging someone else’s horrible code, and I knew intuitively from that trial by fire how important it is to make one’s code clear and understandable. From that experience, I started concentrating on code-level comments as the key to making sure that code is properly documented and can be easily understood by others.

But McConnell’s Code Complete really opened my eyes. Self-documenting code, he writes, is "the Holy Grail of legibility...Such code relies on good programming style to carry the greater part of the documentation burden. In well-written code, comments are the icing on the readability cake." (page 456) While reading the 450 pages leading up to this statement, I began to see how writing good quality code is really a matter of making thousands of tiny decisions along the way. Quality code does not happen by accident. It really takes true desire in the heart of the developer, because at each of those thousands of tiny decision points, there are so many opportunities for shortcuts, and so many opportunities to do something that reduces the quality of the code.

The key to achieving self-documenting code is what McConnell calls "good programming style." To achieve this "Holy Grail of legibility," it really takes constant attention, and an ongoing dialog with myself as I work. I don’t know that I’ll ever achieve it, but I’m always trying. I try to approach the writing of code as if I were making art. In my mind, the metaphor of the musician is most apt, since the musician must work within the mathematical confines of his medium, but at the same time can lend so much personal style to the end product.

Architecture is another useful analogy. The architect designing a building must obviously work within the confines of physics, engineering principles, and municipal building codes, but people pay huge premiums for the best architects, who infuse the building design with their unique stylistic statements.

But is self-documenting code enough? Clearly not, because the code itself can never capture the intent of the developer writing the code. The code documents the solution, but knowledge of the problem can only be inferred. This is where comments come in. Here is a quote from my description of The Principle of Comments:

The code is the solution to the problem being solved. Ideally, the code should speak for itself. A person can read the code, and if it's good code, should be able to readily see what the code is doing and how it's doing it. However, what is lost over time is what was in the mind of the developer who wrote the code. In general, this is what needs to commented on. What was the intent of the developer? How is this code intended to be used? How does this code intendto solve the problem at hand? What was the idea behind the code? How does this code explicitly interrelate to other parts of the code? One of the greatest sins a developer can commit is to leave his code without his intent being clear to subsequent readers of the code.

What I try to capture most in my comments is to explain, at a high level, what my code is doing. I try to illustrate what my "scheme" is—how it all interconnects and works. I try to picture myself in the position of the maintenance developer, coming to my code for the first time, trying to figure out how it all works. What would he want to know about this code? I try to picture myself looking over the shoulder of that maintenance developer. How would I explain this code to him? What’s not immediately obvious? What would his questions be? How would I explain to him why I did it this way? The answers to these questions are what I put in my "at the level of intent" comments.

There is a lot of controversy today over which methodology or "family" of methodologies is the best one (the truth is that different methodologies are better or worse in different circumstances), but the larger issues of process and methodology fall away when a developer is by herself, at the computer, writing code. The writing of code is a very personal act. It’s just the coder and the code, alone at the computer. The opportunity exists for the developer (or pair of developers) to stamp his or her own unique signature and style onto the code, just as the musician or architect does.

However, while the desire to develop a truly advanced coding style is essential, it is not enough. The other essential part of the equation is knowledge. Can the musician produce beautiful music without knowledge of the rules of music? Can the architect design a beautiful building without knowledge of the laws of physics and the principles of structural engineering? Can we as developers produce beautiful code without the knowledge of what it takes to accomplish that?

In order to develop a style that leads to beautiful, self-documenting code (as if the two could be separated), in order to make the best choice in those thousands of tiny decisions—indeed, in order to even recognize the opportunity to make those decisions—we must have the knowledge of where the potential trouble spots are. We must know the techniques and conventions and standards. How can we choose the best data and routine names or use ideal layout techniques if we’ve never learned what the programmers of the last forty years have learned by trial and error? How can we properly modularize a system and make it tolerant to change if we are not intimate with the concepts of cohesion and coupling?

If one has that true desire to make one’s code the best it can be, one must acquire the knowledge of what works, and what doesn’t. One must learn the situational subtleties that go into making the best choice in those thousands of tiny decisions that a developer makes when writing a system. Choice A might be the best choice in Situation 1, but in Situation 2, Choice B might be preferable. The rules and conventions are not necessarily absolutes. But if one does not know the rules and conventions, one cannot know when to adjust them to the situation. This is another way of phrasing the old adage, "First master the rules, then you can discern when to bend and break them."

(One must also master the peculiarities of the language being used, even if that language is not the developer’s favorite. Each language is different, and has its own conventions for naming, layout, exception handling, etc. We should try to respect these differences, and not force the conventions of another language onto the one we are writing in today. Too many developers learn a style (good or bad) with their first language, and then impose that style on every other language they use in the future.)

If one desires to develop his or her own unique style, reading lots of great books, articles, and essays is an excellent first step. Make reading a continuing activity.

The next step would be practice, since the code editor and IDE is where theory gets put to the test. Strive to make each program better than the last one you wrote, and then move on to the next one.

Third, read and analyze other people’s programs. If your team is not performing peer-based code reviews, suggest that you start. If you are learning on your own, download code from programming web sites, or look through the code that comes on the CD-ROM with a programming book. You will find plenty of bad code, and, if you’re lucky, some exceptionally good code too.

Finally, if you are able, find a mentor. Identify someone around you that you look up to, whose opinion you respect, and who has the experience you would like to acquire. Ask that person if she will read your code and help you make it better. This can provide amazing leaps forward that might otherwise take months or years—or that might not ever happen at all.