Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Software Development Life Cycle (1633) (Pass), Assignments of Computer Science

Software Development Life Cycle (Pass)

Typology: Assignments

2022/2023

Uploaded on 06/07/2023

tri-duong
tri-duong 🇻🇳

5

(1)

1 document

1 / 17

Toggle sidebar

Partial preview of the text

Download Software Development Life Cycle (1633) (Pass) and more Assignments Computer Science in PDF only on Docsity! 1 ASSIGNMENT 01 FRONT SHEET Qualification BTEC Level 5 HND Diploma in Computing Unit number and title Unit 09: Software Development Life Cycle Submission date 15/02/2023 Date Received 1st submission 15/02/2023 Re-submission Date 19/02/2023 Date Received 2nd submission 19/02/2023 Student Name Duong Quang Tri Student ID GCH210221 Class GCH1101 Assessor name Do Quoc Binh 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 Tri Grading grid P1 P2 P3 P4 M1 M2 D1 D2 ❒ Summative Feedback: ❒ Resubmission Feedback: Grade: Assessor Signature: Date: Internal Verifier’s Comments: Signature & Date: 2 Table of Contents I. Introduction .................................................................................................................................................................................................................... 3 II. Task 1 (Dennis et al., Project selection & management 2015) ...................................................................................................................................... 3 II.1 SDLC Models: ............................................................................................................................................................................................................. 3 A. Waterfall Models: ................................................................................................................................................................................................ 3 B. V-model ............................................................................................................................................................................................................... 4 C. Prototyping model................................................................................................................................................................................................ 5 D. Scrum model (Digite, 2019) ................................................................................................................................................................................ 5 E. Chosen Framework for the project: Scrum. ............................................................................................................................................................ 6 F. Suitability of each SDLC models ............................................................................................................................................................................ 7 G. The merits of applying waterfall model to a large software development project .............................................................................................. 8 II.2 Identify risks and discuss an approach to manage risk. (Dennis et al., The System Analysis and Information System Development 2015) .............. 9 A. Risk management process. ................................................................................................................................................................................... 9 III. Task 2 Feasibility study (Dennis et al., Project selection & management 2020)......................................................................................................... 11 Task 2. 1: The purpose of conducting a feasibility study for the project ......................................................................................................................... 11 Task 2. 2: The application of feasibility criteria (technical, economic, organization) to the project and the feasible of the project. ............................. 11 A. Feasibility criteria .............................................................................................................................................................................................. 11 B. Project feasibility discussion ............................................................................................................................................................................. 13 C. Alternative technical solutions using alternative matrix. ................................................................................................................................... 14 Task 2.3 Components of a feasibility report explanation; and economic, organizational feasibility study on Tune Source project. ............................. 14 A. Components of a feasibility study explanation. ................................................................................................................................................. 14 B. Economic feasibility discussion on Tune Source project .................................................................................................................................. 15 C. Organizational feasibility study on Tune Source project ................................................................................................................................... 16 Task 2.4 Assess the impact of each feasibility criterion on a software investigation and the discussion and representation of a feasibility alternative matrix for Tune Source project. ........................................................................................................................................................................................................ 16 A. The impact of each feasibility criterion on a software investigation. (Simplilearn, 2023)................................................................................ 16 B. Feasibility alternative matrix for Tune Source project. ..................................................................................................................................... 16 Reference: ........................................................................................................................................................................................................................ 17 Figures References: .............................................................................................................................................................................................................. 17 (Figure 1 Waterfall Model) .................................................................................................................................................................................................... 3 (Figure 2 V-model) ................................................................................................................................................................................................................ 4 (Figure 3: Prototyping model) ................................................................................................................................................................................................ 5 (Figure 4: Scrum suitability) .................................................................................................................................................................................................. 6 (Figure 5: Waterfall suitability) ............................................................................................................................................................................................. 7 (Figure 6: V-Model suitability) .............................................................................................................................................................................................. 7 (Figure 7: Prototyping suitability) .......................................................................................................................................................................................... 7 (Figure 8:Scrum suitability) ................................................................................................................................................................................................... 8 (Figure 9: Overall suitability rating table) ............................................................................................................................................................................. 8 (Figure 10: Suitability rating)................................................................................................................................................................................................. 8 (Figure 11: Risk assessment example) ................................................................................................................................................................................... 9 (Figure 12: Risk Assessment Matrix) .................................................................................................................................................................................. 10 (Figure 13: NPV) ................................................................................................................................................................................................................. 13 (Figure 14: ROI equation) .................................................................................................................................................................................................... 13 (Figure 15: Break-Even equation) ........................................................................................................................................................................................ 13 (Figure 16: Technology alternative matrix) ......................................................................................................................................................................... 14 5 - Able to produce high quality product when the project is over. - Simple to understand. - Project management are easier to process. B.3 Disadvantages: - High risks and uncertainty - Not suitable for project that has high chance of changing requirements. - Does not support iteration of phases. C. Prototyping model C.1 Definition: In this model a prototype of the software will be created. A prototype is a crude version of the project where it has the general view of the operation. This protype will then be provide for the customer to evaluate and then to whether decide to commit on the design or to find a new design that suits the customer’s ideal. In addition, this model will continue to implement the second prototype by rearrange and improvise the project based on the user’s feedback, the cycle continues until the product has satisfied the user’s requirements. Prototyping works great when the end users have not figured out their requirements yet. This model often cost a large amount of time and are very costly to implement. This model is applicable to project that has unclear definition of the project, uncertain requirements, and long-term project. (Figure 3: Prototyping model) C.2 Advantages: - Reducing risks of incorrect user’s requirements - Reliable when the requirements have high risk of changing. - Visible project aid management - Support early product marketing. - Low maintenance cost C.3 Disadvantages: - An unstable prototype often ends up as the final product. - Require extensive customer’s collaboration. - The time scope is uncertain. - Expensive and time consuming D. Scrum model (Digite, 2019) D.1 Definition: Sprints, which typically last between two and four weeks and are used for feedback and reflection, are temporary blocks that are short and periodic that make up the Scrum process. Each Sprint is a separate entity, delivering a finished product or a version thereof that must be able to be provided to the client with the least amount of work whenever necessary. 6 A list of the project plan's objectives and requirements serves as the process's starting point. The project's customer prioritizes these goals while balancing their worth and cost; as a result, the number of iterations and subsequent delivery are decided. On the one hand, the market demands high-quality products delivered quickly and affordably. To meet these demands, a company must be very agile and flexible in the product development process. This allows for quick development cycles that can satisfy customer demand without compromising the quality of the final product. It is a very simple practice to use, and because of the rapid outcomes it produces, it is quite well-liked. Scrum is not suitable for projects that have unclear definition. D.2 Advantages: - Fast and money efficient. - Customer satisfaction is important. - Scrum is adaptive. - Scrum heavily relies on constant customers feedback, therefore the quality of the product will be improved quickly. D.3 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. E. Chosen Framework for the project: Scrum. 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. Therefore, choosing an Agile development Methodology is the best choice because of, despite the company has given clear requirements but the project needed to be finished in a short period of time. So, choosing development methodology like waterfall or V-model and prototyping can be very costly and time consuming. Since, the IT department of Tune Source have already familiar with basic internet technologies, extensive communication with the stakeholders and management can be ran smoothly. In conclusion, the project will choose Scrum as its’ main development methodology. 7 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. F. Suitability of each SDLC models F.1 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) Waterfall is suitable for this project. The end users has provide documentations and requirements, the project has clear definition and can help the development team to manage the workflow with proper documentation of each phases. However, since the project requires to be competitively and need to be finished quickly, an Agile Development methodology would be a better choice. Waterfall is easy to understand and simple to work but it does not work well with project that needs to be release as quick as possible since it has many rigidity properties that can make bottle neck challenges for businesses because it is not adaptive to changing requirements. Suitability for the Tune Source’s project rating: Average. F.2 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) The V-Model is an iteration of the waterfall model. Instead of emphasizing on the testing phase later in the stages, V-Model will start the testing phases earlier, making the development team and end users to have the better grasp of the end product. Just like Waterfall, V-Model works well with project that has clear definition and requirements like Tune Source’s Project. However, it is still too time consuming to be able to satisfy Tune Source’s requirement for an early release. V-Model also has problems with adaptability. Suitability for the Tune Source’s project rating: Average. F.3 Prototyping model discussion With unclear user requirements With unfamiliar technology That are complex That are reliable With short time schedule With schedule visibility System prototyping Excellent Poor Poor Poor Excellent Excellent (Figure 7: Prototyping suitability) Prototyping is not a great choice for this project because of the definition and the requirements have been fully given. Prototype needs extensive feedbacks from both the end users and the stockholders. However, if the project was not given enough time, the project may end up to be release as one of the prototype, a barren version of the full application. It is very risky, costly and time consuming. Suitability for the Tune Source’s project rating: Least suitable. 10 Most project managers are aware of possible hazards and even rank them in order of relevance and degree. The list of dangers will evolve over time as some items are dropped and others emerge. Nonetheless, the greatest project managers make a concerted effort to prevent risks from having an influence on the project's budget and schedule. A.3 Risk Assessment Matrix for Tune Source project. (Figure 12: Risk Assessment Matrix) Risk Risk Level Probability of risk happening Risk Mitigation Server not accessible High Most likely - Prepare backup servers. - Schedule maintenance and set up monitor actions. New IDEs and compiler Low Most Likely - Staff training - Hiring employee that are skilled in the required fields. - Losing source code Moderate Not likely - Document and keeping another copy of the source code - Improve security through connections. 11 - Head programmer not available Moderate Possible - Hiring high level personnels. - Ensuring benefits for present high level personnels. - Infrastructure broken down High Not Likely - Perform regular maintenance and supervision. - Increasing security of the infrastructure. - Buy backups of replaceable key components III. Task 2 Feasibility study (Dennis et al., Project selection & management 2020) Task 2. 1: 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: o Is the project possible to be pulled off. o Does the project benefit the intended users to ensure quality of the product. o In case of needing another plan, alternative options can be considered to be applied. o 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: o Decision on either the project should be greenlight or not. o The problem must be examined in a bigger scale of business strategy. Task 2. 2: The application of feasibility criteria (technical, economic, organization) to the project and the feasible of the project. A. Feasibility criteria A.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. The success of the project's completion might be threatened by several dangers. The application's familiarity with users and analysts comes first. Analysts are more likely to misunderstand users or overlook chances for improvement if they are inexperienced with the business application area. When developing a system to support a new business innovation (like Microsoft launching a new Internet dating service), if users are developing a system to support a 12 new business innovation, the risks rise significantly. While existing systems are typically better known, developing new systems is generally riskier than adding on to them. 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 in the Whether it is determined by the number of people on the development team, the time required to finish the project, or the quantity of different features in the system, project size is a crucial factor. Since they are more difficult to manage and because there is a higher likelihood that some crucial system requirements will be missed or misinterpreted, larger projects carry more risk. Problems may arise due to the project's high degree of system integration with other systems (which is characteristic of large systems), since complexity rises when several systems must cooperate. Project teams must also think about how the new system will work with the existing technology in the company. Systems are rarely created in a vacuum; instead, they are created inside organizations that already have a variety of systems in place. For a variety of reasons, new applications and technologies must be able to interact with the current environment. They may need to utilize the company's current communications infrastructure, rely on data from existing systems, or generate data that feeds into other applications. For instance, a new CRM system is of limited utility if it does not make use of the customer information already present in the organization's sales, marketing, and customer service systems. The evaluation of a project's technical viability is not always straightforward since, in many situations, some interpretation of the underlying circumstances is required (for example, how big a project has to get before it loses viability). Comparing the project under consideration with other initiatives the company has completed is one strategy. Another choice is to speak with seasoned IT specialists inside the company or outside IT consultants; frequently, they can determine whether a project is technically possible. A.2 Economic feasibility Doing an economic feasibility analysis is the second step in a feasibility study (also called a cost–benefit analysis). Should we develop the system? is a question that this tries to address. The system's costs and benefits are identified, their values are given, future cash flows are calculated, and the project's financial viability is assessed to see whether it is economically feasible. The financial prospects and hazards of the project may be understood as a consequence of this research. Remember that organizations only have a certain amount of funds, and other initiatives will be vying for support. The study should be more thorough and in-depth the more expensive the project is. We first outline the framework we will use to review project investments and the typical evaluation metrics that are utilized before providing a full example of this procedure: - Possibility of meeting the bottom line required for the project: o Is it worth to solve the problem? o Calculate the cost and the benefits of each alternative. - Cost and benefits analyzation o Does the benefits outweigh the costs? o The minimal cost to achieve the system. o When will the benefit accrue? o The most return on investment can be gained from all the alternative approaches. o Consideration regarding hardware/software selections, financing arrangements and the possible difficulties. o Rank all the alternatives in a multi-criteria manner. o Calculate the tangible and the intangible benefits. - Some important equations explanation (Such as NPV, ROI and Break-Even equations: o NPV Calculation: IT initiatives sometimes contain an upfront cost that yields a stream of returns over time, as well as some on-going support expenses. As a result, the project's worth must be evaluated throughout time. For a future timespan, both inflows and outflows of cash are projected. The expected benefits are then assessed using a variety of methodologies to determine if paying the expenditures is warranted. The figure below is an example of a NPV calculation table: 15 o Policies o Functionality of the program o Objectives that must be reached o Etc... - Problems that the current system is facing: Identifying problems that the project is having in present time is an easy way to make plans to either counter or minimize the risks and threats, and to better understand the question: “Does the current system have achieved all of the requirements?”. These are factors that should be considered: o Inconsistency o Inadequate functionality o Low performance - Goals and requirements for the system: Validifying goals and setting up expectations is a undeniably the most important factor in any project, it gives the organization a common target to work towards. For this sector, answering the following questions is greatly appreciated: o Currently, which problems should and must be solved for the project to work smoothly? o What is the expectations that the stakeholders wanted to achieve? o What are the deadlines? - Constraints: Findings and acknowledging constraints is also an important factor in a feasibility study, the possible constraints include: o Nonfunctional requirements on the system o Economic constraints o Technology constraints o Etc… - Planning alternatives: Making a list of possible alternatives can sometimes help the organization to find a better alternative that has more profit with less cost, making the project to be more successful. This factor includes: o The current system is always an alternative. o The different approach towards solving problems. o How much or how many solutions that can be computerized. - Listing advantages and disadvantages of alternatives - A conclusion for the feasibility study: That includes: o Is the project feasible? o The preferred alternative. B. Economic feasibility discussion on Tune Source project It has been decided that the service that ABC company provides will be not just one time only, but it will also be a server provider for Tune Source with an fee of 3500$/year, which made it into an tangible benefit. - NPV calculation for the next 2 years: Every figure is in dollar Year 0 Year 1 Year 2 Costs (5,000) (117) (120) Current $ value factor for 12% 1.0 0.893 0.797 Cumulative costs (5,000) (5,117) (5,237) Benefits 3,500 3,090 2,789 Cumulative Benefits 3,500 6,590 9,379 Cumulative Costs + benefits (1,500) 1,473 4,142 - Break-even point calculation: |1,473| 4,142 + |1,473| Result = 0.26 So, the approximate break-even point is 2.26 years. - ROI calculation: 16 9,379 – 5,237 5,237 Result = 79% In conclusion, with a 12% discount in dollar value a year; the break-even point is 2.26 years and the Return On Investment value is 79%. C. Organizational feasibility study on Tune Source project Schedule feasibility: - We do not need to waste time on achieving the required technical expertise since the development team is already capable of develop the system with both the inhouse infrastructure and employee skills. - With the development team’s expertise, the ABC company can reach the deadline in three months; which can ensure the competitive side of the project. - It is mandatory to meet the deadlines on time since it is expected to be a competitive development. - In case of meeting overruns, can extend the release date by maximum 1 months, the proposed period is enough for the testers and developers to finish the product and done a test run several times. Operational feasibility: - The management completely agrees on the proposed plan and have given the last decision of approval to the development team. - The end users (Tune Source) had agreed to the monthly payments and will use the server provider service from ABC company. - In case of resistance from managers and the users, we can deliver patches to fix and to change department that was met with complaints. - According to Tune Source’s requirements, the main platform that the app will run on is kiosks in stores and also mobile devices and also web-based, this will not significantly change the working environment of the end users but however will introduce a whole new experience and an increase in the quality of service for Tune Source. - Tune Source have already been using technology in their current business and their IT department is adequate in internet services, therefore Tune Source can adapt to the new environment quickly. Task 2.4 Assess the impact of each feasibility criterion on a software investigation and the discussion and representation of a feasibility alternative matrix for Tune Source project. A. The impact of each feasibility criterion on a software investigation. The importance of conducting a feasibility study is immense because it will factor in the ability to complete the project given by how much resource it would take and how many the return will be. It plays as an clear picture to approach the project with the highest efficiency and to determine either if the project is worthwhile or not. The impact of technical feasibility study on software investigation: - This criteria will determine if either the organization is capable of meeting technical requirements. And if, the technical team can convert ideas into working system. The impact of economic feasibility on software investigation: - This assessment relate to cost and benefits analysis of the project. This criteria help the organization to determine the viability and benefits associated with the project. The impact of organizational feasibility on software investigation: - Schedule feasibility: The most important criteria in a feasibility study, it will determine the success of the project. The organization will estimates the required time period for the project to complete and to determine either if the project is ready for release or in needs of more time. - Operational feasibility: This assessment will analyze and determine the efficiency of the organization to complete the given tasks. B. Feasibility alternative matrix for Tune Source project. Wt Candidate 1 Candidate 2 Candidate 3 17 Technical feasibility 30% Using JavaScript as the main language. JavaScript is a mature coding language that have proven success through years, and it is also our development team favorite language. Team is experienced in JavaScript. Score: 90 Using HTML frameworks can greatly improve the time needed for the project to release. However, the current development team expertise is not focused on HTML frameworks, organization need to hire new talents to overseer and implement the system. Score: 50 Outsourcing the source code from external organization and our development team will implement the program with layout and designs properly. This is not desired since it is a simple project that our development team can develop. Score: 60 Economic feasibility - NPV - Break-even - ROI 30% - 4,142 $ - 2.26 - 79% Score: 80 - 3657 $ - 3.12 - 67% Score: 70 - 2548 $ - 4.2 - 60% Score: 40 Operational feasibility 20% There was no resistance from both the end users and the development team. Stakeholders have agreed with this approach. Score: 80 The development team have raised some negative opinions regarding forcing the team in a new working environment. Management currently not focusing on expanding the work expertise. Score: 60 The market analyzer has found all of the possible outsource that the organization can approach, and the prices were low but stakeholders do not want to invest in hiring outsources. Score: 50 Schedule feasibility 20% The project will be finished in 3 months. Score: 60 The estimated time will increase by one month but the framework will decrease the work load, helping finish the system in 2 months. The total is 3 months. Score: 40 Outsourcing will finish the back- ends in 1 month and the development team only need 1 month to finish the layouts and designs. The total is 2 months. Score: 70 Overall score 100% 79 56 51 Reference: Dennis, A. et al. (2015) “Project selection & management,” in System analysis & design: An object-oriented approach with UML. Hoboken, NJ: Wiley, pp. 46– 60. Dennis, A. et al. (2015) System analysis & design: An object-oriented approach with UML. Hoboken, NJ: Wiley. Figures References: Dennis, A. et al. (2015) “The System Analysis and Information System Development,” in System analysis & design: An object-oriented approach with UML. Hoboken, NJ: Wiley, pp. 6–37. Dennis, A. et al. (2015) “Project selection & management,” in System analysis & design: An object-oriented approach with UML. Hoboken, NJ: Wiley, pp. 46– 60.
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved