Sashimi Waterfall Software Development Process POSTED BY JIM RISING ON MAY - 6 - 2009
Waterfall Model The Waterfall software development methodology is one of the most widely known and recognized methodologies. Originally designed for the manufacturing and construction industries, it is called „Waterfall‟ because of the way that it‟s phases flow downward, similar to an actual waterfall. It is best uesd for projects where the requirements are clearly stated and static, or where it helps to have a rigid management structure with up-front requirements and agreed timeline and budget. Many times the decision to use Waterfall over another method (such as Agile) is simply a matter of the personalities involved in the project, including the project sponsor. Using the Waterfall software development life cycle, the implementation of the system is preceded by requirements definition, analysis, design and development. One problem with the traditional waterfall method, is that it is impossible to perfect one phase alone before moving to the next phase. Another issue with waterfall in general is that the nature of design in any creative field (software development included) makes it difficult if not impossible to define all of the requirements up-front or even prior to completion. In a project where requirements are always changing, and new ideas are being formed as design proceeds creates a „moving target‟ syndrome where the waterfall model just does not fit. Sashimi Model The sashimi model (so called because it features overlapping phases, like the overlapping fish of Japanese sashimi) was originated by Peter DeGrace. It is sometimes referred to as the “waterfall model with overlapping phases” or “the waterfall model with feedback”. Since phases in the sashimi model overlap, information of problem spots can be acted upon during phases that would typically, in the pure waterfall model, precede others. For example, since the design and implementation phases will overlap in the sashimi model, implementation problems may be discovered during the design and implementation phase of the development process.This iterative method helps alleviate many of the problems associated with
the traditional philosophy of the waterfall model, but does not fully address the organic nature of some software projects. Theoretically, one thing that it is good at is managing your costs during the project by keeping your iteration between two phases at a time. Ideally you will not iterate backwards beyond the previous phase, as if you are already developing and find that you are iterating back to requirements… there was a (potentially expensive) mistake made during the „Design and Architecture‟ phase. Because this modified format of the traditional waterfall method is one of the most common (It is the one I use when using waterfall), this is the one I will be focusing on within this article. Requirements One of the most important tasks in the development of software using the waterfall method is gathering and defining the requirements for the project. Software requirements analysis is a rather broad field of software engineering and project management, but simply put … at the end of a requirements phase within the waterfall method, all involved parties should have a basic understanding of what is going to be developed, and at this point the requirements are written as „prose‟, and are not usually very technical in nature. In some cases (particularly with smaller projects), a budget and timeline estimate is also formed, though in my opinion this is best done after the Design and Architecture phase, when the majority of the costs are more accurately known. For this reason, I will normally split my billing into two major phases … the first includes the first two project phases, „Requirements‟ and „Design and Architecture‟, usually billed on retainer. The second major phase includes the remaining 3 waterfall phases, split into three major billing phases of „Development‟, „Testing‟, and „Implementation‟. Design and Architecture When discussing this phase of the waterfall method with my clients, I compare it to the design and architecture of a construction project. Before you build a custom building, you need to go to an architect in order to have that building designed. When building software, it is very similar. Software developers who specialize in this are even called „Software Architects‟. During the Design and Architecture phase of a project, a Software Architect is responsible for defining with the project sponsor the functional and / or technical definition of the project. At times, tools such as wireframes and/or storyboards are used in order to help the architect to communicate with the developers and the project sponsor. Other times, UML (Unified Modeling Language) is used… though this is generally only used to communicate with other developers, as most project sponsors are not going to understand it. I have even developed the user interface of a software project during this phase in order to help the communication process between our team and the project sponsor. Keep in mind that the Sashimi Model that we‟re using is iterative, so we‟re constantly going back and forth between this phase and the last. Until the prior phase is fulfilled by this one. The tangible result of the Design and Architecture phase should be a solid plan that defines the platform that is going to be used, the flow of the application, a hardware specification showing what hardware will be used… etc… Other tangibles may include the aforementioned wireframes, storyboards, and sometimes even a prototype user interface design. Development and Coding Once we all know what we‟re actually doing, now the fun part begins! Part of the reason why the initial
two phases of the waterfall process are so important is that this phase is the most time consuming and most expensive. Getting something wrong at this phase will inevitably mean one of two things… rework, or an unhappy client. Even when rework is done, this creates a situation where the client‟s project might be late, or if not hers… someone else‟s! Again, since we are using Sashimi Waterfall, the „Development and Coding‟ phase overlaps with the „Design and Architecture‟ phase until this phase fulfills the requirements of the one prior to it. Quality Assurance and Software Testing One of the most obvious improvements to the waterfall model when using Sashimi is during the testing phase. Because of the iterative approach of Sashimi, testing occurs as part of the development process, and then again as part of the deployment process. Develop, Test, Develop, Test, Develop… until the testing phase fulfills the development phase, Test, Implement, Test, Implement… until the application is fully tested and successfully deployed. Testing will also sometimes include several of it‟s own minor phases… sometimes called „Alpha‟ or „Beta‟, other times managed as versions of the project with a version 1.0 project being a final first release. There are also several different types of testing: Unit Testing Integration Testing System Testing Regression Testing Functional Testing Performance Testing Load Testing Compatibility Testing All of these are outside of the scope of this article, but I might be convinced to write another one down the road about testing. Implementation This is the phase of the project where the developed software is installed (or deployment scripts are delivered), documentation is written or cleaned up (as documentation should be written as an ongoing part of the development process), and sometimes client training will occur. Implementation is the only phase that I will sometimes overlap backwards two phases (between Deployment and Development) since there are sometimes things that are caught between Implmentation and Testing phases that require additional development to resolve. Maintenance and Support After the project is released into the wild, bad things can happen. This is why it is important that continued maintenance and support is addressed within any software development process. With the needs of clients and technology itself changing constantly, this support becomes an evolving process… and is essential to making sure that the software continues to perform as expected. I will normally move this phase out of the waterfall, and treat it as a separate project entirely as the nature of supporting an existing project can be very different from building a new project.
