Đang tải... (xem toàn văn)
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.
ASSIGNMENT 02 FRONT SHEET Qualification BTEC Level 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 Bui Quang Minh Student ID GCD210325 Class GCD1104 Assessor name Tran Trong Minh 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 Grading grid P5 P6 P7 M3 M4 M5 M6 D3 D4 ❒ Summative Feedback: Grade: Internal Verifier’s Comments: Signature & Date: ❒ Resubmission Feedback: Assessor Signature: Date: Table of content TASK 1: ANALYSIS (1) I Identifying stakeholders and FRs, NFRs of TuneSource Project (P5.a) Identifying stakeholders and reviewing requirements FRs and NFRs 2.1 What is FRs and NFRs 2.2 Identifying FRs and NFRs of TuneSource Project 2.3 Discussing relationship between FRs and NFRs I Discussing the techniques would be used to obtain the requirements (P5.b) Describing techniques would be used Demonstrating how to collect requirements based on chosen technique SRS (Software Requirements Specification) for the Tune Source 3.1 Introduction 3.2 General discription 3.3 Software features and requirements III Discussing how would trace these requirements throughout the project (M3) TASK 2: ANALYSIS (2) 12 I Analysing identified requirements in Task (P6) 12 ERD (Entity Relationship Diagram) 12 Flow chart 13 DFD (Data Flow Diagram) 16 TASK 3: DESIGN 18 I Discussing how user and software requirements are addressed in design phase (P7) 18 How mockup and Wireframe are used in the project 18 Explaining which architecture is suitable for the project 21 Addressing solution stack that can be suitable to implement the project 22 3.1 What is Tech Stack 22 3.2 Influences the choice of A Tech Stack 22 3.3 Suitable solution stack 23 II Discussing how activity diagram and pseudocode are used to specify software behavior (M5) 24 Activity diagram 24 Pseudocode 25 III Discussing how UML state machine can be used to specify software behavior and differences between FSM and extended FSM using case study (M6) 26 How UML state machine can be used to specify software behavior 26 FSM and extended FSM 28 2.1 What is FSM 28 2.2 What is extended FSM 29 2.3 Differentiating between FSM and extended FSM 29 IV Discussing how data-driven approach improves the reliability and effectiveness of software (D4) 29 What is data-driven 29 What is data-driven for 29 How data-driven approach improves the reliability and effectiveness 30 TASK 4: SOFTWARE QUALITY MANAGEMENT 32 I Discussing two software quality attributes that are applicable to the project (M4.a) 32 Usability 32 Reliability 32 II Discussing two quality assurance techniques that can help improve software quality project (M4.b) 33 Code reviewing 33 Testing 34 III Discussing how design techniques and approaches that is used can help improve software quality (D3) 35 What is software quality 35 What are the C’s of Software Quality 36 How design techniques and approaches help to improve software quality 36 TASK 1: ANALYSIS (1) I Identifying stakeholders and FRs, NFRs of TuneSource Project (P5.a) Identifying stakeholders and reviewing requirements John Margolis (Entrepreneur): Co-founder of Tune Source Role: Strategic decision-making, profitability Megan Taylor (Entrepreneur): Co-founder of Tune Source Role: Classical music expertise, supplier relationships Phil Cooper (Entrepreneur): Co-founder of Tune Source Role: Store operations, and inventory management Carly Edwards (Project Sponsor): Assistant VP of Marketing Role: Project sponsorship, aligning with strategic goals Customers: Existing and potential customers Interests: Finding rare recordings, convenient shopping, digital downloads, and subscription services Development Team: IT department and developers Role: Implementation of digital music download system Internet Service Provider (ISP): Hosts Tune Source's website Role: Reliable hosting and technical support Music Suppliers: Providers of digital music downloads Interests: Expanding reach, increasing sales Marketing Department: Tune Source's marketing team Interests: Promoting the service, and driving sales Competitors: Other music retailers and platforms Interests: Monitoring Tune Source's impact on the market Review the requirement definition of the project Business Need: Increase sales by selling digital music downloads through in-store kiosks and the website Provided by: Carly Edwards (Project Sponsor) Business Requirements: Search for music in the digital music archive Listen to music samples Purchase individual downloads at a fixed fee per download Establish a customer subscription account permitting unlimited downloads for a monthly fee Purchase music download gift cards Provided by: Carly Edwards (Project Sponsor) and Customers (interests and needs) Business Value: Increase sales by enabling customers to purchase specific digital music tracks Reach new customers interested in rare and hard-to-find music Gain revenue from customer subscriptions to download services Increase cross-selling as customers decide to purchase entire CDs Generate revenue from music download gift cards Provided by: Carly Edwards (Project Sponsor) FRs and NFRs 2.1 What is FRs and NFRs Functional Requirements (FRs) are specific capabilities or features that a system must possess to satisfy its intended purpose They describe what the system should and can be objectively verified or tested FRs are typically focused on the system's functionalities and behavior Example FRs for an online shopping website: o o o o o The system will allow users to create an account The system will provide search functionality for users to find products The system will allow users to add products to a shopping cart The system will support different payment methods for users to complete their purchases The system will send order confirmation emails to users after successful purchases Non-Functional Requirements (NFRs) define the qualities or characteristics that a system should possess, typically addressing aspects such as performance, security, usability, and reliability NFRs are not directly related to the system's functionalities but focus on how well the system performs and behaves Example NFRs for an online shopping website: o o o o o Performance: The system should load product pages within two seconds Security: The system should encrypt sensitive user data, such as passwords and payment information Usability: The system's user interface should be intuitive and easy to navigate Reliability: The system should have an uptime of at least 99% to minimize downtime and disruptions Scalability: The system should be able to handle a high volume of simultaneous user requests during peak times 2.2 Identifying FRs and NFRs of TuneSource Project Based on the given information, we can identify the following Function Requirements (FRs) and NonFunction Requirements (NFRs) for the Tune Source project: Functional Requirements (FRs): Online Catalog: Develop an online catalog that allows customers to search for CDs E-commerce Functionality: Enable customers to purchase CDs through the website Search Functionality: Implement a search feature that allows customers to search for specific artists, albums, genres, etc User Accounts: Provide the option for customers to create user accounts for easier future purchases and personalized recommendations Payment Processing: Integrate a secure payment gateway to process customer payments Order Tracking: Allow customers to track the status of their orders, including shipping information and delivery updates Non-Functional Requirements (NFRs): Performance: Ensure that the website loads quickly and provides a responsive user experience Security: Implement robust security measures to protect customer data and prevent unauthorized access Reliability: Ensure high uptime and minimal downtime for the website to prevent disruptions in sales Usability: Design the website interface to be user-friendly, intuitive, and easy to navigate Compatibility: Ensure compatibility with various web browsers and operating systems Accessibility: Make the website accessible to users with disabilities by adhering to accessibility standards Performance Monitoring: Implement tools to monitor website performance, track metrics, and identify areas for improvement These FRs and NFRs provide a basis for developing and implementing the Tune Source project to meet the needs of customers and ensure a successful online presence for the company 2.3 Discussing relationship between FRs and NFRs Systems need both functional requirements and non-functional requirements to be usable Functional requirements define how the system must work and non-functional requirements detail how it should perform Without functional requirements, the system will not work Without at least some non-functional requirements being met to a certain level, users will become frustrated Documenting functional requirements and non-functional requirements helps to avoid disappointment with a new system It is also important in keeping the project on track, to budget and delivered on time Documenting requirements is also more likely to lead to greater satisfaction with the end product for both business stakeholders and end users I Discussing the techniques would be used to obtain the requirements (P5.b) Describing techniques would be used Joint Application Development (JAD) is a process in which business information is gathered for the development of new information technology systems or to improve user involvement or develop and improve quality in systems In this technique IT, specialists and business users collaborate in discussion, project management and learning groups, talking about the new information system With the participation of both parties, it is possible to develop and solve the requirements of the new software system in an easier way The meetings can be hours, days or weeks, depending on the intensity of the workshops Individual interviews with stakeholders, such as Carly Edwards (Project Sponsor), Megan Taylor (Cofounder), and customers, can provide deeper insights into their specific needs and expectations These interviews can be conducted in person, over the phone, or through video conferencing The interviewer should prepare a set of open-ended questions to prompt stakeholders to provide detailed responses For example, questions can be focused on understanding the desired features, user experience, and specific functionalities of the digital music download system Through interviews, stakeholders can express their perspectives and provide valuable input for the requirements gathering process User observation should be planned to ensure that all elements are constant surrounding the observation This will assist in uncertainty, and the consultant can focus on the user and assist in knowing what to look for The analyst will not be distracted and record, or note, irrelevant issues The more useful information gathered, the less time it will take to the analyst to dissect and evaluate afterwards Timing of the observation can also prove relevant when planning For optimal results, the consultant should schedule three different periods of observation: low, normal, and peak times This may prove helpful in because the user may interact with the system differently during different times The consultant will take into consideration the differences in times time settings and use it to obtain to construct better requirements to assist in all three times When observing the user, there are two approaches the consultant can take, passive or active Demonstrating how to collect requirements based on chosen technique I would choose JAD and interview techniques to collect requirements based on the chosen technique Joint Application Development (JAD): a Plan the JAD session: Identify the key stakeholders to include in the session, such as Carly Edwards (Project Sponsor), Megan Taylor (Co-founder), and representatives from the development team Set a date, time, and location for the session Prepare the agenda, including specific topics and objectives to be discussed b Conduct the JAD session: Start the session by introducing the purpose and goals of the session, emphasizing the importance of collaborative participation Encourage stakeholders to share their ideas, perspectives, and requirements Facilitate discussions to clarify and resolve any conflicts or ambiguities in the requirements Summarize the collected requirements at the end of the session and ensure that all stakeholders agree on the documented requirements Interviews: a Identify interview participants: Determine the key stakeholders to interview, including Carly Edwards (Project Sponsor) and Megan Taylor (Co-founder) Consider conducting interviews with a sample of customers to gather their perspectives as well b Prepare interview questions: What are the essential features that you envision in the digital music download system? How you imagine the user experience when searching for and purchasing digital music downloads? Are there any specific requirements or capabilities that you consider critical for the success of the system? c Conduct the interviews: Start the interviews by explaining the purpose and assuring stakeholders that their input is valuable Ask the prepared interview questions, giving stakeholders enough time to provide detailed SRS (Software Requirements Specification) for the Tune Source 3.1 Introduction Purposes Sales Growth: By offering customers the convenience of online shopping, Tune Source aims to increase its annual sales The existing reputation of Tune Source as the go-to place for rare audio recordings will be leveraged to attract customers to the online platform Website Maintenance: The project includes the ongoing maintenance and management of the website The IT department at Tune Source, along with the assistance of the Internet Service Provider (ISP), will ensure the smooth functioning of the website and address any technical issues that may arise Customer Satisfaction: The project aims to enhance the overall customer experience by providing an intuitive and efficient website interface Customers should be able to easily search for their desired CDs, access detailed information about the recordings, and make purchases securely Scope The scope of the Tune Source project includes developing an online platform for customers to search for and purchase CDs in the genres of jazz, rock, country, and folk It involves implementing features such as catalogue browsing, search functionality, music sample playback, user registration and accounts, secure online payment processing, and website maintenance The scope also encompasses integration with the existing IT infrastructure and ensuring compatibility with evolving web technologies 3.2 General discription Business requirements Providing access to a comprehensive music archive with a focus on hard-to-find and classic jazz, rock, country, and folk recordings Allowing customers to listen to music samples before making a purchase Introducing customer subscription accounts for unlimited downloads Selling music download gift cards Capitalizing on digital music sales to drive cross-selling opportunities Achieving revenue growth through increased sales and new revenue streams User needs Access to a wide range of music genres Easy search and discovery of music Personalized accounts and preferences Subscription options for unlimited music downloads Gift card options for gifting music Reliable and responsive website experience 3.3 Software features and requirements Features Music Search: Users can search for music tracks based on artist, album, genre, or other criteria Music Sampling: Users can listen to short music samples to preview tracks Online Purchasing: Users can purchase music tracks and albums online Gift Card Sales: Users can purchase gift cards for digital music downloads Account Management: Users can create and manage personalized accounts, including order history and preferences Functional requirements and Non-Functional requirements These requirements are defined at part I, FRs and NFRs (above) III Discussing how would trace these requirements throughout the project (M3) I would use SDLC to trace these requirements throughout the project SDLC is a process that defines the various stages involved in the development of software for delivering a high-quality product SDLC stages cover the complete life cycle of a software i.e from inception to retirement of the product