Download Software Development Life Cycle and more Essays (high school) Design in PDF only on Docsity!
ASSIGNMENT 0 2 FRONT SHEET
Qualification BTEC Level 5 HND Diploma in Computing Unit number and title Unit 0 9: Software Development Life Cycle Submission date Date Received 1st submission Re-submission Date Date Received 2nd submission Student Name DO THE SON Student ID GCD Class GCD1002 Assessor name Phyomin Tun Student declaration I certify that the assignment submission is entirely my own work and I fully understand the consequences of plagiarism. I understand that making a false declaration is a form of malpractice. Student’s signature Thế Sơn Grading grid P5 P6 P7 M3 M4 M5 M6 D3 D
❒ Summative Feedback: ❒ Resubmission Feedback: Grade: Assessor Signature: Date: Internal Verifier’s Comments: Signature & Date:
1.2 Wireframe designs. ...................................................................................................................................................................................................................... 24
- Hardware architecture........................................................................................................................................................................................................................ 30 References ................................................................................................................................................................................................................................................. 32 Figure 1 Stakeholders ................................................................................................................................................................................................................................. 5 Figure 2 Use-case of Customer ................................................................................................................................................................................................................. 15 Figure 3 Use-case of Administrator........................................................................................................................................................................................................... 16 Figure 4 Use-case of Marketing ................................................................................................................................................................................................................ 16 Figure 5 Context diagram .......................................................................................................................................................................................................................... 18 Figure 6 Data Flow Level.0 Diagram of Tune Source .............................................................................................................................................................................. 21 Figure 7 The system’s ERD....................................................................................................................................................................................................................... 22 Figure 8 homepage .................................................................................................................................................................................................................................... 25 Figure 9 cart page ...................................................................................................................................................................................................................................... 26 Figure 10 payment page ............................................................................................................................................................................................................................ 27 Figure 11 Log up ....................................................................................................................................................................................................................................... 28 Figure 12 Log in ........................................................................................................................................................................................................................................ 29
I. Undertake a software investigation to meet a business need (P5).
1. What Is a Stakeholder?
A stakeholder is either a person, group or organization that’s influenced by the result of a project or a commercial endeavor. Stakeholders have an interest in the success of the project and might be inside or outside the organization that’s supporting the initiative. Stakeholders are crucial because they may have a good or negative effect on the project through their choices. There are also crucial or key stakeholders, whose support is required for the initiative to exist.
Figure 1 Stakeholders Formally, he Scrum team recognises just three roles: developer, scrum master, and product owner. A stakeholder is a person or organization with knowledge regarding goods and consumers. The Stakeholder will contact with the Product Owner, Scrum Master, or Developer on a regular basis to give feedback and project needs.
- Client : The person or organization in responsibility of paying for the consumption of the project's goods and services. Customers may be internal (such as the CEO, CIO, etc.) or external (depending on the project) (depending on the project).
- User : An person or organization that utilizes the project's goods and services directly. Internal and external users might exist in every organization, just as consumers. The client and the user may be the same individual depending on the project.
- Donors : An person or group that offers resources, financial support, or other aid to a project. The project will be approved by the sponsor's signature on the project charter.
- Clients should be able to examine the firm's present state as well as numerous offers offered by the company through the system.
- Clients should be able to verify their due amount and pay the due or premium amount straight from the system.
- The system should also enable the option of making an advance payment.
- Clients should be able to check their insurance start date and allow ample time to collect payments from the firm.
- Clients should be able to view their personal status via the system while at home.
3. Identify FRs and NFRs of the Tune Source Project.
3.1 FRs (Functional requirements).
These are required criteria because they are technical needs specified by the client. The following are the specific functional demands that arose from the aforementioned criteria:
- Process-oriented : Users must be able to accomplish the following with the system:
- Look for your favorite songs.
- Play the music samples.
- Purchase a single download song or album for a fixed charge per download.
- Purchase music download and listening gift cards.
- Creating a user subscription account that permits limitless downloads for a price for a certain length of time.
- Pay for services on the Tune Source platform using a choice of electronic payment methods such as online banking, E-wallets, Mastercard, and so on.
- Information Orientation : The user must be educated about the following things via the system: - The remaining time on the user's account will be cancelled.
- Previous Tune Source platform transactions, providing the user's data, transaction time, item, and cost.
- Prices for things for sale on the Source Tune platform, such as soundtracks and vouchers, are regularly modified.
3.2 NFRs (Non-functional requirements).
These are the essential conditions for obtaining the desired product quality, which include:
- Operational : The system should be:
- Capable of running a vast range of current tools, notably portable devices.
- It is possible to execute it in any web browser.
- Performance : Any interaction between the user and the system should last no more than three seconds.
- A single track may only be downloaded once every three minutes.
The system must be operational 24 hours a day and manage up to 200 concurrent visitors.
The quality of music listening must be commensurate to the amount spent.
- Security :
- The system must integrate all available anti-virus, worm, trojan horse, and other protections.
The user's account password must be encrypted so that it is not given to anyone else, including the administrator.
The relationship and comparison between functional and non-functional needs is as follows: Functional Requirements Non-Functional Requirements A system or one of its components is defined by a functional requirement. A software system's quality characteristic is defined by a non- functional need. It is mandatory. It is not mandatory. It is captured in use case. It is captured as a quality attribute.
Defined at a component level. Applied to a system as a whole. Usually easy to define. Usually more difficult to define. Functional Testing like System, Integration, End to End, API testing, etc are done. Non-Functional Testing like Performance, Stress, Usability, Security testing, etc are done. Helps you verify the functionality of the software. Helps you to verify the performance of the software.
4. Techniques used for obtaining the requirements.
4.1 Joint Application Development (JAD).
Joint Application Development (JAD) is a process that accelerates the design of information technology solutions. JAD uses customer involvement and group dynamics to accurately depict the user's view of the business need and to jointly develop a solution. Before the advent of JAD, requirements were identified by interviewing stakeholders individually. The ineffectiveness of this interviewing technique, which focused on individual input rather than group consensus, led to the development of the JAD approach. The following key commitments must be met in order for the Tune Source project JAD session to proceed as planned: Executive Sponsor: The executive sponsor is the individual from the customer's company who has the final power to make decisions regarding the project. The sponsor may be the customer's project leader, the CIO, or, in certain situations, the CEO. The facilitator works with the sponsor to get the project started; it is crucial, however, that the sponsor make critical choices, not the facilitator
Observer : Keeps track of the JAD session parameters, Tune Source end-user requirements, and each stage of a Tune Source project. ·Watch and listen. ·Learn about user needs and workshop decisions. ·Interact with the participants and facilitator only during breaks or before and after sessions.
4.2 Interview.
This stage also incorporates stakeholders from the ABC firm's clients (Tune Source company) to software developers, IT managers, and others, but it won't take place simultaneously with sessions like JAD that entail complete stakeholder participation. To conduct the interviews with specific clients and the engineering team, we will break the sessions into the following sections:
- Customer : Prior to creating the system's functional requirements based on the information from those interviews, we will undertake technical specifications-accurate technical specifications interviews with executives from the Tune Source group. As a consequence, we have a deeper grasp of the problems that our stakeholders are worried about. By relying on these insights, our organization will be better equipped to build a solution that matches Tune Source's demands.
- Engineering team: We will conduct an internal interview to acquire a better knowledge of the project execution process. Industry specialists will explain non-functional attributes and how functional demands are satisfied. The essential documentation for both the functional and nonfunctional components of the Tune Source system is provided in this technical phase.
4.3 Observation.
This concept may be proven utilizing the current Tune Source project execution procedure, sometimes known as the "AS IS" approach. I investigated for any anomalies in my observations of the "AS IS" approach since Tune Source has its own website that was developed by an Internet consulting business. The following phase asked my colleagues and me to contrast the present method with the "SHOULD BE" approach. We'll be paying careful attention to how the Tune Source project's software operates. Interviews may not always offer us a thorough understanding of the issues and components of a project, but observation can provide us a visual representation of how the project is operating right now.
II. P6 Use appropriate software analysis tools/techniques to carry out a
software investigation and create supporting documentation.
1. Use case diagram
In the Use Case Diagram of the Tune Source project: users interact with the system such as Register (Provide Customers Information and Link Payment Information), View Songs Detail, Listening to Sample Music (After finding or picking the proper songs), and Purchase Subscription (After login for purchasing gift card, download songs, and listen to original songs) (After login for buy gift card, download songs, and listen to original songs).
Figure 3 Use-case of Administrator Figure 4 Use-case of Marketing
2. Context diagram.
To define and make apparent the limits of the software system, a context diagram—also known as a level 0 data-flow diagram— is developed. The information flows between the system and outside organizations are recognized. One process represents the full software system. The Tune Source Digital Music Download System, which is employed in this process, gets data streams from the customer side as well as the Payment Authorization team, Tune Source Marketing Managers, and IT Managers. Customer activities on the system are included in the flow of customer data, including (Providing payment details and personal information, sending song search requests, choosing songs, sending music purchase requests) (Providing payment information and personal information, sending song search requests, selecting songs, sending music purchase requests). When a client requests a song, the system delivers back search results, and when the customer picks the song, it sends back a short sample of the music. The methods of collecting Sale Patterns and transmitting Promotion Decisions to the System are incorporated in the data flow of the Tune Source Marketing Managers team. After receiving the payment request from the system, Payment Authorization verifies it before delivering the payment confirmation. Customers' contact information is obtained by IT Managers, who also submit requests for music uploads to the system when support is requested.
DFD in the Tune Source project at Level.0 include three essential elements:
- Three core systems exist, including (marketing system, music search and browsing system, customer management system) (marketing system, song search and browsing system, customer management system).
- The system is touched by three external elements, namely (Payment processing, customers, and marketing managers) (Payment processing, customers, and marketing managers).
- Major systems and external entities are linked through seven datastores, including (Promotions Plan, Songs management system, customers likes songs, consumers interest songs, shopping cart, sales data, customers data) (Promotions Plan, Songs management system, customers favorites songs, customers interest songs, shopping cart, sales data, customers data).
