To the uninformed, when you hear the term “Sashimi,” one first things of the Japanese style of overlapping slices of raw fish commonly enjoyed in Sushi establishments. In software engineering and development circles; however, Sashimi refers to the Japanese hardware development model that comes from Fuji-Xerox. The Sashimi Waterfall model is a variation on the classic waterfall in that it suggests a fair amount of overlap between the phases of the software development life cycle. The approach to development is considered suitable for projects that require a fair number of insights between each layer of development as the development life cycle progresses. Whereas in the classic or pure waterfall method, complete documentation is expected to be headed off to the team in charge of the next phase of development, in the Sashimi waterfall this documentation can change and encourages a continuity between the development phases.
Waterfall Model Refresher
For those not in school, or several quarters or semesters removed from their core software engineering course, the waterfall methodology is one of the best known and recognized techniques or methods for software development. The original waterfall grew out of the manufacturing and construction fields from the way that the phases of development flow downward (like a waterfall…). The classic waterfall method is considered best for projects that have clear requirements which will remain relatively static. Other cases
that the classic waterfall may prove suitable are when management considers it helpful to have a rigid project structure with a set budget and well-defined timeline to adhere to. Sometimes the waterfall method is simply chosen based on the project manager’s personality. In the standard method, requirements will be defined, then analyzed, designed, and developed. Unfortunately, the waterfall does not take into account the fact that many projects are just not able to define all of the requirements prior to starting resulting in post-fact modifications to the process to be made to result in a successful project.
Sashimi Waterfall Model
The Sashimi waterfall model was originally created by Peter DeGrace. Other terms for the Sashimi include “The Waterfall Model with feedback” or the “Waterfall Model with overlapping phases.” An advantage of permitting overlap between the phases in the Sashimi is that issues can be discovered earlier in the software development process helping result in the minimization of re-work and a better final product. Engineers working on the design phase of a project may discover potential implementation problems prior to full production work beginning. Conversely, since the implementation phase begins prior to design going final, engineers may discover core design issues not intuitive prior to proceeding to development. The iterative method inherent within the Sashimi has been found to eliminate or reduce the cost associated with the classic Waterfall model. It is not without its own problems; however, as production teams or managers have to be careful to avoid iterating back to an earlier phase that has been closed or repeating too many iterations that result in a negative impact on successful completion of the product or bottom-line.
Sashimi Waterfall Model Process
The Sashimi Waterfall model process consists notionally of six phases: Requirements, Design and Architecture, Development and Coding, Quality Assurance and Software Testing, Implementation, and Maintenance and Support.
Sashimi Requirements Phase
Creating well-defined requirements is the most important and most challenging aspects of any software development project. At the end of the requirements phase; however, all of the project teams or representatives should have a good understanding of the task or project at hand. At this stage in the project, the requirements are written in a mix of plain English and some technical ease, but are not formally expressed in technical language (think of it as the bridge behind the “Idea Team or Guy/Gal” and the team who has to implement the idea(s). Some teams (specifically small companies or software teams) will also establish a timeline and budget in this phase, though many argue this should wait or at least be refined in the Design and Architecture phase once the true costs of the project can be suitable expressed.
Sashimi Design and Architecture Phase
During the Design and Architecture phase of the Sashimi, software architects will define the technical and/or functional definition of the project at hand. In this phase, UML (Unified Modeling Language) is popular for use for communication with other development teams (or individual developers) in addition to the documentation created for the project sponsor. As design work progresses, in the Sashimi model it is common for requirements to be refined with resulting changes in the architecture as the team’s work through the problem set. At the end of the phase, a solid plan will be defined for use in development and a working prototype may be created based on the project.
Sashimi Development and Coding
Development and coding will initiate while the design and architecture phase is still ongoing. Depending on the complexity of the project, it may not overlap until towards the later stages of design; however, the development and coding phase can be one of the most expensive and time consuming phases of any software development project. As a result, early feedback from those implementing the project is key to avoiding significant mistakes that can result in missed deadlines or costly rework.
Sashimi Quality Assurance and Software Testing
A significant advantage of the Sashimi Waterfall over classic implementations occurs during this phase. Since Sashimi is an iterative approach, testing occurs throughout the development process and finds issues much earlier in the development cycle. Developers are encouraged to test throughout the coding and development process as well as during the deployment process. Sometimes testing will be broken up to various phases of its own based on the complexity of the project. Some of the commonly found testing types in industry are:
Human Factors (commonly ignored, and commonly the result of complaints for consumer-based projects).
The Implementation phase of the Sashimi may actually overlap with several of the previous phases depending on the nature of the project. Many teams will begin creating both technical and consumer support documentation in parallel with development and testing to better capture critical insights for the client. Additionally, this is the time when the software is delivered or installed and if required, client training occurs.
Sashimi Maintenance and Support
Providing maintenance and support is key to ensuring the client remains satisfied. Errors can occur for a number of reasons, technology can change, and support becomes an evolving and persistent process of its own. Many times the support phase becomes a separate project of its own for companies based on the client and scope of work completed.