yuan-lu.weebly.com · Web viewLyricFloatSoftware Design Document. Version . 1.0. New Clear...

LyricFloatSoftware Design Document

Version 1.0New Clear Software

February 18, 2015Prepared by:Bryan ChongVictoria Dea

Janet KimJon Koehmstedt

Tobias LeeRyan Lu

Jiayang Miao

TABLE OF CONTENTSTABLE OF CONTENTS.....................................................................................iEXECUTIVE SUMMARY..................................................................................41. INTRODUCTION.........................................................................................5

1.1................................................................................................... Purpose5

1.2...................................................................................................... Scope5

1.3.................................................................................. Reference Material5

1.4....................................................................... Definitions and Acronyms6

1.5................................................................................................. Overview6

2. DESIGN DIAGRAMS...................................................................................62.1........................................................................... UML Use Case Diagram

72.1.1 Overview.........................................................................................72.1.2 Design Justification..........................................................................72.1.3 Requirements Validation.................................................................82.1.4 Quality Validation............................................................................8

2.2................................................................................. UML Class Diagram9

2.2.1 Overview.......................................................................................102.2.2 Design Justification........................................................................102.2.3 Requirements Validation...............................................................102.2.4 Quality Validation..........................................................................11

2.3....................................................................... UML Component Diagram12

2.3.1 Overview.......................................................................................12

i - Table of Contents

2.3.2 Design Justification........................................................................122.3.3 Requirements Validation...............................................................132.3.4 Quality Validation..........................................................................13

2.4.......................................................................... UML Sequence Diagram14


2.5.......................................................................... UML Data Flow Diagram16


2.6................................................................... UML State Machine Diagram19


3

3. APPENDIX................................................................................................223.1...................................................................................... Feasibility Study

.............................................................................................................223.2........................................................................................ Design Process

.............................................................................................................223.3......................................................................................... February 11th

.............................................................................................................223.4......................................................................................... February 13th

.............................................................................................................233.5....................................................... Project Management Plan Validation

.............................................................................................................233.6............................................................................................ All Diagrams

.............................................................................................................A1

ii – Table of Contents

Executive SummaryThis document outlines the software design decisions that the team made in regards to the interfaces and organization of the application. These design decisions were made whilst aiming to fulfill each and every one of the software requirements described in the Software Requirements Specification (SRS) document.

Overall, the design of the software focuses on interaction between the user, the browser and the API for the lyrics and Facebook. Within the document, the specific use cases and requests that each party makes of the other interface are also outlined. The team also determined the classes which our software would define: WordCloud, Artist, Song, WC_Word, and API. Following standard good programming practices, the names of the classes reflect their respective function. The Component Diagram demonstrates how each interface depends on each other, and the overall flow of the application can also be seen from the State Machine Diagram.

The justification and how each component validates the requirements are described after each diagram.

5 – Executive Summary

1. Introduction1.1 Purpose

The purpose of the design document is to provide detailed visualizations of the application and its infrastructure. This Software Design Document is intended to evaluate and validate the proposed design. Each design choice will be justified as to how and why it fulfills the requirements. Furthermore, the quality of each design choice will be justified through metrics for each of the following design principles: abstraction, modularity, information hiding, simplicity, and hierarchy.

This document will also feature use cases and descriptive design schematics that will allow development to model off of these descriptions. It provides necessary information to show developers and designers on how LyricFloat is expected to be built and what functionalities and features are needed to complete the software. The intended audiences of the LyricFloat Software Design Document are the stakeholders, the TA and Professor Halfond, and the NCS development team.

1.2 Scope

This Software Design Document inherits all the information recorded and discussed in previous documents and is an addition of the existing documents. This document discusses the design features that were previously discussed in a more in-depth and technical level. No new features will be introduced in this document.

This document will cover all the design features, and will be explain the details on why each feature exists and how the justification of its existence. In addition, this document features comparisons and demonstration on how each different feature interact with each other.

UML diagrams will be provided in the document in order to explain the design features in a explicit, professional and understandable fashion. The UML graphs includes but is not limited to: Data Flow Diagram, State Machine Diagram, Component Diagram, Sequence Diagram, Use Case Diagram and Class Diagram.

1.3 Reference Material

[1] University of Southern California, “Lecture 7: Design Principles”, unpublished.

6 - Introduction

[2] University of Southern California, “Lecture 8: Modeling Techniques”, unpublished.

[3] Vliet, Hans Van, “Software Engineering: Principles and Practices”, 2008.

1.4 Definitions and Acronyms

DefinitionsLink Basic relationship among objects

AcronymsCSS Cascading style sheets, style sheet

language used to describe the look and format of a document written in markup language.

DFD Data Flow Diagram.FR# Functional Requirement (Number) is

the requirements listed in the Software Specification Document

UML Unified Modeling Language.

1.5 Overview

The next chapter discusses six design diagrams and the justification for each diagram. The last section entails group decision-making and justifications.

The following process has been used in designing and conceptually thinking about the design:

1. The team identified a set of feasible abstraction for the design as a whole

2. The team developed and selected during preliminary designing3. The team developed detailed description of the design4. The team evaluated and altered the design to meet requirements5. The team mocked up the design digitally

2. Design DiagramsThe design diagrams features the UML Use Case diagram, UML Component diagram, UML Class diagrams, UML Sequence diagram, UML Data Flow diagram, and UML State Machine diagram.

7 - Introduction

8 - Introduction

2.1 UML Use Case Diagram

Figure 1 - Use Case Diagram

2.1.1 Overview

The Use Case diagram details all the possible use cases for LyricFloat. It represents actors, in green, and how each actor interacts with its tasks. The diagram provides as a visual and simple representation of the user’s interaction with the application. Each specification is depicted as a use case. The diagram ultimately shows how each actor interacts to achieve a goal.

2.1.2 Design Justification

This diagram was created based on the UML standard. The team considered all the possible use cases of the software, and how those usages will most likely be carried out by different kind of actors. Upon consideration, we

9 – Design Diagrams

realized that there are essentially four actors that will be responsible for interacting with the software and handling the tasks, they are: the Users, the Lyrics API(s), the server(s), and the Facebook API. The four actors are represented by the green person figures. The circles are different tasks. Tasks that do not necessarily occur in iteration are labeled as “extend”, and the tasks that do occur iteration are labeled as “include”.

2.1.3 Requirements Validation

FR5 is assumed accomplished, before any actor is able to interact with the application. The user is assumed to be able to access the application through a web browser. Starting from “User” actor, according to the functional requirements, the user should be able to input artist’s name and search for artist. Here, the autocomplete method would begin when the user start typing, which covers FR1. Since “Add artist to cloud” is not a necessary event, it is labeled as “extend,” and this requirement is covered in FR7. After the user submit the artist’s name, relevant data should be pulled from the server using an API, and the application would generate, render and finally direct the user to the word cloud page, satisfying FR2. On the Word Cloud page, the user has the option to click on any of the words in the word cloud, and that brings up a list of song that contain the word, this is a “extend” task, satisfying FR3. On the song list page, the user has the option to click on the song title and that will bring up another page that contains the lyrics. This requirement acts as a “extend” task based on the “song list” task, satisfying FR4. After the word cloud is generated, the user has the option to share the Word Cloud to Facebook through the Facebook API. This requires the Facebook API actor to come into play. This is an optional event and is labeled as “extend” since the user is not required to share. It is an optional task in this specific iteration. This satisfies FR6, completing all seven FRs covered in the specification requirement document.

2.1.4 Quality Validation

Each task has been considered independently. Each functional task illustrated in the diagram can be recognized as independent action that the user can perform. It’s abstraction was not classified in the most abstract level but on the level where each task is a functional action that the user can take.

The cohesion in the diagram has been created in such a way to be procedural. Because the use case diagram relies on chronology and prerequisites, it is necessary for each module to be executed specifically in the order it is presented. There are multiple coupling modularity between the tasks. The few obvious coupling seen would be content, common, and external coupling. Some tasks are directly influential to the next task it enables. This may include data and user input that would be carried onto the next task. In addition, because some of the connections are dependent on an


external database to fetch information, it is categorized under external coupling for these instances.

The user for many of the tasks will be hidden from the processes relating to retrieval of data and generation of the word cloud. In terms of the software and hardware communication between tasks, information is shared without much secrecy. Tasks that require external database will hide the contents of the data of the entire database in secret until requested by an API. Only with permission will the environment be able to obtain data.

Because this diagram utilizes and includes all possible tasks, the complexity for this design is high.

Because tasks are user oriented and is highly dependent on the user’s next interaction, the task diagram in terms of function is structured in a hierarchy that can be followed based on the user’s decision. This, however, is classified as a hierarchy because each task has a pre-requisite task that must be completed prior to calling upon the next task.

2.2 UML Class Diagram

Figure 2 - UML Class Diagram


2.2.1 Overview

The UML Class Diagram models the general class schematics of the LyricFloat application. Each class is a main object and its attributes and functions are modeled within its class diagram. The top of the class signifies the name of the class, the middle section indicates the attributes of the class and the bottom section represents the methods that the class can utilize and execute.


The design was made in accordance with the UML standard. The team extracted the major components of classes from the requirements documentation and utilized logic as well as a step-by-step procedural walkthrough as to how each class component is linked with other components. Each relationship is modeled by a link and each link is determined by the relationship between the components. Associations are represented by a direct arrow and represent a static relationship between the two classes. In this case, WordCloud is related to Songs but not dependent on songs. Therefore, the relationship is an arrow because it is related to creating the Word Cloud but not directly related for it to be aggregation or composition. Aggregation is a relationship that indicates a part-of relationship where the relationship is stronger than a simple association. An empty diamond signifies the relationship. Composition is a stronger relationship that with the absence of certain dependencies the class itself cannot exist as well. We have based our design on the technical implementation and have given each class a relationship with other components based on these criteria.

The class itself contains sections that describe the attributes and methods that the class would implement and have accessible. The accessibility is dependent on the visibility that is determined by symbols: + meaning public and - meaning private. These accessibilities will reflect the accessibilities of the attributes and methods in the implementation.

Our design has a total of four main classes to fully describe the application and is classified by Artist, WC_Word, WordCloud, API and Song. Each component’s significance to the requirement is described in the Requirements Validation section.



The classes were created in consideration of the software requirements specification document. The classes reflect the objects required to satisfy the means listed in the specification document. For the Artist class, it reflects requirements in FR1, where the user has to search for an artist. The information retrieved from the API will be stored in the Artist class. In addition, the Artist class is also related to the WordCloud class that utilizes this class to create a word cloud for FR2. The Song class is related to FR3 where it also contains the storage of FR4 of lyrics - the Song class is able to store lyrics retrieved as documented in FR4 and is the primitive class object for the song list documented in FR3. The methods of the Song class would highlight the lyrics in yellow and is also retrieve the frequency of the selected word. The WordCloud class satisfies FR7 in which the WC_Word class is also utilized to store all words retrieved from all intervals of generated word clouds. The ability to share the WordCloud is directly related to FR6 which would obtain the word cloud object and call upon a method in the API class to share it to the social network.


The design has been modeled to represent a high level of abstraction. The classes were determined by attempting to find the most primitive and lowest level of quality that would comprise as a whole to create the application. We found three domains, Artist, WC_Word, and Song, when combined in total, forms the Word Cloud. The external class API is a means to get data to and from the Word Cloud. These general classes also contain attributes that are relevant and specific to their domain.

The modularity is described by the relationship between each class and its coupling is determined by the type of relationship as shown in the UML class diagram. The type of relationship, association, aggregation and composition, determines the strength of the connection between each component. The data cohesion is abstract enough to fulfill the relationship between these diagrams and does not necessarily fit in a chronological mapping.

Each class has a form of information hiding. The attributes and methods are determined by the plus (+) and minus (-) that represents public and private, respectively. All data is public except for mergeWordCount() under the WordCloud class whose private method is hidden from other classes. All other classes are public, and a result, getters and setters are not needed to identify attributes within the class. The classes still sustain normal data cohesion.

A hierarchy easily represents the design. Each class falls under the WordCloud class besides the class itself. The hierarchy is also mapped based on the dependencies shown by the relationship coupling.


2.3 UML Component Diagram

Figure 3 - Component Diagram

2.3.1 Overview

The component diagram describes the modules present in the LyricFloat application. It features three main subsystems, the Website, the Echonest API, and the Facebook API, as well as the components that compose these subsystems and their respective interfaces. All sockets (represented by a “C” attached to a line) represent an interface required for that component while all lollipops (represented by a “O” attached to a line) indicate an interface provided by that component. Interfaces not paired with a complementary interface are ultimately paired with the end user.



From reviewing the requirements specifications, the team determined that LyricFloat could be separated into three major subsystems, the website, the Echonest API, and the Facebook API, while each subsystem could in turn be divided into smaller components. We then evaluated what interfaces each subsystem could provide and in turn what interfaces they were dependent on. From there, it became a matter of connecting each requirement to a provision. By determining the provided and required interfaces before connecting each component, we could ensure that all functionalities were tied properly and no requirement was left unlinked. For example, we established that the website would require lyrics for word cloud, song list, and lyrics page generation, while the Echonest API would be able to provide that interface for the website, so we tied these connections together. In the end, we determined that LyricFloat would provide a word cloud, song list, lyrics page, and Facebook sharing functionality, while requiring from the user an artist name and Facebook account authentication.


This diagram was created after reviewing the requirements specifications and seeks to conform to them as accurately as possible. While this diagram does not attempt to address any functional requirements in particular, it does touch on aspects of most functional requirements. For example, it describes how the search functionality defined in FR1 would interact with other components to generate the functionality required of it. This correlation holds true for all functional requirements save FR5, which defines the user’s ability to access the application rather than any specific functionalities for components. The subsystems defined satisfy the interface requirements as defined in Section 3.1 of the software requirements specifications document, and their interactions are further explored in this component diagram.


The purpose of the component diagram is to separate the application into separate modules each with defined interfaces and functionalities. Thus, it could be said that the entire purpose of this diagram is to identify the divisible modules in the application and abstract them into subsystems, as well as describe the interactions between these modules. As each module acts as an abstracted “black box,” only showing the external interactions and not the internal mechanisms defining each module, all internal information can easily be kept hidden from prying eyes.


The diagram describes the hierarchy of components in the application. Subsystems contain components, to which they delegate the handling of connections. The diagram further explains how each component uses other components to perform its desired functionalities.

The secrecy is visible through the different class components communicating with each other. The ball and socket symbols signify hidden data being able to be retrieved and shared to class members who don’t have access to the request natively. Mostly, API calls are able to share these “secrets”.

2.4 UML Sequence Diagram


Figure 4 - Sequence Diagram

2.4.1 Overview

The sequence diagram describes a user’s interactions with the application, and the timeline of events following the interaction to produce the desired output. The diagram depicts the objects and classes involved in the interaction in a particular scenario. The diagram serves to show a graphical image of how each message or description form a logical sequential timeline of the processes occurring at a given time.


After reviewing the requirements, certain functions of the application only arise after certain input from the user. There were three main modules that we identified as core parts in the operation: the User, the Web Page, and the API, which would act as three systems amongst which communication takes place. The abstraction of these three modules is described in the quality validation section.

The design depicts green bars referencing to the availability of the module. All arrows pointing right indicate request messages while all arrows pointing left indicate responses to these requests. Events are ordered chronologically from top to bottom so events higher up on the diagram happen before lower events.

The timeline works on the basis of requests and responses, and thus each event can be traced.


The data flow and relationship between different components in this diagram is designed in accordance to the Functional Requirements defined in the SRS. FR5 is satisfied before the data flow begins in the diagram. On the start-up page, the application awaits the user’s input, upon receiving the user’s input, the application sends a request to the API, requesting all the necessary data for generating the Web Page. Once the application receives the data from the API, it generates and renders the word cloud, then directs the user to a Web Page. The design satisfies FR1 and FR2. Upon successful generation of the Web Page, the user has the option to continue adding artists to the current Web Page. This design allows the application to satisfy FR7. At the same time, the user also has the options to: 1) share the generated word cloud to Facebook, 2) click on words on the specific Web Page. FR6 is satisfied in the process where the Web Page communicates with the Facebook API. If the user chooses to click on the words in the Web Page, the application will send another series of requests to the API, and a list of songs that contain that word will be returned. Upon receiving the necessary data, the application will generate a new page that has that list of songs,


satisfying FR3. The user can choose to interact with the song title that will prompt the application to send another request to the API. The full lyrics of that song will be returned upon successfully communication. The page contains the lyrics will be shown to the user upon rendering ultimately satisfying FR4.


The sequence diagram has been simplified to three main headings that represent the key modules driving the application. Each of these modules is independent and is abstract enough to hold the functional components. The three modules: User, Web Pages, and API are broad and simple domains that can encompass the application’s processes.

The cohesion represented in the diagram is procedural and lines represent each execution that either represents requests and responses. Because a response is only active when a request occurs, the connection is executed in order. Many of these occur as external coupling where external mediums communicate amongst each other.

Each module has information that are private and thus hidden from being publically accessible. As a result, a request is required to obtain information and a response is returned. Thus the coupling is restricted based on the request and necessity of each module.

The complexity of the diagram is quite simple due to the fact that it follows a linear and chronological ordering through the user’s input all the way to the lyrical highlight.

The ordering is strictly hierarchical. The user can call upon multiple artists that eliminate vanilla hierarchical flow. Because the connectivity and interaction between the modules act in a request and response function, there is a rigid flow in communication.

2.5 UML Data Flow Diagram


Figure 5 - Data Flow Diagram

2.5.1 Overview

The Data Flow Diagram (DFD) defines the processes and entities that entail the application. The external entities include the User, the Lyrics API, and the Facebook API. The circles are processes that define how the user interacts with the application, and the lines represent the transfer of data. The DFD defines how the external entities interact with the processes of the application.


We assume that the User starts at the homepage of the application. On this page the User can interact with the application in only one way, by typing an artist’s name and submitting the entry. During typing there will be an autocorrect process that is signified by the loop from User Input to Auto-complete and back. After submitting the artist’s name our application retrieves all lyrics from the external Lyrics API and attempts to parse the data and render a word cloud. If there was no artist found, a Word Cloud Page is rendered with no word cloud and no share button. Therefore the only


actions from this page are to submit a new artist, represented by the arrows going back to User Input. If an artist is found, then a Word Cloud page is rendered with a word cloud. From this page a user has four options: add an artist, submit a new artist, share the word cloud on Facebook, or click on a word that takes the user to the Song List page. For both adding an artist and submitting a new artist there are lines back to User Input, effectively creating a loop back to the Word Cloud page. For sharing, there is a line to the Facebook API, which is an external entity. The data being shared is an image. If the user clicks on a word on the word cloud then that word is used to get a list of songs from the Lyrics API. A Song List page is then rendered to the user. From here the user can go back to the word cloud page or click on a song. Upon clicking on a song, the Lyrics page is rendered. There is no need to connect with the Lyrics API for this, as the lyrics will already be stored locally from the last API call. On the Lyrics page the user has only two options, to go back to either the Song List page or the Word Cloud page. The entirety of the application and all actions and transfers of data are represented by this DFD.


All 7 functional requirements are satisfied by this DFD. The User Input, Artist Name, Auto-complete and Lyrics API data flow satisfy FR1. The Lyrics API, Parse data, and Render Word Cloud page data flow satisfy FR2. Clicked Word, Lyrics API and Songs Render Song List page data flow satisfy FR3. Song Title and Render Lyrics satisfy FR4. Because Internet access is assumed to be true, FR5 is satisfied. Image and Share to Facebook data flow fulfills FR6. Additional Artist Name, User Input, and Lyrics API data flow satisfy FR7.


The DFD represents the application as a whole, abstracting all details into transfers of data from processes to external entities and vice versa, in a step-wise fashion. By consequence the abstraction used is procedural.

With regard to modularity in the DFD, the application is broken down into modules: processes and external entities, held together by the transfer of data between them. The cohesion is thus procedural and represented by the transfer of data. By analyzing the DFD it is easy to tell which modules are the main components of the application by looking at the number of actions interacting with that module.

Coupling Analyses of Data Transfer:The DFD primarily uses content coupling. Each module cannot be completed without the completion of the previous one, therefore each module uses content coupling, implying that the module leading to it directly affects it. However, specific modules have additional types of coupling as such:


All user input to the Lyrics API is using Data coupling, passing only the name(s) of the artist(s).

The data transfer from the Lyrics API is External. The coupling between parsing the data from the Lyrics API and the

Render Word Cloud page is Stamp. Complete data structures are exchanged from the generating of the word cloud and the rendering of the page.

With regard to information hiding, the only modules that the User needs to know about is the processes that render. The user does not need to know about the transfer of data between the auto-complete process, of the generation of the word cloud/song list/lyrics, and of the communication with the Lyrics API.

The complexity of the DFD is very simple and easy to follow. Because the diagram is abstracted procedurally, little annotation is needed to follow what each action does or is meant to do. The arrow between modules representing the data transfer defines inter-modularity. The inter-modular complexity is very simple because it requires no more than three words to describe its function. Intra-modularity is similarly simple needing only several words to describe the entire module and what it accomplishes.

Although the complexity of the DFD is simple, the hierarchy is somewhat chaotic. The size is small, with only three external entities, six processes, and 16 edges. However, there are ambiguous dependencies such as where user input came from, and there are many loops, including a possible self-loop with the auto-correct process.

2.6 UML State Machine Diagram


Figure 6 - State Machine Diagram

2.6.1 Overview

The state machine diagram depicts the states and state transitions possible for the LyricFloat application. Each rounded rectangular block defines a possible state of the application. Arrows indicate possible transitions between states, and are each labeled to indicate conditions to transition between states. Start indicates the status when a user opens the application and End indicates the status when user leaves the application.


This diagram is made based on the UML standard. The team considered all the possible states that the system can be in and how the changes between


the states can take place. Based on our design of the application, we decided to represent the states by the pages that users may see and interact with except for the Start and End state. However different from the Data Flow Diagram, the State Machine Diagram focus on how the user’s interaction with the application would change the state of the system. The labels on the arrows represent the conditions that change the states. There is a Not Found Word Cloud Page state in the diagram because search for a artist that have no match in database will return a Word Cloud Page that have no actual Word Cloud and cannot be interacted with. Based on the differences in the conditions of transitions the state can have, it must be separated from the Artist Found Word Cloud Page state. Since the user can quit the application on all the pages, arrows to End state start from all the page states in the diagram. Certain functions like artist suggestions and auto-complete are included in states that show the specific page instead of being shown as individual states.


All functional requirements are reflected and included in the State Machine Diagram. FR1 is satisfied by Start Page state that is designed to include search function, suggestions and auto-complete function. FR2 is represented by the two Word Cloud Page states. FR3 and FR4 each have their corresponding states that represent the pages. FR5 is specifically shown by the arrow labeled “Load” from Start state to Start Page state to indicate the loading process and accessibility of the application. FR6, sharing, have its own pages and related transitions. FR7 is included in the arrow labeled “Artist Found” and “Artist Not Found” starting from Artist Found Word Cloud Page state to itself or the Not Found World Cloud Page state.


The State Machine Diagram is designed to achieve certain level of abstraction by categorizing all status the system may be in into several states and illustrate the details of the processing in the backend into conditions of transitions. While since the application is fully represented, as a whole in the diagram, the abstraction used is procedural.

The cohesion of this diagram is represented by the transitions that connect each of the states to the other states of the application. Since the arrows in the diagram are single headed, the transitions must take place in an order to reach a certain state of the system. The cohesion of this diagram is clearly procedural. The coupling in the diagram is mainly content coupling because the transitions must take place in order to change the state of the system so the future state is highly affected by current state and the


transition that happens. While interaction with external APIs that are represented by transitions that searches for artists is External coupling.

The diagram represents pages into states and hides all the details of the mechanism working in background so the only things the users will know are how to transit between states.

The diagram has a low level of inter-modular complexity because the transitions of states are made to be very easy to understand. The intra-modular complexity is not much simple but not high either because each state only represents one page and the transitions linked to the page make the diagram descriptive on its own.

The diagram has a chaotic hierarchy because the user can navigate in any direction the diagram specifies; including several self-loops and loops between two pages.

3. Appendix3.1 Feasibility StudyOur group found the specification requirements easily translatable to design. We discussed the feasibility within our group and managed to draw mockups and match specifications to their respected designs. Certain designs translated easily, however, with the designs that didn’t, we managed to talk with the stakeholders to verify the design.

3.2 Design ProcessFor each of the six diagrams included in the Software Design Document, our group met together as a whole and discussed a high level overview. After hashing out a rough draft for each of the six diagrams, we split into teams of two to fine-tune each diagram, and then we switched teams to verify correctness. Certain diagrams such as the UML Class diagram relied heavily on certain subgroups. The Backend subgroup was primarily responsible for this diagram, while the Frontend subgroup was primarily responsible for the Data Flow Diagram.

3.3 February 11thNCS met at Leavey Library and created the Data Flow Diagram, UML Class Diagram, Use Case Diagram, Sequence Diagram, and State Machine Diagrams. We justified each decision using the requirements provided by LyricFloat.

24 – Appendix

The team sketched out a few iterations of the DFD. First iteration was naive and was simple. After organization, our team had to justify whether there was more than one external entity. If there was a different data flow for when the application did not find the artist and if the API call and rendering of the web page can be combined into one action. We came to a consensus stating that there should be one external entity for the user and that there should be a different data flow for “no artists found”, and that it would be more precise to separate the API calls with the rendering of pages. We consulted with the stakeholders regarding what happens during couple iterations of the Word Cloud and the user fails to generate multiple users. The stakeholder requested that we effectively handle this bug that was not mentioned in the software requirements document.

3.4 February 13thNCS met in Leavey Library and finished up the components diagram. In addition, the team started digital images and diagrams based on the diagrams drawn on the board. The team also began to start explaining each diagram and how each diagram got the components it had. We referenced the design process on the lectures provided by Professor Halfond.

We adjusted the DFD to include three external entities as opposed to our initial one external entity mocked up on our February 11th meeting.

3.5 Project Management Plan (PMP) ValidationIn accordance with the Configuration Management Plan as discussed in section 7 of the PMP, the proper information was recorded in the CMDB for this CI. Namely, the following:

CI NameDate

CreatedTime

CreatedCI Creator

NameQA

ApprovalVersion Number Modification

Software Design Document 13-Feb-15 6:30 PM Main Group Main Group Version 1.0 Initiated

In accordance with the Monitoring Plan as discussed in section 8.4 of the PMP, comparisons between the actual progress and the projected progress was carried out at our weekly meeting. During the weekly meeting we were on track with our projected date of 2/14 to complete the Design Document. We realized also that our assumption that a PowerPoint would be necessary was incorrect. We decided to remove the PowerPoint deadline from our scheduled tasks and Gantt chart. Finishing touches to the Software Design Document were made on Feb 15th, which extended the actual finish date one day beyond the projected finish date. This was noted on our Gantt chart. These changes were documented in the CMDB:

25 – Appendix

CI NameDate

CreatedTime

CreatedCI Creator

NameQA


Project Management Plan Gantt Chart 15-Feb-15 12:20 PM

Jon Koehmstedt

Bryan Chong

Version 1.0

Removed Power Point from Gantt Chart, made finish date for SDS one day late.

With regard to satisfactory levels as discussed in section 8.6 of the PMP, three criteria were used to measure the satisfactory delivery of this document: Operational, Tactical, and Strategic. The document was determined to be functional, meeting all the requirements of the stakeholders, although some minor adjustments may need to be made later. With regard to the tactility of the implementation of this document, although it was finished a day later than projected, many members of the group were unable to meet during the weekend and the delivery of the document was thus rushed to be finished before the weekend. Considering the scheduling difficulties, we determined the delivery of this document to be appropriately tactical. With regard to strategic criteria, during our main group meeting there was a high level of team cohesion and agreement upon the implications of each design decision. Therefore we believe this document represents a high level of strategies.

In accordance with the Risk Monitoring Plan as discussed in section 9.2 of the PMP, a risk assessment was undertook during our weekly group meeting. We recognized that a couple risks with the implementation, and emailed the stakeholders immediately to get clarification on requirements. We also identified the risk of our team not being available to work on this document over the weekend and determined to meet more often during the week to finish early. We lowered the risk of Staff Unavailability in our Risk Management Document from Low to Very Low because over the past week, a higher commitment was shown by all members overall, regardless of availability to meet in person.

Risk Description Likelihood Severity Mitigation Plan

Staff Unavailability

Project staff becomes unable to continue work, possibly due to illness or other reason Very Low

Catastrophic

Each member acknowledges that their skills may be necessary to handle the requirements assigned to the missing members.

This change was also documented in the CMDB:

CI NameDate

CreatedTime

CreatedCI Creator

NameQA


Risk Management

Plan15-Feb-

15 1:30 PMJon

KoehmstedtBryan

Chong Version 1.0

Changed Staff Unavailability from Low to

Very Low

26 – Appendix

27 – Appendix

yuan-lu.weebly.com · Web viewLyricFloatSoftware Design Document. Version . 1.0. New Clear...

Documents

Transcript of yuan-lu.weebly.com · Web viewLyricFloatSoftware Design Document. Version . 1.0. New Clear...