Course buddy fall16_tuesday_group11

1 | P a g e
SYSTEM ANALYSIS AND PROJECT MANAGEMENT
MIS 6308 – Fall 2016
PROJECT: COURSE BUDDY
Instructor: Srinivasan Raghunathan
GROUP 11
AMISHA SINGH
HANLIN HU
KAVYA RANABOTHU
LAKSHMI DURGA PANGULURI
RACHIT MISHRA

2 | P a g e
CONTENTS
1. Project Presentation YouTube link ………………………..............3
2. Executive Summary…………………………………………………………….3
3. Problem Statement…………………………………………………………….4
4. Business Need…………………………………………………………………….4
5. Objectives/Proposed Solution…………………………………………….5
6. Data Collection (Gathering the Data) ...................................6
7. Scope………………………………………………………….........................6
8. Functional Specifications for Course Buddy…………………………7
9. Business Process Model Notation (BPMN)............................7
10. System Context Diagram……………………………………………...10
11. Use Case Diagram…………………………………………………………11
12. Use Case Descriptions…………………………………………………..12
13. Data Dictionary Notation………………………………………………16
14. Class Diagrams………………………………………………………………21
15. Sequence Diagrams……………………………………...................23
16. Database ER Diagram……………………………………………………25
17. Software Design………………………………………………….27
18. Interface Design………………………………………………….30
19. Weekly Project Timelines……………………………………………..30
20. Minutes of Meeting………………………………………………………32

3 | P a g e
1. Project Presentation YouTube link
https://www.youtube.com/watch?v=mfbgH-1mL60&feature=youtu.be
2. Executive Summary:
Through this project, we aim to use the system analysis and design methodologies and apply them
on a project idea in real life. This project idea can essentially be something which proves to be of
great help for a given community of some people or even for a large segment of people sharing
common interests. In analyzing the requirements of the system and accommodating them
accordingly with our system, we got the opportunity to verse ourselves with the nitty-gritty of the
Unified Modelling language and its applications.
The underlying idea beneath this project is to propose a system which assists the freshmen in a
university to choose courses. Yes, that’s how crude the idea is. The idea, titled Course Buddy can be
thought of in terms of an application which is meant to help the newly arriving students in any given
university with the choice selection for their courses.
The motivation behind this project idea was quite simple. As first year graduate students, a lot of
students embark upon the journey to pursue higher education but they might not necessarily have
enough connections and acquaintances needed to help them in choosing the courses during the
initial semesters. There’ a rather untidy process of information flow that takes place in which, a
person hears review for a given course from some other person who in turn might have heard it
from a third person. A lot of information gets lost in the process or if not lost, then fabricated.
There’s no first hand source of review a fresher can get regarding any given course or a set of
courses which can assist him/her in choosing the course during registration. Registrations being a
matter of serious importance and the fact of this idea being as real as could get is what motivated to
go ahead with it in the first place.
Some of the features we propose which Course Buddy would be offering and which would benefit a
fresher are:
1. Course spread: The first and foremost advantage and a functionality is that the user gets the
spread of courses which he or she is desperate for. Spread implies the distribution of courses
one can opt for say in the very first semester depending on his or her requirements or
preferences. For instance, a fresher with the intent of wanting to finish the course in 18 months
with an intended specialization of business intelligence would most probably get the suggestion
via. The application to go for 4 courses in the first semester and so on.
2. Course reviews/ratings: Another important functionality is reviews given by the Alumni. These
are the alumni of the university who sign up for Course Buddy and update their details which
mostly are related to the course they took in the past and then, they review the course and the
professor. This is meant to help the freshmen on the other side of course buddy who would
then have the power to view the reviews of the courses they are interested in and would get the
information first hand.

4 | P a g e
Thus, as one can easily interpret, there are not existing web-platforms or application-portals developed
to heed such problems faced by the students and accordingly assist them out. Through Course Buddy,
we intend to propose a one-stop platform to bring together the freshman students and the alums, the
latter helping the former.
3. Problem Statement:
A strong problem statement must describe the issues which need to be addressed by the
problem which in our case are the hardships faced by the new students while enrolling for
courses. In registering for a course without a prior knowledge of the reviews or quality of the
coursework, there are high chances that the student might end up disliking any specifics about
the course-be it coursework, teaching methodology, style of the professor, etc. which
ultimately affects his or her grade in one way or the other.
Thus, in order to address such issues, we decided to put together a team to propose a solution
and to subsequently model it. Based on the student’s preferences, the system would suggest
the relevant course spread he or she could opt for. On top of this, the student would also get to
view the reviews to these courses which would be separately inputted by the alumni side of the
application. Our client is the entire student fraternity enrolled in the Jindal School of
Management for MS in Information Technology and Management. The scope and the limitation
form an important part of the statement which would be discussed in the forthcoming sections.
4. Business Need:
From a business’s perspective, the idea to develop such a platform arises from a wide variety of
needs. These needs are jotted down keeping in mind the business idea of our project and the
fact that how important they are should this be implemented on a business-level:
● Customer grievances is the very first point. The customer in this case is the UTD student
community and should this project not be implemented on a business scale; it is bound
to generate a lot of grievances among the customers. The customers will show
dissatisfaction because their demand isn’t being met.
● Optimization/Improving the current system: Another business need which triggers the
development of our proposed system is the need to make improvements with the
current system. The current system isn’t much efficient which is why the need of
development of a new system arises. Current system doesn’t assist the customers in
selection of courses thus requiring improvements.
● Customer relationships: One of the most crucial parameters integral for longevity of a
business is the kind of relationship it is striking with the customer. A happy customer
who gets the recommended course suggestions and the review corresponding to the

5 | P a g e
course as well as other integral details pertaining to internships and specializations is
bound to leave a positive recommendation. This builds a long-term relationship
between the product and the customer thus enhancing the outputs of a business.
5. Objectives/Proposed Solution:
At this point, having been delivered the business needs, summary and the problem statement, we move
forward to articulating all the objectives:
The system CourseBuddy aims at successfully accomplishing the following objectives:
Objective Description
1. Spread of courses Based on the data inputted by the user, the application would suggest
him/her the course spread.
The process followed to accomplish this objective will be based on the
preferences given by the user.
The application asks the user his or her choices of
1. Intended specialization
2. Interest in certification
3. Intended course length, etc.
2. Course Reviews The alumni network who will be linked to the platform will be asked by
course buddy to submit a list of courses and in parallel, they can also review
the course they took by writing a review and/or rating the professor.
This is an important objective since these reviews would be looked up by the
freshmen students and would help them in choosing their courses and
accordingly going ahead with the registration
3. Providing an
attractive interface
for Academic Bio
Another important objective which the CourseBuddy application needs to
address is the academic bio.
The academic bio of a fresher signing into the application will include his or
her field of study, his or her department and some other parameters which
would then be taken as input by course buddy in order to suggest the course
spread.
4. Integrating the
platform
Finally, the main objective stands as integrating the platform bringing
together the fresh students and the alumni.
This is our final course buddy platform which would be performing the task
on retrieving the data inputted by the alumni and would be making it
available for viewing by the fresh students.

6 | P a g e
6. Data Collection (Gathering the Data):
In order to sustain the requirements of CourseBuddy, there are various sources from where the
proposed system can gather the data.
Below, we have listed down all the data sources which we have used in gathering the
requirements for our proposed system:
● The ITM Course Brochure: Should the system be implemented; we would be needing a
lot of information on the backend of CourseBuddy. This information would be the
details of the courses, primarily the:
1. Course Name/ Course Title
2. Details of the sections of the class
3. Details of the professors teaching different sections
Thus, in order to get this data, we would be referring the ITM Course Brochure and that’s our
very first source.
● LinkedIn (data for alumni) – In addition to pulling the data for the courses from the
brochure, if we were to extend the system, we could also pull a lot of information
pertaining to the alumni from their LinkedIn profiles. This data would then be used to be
inputted into the course buddy system and the freshman can then lookup the details for
the alumni thus getting the questions like – Did the alumni taking this particular course
manage to get an internship? How has he rated this course? How helpful did he think
the professor was? – answered.
Thus, these would be the two primary sources of data should the proposed system be
implemented.
7. Scope:
The scope of implementing such a system by means of which, a student can get the first-hand
reviews of courses which he or she intends to take will definitely be numerous:
● The primary scope of this proposed system is to help the students in multiple ways in
shortlisting of their courses.
● The method to achieve that is to bring together a network of alumni and fresh students
and to use the former to help the later
● Since this is a one of a kind model and hasn’t been implemented previously, this model
is open to a lot of improvements that can be made over time. Features such as
recording the intended specialization of a student, his or her academic bio, and

7 | P a g e
intended length of term are among functionalities that can be extensively implemented
in finally suggesting the course spread.
8. Functional Specifications for Course Buddy:
● Recording the previous course work, internship details, specialization details, course
reviews inputted by the alumni in real time.
● Ability to take the data as input from the freshmen regarding the academic bio, all in
real time.
● One of the additional functionalities is that the alumni gets the power to review and
rate any given course and the proposed system has the robustness to deliver it in real
time.
● Flexibility to accommodate the changes that occur in JSOM course structure and new
courses.
● Flexibility and robustness to accommodate new departments if any in the database
design.
● Additional benefit to the Students from the reviews and ratings of the courses and
instructors along with the course spread.
9. Business Process Model Notation (BPMN):
In representing the business process model notation for our proposed system, we include a
total of four pools. The pools are as follows:
1. The very first will be the pool for the student/fresher who joins the university and
signs up for the application and wants to lookup the courses.
2. Secondly, at the heart of our proposed system is our application, CourseBuddy
through which the entire information flow takes place.
3. Thirdly, we have the Alumni pool which is necessary for CourseBuddy to store in the
course reviews and other core details and then present them to the student in the
very first pool.
4. Lastly, we have a pool for the JSOM website which is needed because that’s where
we are getting the data related to the courses from. The details to the professors,
sections of the courses, etc. would be looked up from the ITM website.

8 | P a g e
Process diagram 1: With pools: For students. This is our proposed system.
Process diagram 2: ALUMNI(from the perspective of CourseBuddy):

9 | P a g e
Choreography Diagrams :
Choreography Diagram for students

10 | P a g e
Choreography Diagram (for Alumni from the perspective of Course Buddy):
10. System Context Diagram:
As can be inferred from the diagram below, the proposed CourseBuddy system is right at the
heart of the context diagram with 3 main actors surrounding it namely the Alumni, Student and
ITM web.
The functions which can be performed as an association of Student-CouseBuddy, ITM Web-
CourseBuddy and Alumni-CourseBuddy are listed down below.

11 | P a g e
11. Use Case Diagram:
Diagrams below now represent the use case of our proposed system. The actors which would
be taking part in these use cases are: Student, Alumni and ITM Web Services.
CourseBuddy on the other hand isn’t counted as an actor since it represents the entire system
of which the actors are a part.
We can list down the use case as follows:
● Authorize login
● Enter academic bio
● Display the course spread
● Display the ratings
● Write review
● Rate Course/Professor
● Get Course Info
● Update the course bio

12 | P a g e
12. Use Case Descriptions:
In this section, we have accounted for all the different use cases and documented them below:
Use case 1: Authorize login
Name: Authorize Login
Description: A student or an alumnus wants to sign in
Trigger: Student is ready to sign in into CourseBuddy.
Normal flow of
events:
1. Display the login screen
2. User inputs the credentials.
3. CourseBuddy does the verification and verifies the user info.
Exception flow: 3.a1. If verification is invalid, display Failed Authentication message and
Login screen.

13 | P a g e
Use case 2: Enter the Academic Bio
Name: Enter the Academic Bio
Description: System requests the students to enter the academic bio which would help in
determining the course spread
Trigger: Student lands on the academic bio screen
Normal flow of
events:
1. Students arrives on the update Academic Bio page.
2. CourseBuddy asks for the department details.
3. System then asks the user for the specialization info.
4. System asks the user regarding certification_intent
5. CourseBuddy finally updates the academic bio.
Use case 3: Get the course info
Name: Get the Course Info
Description: The coursebuddy system pulls the data pertaining to the course from ITM Web
services. This is the data which would be containing the details of different courses,
the professors teaching them and the sections that have been opened for each
course.
Trigger: CourseBuddy performs the extracting operation populating its database by getting
the entire course info from the ITM website.
Normal flow of
events:
1. Course Buddy pings the website using the website info given by the
administrator.
2. The course info is then stored for all the different course being offered in terms of
specialization types.
3.. The information to number of sections, room details, etc. are also stored in the
course info in order to assist the student.

14 | P a g e
Use case 4: Display the course spread.
Name: Display the spread of courses
Description: Student requests the system to give different possible spread of courses
Trigger: Student presses the ‘Request course-spread’ button and proceeds
Normal flow of events: 1. System analyses the academic bio info
2. CourseBuddy looks for the course info.
3. System makes sure that all the combination details are accounted for.
4. CourseBuddy finally suggests the course spread to the student.
Use Case 5: Update the course bio
Name: Update the course bio
Description: Alumni is prompted to update the bio-data of the courses he/she took in the
previous years from the university’s course catalog
Trigger: Alumni is on the update course bio screen and proceeds with updating the bio
Normal flow of
events:
1. Alumni is in the system and is prompted by CourseBuddy to update the course
details.
2. After the alumni updates the details, the CouseBuddy system stores the
alumni info.
3. Temp catalog records the details inputted by the alumni for later use by the
students.
Exception flow: 1.a.1 If an alumnus chooses not to update any course details, throw an error.
1.a.2 If an alumnus chooses not to update his or her alumni info, proceed ahead.

15 | P a g e
Use Case 6: Write review for a course
Name: Write review for a course
Description: Alumni is prompted to write a review for the courses which he or she might
have taken
Trigger: Alumni chooses the ‘write review’ button under any specific course
Normal flow of
events:
1. Alumni proceeds to write the review and key details pertaining to each review
are stored as review details.
2. Alumni might review a certain course from the course list he or she had
updated in the course details.
3. CourseBuddy then publishes the review after system verification.
Exception flow: 1.a.1 If an alumnus chooses not to write any review, proceed ahead.
Use Case 7: Rate a course/professor
Name: Write review for a course
Description: Alumni is prompted to write a review for the courses which he or she might
have taken
Trigger: Alumni chooses the ‘write review’ button under any specific course
Normal flow of
events:
1. Alumni proceeds to write the review and key details pertaining to each review
are stored as review details.
2. Alumni might review a certain course from the course list he or she had
updated in the course details.
3. CourseBuddy then publishes the review after system verification.
Exception flow: 1.a.1 If an alumnus chooses not to write any review, proceed ahead.

16 | P a g e
Use case 8: Display the course ratings/reviews
Name: Display the course ratings/reviews
Description: The student who is scouting for the courses after getting the course spread now
moves on to view the ratings and reviews of the course given by the Alumnus.
Trigger: Student chooses the ‘Display the reviews’ option on the screen.
Normal flow of
events:
1. Student gets to know the final reviews which would be having the details of
every review corresponding to the alumni who gave the details.
2. The student then processes these details very carefully.
3.. After getting the course spread and going through the reviews, the students
makes the final decision.
13. Data Dictionary Notation:
For every use case, we now document the corresponding data dictionary notation:
Use case 1: Authorize sign-in/ enter academic bio/ Get course info
Underlined Data Data Dictionary notation
Credentials Password + username
Password = data element
Username = data element
User Info Credentials + First Name + Last Name + Email Address + ZipCode + City + State
First Name = Data element
Last Name = Data element
Email Address = Data element
ZipCode = Data element
City = Data element
State = Data element
Verification [True | False]

17 | P a g e
Use case 2: Enter Academic Bio
Academic bio User Info + department details + certification intent + specialization info
User Info Credentials + First Name + Last Name + Email Address + ZipCode + City + State
Department details Department Name + Department ID + enrolment term
Department Name = Data element
Department ID = Data element
Enrolment term = Data element
Specialization_info specialization name + Specialization Abv + Specialization number
Specialization name = Data element
Specialization Abv = Data element
Specialization number = Data element
Certification_intent [Yes|No]
Use case 3: Get the course info
Website info URL + access_info
Access_info = accrss_date + access_time + access_id
Course Info Course_Number + course_name + course_description + 1{credit_hours}3 +
course_prereq + 1{number_of_sections}10 + number_of_instructors +
20{class_limit}100
Course_Number = Data element
Course_name = Data element
Course_prereq = [TRUE|FALSE]
Credit_hours = Data element
Course_Description = Data element
Number_of_instructors = Data element
Class_limit = Data element

18 | P a g e
Specialization_types Specialization_ID + [Business Intelligence & Analytics | Enterprise Systems |
Cybersecurity management | Healthcare Systems | IT Consulting and Services
Management]
Use case 4: Display the course spread
Academic Bio info User Info + department details + certification intent + specialization info
User Info = Credentials + First Name + Last Name + Email Address + ZipCode + City +
State
Course Info Course_Number + course_name + course_description + 1{credit_hours}3 +
course_prereq + 1{number_of_sections}10 + number_of_instructors +
20{class_limit}100
Course_Number = Data element
Course_name = Data element
Course_prereq = [TRUE|FALSE]
Credit_hours = Data element
Course_Description = Data element
Number_of_instructors = Data element
Class_limit = Data element
Combination
details
1{number_of_courses)6 + course_info + combinationID
Use case 5: Update the course bio
Course details Course_number + course_name + course_description + course_instructor +
section_number + course_term + course_prereq
Course_prereq = course_number + course_name + course_description +
course_instructor + section_number + course_term
Course_number = data element
Course_name = data element
Course_Description = data element

19 | P a g e
Section_number = data element
Course_term = data element
Alumni_info First name + last name + {middle name} + Alumni_term + Alumni_department +
alumni_linkedIn + {alumni_company} +alumni_internship +
{alumni_internshipCompany}
Alumni_internship = [Y|N]
Alumni_linkedIn = URL
Alumni_term = Data element
Alumni_department = Data element
TempCatalogue Course_details + Alumni_info
Use case 6: Write review for a course
Review details ReviewID + 1{Number_of_reviews}20 + Course details + review_Date + review_time
Course detail = Course_number + course_name + course_description +
course_instructor + section_number + course_term + course_prereq
Review_date = Data element
Review_time = Data elmenet
Course_list 1{Course_number + course_name + course_description + course_instructor +
section_number + course_term + course_prereq}20
System Verification Verification_value + Publish_review + ReviewID
Verification_value = [YES|NO]
Publish_review = [YES|NO]

20 | P a g e
Use case 7: Rate a course/professor
Rate details RateID + 1{Number_of_ratings}20 + Professor_details + Course details + rate_Date +
rate_time
Professor_details = ProfessorID + Professor_firstName + Professor_lastName +
{Professor_middleName}
Course details = Course_number + course_name + course_description +
course_instructor + section_number + course_term + course_prereq
Review_date = Data element
Review_time = Data elmenet
System
Verification
Verification_value + Publish_rating + RatingD
Verification_value = [YES|NO]
Publish_rating = [YES|NO]
Use case 8: Display the course ratings/reviews
Final reviews Final_reviewID + Rate details + Review details + alumni_info + review_publishedInfo
Review_PublishedInfo = publish_date + publish_time
Final decision Student_info + 1{course_chosen}6 + course_Info

21 | P a g e
14. Class Diagrams
14.1. Complete Class Diagram (Without Methods)

22 | P a g e
14.2. Complete Class Diagram (With methods and Interface)

23 | P a g e
15. Sequence Diagrams
15.1. Sequence Diagram 1

24 | P a g e
15.2. Sequence Diagram 2

25 | P a g e
16. Database ER Diagram:
16.1. Database Constraints:
UserInfo: ‘UserName’ :Primary Key not null and unique.
Student: ‘StudentID’: Primary Key, not null and unique
‘Username’: Foreign key from UserInfo table, unique
Alumni: ‘AlumniID’ : Primary Key, not null and unique
‘Username’: Foreign key from UserInfo table, unique
AademicBio: ‘StudentID’: Primary Key, not null and unique
Also a foreign key from Student table.
‘DepartmentName’: Foreign key from Department table which is unique
‘CourseSpreadID’: Foreign key from Course Spread table

26 | P a g e
Department: ‘DepartmentID’: Primary Key, not null and unique
‘DepartmentName’: Unique
Courses: ‘CourseID’: Primary Key, not null and unique
Courses_Department: ‘CourseID’ and ‘DepartmentID’: Primary Key, unique and not null
Core Courses: ‘DepartmentID’: Primary key which is a foreign key from Department table, unique and
not null
Certification: ‘CertificationID’: Primary key, not null and unique
‘DepartmentID’: Foreign key from department table.
Specialization: ‘SpecializationID’: Primary key, not null and unique
‘DepartmentID’: Foreign key from department table.
Prerequisites: ‘PrerequisiteID’: Primary key, not null and unique
Courses_Prerequisites: ‘CourseID’ and ‘PrerequisiteID’: primary key, not null, unique and referencing
from Course table and prerequisite table respectively.
Section: ‘CourseID’ and ‘SectionID’ : Primary Key, not null, unique where CourseID is foreign key from
course table.
‘InstructorID’: Foreign key from instructor table.
Schedule: ‘CourseID’ and ‘SectionID’ : Primary Key, not null, unique where CourseID and sectionID are
foreign keys from course and section tables.
Instructor: ‘InstructorID’: Primary Key, not null, unique
‘InstructorFName’: Not Null
RateCourse: ‘ReviewID’: Primary Key, not null, unique
‘SectionID’ and ‘CourseID’ are Foreign keys from section and course tables respectively.
Alumni_RateCourse: ‘ReviewID’ and ‘AlumniID’: Primary Key, not null and unique and these are foreign
keys from RateCourse and Alumni tables.
Internship: ‘InternshipID’ and ‘AlumniID’: Primary Key, not null and unique, where AlumniID is Foreign
Key from Alumni table.

27 | P a g e
17. Software Design
Signature:
Method name:
UpdateCourseCurriculum():
Class name
Courses
ID
CourseID
Clients: Student, Alumni, Department, CourseSpread, Section
Associated use cases: Display the course spread, update the academic bio
Description of responsibilities: Student and the alumni update the course
curriculum.
Arguments received: CourseID, CourseInstructor, CourseDesc
Type of value returned : Information of courses
Pre-Conditions: Courses is not null. Every student and the alumni needs to have some
course updated.
Post-conditions: Update the Course buddy with the course curriculum updates
generated through this signature.
Signature:
Method Name: Update
review/rating
Class name: RateCourse ID: RateCourseID

28 | P a g e
Clients: Alumni, RateCourse, Section
Associated use cases: Rate a course/professor, Display the ratings/reviews
Description of responsibilities: Allow the alumni to rate of review the course he or
she is updating in the course Bio. This rating/review would then be viewed by the student in
order to get a better understanding of the courses.
Arguments received: CourseID, CourseReview, ProfessorRating
Type of value returned: A numeric value for the course rating a description for the
course review.
Preconditions: The Professor rating is a numeric value between 1 to 5.
Postconditions: The coursebuddy system gets updated with the course review and the
course ratings.
Signature:
Method name:
UpdateAcademicBio()
Class name:
Student
ID:
StudentID
Clients: Students, Alumni, AcademicBio
Associated use cases: Update Academic Bio
Description of responsibilities: This signature method lets the user update his or
her academic bio in context of courseBuddy.
Arguments received: DepartmentName, IntendedLength, Specialization, Certification
Type of value returned: A description of the academic bio of the student or the
alumni.

29 | P a g e
Preconditions: Academic bio can’t be null. The argument inputs to it can’t be null either.
Post conditions: Updated academic bio is then updated in the course
Signature:
Method name: Display
the course spread()
Class name: CourseS ID: CourseID
Clients: Course, Students
Associated use cases: Display course spread
Description of responsibilities: Here, course buddy computes and displays the
course spread to the user
Arguments received: Course review, Rate professor
Type of value returned: An entire spread of courses . This course spread would be
used by the students to finally choose the courses of their choice.
Preconditions: Course spread needs to have a minimum of one course and maximum of
six.
Postconditions: Course spread gets updated in the Course Buddy system.

30 | P a g e
18. Interface Design:
19. Weekly Project Timeline
Weekly Schedule Tasks
29th
Aug – 5th
Sept Exchange email ID and phone numbers.
Brainstorming of ideas.
Discussing possible project ideas.
5th
Sept – 11th Sept A thorough analysis of each project idea and
finalizing the idea
Study every idea and its feasibility.
Land on the final idea.
Finalized ‘Coursebuddy’ as the project idea

31 | P a g e
later on.
11th
Sept – 25th
Sept Documentation of the problem and other
proposed data
Doing a feasibility analysis for the project.
Define a process model and the corresponding
BPMN diagram.
25th
Sept – 15th
Oct
15th
Oct – 30th
Oct
Developing a context diagram, initiating the
work on use-case modelling.
Drawing the use-case diagrams and starting
work on data-dictionary notation.
31st
Oct – 3rd
Nov Finalize the data dictionary along with the use-
case description.
Start related works on class and sequence
diagrams.
4th
Nov – 10th
Nov Finish the sequence diagrams and move onto
the ERD depiction.
Finalize the ERD distribution and get done with
the database diagrams/constraints.
11th
Nov – 17th
Nov Documenting the different methods and
brainstorming on interface design.
Presenting an idea for the interface design.
17th
Nov – 25th
Nov Working out the entire software design
Proof-read#1 the entire document
26th
Nov – 9th
Dec Proof-read #2 the entire document.

32 | P a g e
Preparing the presentation.
Preparing the recording. The Final Milestone.
.
20. Minutes of meeting
Meeting 1:
Meeting title Group 11 – 5th
Sept 2:00 – 4:00 P.M
Location – Jason’s Deli
Minutes taker Rachit Mishra
Attendees Rachit Mishra, Kavya Reddy, Hanlin Hu, Amisha
Singh, Lakshmi Panguluri
Discussion Meeting, exchanging info, brainstorming project
ideas
Agenda In this particular meeting, we met and exchange
information and did an extensive set of
brainstorming for discussing the project ideas.
Some of the ideas we discussed included
developing an extensive application framework
for e-learning, CourseBuddy and few others.
Conclusion Discussing feasibility of each idea and its scope.
Work Allotment Person Work
Rachit Mishra Work on information
gathering on
CourseBuddy

33 | P a g e
Kavya Reddy Work on some
additional topics
Laxmi Panguluri Assisting
Hanlin Hu Figure out flaws in the
e-learning project idea
Amisha Singh Come up with
additional ideas.
Next Meeting 14th
Sept 4:00 P.M – Eugene McDermott
Library
Meeting 2:
Sept 4:00 – 5:30 P.M
Location – Eugene McDermott Library
Discussion A final discussion of the feasibility of all the
project ideas.
Finalizing a project idea and kick-starting the
project.
Agenda In this particular meeting, each and every team
member gave their inputs either in the form of a
new idea or with some criticism on the ones
earlier discussed.
Finally, we dropped the other ideas because of
them not satisfying either of the feasibility
criteria.

34 | P a g e
Ultimately, we finalized CourseBuddy as our
project topic.
Conclusion Finalized CourseBuddy and started the work on
same after allocation of tasks subsequently.
Rachit Mishra Creating a flow chart
which uniquely
identifies the
functionalities and
actors in a system.
Kavya Reddy Creating a flow chart
which uniquely
identifies the
functionalities and
actors in a system.
Laxmi Panguluri Figuring out the
modelling and
functionalities of the
system.
Hanlin Hu Figuring out the
modelling and
system.
Amisha Singh Figuring out the
modelling and
system.
Next Meeting 18th
Sept 4:00 P.M – Eugene McDermott
Library
Meeting 3:
Sept 4:00 – 6:00 P.M

35 | P a g e
Minutes taker Hanlin Hu
Discussion Firstly, we clearly identified the flow of our
system.
Post that, we discussed the different attributes of
process modelling for our system.
Agenda In this particular meeting, each and every team
member gave inputs on high the system can be
in terms of adding functionalities and processing
the flows. After being more clear on the flow of
the system and clearly identifying the
functionalities, we moved on to the next part.
An in-depth discussion of modelling the process
followed. The pools were clearly identified and
tasks were allotted to come up with the process
diagrams and the corresponding choreography
tasks with pools.
Conclusion Finalized the system’s flow from previous week
and assigned process modelling tasks for the
upcoming week.
Rachit Mishra Create a skeleton of the
process diagram and
choreography tasks
with pools.
Kavya Reddy Use visual paradigm for
finalizing the process
diagram with pools and
the choreography

36 | P a g e
diagrams with pools.
Laxmi Panguluri Figure out the process
modelling for the
choreography tasks.
Hanlin Hu Double check and
verify the developed
process model with
pools.
Amisha Singh Double check and
verify the developed
choreography tasks
with pools.
Next Meeting 25th
Sept 12:00 P.M – Eugene
McDermott Library
Meeting 4:
Sept 6:00 – 8:00 P.M
Minutes taker Amisha Singh
Discussion Finalizing the process models and the diagrams
from previous week.
Finalizing the choreography tasks from previous
week and subsequent discussion/allotment of
tasks on use case modelling.
Agenda In this meeting, firstly, the work on the process
diagrams – the process diagrams with pools and
the choreography tasks – were given a green
light.

37 | P a g e
Next, we identified the actors for modelling a
simple context diagram for our course buddy
system. In subsequent stages, we identified the
uses cases.
Conclusion Discussed the scopes of the context diagram and
identified the use cases in detail. Allotted the
work on the same to team members.
Rachit Mishra Create the context
diagram along with a
detailed identification
of the use cases.
Model this into a use
case diagram after
coming up with the
context diagram.
Kavya Reddy Identify the use cases
prepared by Rachit,
verify and make the
appropriate changes, if
any.
Laxmi Panguluri Model the use case
diagram and verify the
components of the
context diagram.
Hanlin Hu Make improvements in
the context diagram in
order to make it more
functionality efficient.
Identify the constraints.
Amisha Singh Identify the constraints
in the use case diagram
and optimize it to
within 9 use cases for

38 | P a g e
the entire Course
Buddy system.
Next Meeting 15th
Oct 10:00 A.M – Jason’s Deli
30th
Oct 12:00 .M - Library
Meeting 5:
Meeting title Group 11 –15th
Oct 10:00 A.M – Jason’s Deli
30th
Oct 12:00 .M - Library
Minutes taker Amisha Singh
Attendees Rachit Mishra, Kavya Reddy, Amisha Singh,
Lakshmi Panguluri
Discussion A sit down of team members in order to finalize
the use case and context models from previous
week.
Proceeding with the data dictionary modelling of
the proposed use case model.
Agenda In the first hour, finalized the context and the use
case model diagrams as per the inputs received
from different team members according to the
tasks allotted.
Identifying the steps to develop a data dictionary
notation and dealing with the description for the
use cases. Our system had eight use cases In total
so the very first agenda was to formulate the
descriptions for those use cases and come up
with the underlined data and then accordingly
develop the data dictionary notation.
Conclusion Finalizing the use case and context diagrams and
allotting tasks to come up with the use case
descriptions and the subsequent data dictionary
notation.

39 | P a g e
Rachit Mishra To develop the use case
descriptions for all the
use cases and write
their data dictionary
notation.
Kavya Reddy To develop the data
dictionary notations
from the use case
descriptions above and
verify it.
Laxmi Panguluri To verify the data
dictionary notations
and the use case
descriptions and to
proofread the entire
use case descriptions.
Hanlin Hu To proofread the data
dictionary and use case
notations.
Amisha Singh To proofread the data
dictionary and use case
descriptions.
Next Meeting 4thst
November 10:00 A.M – Jason’s Deli
Meeting 6:
Meeting title Group 11– 4th
November – 10:00 A.M – Jason’s
Deli

40 | P a g e
Minutes taker Laxmi Panguluri
Attendees Rachit Mishra, Kavya Reddy, Amisha Singh, Hanlin
Hu, Lakshmi Panguluri
Discussion Finalizing the data dictionary notations and the
use case models after a thorough proof-reading
and validation done by the team members.
Finally proceeding with the class diagrams and
the sequence diagrams and formulating methods
to be used in them.
Agenda Firstly, we put together the data dictionary
notations as per their use case descriptions and
finalized the aggregation models and the data
elements for each data dictionary notations.
Before doing that, half of the team thoroughly
verified the use case descriptions in order to
eliminate any sort of complication from the data
dictionary notation.
Then, we worked on highlighting the attributes
and working out the methods needed for coming
up with the class diagrams and then the sequence
diagrams.
Conclusion Came up with the maximum possible classes for
the class diagram then optimized them in order
to make the system more compact. Allotted work
to members to develop the class diagram and
then the sequence diagram.
Rachit Mishra Drawing the class and
sequence diagram using
visual paradigm
Kavya Reddy Work on modelling the
class diagram in visual
paradigm.

41 | P a g e
Laxmi Panguluri Work on modelling the
sequence diagram and
creating a prototype to
be implemented.
Hanlin Hu Work on double
checking the developed
class diagrams and the
sequence diagrams and
propose improvements.
Amisha Singh Make sure that the
class and sequence
diagrams are ready with
the final version
including suggested
improvements.
Next Meeting 11th November 6:00 P.M – Jason’s Deli
Meeting 7:
November 6:00 P.M – Jason’s Deli
Minutes taker Kavya Reddy
Lakshmi Panguluri, Hanlin Hu
Discussion As per the class diagram developed, design the
database diagrams including all the constraints.
Agenda Work out ways to convert the classes from the
class diagram into tables in a normalized form.
Make sure that the redundancies are all
eliminated and the referential integrity
constraints are satisfied properly.

42 | P a g e
Conclusion Finalizing the database diagram prototype to be
develop and accordingly allocating tasks to
members.
Rachit Mishra Work on normalizing
the tables generated
from classes and make
sure that the foreign
key relationships are up
to date.
Kavya Reddy Draw the diagram in
visual paradigm.
Laxmi Panguluri Highlight the database
constraints and make
sure that the
constraints are double-
checked.
Hanlin Hu List down all the
constraints handed
over by the members in
the report and validate
them again.
Amisha Singh List down all the
constraints handed
over by the members
and validate it again.
Meeting 8:

43 | P a g e
Lakshmi Panguluri, Hanlin Hu
Discussion Documenting the methods and working out the
interface design
Agenda Documenting the methods implemented in the
sequence design and in parallel, suggesting an
interface for the proposed system.
This interface needs to be functionally user-
friendly and needs to be really simplistic. All such
requirements for the interface were discussed in
this meeting.
Conclusion Finalizing the methods to be documented and the
points of interfacing the design for the proposed
system.
Rachit Mishra Listing down the
methods and preparing
the entire minutes of
meeting document
compiling all the
minutes take till now.
Kavya Reddy Listing down the
methods and proposing
a solution for the
interface design.
Laxmi Panguluri Working on suggesting
an interface design and
verifying the methods
jotted down.
Hanlin Hu Suggesting an interface
design for the proposed
system.

44 | P a g e
Amisha Singh Documenting all the
methods at one place
and verifying them.
Meeting 9:
Minutes taker Lakshmi Panguluti
Attendees Rachit Mishra, Kavya Reddy, Lakshmi Panguluri,
Hanlin Hu
Discussion Finalizing the control/interface design and
suggesting ideas for the software design of the
proposed system.
Agenda In this meet, we had a really vague sense of
understanding of an interface design for our
system from the previous meetings. Thus, we
elaborated the meet to cover the aspects of
interface design again as well as discussed the
idea of software design.
Conclusion Elaborating the interface design ideas and
meanwhile also proposing improvements for
software design of the CourseBuddy system.
Rachit Mishra Researching on
interface design and
fundamentals of
software design.
Kavya Reddy Researching on

45 | P a g e
fundamentals of
software design.
Laxmi Panguluri Researching on
fundamentals of
software design.
Hanlin Hu Researching on
fundamentals of
software design.
Amisha Singh Researching on
fundamentals of
software design.
Meeting 10:
Meeting title Group 11 – 3rdth
December 6:00 P.M – UTD
Library
Attendees Rachit Mishra, Kavya Reddy, Lakshmi Panguluri,
Hanlin Hu
Discussion Finalizing the entire documentations and
preparing the report and the presentation.
Agenda In this final meet, we proofread the entire
document piece by piece and consolidated the
full report in a detailed manner at one place.

46 | P a g e
Also, the presentation was prepared and the
recording was done.
Conclusion Completed the report consolidation, proof-
reading done, presentation prepared.
Rachit Mishra Proof-read the entire
report.
Correct the errors.
Format the report.
Consolidate the
minutes of meeting.
Kavya Reddy Proof-read the entire
report.
Correct the errors.
Format the report.
Laxmi Panguluri Proof-read the entire
report.
Correct the errors.
Format the report.
Hanlin Hu Proof-read the entire
report.
Correct the errors.
Format the report.
Prepare the
presentation
Amisha Singh Proof-read the entire
report.
Correct the errors.

47 | P a g e
Format the report.
Prepare the
presentation
Next Meeting --------------------------------------------

Course buddy fall16_tuesday_group11

Recommended

Recommended

More Related Content

What's hot

What's hot (16)

Similar to Course buddy fall16_tuesday_group11

Similar to Course buddy fall16_tuesday_group11 (20)

Recently uploaded

Recently uploaded (20)

Course buddy fall16_tuesday_group11