Software Engineering (CS301) Lesson 2: Software Development Life Cycle Part 2 PDF

SOFTWARE ENGINEERING (CS301) Lesson 2: Software Development Life Cycle Part 2 Lecturer: Marcelo Sioson Batiduan III  SDLC - Spiral Model The spiral model combines the idea of iterative development with the systematic, control...

SOFTWARE ENGINEERING (CS301) Lesson 2: Software Development Life Cycle Part 2 Lecturer: Marcelo Sioson Batiduan III  SDLC - Spiral Model The spiral model combines the idea of iterative development with the systematic, controlled aspects of the waterfall model. This Spiral model is a combination of iterative development process model and sequential linear development model i.e. the waterfall model with a very high emphasis on risk analysis. It allows incremental releases of the product or incremental refinement through each iteration around the spiral. SDLC - Spiral Model  Spiral Model - Design The spiral model has four phases. A software project repeatedly passes through these phases in iterations called Spirals. 1. Identification 2. Design 3. Construct or Build 4. Evaluation and Risk Analysis  Spiral Model - Design 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. This phase also includes understanding the system requirements by continuous communication between the customer and the system analyst. At the end of the spiral, the product is deployed in the identified market.  Spiral Model - Design Design The Design phase starts with the conceptual design in the baseline spiral and involves architectural design, logical design of modules, physical product design and the final design in the subsequent spirals.  Spiral Model - Design Construct or Build The Construct phase refers to production of the actual software product at every spiral. 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. Then in the subsequent spirals with higher clarity on requirements and design details a working model of the software called build is produced with a version number. These builds are sent to the customer for feedback.  Evaluation and Risk Analysis Risk Analysis includes identifying, estimating The following illustration is a representation and monitoring the technical feasibility and of the Spiral Model, listing the activities in each phase. 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. Based on the customer evaluation, the software development process enters the next iteration and subsequently follows the linear approach to implement the feedback suggested by the customer. The process of iterations along the spiral continues throughout the life of the software.  Spiral Model Application The Spiral Model is widely used in the software industry as it is in sync with the natural development process of any product, i.e. learning with maturity which involves minimum risk for the customer as well as the development firms. The following pointers explain the typical uses of a Spiral Model −  Spiral Model Application When there is a budget constraint and risk evaluation is important. For medium to high-risk projects. Long-term project commitment because of potential changes to economic priorities as the requirements change with time. Customer is not sure of their requirements which is usually the case. Requirements are complex and need evaluation to get clarity. New product line which should be released in phases to get enough customer feedback. Significant changes are expected in the product during the development cycle. Spiral Model - Pros and Cons The advantages of the Spiral SDLC Model are as follows − Changing requirements can be accommodated. Allows extensive use of prototypes. Requirements can be captured more accurately. Users see the system early. Development can be divided into smaller parts and the risky parts can be developed earlier which helps in better risk management. Spiral Model - Pros and Cons The disadvantages of the Spiral SDLC Model are as follows − Management is more complex. End of the project may not be known early. Not suitable for small or low risk projects and could be expensive for small projects. Process is complex Spiral may go on indefinitely. Large number of intermediate stages requires excessive documentation.  V-Model - Design Under the 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. The Coding Phase joins the two sides of the V-Model.  V-Model - Design Verification is the process of checking that software achieves its goal without any bugs. It is the process to ensure whether the product that is developed is right or not. It verifies whether the developed product fulfills the requirements that we have. Verification is static testing. Verification means Are we building the product right?  V-Model - Design Validation is the process of checking whether the software product is up to the mark or in other words product has high-level requirements. It is the process of checking the validation of the product i.e. it checks what we are developing is the right product. It is validation of the actual and expected products. Validation is dynamic testing. Validation means Are we building the right product?  V-Model - Design The following illustration depicts the different phases in a V-Model of the SDLC. V-Model - Verification Phases There are several Verification phases in the V-Model, each of these are explained in detail below. Business Requirement Analysis This is the first phase in the development cycle where the product requirements are understood from the customer’s perspective. This phase involves detailed communication with the customer to understand his expectations and exact requirement. This is a very important activity and needs to be managed well, as most of the customers are not sure about what exactly they need. The acceptance test design planning is done at this stage as business requirements can be used as an input for acceptance testing. V-Model - Verification Phases System Design Once you have the clear and detailed product requirements, it is time to design the complete system. The system design will have the understanding and detailing the complete hardware and communication setup for the product under development. The system test plan is developed based on the system design. Doing this at an earlier stage leaves more time for the actual test execution later. V-Model - Verification Phases Architectural Design Architectural specifications are understood and designed in this phase. Usually more than one technical approach is proposed and based on the technical and financial feasibility the final decision is taken. The system design is broken down further into modules taking up different functionality. This is also referred to as High Level Design (HLD). The data transfer and communication between the internal modules and with the outside world (other systems) is clearly understood and defined in this stage. With this information, integration tests can be designed and documented during this stage. V-Model - Verification Phases Module Design In this phase, the detailed internal design for all the system modules is specified, referred to as Low Level Design (LLD). It is important that the design is compatible with the other modules in the system architecture and the other external systems. The unit tests are an essential part of any development process and helps eliminate the maximum faults and errors at a very early stage. These unit tests can be designed at this stage based on the internal module designs. V-Model - Verification Phases 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 - Verification Phases Validation Phases The different Validation Phases in a V-Model are explained in detail below. Unit Testing Unit tests designed in the module design phase are executed on the code during this validation phase. 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 testing is associated with the architectural design phase. Integration tests are performed to test the coexistence and communication of the internal modules within the system. V-Model - Verification Phases System Testing System testing is directly associated with the system design phase. 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 this system test execution. Acceptance Testing Acceptance testing is associated with the business requirement analysis phase and involves testing the product in user environment. 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.  V- Model ─ Application V- Model application is almost the same as the waterfall model, as both the models are of sequential type. Requirements have to be very clear before the project starts, because it is usually expensive to go back and make changes. This model is used in the medical development field, as it is strictly a disciplined domain.  V- Model ─ Application The following pointers are some of the most suitable scenarios to use the V-Model application. 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.  V-Model - Pros and Cons The advantage of the V-Model method is that it is very easy to understand and apply. The simplicity of this model also makes it easier to manage. The disadvantage is that the model is not flexible to changes and just in case there is a requirement change, which is very common in today’s dynamic world, it becomes very expensive to make the change.  V-Model - Pros and Cons The advantages of the V-Model method are as follows − 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.  V-Model - Pros and Cons The disadvantages of the V-Model method are as follows − 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. Once an application is in the testing stage, it is difficult to go back and change a functionality. No working software is produced until late during the life cycle.  SDLC - Big Bang Model The Big Bang model is an SDLC model where we do not follow any specific process. The development just starts with the required money and efforts as the input, and the output is the software developed which may or may not be as per customer requirement. This Big Bang Model does not follow a process/procedure and there is a very little planning required. Even the customer is not sure about what exactly he wants and the requirements are implemented on the fly without much analysis. Usually this model is followed for small projects where the development teams are very small. SDLC - Big Bang Model  Big Bang Model ─ Design and Application The Big Bang Model comprises of focusing all the possible resources in the software development and coding, with very little or no planning. The requirements are understood and implemented as they come. Any changes required may or may not need to revamp the complete software. This model is ideal for small projects with one or two developers working together and is also useful for academic or practice projects. It is an ideal model for the product where requirements are not well understood and the final release date is not given.  Big Bang Model - Pros and Cons The advantage of this Big Bang Model is that it is very simple and requires very little or no planning. Easy to manage and no formal procedure are required. However, the Big Bang Model is a very high risk model and changes in the requirements or misunderstood requirements may even lead to complete reversal or scraping of the project. It is ideal for repetitive or small projects with minimum risks.  Big Bang Model - Pros and Cons The advantages of the Big Bang Model are as follows − This is a very simple model Little or no planning required Easy to manage Very few resources required Gives flexibility to developers It is a good learning aid for new comers or students.  Big Bang Model - Pros and Cons The disadvantages of the Big Bang Model are as follows − Very High risk and uncertainty. Not a good model for complex and object- oriented projects. Poor model for long and ongoing projects. Can turn out to be very expensive if requirements are misunderstood.  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. Agile Methods break the product into small incremental builds. These builds are provided in iterations. Each iteration typically lasts from about one to three weeks.  Agile Model Every iteration involves cross functional teams working simultaneously on various areas like − Planning Requirements Analysis Design Coding Unit Testing and Acceptance Testing.  Agile Model Agile model believes that every project needs to be handled differently and the existing methods need to be tailored to best suit the project requirements. In Agile, the tasks are divided to time boxes (small time frames) to deliver specific features for a release. Iterative approach is taken and working software build is delivered after each iteration. Each build is incremental in terms of features; the final build holds all the features required by the customer. Agile Model  Agile Model - Pros and Cons The advantages of the Agile Model are as follows − Is a very realistic approach to software development. Promotes teamwork and cross training. Functionality can be developed rapidly and demonstrated. Resource requirements are minimum. Suitable for fixed or changing requirements Delivers early partial working solutions. Good model for environments that change steadily. Minimal rules, documentation easily employed. Enables concurrent development and delivery within an overall planned context. Little or no planning required. Easy to manage. Gives flexibility to developers.  Agile Model - Pros and Cons The disadvantages of the Agile Model are as follows − Not suitable for handling complex dependencies. More risk of sustainability, maintainability and extensibility. An overall plan, an agile leader and agile PM practice is a must without which it will not work. Strict delivery management dictates the scope, functionality to be delivered, and adjustments to meet the deadlines. Depends heavily on customer interaction, so if customer is not clear, team can be driven in the wrong direction. There is a very high individual dependency, since there is minimum documentation generated. Transfer of technology to new team members may be quite challenging due to lack of documentation. Next Session Thank you!