ASM 2 SDLC1623 FPT Greenwich (Merit Super Sale)

Điểm của bài asm còn tùy thuộc vào người chấm. Chỉ cần paraphase bài này là có thể pass. 1 trong nhưng tool paraphase mình recommend là quillbot.The submission is in the form of 1 document.● You must use the Times font with 12pt size, turn on page numbering; set line spacing to 1.3 andmargins to be as follows: left = 1.25cm, right = 1cm, top = 1cm, bottom = 1cm. Citation andreferences must follow the Harvard referencing style. ASSIGNMENT FRONT SHEET Qualification BTEC Level HND Diploma in Computing Unit number and title Unit 2: Networking Infrastructure Submission date Date Received 1st submission Resubmission Date Date Received 2nd submission Student Name Student ID Class Assessor name 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 P1 P2 P3 P4 M1 M2 D1 ❒ Summative Feedback: Grade: Lecturer Signature: ❒ Resubmission Feedback: Assessor Signature: Date: Table of Contents I Network Network definiton

ASSIGNMENT 02 FRONT SHEET

Unit number and title Unit 09: Software Development Life Cycle

Student declaration

I certify that the assignment submission is entirely my 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

❒ Summative Feedback: ❒ Resubmission Feedback:

Internal Verifier’s Comments:

Signature & Date:

Table of Contents

Table of Contents 1

List of Tables 2

List of Figures 2

INTRODUCTION 3

TASK 1 – ANALYSIS(1) 4

A UNDERTAKE A SOFTWARE INVESTIGATION TO MEET A BUSINESS NEED(P5) 4

1 Requirement definition of the project: 4

1.1 Identify the stakeholders, roles, and interests in the case study 4

1.2 Stakeholder role with an interest 5

2 Identify FRs and NFRs of the Tune Source Project 6

2.1 Functional Requirements 6

2.2 Non-Functional Requirements 7

3 Discuss the relationships between the FRs and NFRs 8

3.1 Discuss the approach/technique (es) you'd take to obtain the requirements 8

3.2 Demonstrate how to collect requirements based on the chosen technique 12

TASK 2 – ANALYSIS (2) 16

B USE APPROPRIATE SOFTWARE ANALYSIS TOOLS/TECHNIQUES TO CARRY OUT A SOFTWARE INVESTIGATION AND CREATE SUPPORTING DOCUMENTATION(P8) 16

1 Use Case Diagram for the whole system 16

2 Use Case specification for 2 Use cases 18

2.1 View music use case 18

2.2 Payment Use-case 20

3 Context Diagram for the whole system 21

4 Data Flow Diagram – Level 0 for the whole system 22

5 ERD for the whole system 23

6 Pseudo Code For One Module Of The Program 24

TASK 3 – DESIGN 25

C EXPLAIN HOW USER AND SOFTWARE REQUIREMENTS HAVE BEEN ADDRESSED(P7) 25

I Discuss how the user and software requirements are addressed in the design phase 25

1 Explain how Mock-up, and Wireframe are used in the project 25

2 Explain which architecture (client-server, n-tier, microservices, etc.) is suitable for the project with clear

illustrations and why 28

3 Explanation of why the chosen three-tiered is suitable for this project 30

4 Address which technical solution stack could be suitable to implement the project with clear explanations 30 CONCLUSION 31

References 31

List of Tables Table 1: Stakeholders in Tune Source project clearly indicating which stakeholder(s) provide what requirements 5

Table 2: Stakeholder role with an interest 5

Table 3: Functional functional requirements for the Tune source projects 6

Table 4: Non-functional requirements for tune source projects 7

Table 5: Different between FRs & NFRs 8

Table 6: Techniques used for requirement gathering requirement combination of two or more techniques can be allowed 12

Table 7: Whole system usecase 16

Table 8: View music use case 19

Table 9: Payment use case 21

Table 10: Technical Solution Stack 30

List of Figures Figure 1: Whole system usecase diagram 16

Figure 2: View music use case diagram 18

Figure 3: Payment Use-case diagram 20

Figure 4: Context Diagram for the whole system 21

Figure 6: Data Flow Diagram level 0 22

Figure 7: ERD diagram 23

Figure 8: Pseudocode for login module 24

Figure 9: Main Interface of Software 25

Figure 10: Login Wirefram of software 25

Figure 11: Monthly fee Wireframe 26

Figure 12: User Wireframe 27

Figure 13: Payment Wireframe 27

Figure 14: Three-Tier Architecture 28

Figure 15: Achieve the true Three-tier architecture 29

INTRODUCTION

The Software Development Life Cycle (SDLC) can be viewed as a well-defined procedure for producing high-quality, low-cost software in the shortest amount of time possible The SDLC's purpose is to create exceptional software that exceeds all customer expectations and demands The SDLC is a step-by-step process that specifies and explains a detailed plan with stages, or phases, that each has its methodology and deliverables This report will deeply discuss and present how to undertake a software development lifecycle and discuss the suitability of software behavioural design techniques when working in the TuneSource Project

TASK 1 – ANALYSIS(1)

A UNDERTAKE A SOFTWARE INVESTIGATION TO MEET A BUSINESS NEED(P5)

1 Requirement definition of the project:

1.1.Identify the stakeholders, roles, and interests in the case study

The first process in the Project Communications Management Knowledge Area is Identify Stakeholders, which is part of the Initiating process group This procedure entails identifying and recording all project stakeholders and their interests, impacts, and any negative impacts on the project Stakeholder identification should begin as soon as feasible and continue throughout the project's life cycle (Johnston, 2020)

There are two types of stakeholders in a project which are internal stakeholders and external stakeholders:

a Internal Stakeholders:

Internal stakeholders are people who work within the system or organization being evaluated Internal stakeholders may include physicians, nurses, pharmacists, therapists, administrative employees, porters, and managers if the system is part of a hospital

Internal Stakeholders in TuneSource: Founders: John Margolis, Megan Taylor, Phil Cooper, Carly Edwards, Assistant Vice President, Marketing Department, IT department

b External Stakeholders:

External stakeholders are not part of the system that is being evaluated, yet they are nevertheless impacted by it External partners may include GPs and community health professionals, social care commissioners, professional organisations, and regulators, for example, if the system is a hospital Internal Stakeholders in TuneSource: Customers

Stakeholder Objectives Requirement Provided

 Founders: John

Margolis, Megan

Taylor, Phil Cooper

 Project Sponsor: Carly

Edwards, Assistant Vice

 Product/service quality and value

 Reaching new customers who are interested in our unique archive of rare and hard-to-find music

 Increase sales by creating the capability

of selling digital music downloads

 Gain a new revenue stream from customer subscriptions and gift-card

 Ability to offer digital music downloads

 Contain Specific functionality that the system should have, short-term development

 Requesting this capability, well designed

Table 1: Stakeholders in Tune Source project clearly indicating which stakeholder(s) provide what requirements

1.2 Stakeholder role with an interest

Stakeholder Role Interest Note

 Founders: John

Margolis, Megan

Taylor, Phil Cooper

 Project Sponsor: Carly

 Profits, increase revenues

 Support extending the effect

of TuneSource has on the community

“Because customers have

a number of music download options available to them elsewhere, we need to bring this system

to the market as soon as possible.”

“Many of our current loyal customers have been requesting this capability, and we need to provide this service or face the loss of these customers’ business.”

 Marketing department

 IT department

 Social and Environmental Responsibilities

 Customers  Assess & feedback on

quality and value

 Social impact & efficiency

& quality of this software

 Unique archive of rare and hard-to-find music

Nothing

Table 2: Stakeholder role with an interest

2 Identify FRs and NFRs of the Tune Source Project

2.1 Functional Requirements

A Functional Requirement (FR) is a statement that describes the service that the program must provide

It refers to a software system or a component of one A function is nothing more than the inputs, behaviour, and outputs of a software system A computation, data manipulation, business procedure, user interaction, or any other unique feature that determines what function a system is likely to execute can all be considered (Martin, 2022)

Functional Requirements Description Example

Search for music in our digital

music archive

This software needs to have an easily visible search box (search by text or search by voice recorder) to search any available music in their digital music archive

Able to search a rock recording

in a search box in the top navigation of this software

Listen to music samples The program should permit the user to

listen online to music samples in the digital music archive of this software

The user clicks and tries listening

to jazz song samples

Purchase individual downloads at a

fixed fee per download

Establish the fixed fee per download and develop a system that can support the user perform purchasing functions to what music they want

The user purchases a rock album

at a fixed cost

Establish a customer subscription

account permitting unlimited

downloads for a monthly fee

Develop the system which permits the user to sign up for their subscription account and this account is able to unlimited download for a monthly fee

The user creates your subscription account to download 70 country albums

Purchase music download gift

cards

The software should provide the gift cards which customers can purchase for downloading their favourite music

Customers purchase a music download gift cards to download music

Table 3: Functional functional requirements for the Tune source projects

2.2 Non-Functional Requirements

The Non-Functional Requirement (NFR) provides a software system's quality attribute They assess the software system on the basis of its responsiveness, usability, security, portability, and other non-

functional criteria that are crucial to its success

Non-Functional Requirements Description Example

This software needs to be kind of

scalability

The scalability of this software needs to

be upgraded and developed so that the server can proceed with requests from millions of users without affecting its performance

Now, this software is capable enough to handle 5 million users and its server can be upgraded to serve more than 10 million users

moving from one OS to another OS

Using it on Mac and then use it

Some services such as updating high-quality music could be applied by fee

record the tasks performed on the system, for testing purposes

Every unsuccessful attempt by a user to access an item of data shall be recorded on an audit trail

with MD5

The system will deactivate for 30 minutes if the user enters the wrong password 5 times in a row

All user's "sensitive" data such as password, phone number, ID card, and email must be encrypted with 1024bit SSL

Privacy of information, the export of restricted technologies, intellectual property rights

Table 4: Non-functional requirements for tune source projects

3 Discuss the relationships between the FRs and NFRs

Following is the relationships between the Functional Requirement and Non-Functional Requirement

Functional Requirement Non-Functional Requirement

A functional requirement is a specification that describes

a system or one of its components

A software system's quality attribute is defined by a functional

non-"What should the software system do?" it asks "How should the software system meet the functional

requirements?" is constrained

The user specifies the functional requirements Technical individuals, such as architects, technical

leaders, and software engineers, specify non-functional requirements

System, integration, end-to-end, API, and other types of

functional testing are carried out

Non-functional testing is carried out, such as performance, stress, usability, and security testing

Test Execution is done before non-functional testing After the functional testing

Table 5: Different between FRs & NFRs

3.1 Discuss the approach/technique (es) you'd take to obtain the requirements

Here are some approaches to obtain the requirements:

a) Joint Application Development (JAD)

JAD is a strategy for gathering information that allows our project team, users, and management to collaborate to determine system needs

JAD is a structured procedure in which 10 to 20 users gather under the leadership of a facilitator knowledgeable in JAD techniques to limit scope creep by 50%

Pros Cons

 Documentation is produced within hours and

returned to participants for approval as soon as

possible

 On-the-spot certification of requirements is

possible

 In a short amount of time, successfully gathered

needs from a big group

 When concerns and questions are raised in front of

all stakeholders, consensus can be reached

 Stakeholder availability may jeopardize the meeting

 The facilitator's expertise determines the success rate

 If there are too many people in the workshop, the goal will be impossible to achieve

 By developing rapport with the stakeholder, you

may encourage involvement and form

partnerships

 Planning and conducting interviews take time

 All of the participants must make a commitment

 It is sometimes necessary to receive training in order

to conduct good interviews

c) Observation

The major goal of the observation session is to learn about other people's activities, tasks, tools, and events

All stakeholders are aware of the goal of the observation session, they agree on the expected

outcomes, and the session satisfies their expectations, according to the observation plan You must make it clear to the participants that their performance will not be evaluated

During the session, the observer should keep track of all actions and the time it takes others to complete the job so that he or she can duplicate it The BA will analyze the results and follow up with the participants after the session The act of observation might be active or passive

 Rather than doing one-on-one interviews, you may

gather information in a single session

 A healthy environment is created by active

dialogue among the participants

 It is possible to gain knowledge through the

experiences of others

 Participants may become agitated

 Observers may not receive a clear image if participants change their working methods throughout the observation

 Knowledge-based actions are invisible

d) Document Analysis

This method is used to obtain business data by evaluating and examining the items available that define the company environment This analysis aids in validating the execution of current solutions

as well as understanding the business requirement

Reviewing business plans, technical papers, problem reports, and existing requirement documents, among other things, is part of document analysis When it comes to updating an existing system, this

is really handy

This method is beneficial in migration initiatives

This approach is useful for finding system flaws, such as comparing the AS-IS and TO-BE processes When the individual who developed the current documentation is no longer in the system, this analysis can help

 Current and future procedures can be

compared using existing documentation

 It's possible that existing papers will not be updated

 Existing documents might be utilized as a

starting point for further research

 It's possible that existing records are entirely out of date

 It's possible that the resources who worked on the previous materials won't be available to give information

 This procedure takes a long time

e) Questionares

Stakeholders are given a series of questions to answer in order to quantify their ideas Following the collection of answers from stakeholders, the data is evaluated to determine the stakeholders' areas of interest

High-priority threats should be the basis for questions Direct and straightforward questions are preferred Notify the participants and remind them to participate once the survey is complete

 When compared to interviews, you can

acquire more accurate information

 It is possible that not all stakeholders will take part

Table 6: Techniques used for requirement gathering requirement combination of two or more techniques can be allowed

3.2 Demonstrate how to collect requirements based on the chosen technique

To gather requirements for this project, I used the “interview” approach Particularly, I created the Google Form survey to make a quick interview survey:

Figure 2: Google Form Survey1

Figure 1: Google Form Survey 2

Figure 4: Google Form Survey3

Figure 3: Google Form Survey4

After share the link of this google form survey to some internal stakeholders and run seeding it around some popular social media, I receive the specific responding results of this survey:

Figure 5: Google Survey Result 1

Two images above show that in the number of interviewers engage this survey(123 people), there are approximately 69,6% know the TuneSource above(the positive number) About the functions of this software, almost interviewers choose the search function In other word, the search function become the most necessary in this software Other functions also are chosen quite same to each other

The image above shows that the platform used mostly is window, the following is Mac and Androi/IOS Linux is the platform which receive no use for interviewers With the payment method, banking is the most popular which

outweight the other methods The following is Credit/Debit, cryptocurrency

Figure 6: Google Survey result