1. Software Process Modelling

2. Software Process – What is software development?
Software development is the process of developing software through successive phases in an orderly way.
These phases typically include:
Gathering and analysis of requirements
Software Design
Programming and Implementation
Testing
Maintenance

3. Major activities covered in each phase
Gathering and analysis of requirements - Extracting the requirements of a desired software product is the first task in creating it.
Software design - The design of a software system refers to an abstract representation of that system. Software design is concerned with making sure the software system will meet the requirements of the product, as well as ensuring that future requirements can be addressed.
Programming and implementation- Reducing a design to code may be the most obvious part of the software engineering job, but it is not necessarily the largest portion.
Testing - his part of the process ensures that defects are recognized as soon as possible. In some processes, generally known as test-driven development, tests may be developed just before implementation and serve as a guide for the implementation's correctness.
Maintenance - Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software as missed requirements may force redesign of the software.

4. Software process models
Software process modelling is the means of splitting software development work into distinct phase containing activities with the intent of better planning and management.
A process model provides a fixed framework that guides a project in: 
Development of the product
Planning and organizing the project
Tracking and running the project
A process model also defines:
The activities that have to be carried out in each of the phases, including the sequence in which these activities have to be carried out.
The roles of the executors that have to carry out the activities, including a description of their responsibilities and required skills.
The work products that have to be established or updated in each of the activities. Besides the final product there are usually several other items that have to be generated during the development of a product. These are for example requirements and design document, test specifications and test reports, etc.

5. The Waterfall Model
The Waterfall model is the earliest SDLC(software development life cycle) approach that was used in software engineering.
In this approach the whole process of software development is divided into separate phases. In Waterfall model, typically, the outcome of one phase acts as the input for the next phase sequentially(see Fig 1.0)
Scenarios where the waterfall method can be used
Requirements are very well documented, clear and fixed.
Product definition is stable.
Technology is understood and is not dynamic.
There are no ambiguous requirements.
Ample resources with required expertise are available to support the product.
The project is short.

6. The Waterfall Model
Fig 1.0

7. Waterfall Model – Pros and Cons
Advantages:
Simple and easy to understand and use
Easy to manage due to the rigidity of the model . each phase has specific deliverables and a review process.
Phases are processed and completed one at a time.
Works well for smaller projects where requirements are very well understood.
Clearly defined stages.
Well understood milestones.
Easy to arrange tasks.
Process and results are well documented.

8. Waterfall Model – Pros and Cons
Disadvantages:
No working software is produced until late during the life cycle.
High amounts of risk and uncertainty.
Not a good model for complex and object-oriented projects.
Poor model for long and ongoing projects.
Not suitable for the projects where requirements are at a moderate to high risk of changing. So risk and uncertainty is high with this process model.
It is difficult to measure progress within stages.
Cannot accommodate changing requirements.
Adjusting scope during the life cycle can end a project.
Integration is done as a "big-bang. at the very end, which doesn't allow identifying any technological or business bottleneck or challenges early.

9. Waterfall Model with Prototyping
A prototype is a partially developed product. In this model a prototype is developed in the first few stages of the model.
Prototyping helps
developers assess alternative design strategies (design prototype)
users understand what the system will be like (user interface prototype)
Prototyping is useful for verification and validation

10. Waterfall Model With Prototyping

11. The V Model
The V - model is SDLC model where execution of processes happens in a sequential manner in V-shape. It is also known as Verification and Validation model.
V - Model is an extension of the waterfall model and is based on association of a testing phase for each corresponding development stage.
This means that for every single phase in the development cycle there is a directly associated testing phase.
This is a highly disciplined model and next phase starts only after completion of the previous phase.

12. V Model Design
Under V-Model, the corresponding testing phase of the development phase is planned in parallel. So there are Verification phases on one side of the .V. and Validation phases on the other side. Coding phase joins the two sides of the V-Model. The figure below illustrates the phases of the V model:

13. V-Model: Verification Phases
The following are the verification phases in the V-model:
Business Requirement Analysis: This phase involves detailed communication with the customer to understand his expectations and exact requirement.
System Design: System design would comprise of understanding and detailing the complete hardware and communication setup for the product under development.
Architectural Design: This is also referred to as High Level Design and it is where system design is broken down further into modules with different functionalities.
Module Design: In this phase the detailed internal design for all the system modules is specified, referred to as Low Level Design (LLD). Unit tests can be designed at this stage based on the internal module designs.

14. V-Model: Coding Phase
The actual coding of the system modules designed in the design phase is taken up in the Coding phase.
The best suitable programming language is decided based on the system and architectural requirements.
The coding is performed based on the coding guidelines and standards.
The code goes through numerous code reviews and is optimized for best performance before the final build is checked into the repository.

15. V-Model: Validation Phases
The following are the validation phases in the V model:
Unit Testing: Unit testing is the testing at code level and helps eliminate bugs at an early stage, though all defects cannot be uncovered by unit testing.
Integration Testing: Integration tests are performed to test the coexistence and communication of the internal modules within the system.
System Testing: System tests check the entire system functionality and the communication of the system under development with external systems. Most of the software and hardware compatibility issues can be uncovered during system test execution.
Acceptance Testing:  Acceptance tests uncover the compatibility issues with the other systems available in the user environment. It also discovers the non functional issues such as load and performance defects in the actual user environment.

16. When to Use the V-Model
Similarly to the waterfall model, requirements have to be very clear before the project starts in order to apply the V- model because it is usually very expensive to go back and make changes.
The following scenarios are suitable to use V-Model:
Requirements are well defined, clearly documented and fixed.
Product definition is stable.
Technology is not dynamic and is well understood by the project team.
There are no ambiguous or undefined requirements.
The project is short.

17. The V-Model: Pros and Cons
The following are some cons of using the v model:
High risk and uncertainty.
Not a good model for complex and object-oriented projects.
Poor model for long and ongoing projects.
Not suitable for the projects where requirements are at a moderate to high risk of changing.
The following are some pros of using the v model:
This is a highly disciplined model and Phases are completed one at a time
Works well for smaller projects where requirements are very well understood.
Simple and easy to understand and use.
Easy to manage due to the rigidity of the model . each phase has specific deliverables and a review process.

18. Software Prototype Model
What is software prototyping?
Software Prototyping refers to building software application prototypes which display the functionality of the product under development but may not actually hold the exact logic of the original software.
Prototyping is used to allow the users to evaluate developer proposals and try them out before implementation. The diagram on the next slide illustrates this.
There are 5 main stages in developing a software prototype, namely:
Basic Requirement Identification
Developing the initial Prototype
Review of the Prototype
Revise and enhance the Prototype

19. Diagram of a software prototype model

20. When to use software prototyping
Prototype model should be used when the desired system needs to have a lot of interaction with the end users.
Typically, online systems, web interfaces have a very high amount of interaction with end users, are best suited for Prototype model. It might take a while for a system to be built that allows ease of use and needs minimal training for the end user.
Prototyping ensures that the end users constantly work with the system and provide a feedback which is incorporated in the prototype to result in a useable system. They are excellent for designing good human computer interface systems.

21. Advantages of software prototyping
Users are actively involved in the development
Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed.
Errors can be detected much earlier.
Quicker user feedback is available leading to better solutions.
Missing functionality can be identified easily
Confusing or difficult functions can be identified Requirements validation, Quick implementation of, incomplete, but functional, application.

22. Disadvantages of software prototyping
Risk of insufficient requirement analysis owing to too much dependency on prototype
Users may get confused in the prototypes and actual systems.
Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.
Developers may try to reuse the existing prototypes to build the actual system, even when its not technically feasible
The effort invested in building prototypes may be too much if not monitored properly

23. Operational Specifications Model
The operational approach to software development assumes the existence of a formal specification language and processing environment that supports the evolutionary development of specifications into an prototype implementation
Requirements are examined and their implication evaluated early in the development process
Functionality and the design are allowed to be merged

24. Transformation Model
The transformation model seeks to eliminate some major developmental steps.
This is done by applying a series of transformations to change a specification into a deliverable system such as:
Change data representation
Select algorithms
Optimize
Compile
This model relies on formalism
It also requires a formal specification to allow for transformations

25. Transformation Model

26. Phased Development Model
In the phased development model the system is delivered in pieces
This enables customers to have some functionality while the rest is being developed
This usually results in a shorter cycle time.
Phased development allows two systems to function in parallel, namely:
the production system (release n): currently being used
the development system (release n+1): the next version

27. Phased Development Model

28. Incremental and Iterative Models
Incremental development: This process starts with small functional subsystem and adds functionality with each new version released
Iterative development: The iterative process starts with a simple implementation of a subset of the software requirements and iteratively enhances the evolving versions until the full system is implemented

29. Why is this combination important?
Below are some advantages of using the combined model as well as another diagram illustrating the combination between the two models and how they work together:
Some working functionality can be developed quickly and early in the life cycle.
With every increment operational product is delivered.
Risks are identified and resolved during iteration; and each iteration is an easily managed milestone.
It supports changing requirements.

30. The Spiral Model
Spiral model is a combination of iterative development process model and sequential linear development model i.e. waterfall model with very high emphasis on risk analysis.
The model is presented as a spiral in which each iteration is represented by a circuit around four major activities
Identification
Design
Construct or Build
Evaluation and Risk analysis
It also allows for incremental releases of the product, or incremental refinement through each iteration around the spiral.

31. The Spiral Model: The 4 Phases
Identification: This phase starts with gathering the business requirements in the baseline spiral. In the subsequent spirals as the product matures, identification of system requirements, subsystem requirements and unit requirements are all done in this phase.
Design: Design phase starts with the conceptual design in the baseline spiral and involves architectural design, logical design of modules, physical product design and final design in the subsequent spirals.
Construct or Build: In the baseline spiral when the product is just thought of and the design is being developed a POC (Proof of Concept) is developed in this phase to get customer feedback. In subsequent models a working model of the software called build is produced and is given a version number
Evaluation and Risk Analysis: Risk Analysis includes identifying, estimating, and monitoring technical feasibility and management risks, such as schedule slippage and cost overrun. After testing the build, at the end of first iteration, the customer evaluates the software and provides feedback.

32. Spiral Model Diagram

33. The Agile Model
Agile SDLC model is a combination of iterative and incremental process models with focus on process adaptability and customer satisfaction by rapid delivery of working software product.
An agile process usually consists of:
Effective (rapid and adaptive) response to change
Effective communication among all stakeholders
Drawing the customer onto the team
Organizing a team so that it is in control of the work performed

34. The Agile Manifesto
The manifesto for agile software development emphasis on the following key points:
Value individuals and interactions over process and tools
Prefer to invest time in producing working software rather than in producing comprehensive documentation
Focus on customer collaboration rather than contract negotiation
Concentrate on responding to change rather than on creating a plan and then following it
Examples of agile processing methods are:
Extreme programming (XP)
Crystal: a collection of approaches based on the notion that every project needs a unique set of policies and conventions
Scrum: 30-day iterations; multiple self-organizing teams; daily “scrum” coordination
Adaptive software development (ASD)

35. Extreme Programming(XP)
This is the most widely used form of agile processing contains the following steps
Begins with the creation of “user stories”
Agile team assesses each story and assigns a cost
Stories are grouped to for a deliverable increment
A commitment is made on delivery date
After the first increment “project velocity” is used to help define subsequent delivery dates for other increments.

36. Extreme Programming(XP)- The 12 Facets
Extreme programming has been described as having 12 practices to follow in order to have the best chance of success. These are:
Pair programming
Collective ownership
Continuous integration (small increments)
Sustainable pace (40 hours/week)
On-site customer
Coding standard
The planning game (customer defines value)
Small release
Metaphor (common vision, common names)
Simple design
Writing tests first
Refactoring

37. Extreme Programming Diagram

38. Tools for Process Modelling
There are two major notation categories depending on what is to be captured in the model:
The two major notation categories
Static model: depicts the process, showing that the inputs are transformed to outputs
Dynamic model: can enact the process, so that the user can see how intermediate and final products are transformed over time.

39. Static Modelling: Lai Notation
State tables show information about the completeness of each artifact at a given time.
Transition diagrams show how the states are related to one another.
Element of a process are viewed in terms of seven types
Activity
Sequence
Process model
Resource
Control
Policy
Organization

40. Static Modelling: Lai Notation
Below is an example diagram that illustrates the transition for a car
Parked:
((state_of(car.engine) = off)
(state_of(car.gear) = park)
(state_of(car.speed) = stand))

41. Dynamic Modelling
Enables enacting of process to see what happens to resources and artifacts as activities occur
Simulate alternatives and make changes to improve the process
An example of this is systems dynamic model
One way to understand system dynamics is by exploring how software development process affects productivity.

42. Dynamic Modelling: System Dynamics
System dynamics models are supported by software that simulates the overall process.
Below is a pictorial presentation of factors affecting productivity
Arrows indicate how changes in one factor change another

43. System Dynamic Models
A system dynamic model containing four major areas affecting productivity

44. Practical Process Modelling
When used properly, process modeling offers great benefits for understanding processes and revealing inconsistencies.
Develop special language to help defining and enacting processes, e.g. Marvel specification language.
Three-part process description
rule-based specification of process behaviour
object-oriented definition of model’s information process
set of envelopes to interface between Marvel and external software tools

45. Marvel Specifications Language
Below are some sample marvel commands

46. References
development-process
disadvantages-and-when-to-use-it/
Encyc.pdf