Download SDLC assignment 1 M pass and more Schemes and Mind Maps Software Development in PDF only on Docsity!
ASSIGNMENT 1 FRONT SHEET
Qualification BTEC Level 5 HND Diploma in Computing Unit number and title Unit^7 :^ Software Development Life Cycle Submission date Date Received 1st submission Re-submission Date Date Received 2nd submission Student Name TRAN QUOC ANH Student ID BH Class SE06206 Assessor name DINH VAN DONG 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 QUANH Grading grid P1 P2 P3 P4 M1 M2 D1 D
r Summative Feedback: Resubmission Feedback:
Grade: Assessor Signature: Date: Internal Verifier’s Comments: Signature & Date:
- I. INTRODUCTION
- II. BODY
- A. SDLC models
- Waterfall Models:
- V-model
- Prototyping model..................................................................................................................................
- Scrum model...........................................................................................................................................
- Chosen Framework for the project
- Suitability of each SDLC models
- The merits of applying waterfall model to a large software development project
- Identify risks and discuss an approach to manage risk
- B. Feasibility study
- The purpose of conducting a feasibility study for the project
- feasible of the project 2. The application of feasibility criteria (technical, economic, organization) to the project and the
- Tune Source project 3. Components of a feasibility report explanation; and economic, organizational feasibility study on
- representation of a feasibility alternative matrix for Tune Source project 4. Assess the impact of each feasibility criterion on a software investigation and the discussion and
- III. REFERENCE
- Figure 1: Waterfall model Table of figure
- Figure 2: V-Model.......................................................................................................................................................
- Figure 3: Prototyping model
- Figure 4: Scrum suitability
- Figure 5: waterfall suitability
- Figure 6: V model suitability
- Figure 7: prototyping model suitability....................................................................................................................
- Figure 8: Scrum suitability
- Figure 9: Overall suitability rating table
- Figure 10: Suitability rating
- Figure 11:Risk assessment example
- Figure 12: Risk Assessment Matrix
- Figure 13: NPV
- Figure 14: ROI equation
- Figure 15: Break-Even equation
- Figure 16: Technology alternative matrix
I. INTRODUCTION The software development life cycle theory will be discussed in this report along with the methodology that will be used with the chosen model. This assignment will be considered a presentation to the board of directors of Tune Source for the future development of the program known as TUNEY, as the primary scenario has proven. II. BODY
A. SDLC models
- Waterfall Models: a) Definition: The first model to be developed is the linear-sequential life cycle model, or waterfall model. It adheres to stringent protocol guidelines. Before going on to the next stage of this approach, the results of these phases are frequently presented to the management and stakeholders for approval. The project proceeds in a way akin to that of a waterfall as it moves forward. Consequently, it is known as a waterfall development model. There is little chance of going back to the earlier stages of the project, even though it is feasible. This is because there are obstacles that might impact the project's economy, development timeline, and other factors. Changes are generally not encouraged since the waterfall development paradigm necessitates specifying all needs up front before beginning work. This is also the main drawback of a waterfall development model, though, as it limits the project's ability to change. If significant changes are needed, the project may come to an abrupt stop, necessitating the costly reformulation of the requirements outlined in all earlier phases. These stages are closely tied to one another and each must be completed before going on to the next. This approach should be used for substantial projects with well defined scope and appropriate needs.
- V-model a) Definition A variation on the waterfall paradigm, the V-Model development places a greater emphasis on testing. Following the completion of the coding, the development team must go through the testing phases in accordance with the relevant phases for establishing requirements and implementation. Among the tests are:
- Unit testing
- Integration testing
- System testing
- Acceptance testing The core idea of this development approach is testing according to stages, which include requirements and defined components. Every testing stage is connected to a specific area of the analysis or design process, guaranteeing the efficacy of test runs as well as the product's efficiency and quality. With a focus on testing early in the development cycle to assist tester beware of the final product, this development methodology is straightforward and simple to grasp. It is not appropriate for the dynamic business model and still has some of the waterfall model's drawbacks. Figure 2 : V-Model
b) Advantages
- Has great discipline
- Able to produce high quality product when the project is over
- Simple to understand
- Project management are easier to process c) Disadvantages
- High risks and uncertainty
- Not suitable for project that has high chance of changing requirements
- Does not support iteration of phases
- Prototyping model a) Definition A software prototype will be made using this model. A prototype is an unfinished form of the project that shows the main idea of how it works. After the customer has had a chance to review the prototype, they will determine whether or not to commit to the design, or they will look for another that better fits their vision. Furthermore, by rearranging and improvising the project in response to customer feedback, this model will carry out the second prototype. This cycle will continue until the product satisfies user expectations. When end consumers haven't yet figured out what they need, prototyping is ideal. The implementation of this paradigm can be exceedingly expensive and time-consuming. This model is applicable to project that has unclear definition of the project, uncertain requirements, and long- term project. Figure 3 : Prototyping model
- Scrum heavily relies on constant customers feedback, therefore the quality of the product will be improved quickly. c) Disadvantages
- Sprints cannot be changed
- It is not a fully described model, if there are changes; self provides details are required
- Hard to plan. Structure and organize without a clear definition.
- Daily meeting and reviews require resources.
- Chosen Framework for the project With unclear user requirements With unfamiliar technology That are complex That are reliable With short time schedule With schedule visibility Scrum Excellent Poor Poor Good Excellent Excellent Figure 4 : Scrum suitability Discussion: The requirements given by Tune Source are as follow
- Able to run on two platform: Instore-kiosks and on website
- Basic CRUD functions
- Users can freely listens to music available
- Make in-app purchase of individual downloads with fixed price
- Customer subscriptions
- Music gift cards available for purchase
- To be finished the project in a short time
- The product must have high quality Consequently, even if the organization has provided precise requirements, using an Agile development methodology is the best option because the project has to be completed quickly. Therefore, selecting a development technique such as the V-model or waterfall and prototyping can be highly expensive and time-consuming. Since Tune Source's IT department is already familiar with the fundamentals of internet technology, extended contact with management and stakeholders may go more smoothly. In conclusion, the project will choose Scrum as its’ main development methodology.
After a lengthy consideration, the chosen framework will be Scrum:
- Scrum is an iteration of Agile Development. Therefore, it is very adaptive.
- Scrum is efficient and can finish the project quickly. Furthermore, it can also produce high quality product and that can satisfy the end user’s requirements.
- Suitability of each SDLC models a) Waterfall model discussion With unclear user requirements With unfamiliar technology That are complex That are reliable With short time schedule With schedule visibility Waterfall Poor Poor Good Good Poor Poor Figure 5 : waterfall suitability This project is best suited for waterfall. The project has a clear definition, the end users have provided documentation and requirements, and the development team can manage the process with appropriate documentation of each phase. However, an agile development technique would be a preferable option given the project's requirement to be completed swiftly and competitively. Although waterfall is straightforward to use and easy to comprehend, it is not suitable for projects that must be completed as soon as possible due to its numerous rigidity features, which can produce bottleneck problems for organizations since it is not flexible enough to meet changing requirements. Suitability for the Tune Source’s project rating: Average. b) V-Model discussion With unclear user requirements With unfamiliar technology That are complex That are reliable With short time schedule With schedule visibility V-Model Poor Poor Good Excellent Poor Poor Figure 6 : V model suitability A variation of the waterfall model is the V-Model. V-Model will begin the testing phases early rather than focusing on them later in the stages, giving the development team and end users a better understanding of the final product. Similar to Waterfall, V-Model performs well in projects with well-defined specifications, such as the
release date but also quality. The development staff at Tune Source has experience with internet technology, so there is always access to feedback and end users and investors can understand how the project is progressing. Suitability for the Tune Source’s project rating: Most suitable.
e) Suitability ratings Usefulness in developing systems Waterfall V-Model System Prototyping Scrum With unclear user requirements Poor Poor Excellent Excellent With unfamiliar technology Poor Poor Poor Poor That are complex. Good Good Poor Poor That are reliable. Good Excellent Poor Good With short time schedule Poor Poor Excellent Excellent With schedule visibility Poor Poor Excellent Excellent Figure 9 : Overall suitability rating table Most suitable Moderately Least suitable Waterfall X V-Model X Prototyping X Scrum X Figure 10 : Suitability rating
(2) Risk Management process Project teams typically produce a risk assessment, or a document that records possible hazards and evaluates the risk's likelihood and impact. There is a paragraph or two that describes possible approaches to addressing the danger. There are several choices: By addressing its underlying source, a danger might be made aware of, averted, or even completely removed. Consider a scenario where a project team intends to adopt new technology but has recognized a risk due to a member's lack of technical expertise. They think that because there is a steep learning curve, jobs can take substantially longer to complete. One strategy would be to locate the time and resources required to give the team the necessary training by addressing the risk's primary underlying cause—the team members' lack of technical competence. Many project managers are cognizant of potential risks and have even categorized them according to significance and intensity. Over time, as some things disappear and others appear, the list of threats will change. That being said, the best project managers work hard to keep risks from impacting the project's budget and schedule. Figure 11 :Risk assessment example
(3) Risk Assessment Matrix for Tune Source project Figure 12 : Risk Assessment Matrix
through connections.
B. Feasibility study
- The purpose of conducting a feasibility study for the project
- The feasibility study exist in order to find out if the development of a project can be done or not by presenting questions like is it possible or is it justified
- In case of the worst scenario happening, alternative options can be raised and used to ensure the safety of the company’s profit.
- The documentation of a feasibility study is incredibly helpful for the management to acknowledge of these following criteria: ◼ Is the project possible to be pulled off. ◼ Does the project benefit the intended users to ensure quality of the product. ◼ In case of needing another plan, alternative options can be considered to be applied ◼ Are there any better alternative than the chosen plan.
- Feasibility requires the support from both sides: the development team and the management team, therefore management also has to finish these following tasks: ◼ Decision on either the project should be greenlight or not. ◼ The problem must be examined in a bigger scale of business strategy.
- The application of feasibility criteria (technical, economic, organization) to the project and the feasible of the project a) Feasibility criteria (1) Technical feasibility The first step in the feasibility analysis is to evaluate the project's technical viability, or how well the IT team can design, create, and implement the system. The goal of a technical risk analysis, or technical feasibility analysis, is to determine whether or not something can be built.
There might be several risks that could jeopardize the project's successful completion. Users' and analysts' familiarity with the program is crucial. If analysts lack familiarity in the business application domain, they are more likely to misinterpret users or fail to see opportunities for improvement. In the event when users are creating a system to support a new commercial innovation, such as Microsoft introducing a new online dating service, the hazards increase dramatically. Creating new systems is always riskier than adding to existing ones, even if current systems are usually more well-known. Another key source of technical risk is familiarity with the technology. When a system will employ technology that has never been employed before in the Another key source of technical risk is familiarity with the technology. When a system will employ technology that has never been employed before. Project size is an important consideration, which may be influenced by the number of developers working on it, the amount of time needed to complete it, or the variety of features it contains. Larger projects involve greater risk because they are more challenging to manage and because there is a greater chance that some important system needs will be overlooked or misunderstood. The project's high level of system integration with other systems, which is typical of big systems, may cause issues since complexity increases when several systems need to work together. Project teams also need to consider how the new system will integrate with the company's current technological infrastructure. Rarely are systems developed in a vacuum; rather, they are developed within of businesses that already have a number of different systems in operation. New apps and technologies need to be able to work with the present environment for a number of reasons. They can have to rely on data from present systems, use the company's current communications infrastructure, or provide data that feeds into other applications. For example, if a new CRM system doesn't utilize the customer data that is already in the company's sales, marketing, and customer support systems, it won't be very useful. The technical viability of a project is not always easily assessed as, in many cases, an interpretation of the underlying conditions is necessary (e.g., the size of the project that must be reached before it loses viability). One tactic is to contrast the project under discussion with past projects that the organization has successfully executed. Speaking with seasoned IT professionals inside the organization or outside IT consultants is an additional option; they can typically ascertain whether a project is technically feasible. (2) Economic feasibility The second phase in a feasibility study is to conduct an economic feasibility analysis (sometimes termed a cost– benefit analysis). Should we create the system? is a query that this attempts to answer. The costs and benefits of the system are determined, along with their respective values. Additionally, projected cash flows are computed, and the project's financial viability is evaluated to determine its economic feasibility.
