text: The name Sashimi comes from the Japanese style of presenting raw fish, where the slices overlap each other. In the sashimi model, too the stages overlap each other to overcome the drawbacks of the traditional waterfall development model.
  The sashimi model of development is a modification to the traditional waterfall model.
  The traditional waterfall provides minimal overlapping between the two stages of development. But that s not the case with the Sashimi model of development.
  This model suggests a stronger degree of overlap between the stages-For example, suggesting you might be well into architectural design partway between the structural analysis and perhaps partway into the detailed designing before you consider requirements analysis to ve complete. This is a reasonable approach for many projects, which tend t gain important insights into what they are doing as they move through their development cycles and which function poorly with their strictly sequential development plans. In the pure waterfall model, the ideal documentation is that one team can to a completely separate team between any two phases. The question is, "why?" If you can provide personnel continuity between all stages of software development, you don't need much documentation. This wa, by following modified waterfall model, you can substantially reduce the need for documentation.
  The Sashimi model is no without problems. Because there is an overlap between the phases, milestones are more ambiguous, and it's harder to track progress accurately. Performing activities in parallel can lead to miscommunication, mistaken assumptions and result in inefficiency. If you are working on a small, well-defined project, something close to the pure waterfall can be more efficient instead.
  Notes and images from Rapid Development: Taming Wild Software Schedules by Steve McConnell
  If you liked the post, please like it and follow me on Github!