Download Risk Management in Software Projects: A Focus on the V-Shaped Model and Feasibility Study and more Assignments Computer Science in PDF only on Docsity!
ASSIGNMENT 1 FRONT SHEET
Qualification BTEC Level 5 HND Diploma in Computing Unit number and title Unit 9 : Software Development Life Cycle Submission date 25/01/2021^ Date Received 1st submission Re-submission Date Date Received 2nd submission Student Name Vo Thanh Nhan^ Student ID GCD Class GCD0806^ Assessor name Srikanth Raju Kandukuri 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 Vo Thanh Nhan Grading grid P1 P2 P3 P4 M1 M2 D1 D 1
Summative Feedback: Resubmission Feedback:
Grade: Assessor Signature: Date: Internal Verifier’s Comments: Signature & Date:
TABLE OF CONTENTS
Figure 42: The MERN Stack development.................................................................................................... 82 Figure 43: The logo of mongoDB.................................................................................................................. 82 Figure 44: The logo of Express JS.................................................................................................................. 83 Figure 45: The logo of React JS..................................................................................................................... 83 Figure 46: The logo of node JS...................................................................................................................... 84 Figure 47: The LAMP Stack........................................................................................................................... 84 Figure 48: The logo of Linux.......................................................................................................................... 85 Figure 49: The logo of Apache...................................................................................................................... 85 Figure 50: The logo of MySQL....................................................................................................................... 86 Figure 51: The logo of PHP............................................................................................................................ 86 Figure 52: The Alternative Matrix of the Tune Source project..................................................................... 91 1 Chapter 1: PROBLEM STATEMENT
1.1 SCENARIO
Tune Source is a company headquartered in southern California. Tune Source is the brainchild of three entrepreneurs with ties to the music industry: John Margolis, Megan Taylor, and Phil Cooper. Originally, John and Phil partnered to open a number of brick-and-mortar stores in southern California specializing in hard-to-find and classic jazz, rock, country, and folk recordings. Megan soon was invited to join the partnership because of her contacts and knowledge of classical music. Figure 1 : Introducing the scenario
Tune Source quickly became known as the place to go to find rare audio recordings. Annual sales last year were $40 million with annual growth at about 3%–5% per year. Tune Source currently has a website that enables customers to search for and purchase CDs. This site was initially developed by an Internet consulting firm and is hosted by a prominent local Internet Service Provider (ISP) in Los Angeles. The IT department at Tune Source has become experienced with Internet technology as it has worked with the ISP to maintain the site. A person is a project manager of a company named ABC. His company has been hired by Tune Source to carry out a project that helps them develop a software for the requirements specified in the system request.
1.2 REPORT OBJECTIVES
Two main tasks which will be completed in the report are including: Task 1 – SDLC model
- Describing the following SDLC models: waterfall, v-model, prototyping, scrum and spiral. Choosing one that is considered being suitable for the project and giving the reason why. Discussing the suitability of each of the SDLC models for the project. For each model, specifying whether it is most, moderately or least suitable. Discussing the merits of applying the waterfall model to a large software development project.
- Identifying some risks and discussing an approach in order to manage them. Task 2 – Feasibility study
- Discussing the purpose of conducting a feasibility study for the project.
- Discussing how the three feasibility criteria (technical, economic, organizational) are applied to the project. Discussing whether the project is feasible. Discussing alternative technical solutions using the alternative matrix.
- Explainning the components of a feasibility report.
Sequential models (such as Waterfall or V-Model) rely on intensive product collection and refining periods before design and development activities can take place. Products developed using these models are intended to be completed upon release to customers. The central of the approach is the assumption that by complying with the requirements identified at the outset, the product will fulfill the requirements of the customers: Figure 2 : Sequential development 2.1.1.1 Waterfall Model The Waterfall Model illustrates the software development process in a linear sequential flow. This means that every step of the construction process can only start once the previous phase is finished. a. Design Waterfall approach was the first SDLC model to be commonly used in software engineering to ensure the success of the project. The entire process of software development is split into different stages in the "The Waterfall" approach. Usually, the result of one step in this Waterfall model serves as a sequential input for the next phase. The following figures illustrates all of various stages of the Waterfall Model.
Figure 3 : The Waterfall model The sequential phases of the Waterfall model are including: No Step Description 1 Requirement gathering and analysis All potential system requirements developed are defined at this stage and recorded in a requirement specification document. 2 System design The requirements of the first phase are analyzed at this level and the design of the system is prepared. This system design helps to determine hardware and system requirements and helps to define the overall system architecture. 3 Implementation With system design inputs, the system is first developed in small programs called units, which are implemented in the next step. Each unit is developed and tested for its functionality, which is referred to as unit testing. 4 Integration and testing All units developed during the implementation stage are integrated into the system after testing of each unit. After integration, the entire system is tested for any faults or failures. 5 Deployment of the system When the functional and non-functional testing has been carried out; the product is deployed in the customer environment or released on the market. 6 Maintenance There are some issues that arise in the client environment. Patches are released to address these problems. Some better versions are also released to improve the quality of products. Maintenance is done to deliver these changes
2.1.1.2 V-Model a. Design The V-Model is an evolution of the waterfall model which is based on the combination of the test step with each subsequent stage of development. This means that there is a specifically linked monitoring process for any single phase of the production cycle. This is a highly disciplined model and the next phase will begin only after the previous phase has been completed. The subsequent phase of testing of the project execution is scheduled in parallel under the V- Model. Thus, there are phases of verification on one side of the 'V' and phases of confirmation on the other. The figure below depicts the different phases in a V-Model of the SDLC. Figure 4 : The V-shaped model b. Verification Phases There are a number of verification phases in the V-Model, each of them is described in detail below. No Phase^ Description 1 Business requirement analysis This is the first step of the development cycle in which the specifications of the product are understood from the point of view of the customer. This process requires a thorough contact with the client in order to clarify his preferences and the exact requirements. It is a very critical activity that has to
be well-managed, since most consumers are not sure precisely what they need. Acceptance test design planning is being undertaken at this level as requirements of the business can be used as input for acceptance testing. 2 System design When the clear and detailed specifications for the product have been defined, it is time to develop the full system. The system designed would provide the understanding and detail of the full hardware and communication setup for the product under production. The system test plan shall be built on the basis of the system architecture. Making this at an early stage allows more time for the real execution of the test later. 3 Architectural design In this phase, architectural specifications are understood and designed. Usually more than one technical approach is proposed and the final decision is taken on the basis of technical and financial feasibility. The system design is further broken down into different functionality modules. This is also known as a high-level design (HLD). Data transfer and communication between internal modules and other systems is fully understood and defined at this stage. With this information, integration tests can be designed and documented at this point. 4 Module design The detailed internal design for all system modules, referred to as the Low-Level Design (LLD), is specified at this stage. It is important that the design is consistent with other modules in the system architecture and with other external systems. Unit testing is an essential part of any development process and helps to eliminate the maximum errors and faults at a very early stage. During this stage, these unit tests can be designed on the basis of internal module designs. Table 3 : Verification phases in the V-shaped model c. Coding Phase The actual coding of the system modules designed during the design phase is taken up in the coding phase. The most appropriate programming language is decided based on the system and architectural requirements.
- The definition of the product is unchanged.
- Technology is not dynamic and the project team is well-understood.
- There are no ambiguity or unclear requirements.
- The project is a short one. f. Advantages and disadvantages Advantages Disadvantages Simple and easy-to-use. Each step has its own particular deliverables. Better probability of success over the waterfall model due to the early production of test plans during the life cycle. Fits best when specifications are readily understood. Verification and evaluation at the early stage of the development of the product. Really rigid, like the Waterfall model. Scope modification is difficult and costly. The software is created during the implementation phase, so that no early prototypes of the software are made. The model would not offer a straightforward path to the issues encountered during the testing phases. In addition to a detailed schedule, it takes more effort. Table 5 : Advantages and disadvantages of the V-shaped model 2.1.2 Iterative software lifecycle models The iterative model is known as a specific implementation of the Software Development Life Cycle (SDLC) based on original, simplified implementation, which can eventually become more complicated and more detailed until the final system is complete. When describing the iterative method, the concept of incremental development can also often be used liberally and interchangeably, which defines the incremental changes made during the design and implementation of any new iteration. The basic idea behind this method is for creating a system by repeated cycles (iterative) and in smaller parts at a time (incremental). The following figure is an illustration of the Iterative and Incremental model.
Figure 5 : The Iterative and Incremental model The techniques encourage regular feedback from customers and quick response to feedback as well; refine ideas and re-design and development activities with a perspective for delivering products that better reflect what customers want: Figure 6 : Iterative development 2.1.2.1 Spiral Model a. Design The spiral model combines the concept of iterative development with the systematic, controlled features of the model of the waterfall. This spiral model is a combination of the iterative process model and the sequential linear development model (the waterfall model) with a very strong emphasis on risk analysis. It requires incremental product releases or incremental refinement through each iteration around the spiral.
design details, a working model of the software called build is produced with a version number. These builds will be submitted to the customer for feedback. 4 Evaluation and risk analysis Risk analysis includes the identification, estimation and monitoring of technological viability and management risks, such as scheduling and cost overruns. After evaluating the build, the customer evaluates the program and gives feedback at the completion of the first iteration. Table 6 : Stages of the Spiral model The following figure is a representation of the spiral model, listing the activities of each step.
Figure 8 : The Spiral model with listing the activities of each step Based on the review of the customer, the software development process begins with the next implementation and takes a sequential approach to applying the feedback suggested by the customer. The process of repetition around the spiral continues throughout the life of the software. b. Application The spiral model is commonly used in the software industry since it is in line with the normal growth phase of every product, i.e., mature learning, which entails a low risk for both consumers and development firms.
- The following points illustrate the typical uses of the spiral model
- Whenever there is a budget constraint and risk evaluation is critical.
- For medium to high-risk projects.
- Long-term commitment to the project due to future changes to economic goals as requirements change over time.
- Customer is not aware about their specifications, as is generally the case.
