Download ASSIGNMENT 1 - 1631-Software Development Life Cycle and more Assignments Software Development in PDF only on Docsity!
ASSIGNMENT 01 FRONT SHEET
Qualification BTEC Level 5 HND Diploma in Computing Unit number and title Unit 09: Software Development Life Cycle Submission date Date Received 1st submission Re-submission Date Date Received 2nd submission Student Name Nguyen Le Thanh Thai Student ID GCD Class GCD1002 Assessor name Phyo Min Tun 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 Thai Grading grid P1 P2 P3 P4 M1 M2 D1 D
❒ Summative Feedback: ❒ Resubmission Feedback:
Grade: Assessor Signature: Date: Internal Verifier’s Comments: Signature & Date:
- I/ SDLC MODEL ( P1 – P2 – M1 – D1 )........................................................................................................................................................
- What is the Systems Development Life Cycle (SDLC)..........................................................................................................................
- SDLC models (P1)................................................................................................................................................................................
- 2.1 Sequential life cycle model...............................................................................................................................................................
- 2.2 Iterative Model................................................................................................................................................................................
- 3 The suitable SDLC modal for this project and explaint (M1)................................................................................................................
- 3.1 The significance of selecting a model for a development project...................................................................................................
- 3.2 The suitable SDLC modal for this project.......................................................................................................................................
- Discuss the merits of applying the waterfall model to a large software development project. (D1).....................................................
- Identify some risks and discuss an approach to manage them (P2)...................................................................................................
- 5.1 What is Risk Management process................................................................................................................................................
- 5.2 Five Steps of the Risk Management Process................................................................................................................................
- 5.3 Risk Management Matrix................................................................................................................................................................
- 5.4 Risk management table of Tune Source project............................................................................................................................
- II/ FEASIBILITY STUDY ( P3 – P4 – M2 – D2 ).........................................................................................................................................
- What is a feasibility study?..................................................................................................................................................................
- The purpose of conducting a feasibility study for the project...............................................................................................................
- is feasible................................................................................................................................................................................................. 3. Discuss how the three feasibility criteria (technical, economic, organizational) are applied to the project. Discuss whether the project
- 3.1 Technical feasibility........................................................................................................................................................................
- 3.2 Organizational Feasibility...............................................................................................................................................................
- 3.3 Economic feasibility........................................................................................................................................................................
- 3.4 Whether the project is feasible.......................................................................................................................................................
- Describe how technical solutions can be compared............................................................................................................................
- 4.1 Performance...................................................................................................................................................................................
- 4.2 Legacy System Upgrade................................................................................................................................................................
- 4.3 Automation.....................................................................................................................................................................................
- 4.4 Human Errors Elimination..............................................................................................................................................................
- The components of a feasibility report (M2)........................................................................................................................................
- 5.1 Structure of the Feasibility Study....................................................................................................................................................
- 5.2 Economic feasibility study on Tune Source project........................................................................................................................
- 5.3 Organizational feasibility study on Tune Source project................................................................................................................
- Assess the impact of different feasibility criteria on a software investigation (D2)..............................................................................
- 6.1 Technical impact............................................................................................................................................................................
- 6.2 Operational Impact.........................................................................................................................................................................
- 6.3 Economic impact............................................................................................................................................................................
- 6.4 Social Impact..................................................................................................................................................................................
- 6.5 Conclusion.....................................................................................................................................................................................
- References.................................................................................................................................................................................................
- Figure 1: Definition of Systems Development Life Cycle (SDLC)................................................................................................................. Table of Figures
- Figure 2: SDLC models................................................................................................................................................................................
- Figure 3: Sequential life cycle model............................................................................................................................................................
- Figure 4: Iterative Model.............................................................................................................................................................................
- Figure 5: Spiral model.................................................................................................................................................................................
- Figure 6: Waterfall model............................................................................................................................................................................
- Figure 7: Risk Management process..........................................................................................................................................................
- Figure 8: Feasibility study...........................................................................................................................................................................
- Figure 9: Technical feasibility.....................................................................................................................................................................
- Figure 10: Organizational Feasibility..........................................................................................................................................................
- Figure 11: Economic feasibility...................................................................................................................................................................
- Figure 12: Structure of the Feasibility Study...............................................................................................................................................
Synchronous Data Link Control and software development life cycle are frequently abbreviated as SDLC. The software development life cycle is quite similar to the systems development life cycle, except it is only focused on the software development life cycle.
2. SDLC models (P1)
Figure 2: SDLC models
2.1 Sequential life cycle model
In this paradigm, the developer must adhere to certain rules, regulations, and set orders in order to complete the project.
Figure 3: Sequential life cycle model a. Waterfall model Waterfall model: Developers define the requirements, assess them, decide on a solution, and design a software architecture, interface representation, and algorithmic details. They then write the code, test it, deploy the program, and maintain it. While the waterfall technique is simple to grasp and provides requirement constancy, it may give the impression that little client input is provided. The fundamental issue with this paradigm is that the need to fix faults should be understood from the start. Otherwise, the entire process may proceed in the incorrect direction, significantly impacting manufacturing costs. Advantages The most straightforward way for explaining to consumers Utilizes a methodical technique Well-defined stages that help to plan the project ahead of time Disadvantages
When the project is modest to medium in size and has well-defined needs. In the event of a complex project, we employ the v-model.
2.2 Iterative Model
Iterative models are a type of software development lifecycle that focuses on a simple, initial implementation that gradually increases in complexity and feature set until the final system is complete. Improvements in this sort of model may be seen fast as they are implemented during each cycle. Prototype and agile models are the two iterative approaches that I will discuss. Figure 4: Iterative Model a. Prototype model Prototype model: During the requirement phase, a prototype is created and reviewed by end users. Developers modify the prototype based on customer input to meet the needs of the users. While this approach efficiently finalizes requirements, its usage in a production context may result in quality difficulties, causing the rectification process to continue indefinitely. Advantages:
The design of this model is adaptable. Errors are easily detected. We may simply locate missing functionality. There is room for improvement, which implies that future requirements may be readily met. It can be utilised by the developer in the future for more complex applications. It provides improved client pleasure and comfort. It is perfect for an online system. It improves both developers' and users' understanding of the system. Integration needs are clearly defined, and deployment channels are determined early on. It has the ability to actively include users in the development phase. Disadvantages: This type is rather pricey. Because to the constantly changing client needs, it has weak documentation. There may be an excessive amount of variety in requirements. After witnessing an early prototype, customers may demand that the final product be supplied as quickly as possible. Because developers are in a rush to construct prototypes, there may be sub-optimal solutions. After witnessing the original prototype, customers may not be happy or interested in the product. The number of iterations can be determined with accuracy. It's possible that the problem analysis is incomplete or insufficient. The system's complexity may rise as a result. When to use Prototype model: When the customer is unsure about the requirements, we usually proceed with a prototype model. If the project is complex, the prototype model clarifies the requirements. Prototyping ensures that the consumer is continually working with the system and providing feedback on it.
The project's conclusion may not be known for some time. It is not appropriate for low-risk projects. Objective, verifiable milestones may be difficult to establish. A large number of intermediate phases necessitate an abundance of documentation. When to use Spiral model: When working on a long-term project, the spiral model comes in handy. When a person is unsure about their expectations When a new product line is introduced If the project is critical, For initiatives with a medium to high chance of failure c. Scrum model Scrum is a project management framework. It adheres to the agile approach and specifies roles, procedures, tools, and processes to ensure that an efficient and successful project is delivered on schedule via iterative development cycles. According to one survey, about 70% of software teams utilize scrum or a scrum hybrid. This technique is mostly used where there is a significant demand for rapid growth and substantial stakeholder participation. The Scrum technique continuously analyzes software development while the project is being built. The Scrum Software Development Methodology places a strong emphasis on accountability, cooperation, and iterative progress toward a well-defined business goal. Advantages: Transparent approach encourages developers to complete their responsibilities on time. Defined deadlines at each stage keep developers motivated and empowered. Feedback at each stage of the project guarantees that a high-quality project is completed.
Disadvantages: A project with no defined objective and vision is difficult to design, structure, and coordinate. Frequent modifications in the project cause a delay in the project's delivery schedule. More resources are used, and stakeholders are involved in every minute detail modification and debate. When to use scrum model: Anyone who wants to create an end product, such as a website, a software program, or even a building project, may utilize Scrum. Let's go deeper into the Scrum process, including the many Scrum roles, to discover if this project management style is a good fit for you.
3 The suitable SDLC modal for this project and explaint (M1)
3.1 The significance of selecting a model for a development project
The lifespan model chosen will affect whether or not the project is successful. Because the model influences how the development process is carried out, the most appropriate model must be chosen based on the project's size and the complexity of finishing the final product and achieving the objectives. Different models will provide different methods for completing the product; picking the appropriate model will guarantee that the project is as efficient as feasible in terms of completion time and product quality.
One of the most intriguing aspects of the SDLC Spiral model is that it was utilized by Microsoft to create early versions of Windows. The approach was also used to create the Gantt chart software. As a result, it comes as no surprise that Spiral Model is used for large, high- risk initiatives that are also aimed at a large audience. Another business that use the Spiral model is game development. As previously stated, the approach enables meticulous and rapid prototyping. Because the gaming business relies significantly on early game versions, Spiral becomes a viable choice. With the strategy, game development businesses may quickly receive feedback from their clients and create a playable that can expand into equally fun games.
4. Discuss the merits of applying the waterfall model to a large software
development project. (D1)
Figure 6: Waterfall model
The waterfall model is connected with a significant amount of money and effort. In such case, it needs the approval of multiple documents, changes are costly to implement, iterations require a significant amount of time and effort, and concerns are often delayed until later stages. Few Tune Source studies have been conducted explicitly on the waterfall model, and specific reasons for the waterfall approach's efficacy have been identified. Waterfall Processes Assume or Require that The achievement of the planned scope defines success. o The most severe limitation may be on scope or scheduling. Schedules are sometimes stretched to attain scope. Scope is sometimes lowered to meet a deadline. The requirements are fully recognized and will not be altered. o Change requests are exceptions that must be handled through the change-request procedure. All stages are known and may be approximated quite well. The procedure is sequential: Begin with requirements, progress to results, and end with results. Some stages may need lengthy lead periods or the use of several specialist resources. Incremental outcomes (for example, at 20% of scope) are of little or no value. During the product development process, the Waterfall approach involves very little consumer engagement. Only when the product has been completed can it be demonstrated to end users. Once the product is produced, if a fault happens, the cost of resolving such issues is quite significant since we must update everything from the documentation to the logic. Conclusion: This case study analyzes and explores business difficulties connected to waterfall methods used in large-scale software development. As a result, the most essential requirements and verification challenges in waterfall development are exposed. As a result, the waterfall model is unsuitable for large-scale development. As a result, Tune Source is forced to use a different model. When case studies are compared to commercial results, it is evident that the case study has all of the challenges highlighted in the literature. Case studies, on the other hand, provide corrective explanations for issues while also identifying four new ones, such as who implements
Figure 7: Risk Management process Because of its emphasis on predicting and understanding risk throughout a company, this holistic approach to risk management is also referred to as enterprise risk management. Enterprise risk management (ERM) highlights the necessity of managing positive risk in addition to focusing on internal and external threats. Positive risks are opportunities that, if not accepted, can either improve corporate value or harm a firm. Indeed, the goal of any risk management program is not to remove all risk, but rather to protect and create value to the organization by making prudent risk decisions.
5.2 Five Steps of the Risk Management Process
Identify the Risk: The first stage in risk management is to identify the hazards that the company faces in its operational environment. It is critical to identify as many of these risk factors as feasible. In a manual setting, these risks are manually recorded. If the business is using a risk management solution, all of this information is instantly entered into the system.The benefit of this strategy is that these risks are now apparent to any stakeholder in the organization who has access to the system. Instead of being locked away in a report that must be requested via email, anybody who wants to know which risks have been detected may access the information in the risk management system. Analyze the Risk: Once a danger has been identified, it must be evaluated. The scope of the danger must be established. It is also critical to understand the relationship between the risk and other components inside the firm. To assess the risk's degree and significance, consider how many business operations are affected. There are dangers that, if realized, may bring the entire firm to a halt, while others will merely cause small hassles in the analysis. This analysis must be performed manually in a manual risk management system. One of the most critical basic steps in implementing a risk management solution is mapping risks to various documents, rules, procedures, and business processes. This implies that the system will already have a risk management framework in place that will analyze hazards and inform you of the long-term consequences of each risk. Evaluate the Risk or Risk Assessment: The risks must be rated and prioritized. Depending on the magnitude of the risk, most risk management solutions categorize hazards. Risks that may cause minor discomfort are rated low, whereas risks that may result in catastrophic loss are rated highest. It is critical to rate risks because it helps the company to acquire a comprehensive perspective of the organization's risk exposure. The company may be subject to a number of low-level dangers, but they may not necessitate the intervention of senior management. On the other hand, even one of the highest-rated hazards necessitates rapid action. Risk assessments are classified into two types: qualitative risk assessments and quantitative risk assessments. Treat the Risk: Every danger must be reduced or eliminated to the greatest extent practicable. This is accomplished by contacting specialists in the subject to which the risk pertains. In a manual system, this means calling every stakeholder and then scheduling meetings so that everyone can talk about and debate the concerns. The difficulty is that the conversation is fragmented among several email threads, papers and spreadsheets, and phone conversations. All key stakeholders in a risk management solution may be notified from within the system. Within the system, a conversation about the danger and alternative solutions might take place. Upper management can also keep an eye on the solutions proposed and the progress achieved within the system. Instead of contacting each other for updates, everyone may obtain them straight from the risk management solution.
