Download Spiral Lifecycle Model: Risk Management and Software Development and more Exercises Software Development in PDF only on Docsity!
ASSIGNMENT 01 FRONT SHEET
Qualification BTEC Level 5 HND Diploma in Computing Unit number and title Unit 0 9: Software Development Life Cycle Submission date 5 th^ April,2022 Date Received 1st submission 5 th^ April, Re-submission Date Date Received 2nd submission Student Name Nguyen Duc Quang Student ID GCH Class GCH0908 Assessor name Michael Omar Student 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 P 1 P 2 P 3 P4 M 1 M 2 D1 D 2
❒ Summative Feedback: ❒ Resubmission Feedback:
Grade: Assessor Signature: Date: Internal Verifier’s Comments:
Table of contents TABLE OF CONTENTS .......................................................................................................................................................................... 4 LIST OF TABLES ................................................................................................................................................................................... 6 LIST OF FIGURES ................................................................................................................................................................................. 6 INTRODUCTION ............................................................................................................................................................................................... 7 P1 DESCRIBE TWO ITERATIVE AND TWO SEQUENTIAL SOFTWARE LIFECYCLE MODELS. 1.DESCRIBE THE FOLLOWING SDLC Describe general SDLC models.: TWO ITERATIVE SOFTWARE LIFE CIRCLE MODEL WATERFALL ...................................................................................................................................................................................................... 7 V-MODEL .......................................................................................................................................................................................................... 10 TWO SEQUENTIAL SOFTWARE LIFE CIRCLE MODEL SCRUM.............................................................................................................................................................................................................. 15 SPIRAL............................................................................................................................................................................................................... 19 1.1DISCUSS THE SUITABILITY OF EACH OF THE SDLC MODELS FOR THE PROJECT Discuss the suitability of the model ................................................................................................................................................................. 20
P2 EXPLAIN HOW RISK IS MANAGED IN THE SPIRAL LIFECYCLE MODEL.
1HOW RISK IS MANAGED IN THE SPIRAL LIFECYCLE ........................................................................................................................................ 24
P3 EXPLAIN THE PURPOSE OF A FEASIBILITY REPORT.
1.DISCUSS THE PURPOSE OF CONDUCTING A FEASIBILITY STUDY FOR THE TUNE SOURCE PROJECT. ........................................................... 27
2.DISCUSS HOW THE THREE FEASIBILITY CRITERIA
- Technical feasibility:........................................................................................................................................................................................ 28
- Economic feasibility (NPV, Cashflow, Break-Even Point) ROI ......................................................................................................................... 29
- Organizational feasibility ................................................................................................................................................................................ 29 HOW THE THREE FEASIBILITIES ARE APPLIED TO THE TUNE SOURCE PROJECT .............................................................................................. 30 3.DISCUSS WHETHER THE PROJECT IS FEASIBLE OR NOT. ............................................................................................................................... 30 4.DISCUSS ALTERNATIVE TECHNICAL SOLUTIONS USING THE ALTERNATIVE MATRIX ................................................................................... 31 5.EXPLAIN THE COMPONENTS OF A FEASIBILITY REPORT. .............................................................................................................................. 32 P4 DESCRIBE HOW TECHNICAL SOLUTIONS CAN BE COMPARED. ASSESS THE IMPACT OF EACH FEASIBILITY CRITERION ON A SOFTWARE INVESTIGATION............................................................................. 38 DISCUSSION AND REPRESENT AS FEASIBILITY ALTERNATIVES MATRIX FOR TUNE SOURCE PROJECT ............................................................ 44 REFERENCES ..................................................................................................................................................................................................... 45
Introduction Be a project manager of ABC company, our company is collaborating with Tune Source to complete the project. I argue that there are various SDLC models that our cooperator(Tune Source) can use for its. I will describe and analyze detaily about models that is useful, effective and suitable for Tune Source. Then, I will show list of risk that can threat to Tune Source and offer an approach to manage risks.
P1. Describe two iterative and two sequential software lifecycle models.
I. Describe the following SDLC models
1. Waterfall Model:
The Waterfall Model was the first Process Model to be introduced. It is also referred to as a linearsequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases. The Waterfall model is the earliest SDLC approach that was used for software development. The Waterfall Model illustrates the software development process in a linear sequential flow. This means that any phase in the development process begins only if the previous phase is complete. In this waterfall model, the phases do not overlap. Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate phases. In this Waterfall model, typically, the outcome of one phase acts as the input for the next phase sequentially.
The sequential phases in Waterfall model are :
- Requirement Gathering and analysis − All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification document.
- System Design − The requirement specifications from first phase are studied in this phase and the system design is prepared. This system design helps in specifying hardware and system requirements and helps in defining the overall system architecture.
- Implementation − With inputs from the system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality, which is referred to as Unit Testing.
It also has many advantages and disadvantages for users: ADVANTAGES DISADVANTAGES Simple to use and understand The software is ready only after the last stage is over Management simplicity thanks to its rigidity: every phase has a defined result and process review High risks and uncertainty Development stages go one by one Not the best choice for complex and objectoriented projects Easy to determine the key points in the development cycle The progress of the stage is hard to measure while it is still in the development Easy to classify and prioritze tasks Integration is done at the end, which does not give the option of indentifying the problem in advance Perfect for the small or mid-sized projects where requirements are clear and not equivocal Inapproriate for the long-term projects McConnell, Steve (1996), McConnell, Steve (2004).
2. V-Model:
The V-model is an SDLC model where execution of processes happens in a sequential manner in a V-shape. It is also known as Verification and Validation model. The V-Model is an extension of the waterfall model and is based on the 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 the next phase starts only after completion of the previous phase.
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. The following illustration depicts the different phases in a V-Model of the SDLC. 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
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.
- 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.
- 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.
The usage for V-Model: 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. 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. Pros and Cos of V-Model: ADVANTAGES DISADVANTAGES This is a highly-disciplined model and Phases are completed one at a time. High risk and uncertainty. Works well for smaller projects where requirements are very well understood. Not a good model for complex and objectoriented projects Simple and easy to understand and use. Poor model for long and ongoing projects. Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process. Not suitable for the projects where requirements are at a moderate to high risk of changing.
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 and monitoring the 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. The following illustration is a representation of the Spiral Model, listing the activities in each phase.
Development can be divided into smaller parts and the risky parts can be developed earlier which helps in better risk management. Spiral may go on indefinitely. (none) Large number of intermediate stages requires excessive documentation. Boehm, B (August 1986).
4. Scrum Model:
Scrum is an agile software development methodology based on iterative and growth mechanics. Scrum is designed to support the development, delivery, and improvement of complex products. With Scrum, the product is built in a series of iterative processes, called a sprint. Thereby, you can continuously improve the product, technique, team (team) and work environment. That way you can provide value to your customers throughout the development process. The three core principles are: Transparency: Artifacts (artifacts or documents) must be transparent to stakeholders. Inspection: you need to check regularly, regularly the artifact and work progress. Adaptation: if a serious problem occurs, the process or artifacts must be adjusted. All work and values of Scrum are expressed through three artifacts (meaning artifacts - things created to serve the Scrum model). Through these artifacts, you can maximize transparency as well as create opportunities for inspection and adaptation.
- Product backlog: an ordered and evolving list of what is needed to improve the product. In addition, the product backlog includes the long-term product goals that the Scrum team needs to meet. Constrained by product goal: a description of the future state of the product.
- Sprint backlog: includes the sprint goal, product backlog items for the sprint, and how to create the growth package. In other words, it includes the necessary items and the reasons and ways to achieve them. Constrained by sprint goal (sprint goal): the only goal that needs to be achieved after the sprint.
- Increment: an aggregate of product backlog items completed up to the current sprint. At the end of each sprint, new and “completed” increments are added to this aggregator. Constrained by definition of done: the formal definition of the state "done". Pros and Cons of its: ADVANTAGES DISADVANTAGES Improve software quality effectively. Management is more complex. Shorten software release time, bring fast and quality product usage experiences to customers. Process is complex Promote teamwork, optimize the efficiency and efforts of the development team. Not suitable for small or low risk projects and could be expensive for small projects. Control the progress of the project well, continuously improve and limit unwanted risks when building products. none Increase return on investment (ROI). none
