Vòng đời phát triển phần mềm là một quy trình tích hợp nhằm thúc đẩy việc xây dựng phần mềm an toàn, chất lượng tốt trong toàn bộ quá trình phát triển. Mục đích của môn học này là cung cấp cho sinh viên kiến thức và kỹ năng cần thiết để hiểu vòng đời phát triển phần mềm và thể hiện kiến thức của họ bằng cách triển khai vòng đời phát triển phần mềm với một phương pháp phù hợp. Đơn vị này giới thiệu cho sinh viên cách ra quyết định trong vòng đời ở các giai đoạn khác nhau của quy trình phát triển phần mềm. Học sinh sẽ kiểm tra các mô hình vòng đời khác nhau và đánh giá cao các đặc điểm cụ thể của chúng để hiểu môi trường dự án nào chúng phù hợp nhất. Sự hiểu biết lý thuyết sẽ được chuyển thành các kỹ năng thực tế thông qua một dự án vòng đời phát triển phần mềm thực tế và sinh viên sẽ trở nên tự tin trong việc sử dụng các công cụ và kỹ thuật cụ thể phù hợp với phương pháp đã chọn. Trong số các chủ đề trong đơn vị này có các mô hình lặp và tuần tự về vòng đời phát triển phần mềm và các khung tham chiếu để thu thập dữ liệu và thông tin khái niệm ban đầu thông qua nghiên cứu khả thi và các kỹ thuật thu thập yêu cầu cho đến các hoạt động phân tích, thiết kế và triển khai phần mềm. Kết quả là học sinh sẽ phát triển các kỹ năng như kỹ năng giao tiếp, tư duy phản biện, phân tích, lý luận và diễn giải, những kỹ năng rất quan trọng để kiếm được việc làm và phát triển năng lực học tập.
SDLC MODEL
Describing SDLC models (P1-M1-D1)
1 Describing 5 SDLC models and choosing suitable one for the project (P1)
The Waterfall approach was established in 1970 by Winston w Royce It contains five phases of management, where each requires a deliverable from the previous phase to proceed Waterfall is ideal for projects like software development, where the end result is clearly established before starting, and is best suited for projects that require a lot of predictability
There are five phases of the Waterfall methodology: Requirements, Design, Implementation,
The Waterfall methodology depends on the belief that all project requirements can be gathered and understood upfront The project manager does their best to get a detailed understanding of the project sponsor’s requirements Written requirements, usually contained in a single document, are used to describe each stage of the project, including the costs, assumptions, risks, dependencies, success metrics, and timelines for completion
Here, software developers design a technical solution to the problems set out by the product requirements, including scenarios, layouts, and data models First, a higher-level or logical design is created that describes the purpose and scope of the project, the general traffic flow of each component, and the integration points Once this is complete, it is transformed into a physical design using specific hardware and software technologies
Once the design is complete, technical implementation starts This might be the shortest phase of the Waterfall process because painstaking research and design have already been done In this phase, programmers code applications based on project requirements and specifications, with some testing and implementation taking place as well If significant changes are required during this stage, this may mean going back to the design phase
Before a product can be released to customers, testing needs to be done to ensure the product has no errors and all of the requirements have been completed, ensuring a good user experience with the software The testing team will turn to the design documents, personas, and user case scenarios supplied by the product manager to create their test cases
Once the software has been deployed in the market or released to customers, the maintenance phase begins As defects are found and change requests come in from users, a team will be assigned to take care of updates and release new versions of the software
Figure 1 Waterfall method phases Advantages and Disadvantages
Before the next phase of development, each phase must be completed Error can be fixed only during the phase
Suited for smaller projects where requirements are well defined It is not desirable for complex project where requirement changes frequently
They should perform quality assurance test
(Verification and Validation) before completing each stage
Testing period comes quite late in the developmental process
Elaborate documentation is done at every phase of the software’s development cycle Documentation occupies a lot of time of developers and testers
Project is completely dependent on project team with minimum client intervention Clients valuable feedback cannot be included with ongoing development phase
Any changes in software are made during the process of the development
Small changes or errors that arise in the completed software may cause a lot of problems
The V-model is a type of SDLC model where process executes in a sequential manner in V-shape It is also known as Verification and Validation model It is based on the association of a testing phase for each corresponding development stage Development of each step directly associated with the testing phase The next phase starts only after completion of the previous phase i.e for each development activity, there is a testing activity corresponding to it
The V-Model is a software development life cycle (SDLC) model that provides a systematic and visual representation of the software development process It is based on the idea of a “V” shape, with the two legs of the “V” representing the progression of the software development process from requirements gathering and analysis to design, implementation, testing, and maintenance
Requirements Gathering and Analysis: The first phase of the V-Model is the requirements gathering and analysis phase, where the customer’s requirements for the software are gathered and analyzed to determine the scope of the project
Design: In the design phase, the software architecture and design are developed, including the high- level design and detailed design
Implementation: In the implementation phase, the software is actually built based on the design
Testing: In the testing phase, the software is tested to ensure that it meets the customer’s requirements and is of high quality
Deployment: In the deployment phase, the software is deployed and put into use
Maintenance: In the maintenance phase, the software is maintained to ensure that it continues to meet the customer’s needs and expectations
The V-Model is often used in safety-critical systems, such as aerospace and defense systems, because of its emphasis on thorough testing and its ability to clearly define the steps involved in the software development process
This is a highly disciplined model and Phases are completed one at a time
V-Model is used for small projects where project requirements are clear
Simple and easy to understand and use
This model focuses on verification and validation activities early in the life cycle thereby enhancing the probability of building an error-free and good quality product
It enables project management to track progress accurately
Clear and Structured Process: The V-Model provides a clear and structured process for software development, making it easier to understand and follow
Emphasis on Testing: The V-Model places a strong emphasis on testing, which helps to ensure the quality and reliability of the software
Improved Traceability: The V-Model provides a clear link between the requirements and the final product, making it easier to trace and manage changes to the software
Better Communication: The clear structure of the V-Model helps to improve communication between the customer and the development team
It is not a good for complex and object-oriented projects
It is not suitable for projects where requirements are not clear and contains high risk of changing
This model does not support iteration of phases
It does not easily handle concurrent events
Inflexibility: The V-Model is a linear and sequential model, which can make it difficult to adapt to changing requirements or unexpected events
Time-Consuming: The V-Model can be time-consuming, as it requires a lot of documentation and testing
Overreliance on Documentation: The V-Model places a strong emphasis on documentation, which can lead to an overreliance on documentation at the expense of actual development work
The prototyping model is a systems development method in which a prototype is built, tested and then reworked as necessary until an acceptable outcome is achieved from which the complete system or product can be developed This model works best in scenarios where not all of the project requirements are known in detail ahead of time It is an iterative, trial-and-error process that takes place between the developers and the users
Step-1: Requirements gathering and analysis :
Requirement analysis is the first step in developing a prototyping model During this phase, the system’s desires are precisely defined During the method, system users are interviewed to determine what they expect from the system
The second phase could consist of a preliminary design or a quick design During this stage, the system’s basic design is formed However, it is not a complete design It provides the user with a quick overview of the system The rapid design aids in the development of the prototype
During this stage, an actual prototype is intended to support the knowledge gained from quick design
It is a small low-level working model of the desired system
The proposed system is presented to the client for preliminary testing at this stage It is beneficial to investigate the performance model’s strengths and weaknesses Customer feedback and suggestions are gathered and forwarded to the developer
If the user is dissatisfied with the current model, you may want to improve the type that responds to user feedback and suggestions When the user is satisfied with the upgraded model, a final system based on the approved final type is created
Step-6: Implement Product and Maintain :
Identifying risks and discussing approach to manage them (P2)
1 How risk is managed in the Spiral Lifecycle Model
Risk management is at the heart of the spiral lifecycle software development model designed here, which sets it apart from other software development methodologies It is an integral part of every iteration or phase of the project, making it a proactive approach rather than a reactive one
Risk Identification: This is the spiral model’s initial phase of risk management In each iteration, the first step is to identify potential risks These could be operational, technical, or external
Operational risks could include potential team changes or miscommunications Technical risks could involve technology malfunctions or the use of untested technology External risks could arise from changes in market conditions or regulatory laws
Risk Analysis: After identifying potential risks, the next step is to analyze them This analysis includes determining the likelihood of each risk occurring and the potential impact on the project if it does occur Risks are typically categorized as high, medium, or low priority based on these factors This prioritization helps guide the team’s focus on the most significant risks
Risk Evaluation: Once the risks have been analyzed, they are evaluated to decide which risks to address in the current iteration of the spiral The risks are evaluated based on their priority and the project’s current phase Sometimes, addressing certain risks in later spirals may be more efficient
Risk Mitigation: After evaluation, the next step is to devise strategies to mitigate the identified risks This could involve taking preventive measures to reduce the likelihood of the risk occurring, creating contingency plans to handle the risk if it does occur, or accepting the risk if it cannot be avoided or if the cost of mitigation exceeds the potential impact
Risk Monitoring: Even after implementing a risk mitigation strategy, it is vital to monitor the risk continuously This is because the likelihood and impact of risks can change over time as the project progresses Monitoring involves keeping an eye on the risk factors and adjusting the mitigation strategy if necessary
Risk Communication: Throughout all these steps, it is essential to maintain clear and consistent communication about risks All project stakeholders should be kept informed about the identified risks of small projects, their potential impact, and the strategies for managing them
The risk management process is a framework for the actions that need to be taken There are five basic steps that are taken to manage risk; these steps are referred to as the risk management process It begins with identifying risks, goes on to analyze risks, then the risk is prioritized, a solution is implemented, and finally, the risk is monitored In manual systems, each step involves a lot of documentation and administration
The Five Essential Steps of A Risk Management Process
3 Evaluate or Rank the Risk
5 Monitor and Review the Risk
Figure 7 Risk management process Step 1: Identify the Risk
The initial step in the risk management process is to identify the risks that the business is exposed to in its operating environment
There are many different types of risks:
It is important to identify as many of these risk factors as possible In a manual environment, these risks are noted down manually If the organization has a risk management solution employed all this information is inserted directly into the system
Once a risk has been identified it needs to be analyzed The scope of the risk must be determined It is also important to understand the link between the risk and different factors within the organization To determine the severity and seriousness of the risk it is necessary to see how many business functions the risk affects There are risks that can bring the whole business to a standstill if actualized, while there are risks that will only be minor inconveniences in the analysis
In a manual risk management environment, this analysis must be done manually.When a risk management solution is implemented one of the most important basic steps is to map risks to different documents, policies, procedures, and business processes This means that the system will already have a mapped risk management framework that will evaluate risks and let you know the far-reaching effects of each risk Step 3: Evaluate the Risk or Risk Assessment
Risks need to be ranked and prioritized Most risk management solutions have different categories of risks, depending on the severity of the risk A risk that may cause some inconvenience is rated lowly, risks that can result in catastrophic loss are rated the highest It is important to rank risks because it allows the organization to gain a holistic view of the risk exposure of the whole organization The business may be vulnerable to several low-level risks, but it may not require upper management intervention On the other hand, just one of the highest-rated risks is enough to require immediate intervention
Every risk needs to be eliminated or contained as much as possible This is done by connecting with the experts of the field to which the risk belongs In a manual environment, this entails contacting each and every stakeholder and then setting up meetings so everyone can talk and discuss the issues The problem is that the discussion is broken into many different email threads, across different documents and spreadsheets, and many different phone calls In a risk management solution, all the relevant stakeholders can be sent notifications from within the system The discussion regarding the risk and its possible solution can take place from within the system Upper management can also keep a close eye on the solutions being suggested and the progress being made within the system Instead of everyone contacting each other to get updates, everyone can get updates directly from within the risk management solution
Step 5: Monitor and Review the Risk
Not all risks can be eliminated – some risks are always present Market risks and environmental risks are just two examples of risks that always need to be monitored Under manual systems monitoring happens through diligent employees These professionals must make sure that they keep a close watch on all risk factors Under a digital environment, the risk management system monitors the entire risk framework of the organization If any factor or risk changes, it is immediately visible to everyone Computers are also much better at continuously monitoring risks than people Monitoring risks also allows your business to ensure continuity
FEASIBILITY STUDY
Purpose of feasibility study and how can it help project manager (P3)
1 Discussing the purpose of conducting a feasibility study
A feasibility study is an analysis done to determine the viability of a project from an economical, legal, and technical perspective Simply put, it gives us an insight into whether a project is doable or worth the investment
A feasibility study, that’s well-designed should offer insights on the description of the project, resource allocation, accounting statements, financial data, legal requirements, and tax obligations It helps to determine whether the project is both possible and profitable for the company to undertake Hence, this study is mandatorily done before technical development and project execution
Steps to conduct a feasibility study
The following stages are involved while conducting any feasibility study, in general:
A preliminary analysis: This is like a pre-screening of the project It helps discover the viability of the project as well as identify any roadblocks if any
Scope definition: This step includes outlining the project’s scope as well as its potential impact on the organization
Market research: This is an essential factor, as no project is begun without adequate market research A thorough analysis of the existing market and competition is done to manage the project accordingly
Financial assessment: In this stage, all the costs related to the project, including equipment, man-hours, the financial risks, and the benefits associated with the project are estimated and scrutinized
Alternative solutions: Whenever any hiccups arise, the team should be well-prepared to come up with a solution This is an integral yet dynamic part of a feasibility study
Go/no-go decision: The final stage of a feasibility study is the course of action, in other words, whether the project is worth proceeding with or not
This study takes stock of the technical resources available to undertake a project from an organization’s perspective It includes ensuring that the technical resources are adequate, and the hardware and software requirements are met Technical feasibility will also include if proven technologies and methodologies exist to support the proposed development
This assessment performs a cost/ benefits analysis of the project before the financial resources are allocated This type of study gives a clear-cut idea of project credibility (viability) as well as the economic benefits to the organization from the project
In this type of feasibility study, the legal requirements of the proposed project are analyzed Several parameters, ranging from zonal laws to data protection acts are checked, and compliance mandates are mapped out
This study will help analyze and determine whether the organization’s goals can be satisfied by completing the project
This is the most important assessment for project success It estimates the time necessary to complete the project after considering the organization’ s capabilities and determines whether that amount of time is available
Assessing Technical Feasibility: Determine if the necessary technology and resources are available for the project
Evaluating Economic Feasibility: Assess the financial viability and potential returns on investment
Analyzing Market Feasibility: Determine the market demand, competition, and growth potential
Considering Legal and Regulatory Feasibility: Ensure compliance with laws, regulations, and industry standards
Addressing Organizational Feasibility: Evaluate the project's fit within the organization's structure and capabilities
By conducting a feasibility study, organizations can make informed decisions, minimize risks, allocate resources effectively, and increase the chances of project success
2 How can feasibility report help project manager in project selection, planning and design
A feasibility report plays a crucial role in assisting project managers in project selection, planning, and design
Evaluation of Alternatives: A feasibility report assesses multiple project alternatives, providing valuable insights and analysis to project managers It helps them compare the feasibility and viability of different options, enabling informed decision-making
Risk Assessment: The report identifies potential risks, challenges, and limitations associated with each project alternative Project managers can use this information to evaluate the risk- reward ratio and select projects with acceptable levels of risk
Resource Allocation: A feasibility report provides information on resource requirements, such as financial, technological, human resources, and infrastructure needs This helps project managers in planning and allocating resources effectively
Timeline and Scheduling: The report includes estimates of the time required for project completion, milestones, and critical path analysis Project managers can use this information to create realistic project schedules and ensure timely completion
Technical Feasibility: The feasibility report assesses the technical feasibility of the project, considering factors such as technology compatibility, available resources, and required expertise This helps project managers in designing and structuring the project to align with technical capabilities
Design Optimization: The report may provide insights into potential design improvements, cost-saving measures, or alternative approaches Project managers can use this information to optimize the project design, resulting in a more efficient and effective implementation.
Feasibility criteria (P4)
1 Discussing how three feasibility criteria are applied to the project
In software development, the feasibility criteria are used to assess the viability of a project These criteria include technical feasibility, economic feasibility, and organizational feasibility
Technical Feasibility: This criterion evaluates whether the project can be implemented from a technical standpoint It considers factors such as the availability of required technology, expertise, and resources In the case of my small and well-prepared project, if I have the necessary technical skills, tools, and resources readily available, it indicates a positive technical feasibility
Economic Feasibility: Economic feasibility assesses whether the project is financially viable and will provide a satisfactory return on investment (ROI) It involves analyzing the project's costs and benefits For my small project, I need to consider the costs associated with development, maintenance, and any potential licensing or infrastructure expenses If the benefits, such as improved efficiency or cost savings, outweigh the costs, then the project is economically feasible
Organizational Feasibility: Organizational feasibility examines whether the project aligns with the goals, capabilities, and resources of the organization It considers factors like the organization's structure, culture, and existing systems Since my project is small and well- prepared, it suggests that it aligns with the capabilities and resources of my organization Additionally, if my project complements the organization's strategic objectives and can be integrated smoothly into its operations, it demonstrates organizational feasibility
Based on the information provided, it appears that my mall and well-prepared project is feasible The technical feasibility is supported by my preparedness and availability of necessary resources The economic feasibility is favourable if the anticipated benefits outweigh the costs Lastly, the organizational feasibility is indicated by the project's alignment with the organization's capabilities and goal
2 Two technical solutions and comparing them about feasibility
Frontend and backend but not good as server-side language
Good security such as using authentication, authorization, validations
5 50 Not have auth like other languages 3 30 Not good for large project 4 40
The license is less than $5
Visual studio + NET Framework cost $4500
4 40 Free for commercial use 5 50 Free for commercia l use 5 50
A server costs less than S1 10 Reuse current server 5 50 Reuse server 3 30 Reuse server 5 50
Capable of hiring a senior developer
10 Very high salary 3 30 Not easy to find 5 50 Easy to find 5 50
Capable of hiring testers for less than
40 Easy to find 5 200 Easy to find 5 200 Easy to find 4 160
Components of a feasibility report (M2)
A feasibility analysis contains key components that show company officials, employees, investors and other parties that an organisation has the capability and operational expertise to complete a project successfully if it has access to adequate funding Here are the components to include in the document:
The title page is the first part of the study readers sees It provides the reader with direct information about the theme of the project Besides mentioning the name of the project, the title page typically contains the name of key members of the team, including the project manager and team members It also lists the proposed project start and completion dates
The table of content makes it easy for readers to navigate the document It shows the reader the page number for each section of the study Many word processor applications have a feature that allows you to insert a table of content automatically into your documents
The executive summary is the first comprehensive section of the study It provides a brief introduction to the project and describes its purpose The executive summary also outlines the specific results you want to achieve at the end of the project and the resources you require to deliver those outcomes
In this section, you provide important statistics about the company that qualifies it to deliver the project The market feasibility section offers information on the company's industry, its history, current projects and future predictions Here, you can also discuss the company's main competitors, primary revenue sources, sales figures and areas where the business can expand This section provides the reader with an in-depth understanding of the company and its operations and explains how the new project can improve its growth and results
In the technical feasibility section, you discuss operational factors that can affect the company's success Here, you can outline the resources required to produce products or services, the personnel requirements, manufacturing and quality control processes and the logistics and distribution network to meet customer demands This section shows the reader the primary factors that make the business viable
This section shows the reader information about the company's finances, which makes it an important tool for convincing investors to support a new project The feasibility section provides information about assets and liabilities, total annual revenue from the previous year, current revenue, existing investors and other sources of funding It can also outline the capital requirements for the new project so that readers know the amount of funding the company requires to execute the venture
The organisational feasibility section describes the structure of the company It shows the reader the locations and departments where the company operates The section can also provide information about the executives, such as the founders, board members and other principal officers In this section, you can highlight the company guidelines for recruiting staff, achieving productivity targets and complying with industry regulations This section helps the reader to assess how current company practices align with the proposed project
Figure 11 roles in group illustration
Accessing the impact of each feasibility criterion on a software investigation (D2)
When conducting a software investigation, various feasibility criteria need to be considered to assess the viability and potential success of the project Let's examine the impact of each feasibility criterion on a software investigation:
Technical feasibility evaluates whether the proposed software solution can be developed and implemented successfully Factors that impact technical feasibility include:
Compatibility: Can the software integrate with existing systems, databases, and infrastructure?
Scalability: Is the software capable of handling increasing data loads or user traffic?
Performance: Will the software meet the required speed, response time, and throughput?
Security: Can the software protect sensitive data and mitigate potential vulnerabilities?
Technology: Are the necessary tools, programming languages, and frameworks available and suitable for the project?
The impact of technical feasibility is significant as it determines whether the software can be built and deployed effectively Challenges in this area may lead to increased development time, cost overruns, or even project failure
Economic feasibility assesses the financial viability of the software investigation It involves analyzing the costs, benefits, and potential returns on investment Factors to consider include:
Development costs: How much will it cost to design, develop, and test the software?
Operational costs: What are the ongoing expenses related to maintenance, support, and upgrades?
Benefits: Will the software generate tangible benefits such as increased efficiency, cost savings, or revenue generation?
Return on Investment (ROI): What is the anticipated payback period and overall profitability of the software?
The impact of economic feasibility is crucial as it determines the financial viability and justification for undertaking the software investigation If the costs outweigh the potential benefits, the project may not be deemed economically feasible
Organizational feasibility examines the impact of the software investigation on the organization's structure, resources, and stakeholders Key considerations include:
Resource availability: Does the organization have the necessary human, financial, and technical resources to support the software investigation?
Organizational culture: Will the software align with the organization's goals, values, and existing practices?
Stakeholder acceptance: Will the software be accepted and embraced by employees, customers, and other relevant parties?
Change management: Can the organization manage the transition to the new software effectively?
The impact of organizational feasibility is crucial to ensure smooth adoption, utilization, and integration of the software within the organization Resistance to change or lack of support from stakeholders can hinder the success of the project