Download Software Development Life Cycle Models: Waterfall, V-Model, Spiral, and Agile and more Essays (high school) Technology in PDF only on Docsity!
ASSIGNMENT 01 FRONT
SHEET
Qualification BTEC Level 5 HND Diploma in Computing Unit number and title Unit 09:^ Software^ Development^ Life^ Cycle Issue date Date Received 1st submission Re-submission Date Date Received 2nd submission Student Name Tran Dang Khoa Student ID GBD Class GCD1104 Assessor name udent declaration I certify that the assignment submission is entirely my own work and I fully understand the consequences of plagiarism. I understand that making a false declaration is a form of malpractice. Student’s signature Grading grid P1 P2 P3 P4 M1 M2 D1 D
❒ Summative Feedback: ❒ Resubmission Feedback:
Grade: Assessor Signature: Date: Internal Verifier’s Comments: Signature & Date:
- Chapter 1: Describe two iterative and two sequential software lifecycle models
- I. Define two sequential software lifecycle models.
- Waterfall Model
- 1.1. Pros and Cons of Waterfall Model
- V-model.
- 2.2. Pros and Cons of V-Model..........................................................................................................................
- II. Define two iterative software lifecycle models
- a) Pros and Cons of Spiral Model.
- a) Pros and Cons of Spiral Model
- Chapter 2: Explain how risk is managed in the Spiral lifecycle model......................................................
- I. What is risk in Spiral Model?
- II. Manage risk in Spiral lifecycle Model
- Chapter 3: Explain the purpose of a feasibility report
- I. What is Feasibility report?
- II. Type of Feasibility report
- Technical Feasibility
- Economic Feasibility
- Schedule Feasibility
- Operational Feasibility..............................................................................................................................
- III. Purpose of Feasibility report
- IV. The components of Feasibility Study
- Project Scope
- The Current Analysis
- Requirements.
- The Approach
- Evaluate
- Review
- Chapter 4: Describe how technical solutions can be compared
- I. What is techinical solutions?
- II. Comparison of technical solution
- References
- Figure 1: Waterfall Model Table of Figures
- Figure 2: V-Model...........................................................................................................................................
- Figure 3: Prototype Model
- Figure 4: Spiral Model
- Figure 5: Manage risks in spiral model.
- Figure 6: Feasibility report.
- Figure 7: Technical Feasibility
- Figure 8: Economic Feasibility
Chapter 1: Describe two iterative and two sequential software lifecycle models
I. Define two sequential software lifecycle models
1. Waterfall model: Requirements Gathering: The project requirements are collected and documented in detail. This phase involves understanding the client's needs, expectations, and any specific functionalities required for the software. System Design: In this phase, the system architecture and design are created based on the gathered requirements. The design typically includes the overall structure of the system, modules, data flow, and user interface. Implementation: The development team starts coding based on the system design. Each module or component is implemented separately by different developers or teams. The focus is on building the software according to the requirements and design specifications. Testing: Once the implementation is complete, thorough testing is performed to identify and fix any defects or bugs. Different types of testing, such as unit testing, integration testing, system testing, and user acceptance testing, are conducted to ensure the software functions as intended. Deployment: After successful testing and bug fixing, the software is deployed or installed on the production environment or user's system. This phase involves the necessary configurations and setups to make the software operational. Maintenance: Once the software is deployed, ongoing maintenance and support activities take place. This includes addressing any issues or bugs reported by users, performing updates or enhancements, and demonstrating the software remains functional over time. ➢ The waterfall model is a software development process approach that was first described by Dr. Winston W.Royce in a 1970 essay. The software development process is divided into different phases and conducted sequentially in this paradigm, with the output of one phase serving as the input of the next phase and no overlap. The waterfall model is named for the top-to-bottom sequential method, which resembles the flow of a waterfall. ➢ It was, in fact, the first widely used model in the software business. However, in recent years, this approach has revealed numerous flaws, and Agile Software Development methodologies are gradually replacing it.
➢ Disadvantages of waterfall model:
- For major, long-term projects, this is not the best model.
- Not suitable for projects with ambiguous requirements from the start.
- Change is difficult to adjust to, including needs, plans, and project scope...
- When the end-of-life user sees and uses the product, intuitiveness is poor, and value is late to arrive. Requirement Gathering: Begin by thoroughly understanding and documenting the project requirements. Engage with stakeholders, users, and clients to gather all necessary information about their needs and expectations. This phase involves creating a detailed requirements document that serves as the foundation for the project. System Design: Based on the gathered requirements, proceed to create a comprehensive system design. This design should outline the system's architecture, modules, data flow, and user interface. Ensure that the design aligns with the requirements and establishes a clear roadmap for the development process. Implementation: With the system design in place, development can begin. Assign tasks to different developers or teams based on the modules or components defined in the design phase. Each team should work on their respective tasks, ensuring that they adhere to the design specifications and coding standards. Testing: Once the implementation phase is complete, move on to testing the software. This phase involves a series of tests to identify and resolve any bugs or issues. Start with unit testing, where individual modules are tested in isolation. Then progress to integration testing, where the interaction between different modules is tested. Follow it up with system testing to validate the entire system's functionality. Finally, perform user acceptance testing to ensure that the software meets the users' expectations. Deployment: After successful testing, the software is ready for deployment. This phase involves preparing the software for production and installing it in the desired environment. Conduct any necessary configurations and setups to ensure the software is operational and accessible to the intended users. Maintenance: Once the software is deployed, ongoing maintenance and support becomes crucial. Establish a system to address any issues or bugs reported by users promptly. In addition, consider performing periodic updates and enhancements to improve the software's functionality and address any emerging requirements.
2. V model:
Requirements Analysis: The software requirements are gathered, analyzed, and documented in detail. This phase involves understanding the needs of the stakeholders and translating them into clear and unambiguous requirements. System Design: Based on the requirements, a high-level system design is created. This design phase focuses on defining the overall architecture, subsystems, and their interactions. It provides a blueprint for the subsequent development and testing activities. Module Design: In this phase, the high-level system design is decomposed into individual modules or components. Detailed designs are created for each module, specifying their internal structure, interfaces, and algorithms.
Coding: The implementation of the software modules is carried out in this phase. Developers write the actual code according to the detailed module designs. Coding standards and best practices are followed to ensure high-quality and maintainable code. Unit Testing: Once a module is coded, unit testing is performed on each module individually. Unit tests verify the functionality and behavior of the module in isolation. Developers typically write unit tests to cover different code paths and ensure that the module works as expected. Integration Testing: After unit testing, the modules are integrated and tested together to verify the interactions and interfaces between them. Integration tests focus on identifying any issues that arise to the integration of different modules. This testing phase ensures that the integrated system functions correctly and meets the requirements. System Testing: The system testing phase verifies the complete software system as a whole. It involves testing the system against the defined requirements to ensure it meets the desired functionality, performance, and quality criteria. System testing is typically carried out by a dedicated testing team. User Acceptance Testing (UAT): UAT involves testing the system with end-users or stakeholders to validate that it meets their expectations and requirements. Users perform real-world scenarios and provide feedback on any issues or deviations from their needs. Deployment: Once the system has passed all the testing phases and received approval from stakeholders, it is deployed to the production environment or made available to users. Deployment involves activities like installation, configuration, and final setup. Maintenance: After deployment, the software enters the maintenance phase. This phase includes ongoing support, bug fixing, and periodic updates to address any issues or evolving requirements. ➢ The V-Model (or V-paradigm) is a highly disciplined SDLC (Software Development Life Cycle) model for development testing in which a test phase runs concurrently with each phase of the software. develop. The V-model is a variation on the Waterfall paradigm, in which testing is done in parallel with development in a sequential order. The Validation Model or Verification Model is another name for it.
- Large and complex tasks are not recommended.
- If your needs change frequently, this is not the best solution.
- At the intermediate stage, no working software is created.
- Because there is no risk analysis provided, there is ambiguity and risk. Requirements Analysis: Thoroughly understand and document the software requirements. Engage with stakeholders to gather all necessary information about their needs and expectations. Ensure the requirements are clear, complete, and unambiguous. System Design: Based on the requirements, create a high-level system design that outlines the overall architecture, subsystems, and their interactions. Ensure the design aligns with the requirements and provides a blueprint for development and testing. Module Design: Decompose the high-level design into individual modules or components. Create detailed designs for each module, specifying their internal structure, interfaces, and algorithms. Ensure the module designs are consistent with the overall system design. Coding: Implement the software modules according to the detailed designs. Write the actual code, adhere to coding standards and best practices. Conduct code reviews and ensure proper documentation is in place. Unit Testing: Perform unit testing on each module independently. Develop and execute unit tests to verify the functionality and behavior of the modules in isolation. Ensure that all code paths are covered and that the modules function as expected. Integration Testing: Integrate the tested modules and perform integration testing. Verify the interactions and interfaces between the modules. Conduct tests to identify any issues arising due to integration. Ensure that the integrated system works correctly and meets the requirements. System Testing: Test the complete software system as a whole. Verify its functionality, performance, and quality against the defined requirements. Conduct system-level tests to ensure the software meets the desired criteria. Use various testing techniques, such as functional testing, performance testing, security testing, and usability testing. User Acceptance Testing (UAT): Involve end-users or stakeholders to perform UAT. Allow them to test the system in real-world scenarios and provide feedback. Validate that the software meets their expectations and requirements. Deployment: Once the system has passed all the testing phases and received approval from stakeholders, proceed with deployment. Install the software in the production environment and configure it as needed. Ensure all necessary setups and configurations are completed for the system to be operational. Maintenance: After deployment, enter the maintenance phase. Provide ongoing support, address reported issues, and perform periodic updates or enhancements to meet evolving requirements.
II. Define two iterative software lifecycle models:
1. Spiral model: Identification of Objectives and Risks: In this phase, the project objectives and requirements are defined, along with identifying potential risks and uncertainties. The risks may include technical challenges, resource constraints, budget limitations, or changing user requirements. The project team conducts a thorough analysis to identify and prioritize these risks.
Risk Analysis and Mitigation: The identified risks are analyzed, and strategies are developed to mitigate them. Alternative solutions are created explored, and a plan is to address the risks in the upcoming iteration. This phase involves gathering feedback from stakeholders, consulting, and making informed decisions on how to manage the risks effectively. Development and Testing: In this phase, the software is developed, following the plan and mitigating the identified risks. The development process may follow any suitable methodology, such as the waterfall model or an agile approach. The software is implemented, and incremental releases or iterations are made based on the development plan. Testing activities are conducted throughout the development phase. This includes unit testing of individual components, integration testing to ensure proper functioning of integrated modules, and system testing to validate the software against the requirements. Feedback and results from testing activities inform the subsequent iterations. Evaluation and Planning for the Next Iteration: Once a release or iteration is complete, it undergoes evaluation and review. The software is assessed against the project objectives, requirements, and user feedback. Lessons learned from the current iteration are gathered and incorporated into the planning for the next iteration. This phase involves making decisions on whether to proceed to the next iteration or make adjustments to the project plan based on the evaluation outcomes. ➢ Spiral-Model is a hybrid model that combines waterfall (Waterfall-Model) and iterative (Iterative-Model), and it shares many characteristics with incremental model (Incremental-Model). The spiral model is a software development approach that is risk-driven. It is still possible to combine the strengths of other models with the problem-solving abilities of previous models. The spiral model provides a way to apply components of one or more treatment models, such as the accelerometer, waterfall model, or evolutionary prototyping, according on the particular risk models of each project. Figure 3: Spiral model
Repeat Iterations: Continue with subsequent iterations, following the same cycle of risk identification, risk analysis, development, testing, evaluation, and planning. Each iteration builds upon the knowledge and experience gained from previous iterations, allowing for incremental improvements and mitigating risks as the project progress.
2. Agile model: Product Backlog: The Agile development process starts with creating a product backlog, which is a prioritized list of features, enhancements, and tasks that need to be implemented in the software. The product backlog is typically managed by the product owner, who represents the stakeholders' interests. Sprint Planning: In the sprint planning phase, the development team, including developers, testers, and other stakeholders, collaboratively selects a set of items from the product backlog to be implemented in the upcoming sprint. They determine the sprint goals, define the tasks required to complete the selected items, and estimate the effort involved. Sprint Execution: The development team works on implementing the selected items during the sprint, typically a time-boxed period of 1-4 weeks. Daily stand-up meetings are conducted to provide updates, discuss progress, and address any obstacles. The team collaborates closely, breaking down the work into smaller tasks and continuously integrating and testing the software. Daily Stand-ups: Daily stand-up meetings, also known as daily scrums, are short, time-boxed meetings where team members provide updates on their progress, share any challenges or roadblocks, and plan their activities for the day. The focus is on maintaining transparency, promoting communication, and fostering collaboration within the team. Continuous Integration and Testing: Agile emphasizes the practice of continuous integration, where code changes from different team members are frequently integrated into a shared repository. Automated testing is performed continuously to identify and address defects early in the development process. This ensures the software remains stable and functional throughout the development iterations. Sprint Review: At the end of each sprint, a sprint review meeting is held to demonstrate the completed work to stakeholders and gather their feedback. The team presents the implemented features, discusses any changes or enhancements required, and integrates the feedback into future iterations Sprint Retrospective: Following the sprint review, a sprint retrospective meeting takes place. The team commented on their performance during the sprint, what went well and what could be improved, and action items for process enhancements in subsequent sprints. The retrospective fosters continuous improvement and helps the team optimize their development practices. Incremental Delivery: The Agile model emphasizes delivering working software at the end of each sprint. This allows stakeholders to see tangible progress, provide feedback, and make adjustments to the product direction as needed. Each sprint adds new functionality or existing features, building upon the previous iterations. Iterative Development: The Agile model promotes an iterative approach, where the development process repeats with each sprint. The team continuously refines and reprioritizes the product backlog, selects new items for implementation in the upcoming sprint, and proceeds with planning, execution, review, and retrospective in an iterative fashion. ➢ Agile model is a method of focusing on continuous development and testing throughout a project's software development life cycle. The Agile model's software development and testing operations are substantially different from the Waterfall model's. ➢ Scrum is an agile development and management methodology that focuses on managing work in a team development setting. Scrum is
derived from actions that take place in a cycle. Scrum emphasizes the importance of empowering development teams and working in small groups (7-9 people).
- The results are difficult to predict because the documentation is sparse, if not non-existent, which makes it difficult to create needs and specifications.
- When debugging Agile Testing, it's easy to make mistakes.
- Agile Testing has numerous challenges while managing complex projects. Define Project Vision and Objectives: Clearly articulate the project vision and objectives. Understand the needs and expectations of stakeholders and align them with the project goals. This serves as the guiding principle throughout the Agile development process. Form an Agile Team: Assemble a cross-functional Agile team consists of developers, testers, designers, and other necessary roles. Ensure the team members have the required skills and expertise to collectively deliver the project. Create a Product Backlog: Collaborate with stakeholders to create a product backlog, which is a prioritized list of features, enhancements, and tasks. The backlog represents the work to be done and serves as a single source of truth for the team. Sprint Planning: Conduct sprint planning meetings to select a set of items from the product backlog for implementation in the upcoming sprint. The team collaborates to determine the sprint goals, define the tasks required to complete the selected items, and estimate the effort involved. Sprint Execution: During the sprint, the team works on implementing the selected items, following the Agile principles and practices. Break down the work into smaller tasks, and let team members self-organize to determine how to best accomplish their assigned tasks. Encourage collaboration, communication, and transparency within the team. Daily Stand-up Meetings: Conduct daily stand-up meetings to provide updates on progress, discuss any challenges or roadblocks, and plan the day's activities. Each team member shares what they worked on since the last stand-up, what they plan to work on next, and any impediments they are facing. Keep the meeting concise and time-boxed to ensure everyone is aligned. Continuous Integration and Testing: Practice continuous integration, where code changes are frequently integrated into a shared repository. Automate testing as much as possible to identify and fix issues early. Conduct regular code reviews and ensure the software remains stable and functional throughout the development iterations. Sprint Review: At the end of each sprint, conduct a sprint review meeting to demonstrate the completed work to stakeholders. Collect feedback, address any questions or concerns, and incorporate the feedback into the product backlog. This ensures that the software aligns with stakeholder expectations and requirements. Sprint Retrospective: Hold a sprint retrospective meeting to reflect on the team's performance during the sprint. Discuss what went well, what can be improved, and identify action items for process enhancements in future sprints. Continuously adapt and improve the Agile practices based on the team's learnings.
Repeat Sprints: Continue with subsequent sprints, repeating the cycle of backlog refinement, sprint planning, execution, review, and retrospective. Continuously adapt and prioritize the backlog based on changing requirements and customer feedback. Chapter 2: Explain how risk is managed in the Spiral lifecycle model
I. What is risk in Spiral Model?
➢ Any adversity that could jeopardize the effective execution of a software project is referred to as a risk. The spiral model's most essential aspect is how it handles unforeseen hazards once the project has begun. The development of a prototype makes such risk resolutions easier.
II. Manage risk in Spiral lifecycle model:
The Spiral model is an iterative software development process model that combines elements of both waterfall and iterative development approaches. It emphasizes risk management and incorporates the iterative nature of prototyping to ensure that potential risks are identified and managed throughout the project. However, like any software development model, the Spiral model has its own set of risks. Here are some common risks associated with the Spiral model and how it can help manage them:
- Requirement volatility: Requirements can change throughout the project lifecycle, leading to scope creep and project delays. The Spiral model addresses this risk by allowing for iterative development cycles, where requirements can be refined and modified based on feedback from users and stakeholders. This helps manage requirement volatility and allows for better alignment with evolving needs.
- Increased project complexity: The Spiral model can lead to increased project complexity due to the need for risk analysis and mitigation in each iteration. Managing this risk requires a strong emphasis on risk identification, assessment, and mitigation strategies. The model encourages the identification and analysis of risks early on, administering that appropriate measures are taken to address them in subsequent iterations.
- Resource allocation: The Spiral model may require additional resources, such as skilled personnel, time, and budget, to address risks and accommodate iterative development. Effective risk management includes proper resource allocation to tackle identified risks. It is essential to allocate resources for risk analysis, prototyping, testing, and addressing potential changes in requirements.
- Limited user involvement: Inadequate user involvement can lead to misalignment of project goals and user expectations. The Spiral model promotes user involvement through regular feedback and during each iteration. By involving users early and developing continuously, the model helps in managing the risk of a product that does not meet user needs or expectations.
"operationally useful and robust enough to serve as a low-risk base for future product evolution," the risk-driven steps after that would be an evolving series of evolutionary prototypes moving toward the right, with the option of writing specifications addressed but not exercised. This brings us to Quadrant 3. ➢ Quadrant 3: Develop, Verify, Next-Level Product If it is determined that prior prototyping efforts have resolved the COIs/CTIs, next-level product development and verification activities are carried out. As a result, the basic "waterfall" technique may be used—that is, the next system or product iteration's concept of operations, design, development, integration, and testing. In some cases, gradual development methodologies may be appropriate. ➢ Quadrant 4: Plan Next Phases The necessity for extensive technical planning and multidisciplinary reviews at important staging or control points is a feature of the spiral development model that is shared by all models. Each cycle of the model concludes with a technical review that evaluates the current state, progress, maturity, merits, and risk of development efforts; resolves critical operational and/or technical issues (COIs/CTIs); and reviews plans and identifies COIs/CTIs to be resolved for the next iteration of the spiral. Lower level spirals that follow the same quadrant patterns and decision considerations may be used in subsequent spiral implementations. Other Software/System Development Life Cycles are also available.
Figure 5: Manage risks in spiral model Chapter 3: Explain the purpose of a feasibility report
I. What is Feasibility report?
➢ The practical extent to which a project may be completed effectively is defined as feasibility. To determine feasibility, a feasibility study is conducted, which determines whether the solution proposed to meet the requirements is practicable and implementable in software.
