Tải bản đầy đủ (.pdf) (56 trang)

Software huỳnh trần anh khoa GCS200252 2426782

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.49 MB, 56 trang )

ASSIGNMENT 02 FRONT SHEET
Qualification

BTEC Level 5 HND Diploma in Computing

Unit number and title

Unit 09: Software Development Life Cycle

Submission date

06/03/2022

Date Received 1st submission

06/03/2022

Re-submission Date

09/03/2022

Date Received 2nd submission

09/03/2022

Student Name

Huỳnh Trần Anh Khoa

Student ID


GCS200252

Class

GCS0903B

Assessor name

Thái Thị Thanh Thảo

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

KHOA

Grading grid
P5
X

P6
X

P7
X

M3

M4


M5

M6

D3

D4


❒ Summative Feedback:

Grade:
Internal Verifier’s Comments:

Signature & Date:

❒ Resubmission Feedback:

Assessor Signature:

Date:


Assignment Brief 02 (RQF)
Higher National Certificate/Diploma in Business
Student Name/ID Number:
Unit Number and Title:

Unit 09: Software Development Life Cycle


Academic Year:
Unit Assessor:
Assignment Title:

Undertake a software development life cycle

Issue Date:

07/12/2020

Submission Date:
Internal Verifier Name:
Date:

Submission Format:
Format:


● 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 and
margins to be as follows: left = 1.25cm, right = 1cm, top = 1cm, bottom = 1cm. Citation and
references must follow the Harvard referencing style.
Submission:
● Students are compulsory to submit the assignment in due date and in a way requested by the Tutor.
● The form of submission will be a soft copy posted on />● Remember to convert the word file into PDF file before the submission on CMS.
Note:
● The individual Assignment must be your own work, and not copied by or from another student.



If you use ideas, quotes or data (such as diagrams) from books, journals or other sources, you
must reference your sources, using the Harvard style.

● Make sure that you understand and follow the guidelines to avoid plagiarism. Failure to comply
this requirement will result in a failed assignment.
Unit Learning Outcomes:
LO3 Undertake a software development lifecycle.
LO4 Discuss the suitability of software behavioural design techniques.

Assignment Brief and Guidance:


Tasks
At this stage, you have convinced Tune Source to select your project for development. Complete the
following tasks to analyse and design the software.
Task 1 – Analysis (1)
1. Identify the stakeholders, their roles and interests in the case study.
Review the requirement definition of the project. Clearly indicate which stakeholder(s) provide what
requirements.
Word limit: 150 – 200.
Identify FRs and NFRs of Tune Source Project.
Discuss the relationships between the FRs and NFRs.
Word limit: 300 – 400 words.
2. Discuss the technique(s) you would use to obtain the requirements.
If needed, you may state suitable additional assumptions about the project in order to justify the
technique(s) that you choose.
Techniques: JAD, Interview, Observation, etc.
Demonstrate how to collect requirements based on chosen technique.
Word limit: 700 – 1000.
3. Discuss how you would trace these requirements throughout the project by using Requirement

Traceability matrix. You will have to provide real usage of it.
Word limit: 400 – 500 words.
Task 2 – Analysis (2)


Analyze the requirements that you identified in Task 1 using a combination of structural and behavioral
modelling techniques that you have learnt.
Scope: You only need to construct following items for the system. You will have to include:






Use Case Diagram for the whole system.
Use Case specification for 2 Use cases.
Context Diagram for the whole system.
Data Flow Diagram – Level 0 for the whole system.
ERD for the whole system.

For each diagram, you will have to explain properly.
Word limit: 1000 – 1200 words.
Task 3 – Design
Based on the analysis result, discuss how you would conduct the design phase:
1. Discuss how the user and software requirements are addressed in the design phase.
● You will explain how Mock-up, and Wireframe are used in the project. You should include some
of the mockup or wireframe (at least 5) design of the Tune Source project to justify that it matches
users’ requirements.
● You will explain which architecture (client – server, n-tier, microservices, etc.) is suitable for the
project with clear illustrations and why.

● Then you will address which technical solution stack could be suitable to implement the project
with clear explanations.
2. Discuss how activity diagram and pseudocode are used to specify the software behaviour.
3. Discuss how UML state machine can be used to specify the software behaviour. Differentiate between
FSM and extended FSM using the case study.


4. Discuss how the data-driven approach improves the reliability and effectiveness of software.
Word limit: 800 – 1500.
Task 4 – Software quality management
1. Discuss two software quality attributes that are applicable to the project.
2. Discuss two quality assurance techniques that can help improve the software quality in the project.
3. Discuss how the design techniques and approaches that you have used can help improve the software
quality.
Word limit: 400 – 1500.


Learning Outcomes and Assessment Criteria (Assignment 02):
Learning
Outcome

Pass

P5 Undertake a software
investigation to meet a
business need.
LO3 Undertake a
software
development
lifecycle


LO4 Discuss the
suitability of
software
behavioural
design techniques

P6 Use appropriate
software analysis
tools/techniques to carry
out a software
investigation and create
supporting documentation.

P7 Explain how user and
software requirements
have been addressed.

Merit

Distinction

M3 Analyse how software
requirements can be traced
throughout the software
lifecycle.

D3 Critically evaluate
how the use of the
function design

paradigm in the
software development
lifecycle can improve
software quality.

M4 Discuss two
approaches to improving
software quality.

M5 Suggest two software
behavioural specification
D4 Present
methods and illustrate their justifications of how
use with an example.
data driven software
M6 Differentiate between can improve the
reliability and
a finite state machine
effectiveness of
(FSM) and an extendedsoftware.
FSM, providing an
application for both.


1. List all necessary components in a design document
● Analyze customer needs
● Analyze customer requirements
● Inventor of Ideas
● Checking
● Testing

● Backup
● Fixing
2. How many System acquisition strategies? Explain each strategy in detail.
The Acquisition Strategy is a detailed plan that identifies and specifies the acquisition strategy that Program Management will use to manage program risks and
accomplish program objectives. The Acquisition Strategy directs program execution throughout the program's life cycle and is modified at each significant
milestone and review. The Milestone Decision Authority (MDA) at Milestone A and the Development RFP Decision Point assess and approve an acceptable
strategy. At Milestone B, Milestone C, and Full-Rate Production Decision (FRPD) review, the acquisition plan is then modified for MDA approval.

Table of Contents

Assignment Brief 02 (RQF)
Higher National Certificate/Diploma in Business
Table of Contents
P5 Undertake a software investigation to meet a business need.
I/ Definition of Requirement

3
3
9
12
12

Stakeholders

12

Identify stakeholders for the Tune Source project

13



Requirements

13

The requirement definition of the project

13

II/ Techniques for eliciting requirements

15

Personal interview

15

Development of Joint Applications (JAD)

16

JAD participants

17

JAD Meetings

18

The Benefits of Joint Application Development


19

Phases of JAD

19

When to use JAD?

19

Joint Application Development Challenges

20

Questionnaires

21

Document Examination

22

Observation

23

Choosing the Most Appropriate Techniques

23


P6 Use appropriate software analysis tools/techniques to carry out a software investigation and create supporting documentation.

26

Use Case Diagram

26

Context Diagram

30

Data flow diagram (DFD)

31

Definition

31

Tune Source DFD Level 0 Project

35


ERD

38


Flowchart

41

Search in web

41

Purchase

43

Tools and techniques for conducting a software investigation

45

Documentation in support

49

P7 Explain how user and software requirements have been addressed.

50

Use Interface

50

Purchase and Download Function


53

Conclusion

56

References

56


P5 Undertake a software investigation to meet a business need.
I/ Definition of Requirement
1) Stakeholders
As an example (Somerville, 2016) Individuals, people, and organizations with close interaction with enterprises, particularly in projects, are referred to as
stakeholders. This is the object of interest, which may share resources, effect, and/or be impacted directly or indirectly to the business activities of strategy, plan,
and business operations at the same time. This is also a category of things that can have an impact on or decide the existence and development of a business.
Here are a few examples:
- Speculators
They are the company's original and most significant owners since they invested in it and expect a reasonable return on their investment.
- Debtors
Creditors are banks or large corporations that lend money to the company. Retail customers who purchased the company's bankruptcy filings and lending
instruments may be creditors.
- Employees
Employees are the most critical business partners. They are in charge of making choices and running the firm. They put in the time, effort, and expertise
necessary to run the businesses for which they are paid.
- Clients
Because the consumer does business with the company, he or she is an important linked party to the company. Businesses look for possibilities and examine
product demand. They design and manufacture items that clients require and that can address their day-to-day challenges.



2) Identify stakeholders for the Tune Source project
It has a link with the music business, according to the Tune Source scenario: John Margolis, Megan Taylor, and Phil Cooper. John and Phil worked together to
build multiple brick-and-mortar stores in southern California selling hard-to-find and classical music, rock, country, and folk recordings. Tune tune has recently
partnered with an online consulting business (ISP).
The initiative is sponsored by Carly Edwards, Assistant Vice President, Marketing.
Management: My organization is now working with Tune Source to create the prototype. ABC's project manager is me.
Device users include individuals who stream music from the Tune Source website and those who utilize retail kiosks.

3) Requirements
As an example (Dennis, 2014) A need might be a single recorded physical or functional necessity that a particular design, product, or process tries to meet. It is
widely used in engineering design in a correct meaning, such as in systems engineering, software engineering, or enterprise engineering. It's a wide notion that
can refer to any required (or sometimes desirable) function, attribute, capacity, trait, or quality of a system in order for it to be valuable and useful to a customer,
company, internal user, or other stakeholders. A requirement specification or requirement "spec" (often imprecisely referred to as "the" spec/specs, but there are
literally different types of specifications) refers to a specific, highly objective/clear (and often quantitative) requirement (or sometimes, set of requirements) to be
satisfied by a cloth, design, product, or service.
4) The requirement definition of the project
We will work with stakeholders to develop the specs and include some of the fundamental responsibilities that the project would necessitate. Let's begin by
making an account, looking for music, listening to it, and then placing an order. Before making an order, customers may also see invoices and make adjustments
to orders directly on the invoice. You may buy the music or pay for a monthly charge and get unlimited downloads. The consumer can resume the update at any
point during the procedure. Customer information would be kept confidential.
Functional prerequisites


As an example (Sommerville, 2016) Functional prerequisites These are assertions about the services that the system should deliver, how the system should
respond to inputs, and how the system should behave in specific scenarios. In certain circumstances, the functional requirements may expressly indicate what the
system should and should not accomplish.
Tune Source is functional.
Customers may use the internet or retail kiosks to search for and purchase digital music downloads. Among the extras are:
• Look for music in the optical media collection.

• Play the song you've chosen.
• Buy individual downloads at a fixed price per copy.
• Create a consumer registration account and pay a subscription fee for limitless downloads.
• Purchase download-able tunes and presents.
Music selections will be personalized to the consumer on subsequent visits to the website based on past sales. Customers' interests may be used to alert them of
unique discounts on CDs that can be purchased at the daily Tune Source web site or in a Tune Source shop.
Nonfunctional Prerequisites

As an example (Sommerville, 2016) Non-functional prerequisites These are limitations on the system's services or operations. They include temporal limitations,
event process restrictions, and standards-imposed constraints. Non-functional requirements frequently apply to the system as a whole rather than to particular
system features or services.
Tune Source is inoperable.
• A digital music archive would be built to facilitate music searching.
• If a customer's music transfer fails, he or she can choose to restart it or be sent to a backup download link.
• The download speed will be monitored and maintained at an acceptable rate (not too slow)


• All client information and payment information will be kept confidential.
5) Stakeholder in Tune Source project
Internal stakeholders:



Include the founders, John Margolis, Megan Taylor, and Phil Cooper, as well as the marketing staff.
Department of Information Technology.

Stakeholder from the outside:






Carly Edward is the project's sponsor.
Vice President Adjunct
A well-known local Internet Service Provider (ISP)
Clients / Users

II/ Techniques for eliciting requirements

1)

Personal interview

As an example (Dennis, 2016) The interview is the most commonly used approach for eliciting requirements. All things considered, it is normal—if you need to
know something, you usually ask someone. When everything is said and done, interviews are conducted one on one (one questioner and one interviewee),
however due to time constraints, a few persons may be met at the same time. The meeting method consists of five major steps: selecting interviewees, designing
inquiry questions, preparing for the meeting, leading the meeting, and post-meet growth.
The interviews are split into two categories:
• A private interview is one in which the interviewer prepares questions ahead of time and tries to elicit replies from stakeholders.
• An open ended interview is one in which the interviewer does not need to arrange any questions and the questions are completely random during the interview.

Benefits

Drawbacks


Extensive data collecting.

Collect information from huge groups of individuals or large sampling of
people.


Collect data for survey design or other usage activities.
It is not possible to collect data in a timely manner.
Obtaining a comprehensive perspective.

2)

Development of Joint Applications (JAD)

As an example (Dennis, 2016) Joint application development (JAD) is a data collection technique that allows the project team, clients, and the board to
collaborate to identify framework requirements. IBM developed the JAD strategy in the late 1970s, and it is typically the most useful method for acquiring
customer data. Tricks Jones assures that JAD can cut scope creep in half and avoid framework requirements from being either explicit or very cryptic, both of
which can cause problems later in the SDLC. JAD is a structured procedure in which 10 to 20 clients gather under the supervision of a facilitator skilled in JAD
procedures. A facilitator is a person who organizes the meeting and assists the talk but does not engage in it as a member. The individual does not provide
opinions or hypotheses on the topics being discussed and remains impartial during the conversation. The facilitator must be an expert in both process approaches
and frameworks, as well as inquiry and planning tactics. A pair of copyists assist the facilitator by taking notes, creating duplicates, and so forth. As the JAD
meeting progresses, the copyists will frequently use PCs and CASE devices to capture data. JAD, or Joint Application Development, is the process of designing
and developing computer-based systems/solutions. It gathers requirements side by side as per business needs while developing new information systems for a
company, implying that JAD involves the client or end-users in the design and development process. It also includes approaches for improving specification
quality and user participation through a series of collaborative workshops known as JAD sessions. Because the client is involved throughout the development
process, development times are shortened and client satisfaction is higher.


Figure 1: Room for JAD
a) JAD participants
The JAD Process involves a large number of key stakeholders. They are as follows:


Execution Process: This process is from the customer's perspective and includes the Project Manager, CIO, CEO, or CISO who has the authority to make project
decisions.

Facilitator: This person is in charge of developing, managing, and carrying out JAD activities, as well as minimizing disagreements, encouraging end-user
involvement, maintaining focus, and maintaining an unbiased approach.
IT Representatives: This person is responsible for providing technical advice and assisting the team in developing technical models and building a prototype of
the end result. They must approach and assist customers in converting their visualizations into models that meet the requirements, develop an understanding of
the end-user business goals, represent in IT functions, render end solutions that are cost-effective, and so on.
End-User: This concerned individual is usually the primary focus of JAD. They provide appropriate business knowledge and strategy, depict all key user groups
affected by development, and represent multiple levels within the organization.

Writer:
This person is in charge of precisely and effectively documenting the JAD process and JAD sessions. They usually act as a facilitator's partner in each JAD
session and provide references for the review.
Observant:
The observer will observe each JAD session and gather knowledge for end-user needs and JAD session decisions, as well as interact with JAD participants only
outside of JAD sessions.
b) JAD Meetings
The objectives and agenda items for the JAD sessions must be clearly defined. It must be ensured that key personnel from the technical and business worlds, as
well as those who take notes, are present.
Questions and items are the essences of the discussion for driving the meeting, and we should not expect quick answers. We should also ask questions, keep track
of important details, and assign action items.
The goal of JAD sessions is to stimulate creative thinking, which leads to collaborative discussions that require expertise from multiple departments.


Teams should assist one another in making decisions. If the teams are unable to reach an agreement, we must conduct scheduled JAD sessions known as JAD
workshops.
We know that the majority of JAD sessions are scheduled during the development phase, but they may occur during the project's requirements.
c) The Benefits of Joint Application Development
These are some of the primary advantages of JAD:
● Create a design from the customer's point of view.
● The collaboration of the company and the client helps to eliminate all risks.
● Progress is accelerated as a result of the close interactions.

● JAD aids in the acceleration of design while also improving quality.
● JAD encourages the team to push each other, which leads to faster work and on-time delivery.
d) Phases of JAD
Now that you're familiar with the JAD concept, it's time to learn about its phases and how the model's design and development approach works:
● Defining Specific Objectives: The facilitator, in collaboration with stakeholders, defines all of the goals as well as a list of items, which are then provided
to other developers and participants to understand as well as a review. This goal includes the scope of the proposed system as well as its potential. As a
result, technological specifications are required, and so on.
● Preparation for the session: The facilitator is solely responsible for this preparation, which includes gathering all necessary information. Data is collected
in advance and distributed to other members. Work to improve understanding has been carried out in order to learn more about the device's requirements
and to obtain all of the necessary information about the implementation.
● Session Conduct: The facilitator is in charge of identifying the issues that must be resolved in order for the system to be error-free. The facilitator will
participate in this discussion but will have no say over what information is shared.
● Documentation: Once the product has been established, reports and written papers are delivered to the meeting so that stakeholders and customers can
acknowledge it.
e) When to use JAD?
Types of Projects New Systems
● Upgrades to existing systems.
● Conversion of systems.
● System acquisition.


● Specifications of the Project.
However, JAD is not suitable for every project. A suitable project has at least some of the following characteristics:
● Involves a large number of users with responsibilities that extend beyond traditional department or division lines.
● Is the organization's first project; • Has a troubled project history or relationship between the systems and user organizations; and • Is deemed critical to
the organization's future success.
● Involves willing participants.
● Is the organization's first project of its kind.
f) Joint Application Development Challenges
● Sometimes team members' opinions differ, making it difficult to align goals and maintain focus.

● Depending on the size of the project, people in JAD may have to spend a significant amount of time.
Joint Application Development (JAD) may not be the solution that the organization requires, but it provides a more inclusive and fluid environment than others.
JAD is a technique used in the early stages of a systems development project to develop business system requirements. One of the goals of JAD is to bring MIS
and end-users together in a structured workshop, which is accomplished by experienced JAD facilitators and customized, scheduled agendas to assist participants
in completing high-quality requirements. It can also be seen that the JAD process reduces development time, costs, and errors.

Benefits

Drawbacks


JAD is capable of addressing a wide range of needs.

Because JAD is a quick solution, it is not always possible to conduct complete
verification in the smallest amount of time.

JAD provides a well-structured solution.
The JAD team requires a significant amount of subject-matter expertise and
JAD makes it possible for all project participants to communicate directly with experience.
one another.

3)

Questionnaires

As an example (Dennis, 2014) A questionnaire is a collection of questions designed to elicit information from persons. Surveys are frequently used when a large
number of people are required to provide data and hypotheses. Surveys, in our experience, are typically used for frameworks intending to use the outside of the
business (e.g., by customers or merchants) or for frameworks with commerce clients distributed across many geographic locations. Most people think of paper
when they think of surveys, but increasingly, more surveys are sent electronically, either through the mail or on the Internet. When compared to sending paper
surveys, electronic distribution can save a significant amount of money.

Structure of a Questionnaire





-

Why
usually leads to more in-depth reasons and structural understanding.
What
happens most of the time is that this leads to facts.
What is the client's problem?
When
When does the problem happen?
How
usually leads to an argument over mechanism rather than form.
Could
the most openness result in no results?


Benefits

Drawbacks

Less expensive

Anonymous

A large number of people are given questionnaires.


The Request form must be filled out depending on the respondent's degree of
expertise and basic knowledge.

Spending less time
Depending on the tools at hand

4)

Document Examination

As an example (Dennis, 2014) Document analysis is frequently used by project teams to comprehend the same system. In an ideal circumstance, the project team
has established the present system and will generate documentation, which will then be updated for all future projects. In this instance, the project team should
begin by studying the documentation and testing the system.

Benefits

Drawbacks

It saves time and money to reuse previously obtained data.

Any type of analytical evidence is required.

People are not the main source of intelligence when it comes to specifications.

This is never a viable choice when inventing a completely new approach.

It is impossible to overestimate the value of information and opinion.



5)

Observation

As an example (Dennis, 2014) Observation, or the act of witnessing forms being executed, might be a useful tool for incorporating information into the existing
structure. Perception enables the investigator to perceive the reality of a situation rather than listening to how others portray it in interviews or JAD sessions.
Several research studies have revealed that many supervisors actually don't remember how they operate and how they use their time. Perception might be a
fantastic tool to validate data gathered from other sources such as interviews and surveys.
This approach is frequently used in conjunction with other necessary procedures such as interviews and document analysis.

Benefits

Drawbacks

A very genuine tech tool is required.

It was too expensive due to the high cost of travel.

The fundamental goal of observations is to confirm and validate requests.

Analyzing can be time-consuming.

6)

Choosing the Most Appropriate Techniques

As an example (Dennis, 2014) Each of the requirements elicitation methodologies discussed has advantages and disadvantages. There is no single approach that
is always superior to the others, and most businesses benefit from a combination of methods. As a result, it is vital to understand the benefits and drawbacks of
each method, as well as when to employ each. One point that has gone unmentioned is the analysts' interaction. In general, report investigation and perception
require the least amount of preparation, whereas JAD sessions are the most difficult.



Figure 2: Type of InformationInformation


In general, assessing and viewing materials necessitates the least amount of training time, whereas JAD sessions provide the most difficult problems. So we went
with the technical interview.


×