Download Software Development Life Cycle (SDLC) Assignment: Tune Source Project and more Exercises Technology 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.1 The usage of wireframe and mockup........................................................................................................................................................................................... 18 1.2 Wireframe designs. ...................................................................................................................................................................................................................... 19
- Hardware architecture........................................................................................................................................................................................................................ 25 References ................................................................................................................................................................................................................................................. 26 Figure 1 Stakeholders ................................................................................................................................................................................................................................. 5 Figure 2 Use-case of Customer ................................................................................................................................................................................................................. 14 Figure 3 Use-case of Administrator........................................................................................................................................................................................................... 15 Figure 4 Use-case of Marketing ................................................................................................................................................................................................................ 16 Figure 5 homepage .................................................................................................................................................................................................................................... 20 Figure 6 cart page ...................................................................................................................................................................................................................................... 21 Figure 7 payment page .............................................................................................................................................................................................................................. 22 Figure 8 Log up ......................................................................................................................................................................................................................................... 23 Figure 9 Log in .......................................................................................................................................................................................................................................... 24
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.
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 Stakeholders: They represent various levels inside the ABC corporation as well as all the key user groups whose behavior the Tune Source project will affect. JAD meetings give stakeholders the chance to participate significantly in the project and receive what they want. Facilitator: The success or failure of the JAD process is intimately connected to how effectively the facilitator manages the session. This individual must be well trained as a facilitator and must have a good working understanding of the tools and procedures to be utilized for collecting requirements in the JAD sessions. The facilitator must also be able to interact successfully with the varied personality types present on a JAD team. IT Representative: IT personnel give technical advise when it is necessary, help design logical models and requirements, and construct the prototype. To accomplish these activities, employees must be educated with the JAD process and the tools and procedures being employed. IT representatives are often some of the major developers of the system. They take the JAD chance to become experts in the customer's business operations. Whatever their degree of competence, however, they must not attempt to compel the decision? making process, but rather aid in building the user's vision of the solution
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 2 Use-case of Customer
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.
3. Data Flow Level.0 Diagram.
Another term for it is a context diagram. It is designed to be an abstraction view that portrays the system as a lone process with its links to outside entities. It represents the full system as a single bubble with incoming/outgoing arrows representing input and output data. 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).
4. Entity connection diagram.
A sort of flowchart called as an entity-relationship (ER) diagram displays the links between "entities" such as humans, things, or ideas inside a system. To design or debug relational databases, ER Diagrams are most often used in the areas of software engineering, business information systems, education, and research. They also go by the titles ERDs or ER Models, and they employ a fixed set of symbols to show how entities, relationships, and their characteristics are interrelated. Rectangles, diamonds, ovals, and connecting lines are some of these symbols. They emulate the grammatical structure by having verbs for connections and nouns for entities. ER diagrams are comparable to data structure diagrams (DSDs), which concentrate on interactions between parts inside entities rather than connections between entities themselves. Data flow diagrams (DFDs), which represent the information flow for systems or processes, are usually associated with ER diagrams.
In other words, a wireframe describes the content, features, and fundamental structure of a page. Depending on the objectives and preferences of the Tune Source project, wireframes could be low-fidelity or high-fidelity. Typically, a low-fidelity wireframe is developed on paper or a whiteboard. A high-fidelity wireframe is more detailed and may incorporate basic interactions and procedures. b. Mockup. A mockup is a static wireframe that incorporates extra UI and aesthetic aspects to mimic the actual website or application as nearly as feasible. While a mockup is akin to a visual model, a wireframe is like a blueprint. Mockups often have additional visual qualities including:
- Design components incorporate colors, styles, graphics, and typography. Mockups often have additional visual qualities including:
- Design components incorporate colors, styles, graphics, and typography. Mockups enable Tune Source project stakeholders to examine design and aesthetic options before selecting to construct the app in a functioning prototype. They are important tools for understanding and presenting the final interface.
1.2 Wireframe designs.
The user requirements research findings from the Tune Source project are given in this section. We'll discuss and present samples of the sample designs, including the interface and functionality of the Tune Source internet music service. Wireframe’s components include:
- Structure: The pieces put in the interface.
- Material: Information and content to be shown.
- Hierarchy: The hierarchy between information and content.
- Functionality: The operability of the interface.
- Behavior: The user's behavior while engaging with the interface.
Here is the website service's wireframe homepage for consumers who are accessing it for the first time: Registered user home page Figure 5 homepage
