A software process model is a simplified depiction of a software process that represents one sight of that process. Process models may incorporate actions that are fraction of the software process, software products and the roles of people concerned in software engineering. Apiece of process model represents a process from a particular perspective, and thus provides only limited and specified information about that process. For example, a process activity model demonstrates the activities and their sequence but may not show the functions of the people involved in these activities. In this Article, We introduce a number of very general software process models (sometimes it called process paradigms) and present these from an architectural perspective. Specifically, we can spot the framework of the process but not the detail information of specific activities.
These standard models of software processes are not definitive descriptions of software processes. Moderately, they are abstractions of the process that can be helpful to clarify different approaches to software development. You can consider of them as process frameworks that may be extended and bespoke to create more specific software engineering processes.
Some types of software process model that may be produced are covered here:
- A workflow model: This software processes modeling shows the sequence of activities in the process along with their inputs, outputs and dependencies. The activities in this model represent human actions. This model takes the fundamental process activities of requirement specification, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implementation, testing, and so on. After each stage is defined it is ‘signed-off, and development goes on to the following stage.
- Incremental development: This model interleaves the activities of customer requirement specification, development, and validation. An initial system is rapidly developed from very abstract specifications. Then the system refined with customer input to produce a system that satisfies the customers’ needs. The final system is developed as a succession of versions (increments), with each version involve up-gradation in functionality to the previous version. Alliteratively, it may be re-implemented using a more structured approach to produce a more robust and maintainable system.
- A dataflow or activity model: This process model represents the route as a set of activities, each of which carries out a number of data transformations. It shows how the input to the process, such as a requirement specification, is transformed to an output, such as a design. The activities here may signify transformations carried out by people or by computers.
- A role/action model: This process model represents the roles of the people involved in the software process and the activities for which they are answerable.
- Reuse-oriented software engineering: This process modeling approach is based on the continuation of a significant number of reusable components. The system development process focuses on integrating these components into a system rather than developing them from scratch.
- Component-based software engineering (CBSE): This process modeling technique assumes that parts of the system already exist. The system development process spotlights on integrating these parts rather than developing them from scratch.
Also Check: Theory of Automata tutorials
These software process models are not mutually elite and are frequently used together, especially for large systems development. For large systems, it makes logic to merge some of the best features of the one model like waterfall to other model like incremental development models. As a software engineer you need to have detailed information about the essential system requirements to design software architecture to support these requirements. You cannot develop this incrementally. Sub-systems within a larger system may be developed using different approaches. Ingredient parts of the system that are well understood can be specified and developed using a waterfall-based process. Parts of the system which are difficult to specify in advance, such as the user interface, should always be developed using an incremental approach.
