Software Process Modelling

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

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.

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.

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.

The Waterfall Model Fig 1.0

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.

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.

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

Waterfall Model With Prototyping

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.

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:

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.

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.

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.

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.

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.

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

Diagram of a software prototype model

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.

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.

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

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

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

Transformation Model

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

Phased Development Model

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

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.

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.

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.

Spiral Model Diagram

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

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)

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.

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

Extreme Programming Diagram

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.

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

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))

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.

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

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

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

Marvel Specifications Language Below are some sample marvel commands

References http://www.selectbs.com/analysis-and-design/what-is-a-software- development-process http://www.tutorialspoint.com/sdlc/index.htm http://slideplayer.com/slide/6862771/ http://istqbexamcertification.com/what-is-prototype-model-advantages- disadvantages-and-when-to-use-it/ http://www.ics.uci.edu/~wscacchi/Papers/SE-Encyc/Process-Models-SE- Encyc.pdf http://www.the-software-experts.com/e_dta-sw-process.php