Download Software Development Life Cycle (1633) (Pass) and more Assignments Computer Science 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 15/02/2023 Date Received 1st^ submission 15/02/ Re-submission Date 19/02/2023 Date Received 2nd^ submission 19/02/ Student Name Duong Quang Tri Student ID GCH 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 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: Signature & Date:
Table of Contents
- I. Introduction
- II. Task 1 (Dennis et al., Project selection & management 2015)
- II.1 SDLC Models:
- A. Waterfall Models:
- B. V-model
- C. Prototyping model................................................................................................................................................................................................
- D. Scrum model (Digite, 2019)
- E. Chosen Framework for the project: Scrum.
- F. Suitability of each SDLC models
- G. The merits of applying waterfall model to a large software development project
- II.2 Identify risks and discuss an approach to manage risk. (Dennis et al., The System Analysis and Information System Development 2015)
- A. Risk management process.
- 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
- Task 2. 2: The application of feasibility criteria (technical, economic, organization) to the project and the feasible of the project.
- A. Feasibility criteria
- B. Project feasibility discussion
- C. Alternative technical solutions using alternative matrix....................................................................................................................................
- Task 2.3 Components of a feasibility report explanation; and economic, organizational feasibility study on Tune Source project.
- A. Components of a feasibility study explanation.
- B. Economic feasibility discussion on Tune Source project
- C. Organizational feasibility study on Tune Source project...................................................................................................................................
- Tune Source project. 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
- A. The impact of each feasibility criterion on a software investigation. (Simplilearn, 2023)................................................................................
- B. Feasibility alternative matrix for Tune Source project.
- Reference:
- Figures References:
- (Figure 1 Waterfall Model)
- (Figure 2 V-model)
- (Figure 3: Prototyping model)
- (Figure 4: Scrum suitability)
- (Figure 5: Waterfall suitability)
- (Figure 6: V-Model suitability)
- (Figure 7: Prototyping 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)
- Easy to manage.
- Each phase does not intertwine with each other.
- Efficient when the project has specific documentation.
- Each phase is clearly defined.
- Milestones are hard to miss and easy to understand.
- Tasks are easy to arrange.
- The workflow creates easy documentation. A.3 Disadvantages
- Working software presence can only be found at the later stages.
- Risks are high.
- Not suitable for project that has high risk of changing for the requirements.
- Integrations are done at the very last phase, therefore making bottleneck and business challenge are hard to verify at the start.
B. V-model
B.1 Definition: The V-Model development is an variant of the waterfall model but with a more intricate focus on testing. After the coding is finished, the development team has to go through testing phases according to the corresponding defining requirements and implementation phases. The testing includes:
- Unit testing.
- Integration testing.
- System testing.
- Acceptance testing. Testing for according to phases including requirements and specified components is the key concept of this development model. Each testing level is linked to a part of the analysis or design phase, ensuring the efficiency, the quality of the product, and to also maximize the effectiveness of test runs. This development model is simple and easy to understand with an emphasis on the testing earlier in the development cycle to help tester beware of the end product. However, it still has negative points of the waterfall model, and it is not suitable for the dynamic business model. (Figure 2 V-model) B.2 Advantages:
- Has great discipline
- 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.
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.
F.4 Scrum model discussion 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 Good (Figure 8 :Scrum suitability) This framework is a one of the types of agile frameworks, it will provide a product with high quality and able to adapt to the situation depends on the user’s feedback. Therefore, the product has great quality on top of releasing on time for the requirements. Tune Source’s development team have experience with internet technology, therefore constant feedbacks is available, the end users and the stockholders can also have a grasp of the developing project. Suitability for the Tune Source’s project rating: Most suitable. F.5 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)
G. The merits of applying waterfall model to a large software development project
When applied to a big project With unclear user requirements With unfamiliar technology That are complex That are reliable With short time schedule With schedule visibility Waterfall Poor Poor Excellent Good Poor Poor First off, the waterfall model is a great choice for project that has a large team due to its simplicity and progress can be tracked easily for documentation of the project. However, it is extremely not agile and hard to adapt to the changes of the documentation, this drawback can be critical since
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.
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
(Figure 13 : NPV) o ROI (Return On Investment) Calculation: The average rate of return on the funds invested in the project is calculated as the return on investment (ROI). ROI is a straightforward formula that divides the net benefits of the project (total benefits minus total expenses) by the total costs. The ROI equation is: (Figure 14 : ROI equation) o Break-Even point: The break-even point is a popular method for determining a project's value. The break-even point, also known as the payback method, is the length of time it takes a business to recoup its initial project expenditure through net cash flows. The Break-Even point can be easily calculated using this formula: (Figure 15 : Break-Even equation) A.3 Organizational feasibility The system's organizational viability, or how well it will be eventually accepted by its users and integrated into the continuing operations of the company, is the last approach utilized for feasibility study. Many organizational aspects might affect the project, and seasoned developers are aware that evaluating organizational feasibility can be the most challenging aspect of feasibility. In essence, an organizational feasibility analysis seeks to provide a response to the question, "Will they come if we construct it?". Understanding how well the project's aims connect with corporate objectives is one method to evaluate the organizational viability of the undertaking. From the standpoint of organizational viability, strategic alignment refers to how well a project fits with the company's overall business plan. The higher the strategic alignment, the less hazardous the project will be. A CRM project that generates integrated customer information, for instance, would have great strategic alignment with the marketing department's purpose if it had opted to become more customer focused. When the IT department alone launches a project without much to no coordination with business unit or organizational strategies, many initiatives fail. Doing a stakeholder analysis is a second technique to evaluate organizational viability. A stakeholder is a person, team, or business that has the power to influence (or be impacted by) a new system. The project champion, system users, and organizational management are typically the most crucial stakeholders in the implementation of a new system, however other stakeholders may also be impacted on occasion. A system's IS department, for instance, may have a stake in it since the department's duties or functions may alter considerably once the system is put into place. The U.S. Department of Justice was a significant player in Microsoft's endeavor to integrate Internet Explorer as a default feature of Windows, in addition to the advocates, users, and management.
B. Project feasibility discussion
The project is totally feasible to complete following these studies: Technically:
- Our organization has every infrastructure that are ready to finish the project and the team is consists of experienced coders who can successfully deliver a great product that can satisfy Tune Source’s requirements and made a release in time to compete with other company. Economically:
- The product can be finished just with a small funds and can ensure return on investment really soon after the implementation, no extra funds is required to finish the project. Organizational feasibility:
- All the required documents were given by Tune Source, the management and supervisor have all lit the green light for the company to start on the project
- Since the product is expected to be competitive, our development framework have been chosen to be ensure of the quality of the product. The work progress will be easy to understand, and the deadlines will be set to be releasing as soon as the product is ready to be able to remain competitively.
C. Alternative technical solutions using alternative matrix.
Technical feasibility Score Candidate 1 Candidate 2 Candidate 3 Alternative technical solutions Using JavaScript Using HTML Framework Implementing Front-end for outsourced back-end Technology familiarity 1 0% The development team is skilled in programming using JavaScript. Score: 30 The framework is new to the organization, requires new talents and high-level personnel to ensure the best quality of the product. Score: 10 The development team can provide front-end implementation with ease. However, we are unsure of the platform. Score: 20 Project size 1 0% The project size is moderate, the team can balance out the workload easily. Score: 30 Since hiring new workforce will significantly reduce the amount of workload per employee. However, most of the work will be done by new hires, making it complicated. Score: 20 The organization only have to done half of the work, therefore making it a short project. Score: 20 Technology viability 1 0% By this day, JavaScript is still one of the most preferred languages and is also one of the most efficient and has the greatest security. Score: 30 The HTML framework can help the company greatly improve the development speed. However, debugging and releasing patches will be harder to provide on a regular basis. Score: 20 By implementing other’s work, there are uncertainty of which platform we may receive, it may be unviable. Score: 20 Total Score 30% 90 50 60 (Figure 16 : Technology alternative matrix)
Task 2.3 Components of a feasibility report explanation; and economic, organizational
feasibility study on Tune Source project.
A. Components of a feasibility study explanation.
In a feasibility study, there are many factors that must be considered to compose a great feasibility study; those factors are required to satisfied to detect all possible risks and opportunities for the project. Those components are as follows:
- Present organizational system: The existing organization and factors that can influence the project, such as: o Stakeholders o Users
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
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
Score: 80
Score: 70
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 )
Reference:
Dennis, A. et al. (2015) “Project selection & management,” in System analysis & design: An object-oriented approach with UML. Hoboken, NJ: Wiley, pp. 46–
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–
