Table of Contents

TABLE OF FIGURES ................................................................................................... 4

LIST OF TABLES ......................................................................................................... 5
Organization Part ........................................................................................................... 7
1.1 Organization Overview ........................................................................................ 8
1.2 Organization Services .......................................................................................... 8
1.3 Our Location at Bangladesh................................................................................. 9
1.4 Organization Vision ........................................................................................... 10
1.5 Organization Mission ......................................................................................... 10
1.6 My position in this Organization ....................................................................... 10
1.7 Organization Structure: ...................................................................................... 11
Project Introduction ..................................................................................................... 12
2.1 Introduction: ....................................................................................................... 13
2.2 Background of Study: ........................................................................................ 13
2.3 Objectives: ......................................................................................................... 13
2.3.1 Broad Objective: ......................................................................................... 14
2.3.2 Specific Objectives: .................................................................................... 15
2.4 Proposed System’s Benefits:.............................................................................. 15
2.4.1 Easy to get registered: ................................................................................. 15
2.4.2 Time Effective: ........................................................................................... 15
2.4.3 Improve Efficiency: .................................................................................... 15
2.4.4 Data Security and Retrieve-ability: ............................................................. 16
2.4.5 New Technology: ........................................................................................ 16
2.5 Methodology: ..................................................................................................... 16
2.5.1 Data Sources: .............................................................................................. 16
2.6 Software Development Process Model: ............................................................. 16
2.6.1 Reason for Choosing: .................................................................................. 19
2.6.2 Steps of Incremental Approach:.................................................................. 19
2.7 Feasibility Study ................................................................................................ 21
2.7.1 Technical Feasibility ................................................................................... 21
2.7.2 Economic Feasibility .................................................................................. 22
2.7.3 Operational Feasibility ................................................................................ 22
Requirement Engineering ............................................................................................ 24

1
 3.1 Requirement Analysis: ....................................................................................... 25
3.2 Requirements Engineering: ................................................................................ 26
3.2.1 User Requirements ...................................................................................... 26
3.2.2 System Requirements: ................................................................................ 27
3.2.3 Functional Requirements ............................................................................ 28
3.2.4 Non-Functional Requirements: ................................................................... 29
3.3.1 Use case symbols: ....................................................................................... 29
3.3.2 Use case diagram: ....................................................................................... 31
3.3.3 Use case text: .............................................................................................. 32
System Planning........................................................................................................... 33
4.1 Scope of Project ................................................................................................. 34
4.2 Functions of Proposed System: .......................................................................... 34
4.2.1 Function Description ................................................................................... 34
4.3 System Project Planning: ................................................................................... 39
4.3.1 System Project Estimation .......................................................................... 40
4.3.2 Function Oriented Metrics .......................................................................... 40
4.4 Identifying complexity: ...................................................................................... 43
4.4.1 Identifying complexity of transition function: ............................................ 43
4.4.2 Identifying complexity of data function: .................................................... 46
4.4.3 Unadjusted function point contribution: ..................................................... 48
4.4.4 Performance and Environmental impact:.................................................... 49
4.4.5 Counting Adjusted Function point: ............................................................. 50
4.6 Process Based Estimation .................................................................................. 50
4.6.1 Effort Distribution ....................................................................................... 51
4.6.2 Project Schedule.......................................................................................... 52
4.6.3 Project Schedule Chart ................................................................................ 53
4.7 Accounts Table: ................................................................................................. 56
Risk Management ........................................................................................................ 57
5.1 Risk Management .............................................................................................. 58
5.1.1 Stages of risk: .............................................................................................. 58
5.1.2 Categories of risk: ....................................................................................... 60
5.2 The RMMM Plan ............................................................................................... 60
Analysis Modeling ....................................................................................................... 65

2
 6.1 Software analysis pattern ................................................................................... 66
6.2 Activity Diagram ............................................................................................... 66
6.3 Swimlane Diagram............................................................................................. 70
Designing ..................................................................................................................... 73
7.1 Interface design .................................................................................................. 74
7.2 Data Flow Diagram: ........................................................................................... 79
7.2.1 DFD of project: ........................................................................................... 80
7.3 Database Design: ............................................................................................... 82
7.3.1 Entity Relationship Model: ......................................................................... 83
7.3.2 Database Table Structure ............................................................................ 86
7.3.3 Flow Chart .................................................................................................. 89
7.3.4 Class Diagram ............................................................................................. 90
Quality Assurance ........................................................................................................ 91
8.1 System Quality Management ............................................................................. 92
8.1.1. Software Quality Management Process: .................................................... 93
8.2 System Testing ................................................................................................... 96
8.3 Testing: .............................................................................................................. 99
Conclusion ................................................................................................................. 102
9.1 Practicum and Its Value ................................................................................... 103
9.2 Conclusion ....................................................................................................... 103
9.3 Limitations ....................................................................................................... 104
9.4 Future Plan ....................................................................................................... 104
Bibliography .............................................................................................................. 105

3
TABLE OF FIGURES

Figure 1. 1 Organizational Structure ............................................................................ 11

Figure 2. 1 Incremental Model Structure ..................................................................... 17
Figure 2. 2 Incremental Model Design ........................................................................ 18
Figure 3. 1 Use case Diagram ...................................................................................... 31
Figure 4. 1 Effort Based Estimation ............................................................................ 52
Figure 4. 2 Project Schedule Chart .............................................................................. 53
Figure 6. 1 Activity Diagram for “Admin”:................................................................. 68
Figure 6. 2 Activity Diagram for “Student”................................................................. 69
Figure 6. 3 Swimlane Diagram for “Admin” ............................................................... 71
Figure 6. 4 Swimlane Diagram for “Student” .............................................................. 72
Figure 7. 1 Application home page .............................................................................. 74
Figure 7. 2 Student sign up page .................................................................................. 74
Figure 7. 3 Student sign in page................................................................................... 75
Figure 7. 4 Admin dashboard....................................................................................... 75
Figure 7. 5 Admin Login ............................................................................................. 76
Figure 7. 6 Course Add/Edit/Delete............................................................................. 76
Figure 7. 7 Student Profile ........................................................................................... 77
Figure 7. 8 Student Feedback....................................................................................... 77
Figure 7. 9 Lesson Dashboard ..................................................................................... 78
Figure 7. 10 Online Courses ........................................................................................ 78
Figure 7. 11 Context Level Diagram ........................................................................... 80
Figure 7. 12 Level 1 DFD ............................................................................................ 81
Figure 7. 13 Entity Relationship Diagram ................................................................... 85
Figure 7. 14 Flow Chart ............................................................................................... 89
Figure 7. 14 Class Diagram ......................................................................................... 90

4
LIST OF TABLES

Table I: Complexity Matrix ......................................................................................... 42

Table II- Complexity Matrix for UFP .......................................................................... 43
Table III- Transaction Function point count ................................................................ 43
Table IV- Data function point count ............................................................................ 46
Table V- Unadjusted function point contribution of transition function ..................... 48
Table VI- Unadjusted function point contribution of data function ............................ 49
Table VII- Complexity Adjustment Value Count ........................................................ 49
Table VIII- Process based estimation .......................................................................... 51
Table IX- Personnel cost .............................................................................................. 54
Table X- Personnel cost ............................................................................................... 54
Table XI- Hardware cost .............................................................................................. 55
Table XII- Software Cost ............................................................................................. 55
Table XIII- Other cost .................................................................................................. 55
Table XIV- Account Table .......................................................................................... 56
Table XV- Business risks............................................................................................. 60
Table XVI- Technical risks .......................................................................................... 62
Table XVII- Project risks ............................................................................................. 64
Table XVIII- Admin (Stores Admin Detail) ................................................................ 86
Table XIX- Student (Stores Student Detail) ................................................................ 86
Table XX- Feedback (Stores Feedback Detail) ........................................................... 86
Table XXI- Course (Stores Course Detail) .................................................................. 87
Table XXII- Lesson (Stores Lesson Detail)................................................................. 87
Table XXIII- Courseorder (Stores Course order Detail) ............................................. 88
Table XXV- Login ....................................................................................................... 99
Table XXVI- User/Student Registration .................................................................... 100
Table XXVII- Add Course......................................................................................... 101

5
Development of
E-learning Management System for
LancerCode

6
Chapter: 01
ORGANIZATION PART

7
1.1 ORGANIZATION OVERVIEW
Lancercode was founded by pro-minded, motivated, and young individuals who are
leading a superior life in freelancing marketplaces. Lancercode offers you the best
training opportunities to develop your skills and bring out your inner potentiality to lead
a path on your freelancing career. It came to stand out with an aim to play a vital role
to eradicate the unemployment problem in Bangladesh. Enriched with the best skill and
quality we will help you to reveal your talents and make you a successful freelancer to
lead a superior life.

Freelancing is the most in-demand career nowadays. Everyday many people start to
become a freelancer but few of them succeed and others fail due to lack of confidence
and proper guidance. Proper Branding and best soft skill is the key to be a successful
freelancer.

Lancercode is a skill development training center providing the best freelancing and
skills training on the most demandable skills with proven strategies and planning that
worked for many freelancers to succeed. We are committed to proving eccentric
learning ways that will focus on technical skills, as well as branding, soft skills,
effective communication, and support which you need equally to succeed as a
freelancer.

1.2 ORGANIZATION SERVICES

1. Mobile App Development:

 IOS, android, and windows app creation.

 Business requirements analysis.
 User Interface (UI) testing.
 Quality assurance (QA) testing
 Project completion on time and budget.

8
2. Web Application Development for Data Visualization

 Controlled and transparent development process.

 Experience backed QA practices.
 Deployment, stabilization and ongoing support & maintenance.
 Data visualizations.

3. Custom form development for mobile client

 Customer design the form for survey.

 Customer See the submission in real-time.

4. Freelancing Skill Development

 Digital Marketing
 WordPress Website Design
 Video Editing
 Graphic Design

5. Product Delivery

1.3 OUR LOCATION AT BANGLADESH

House#85, Road#8, Block#D, Banani, 1213

(+880) 1894088658
[email protected]

9
1.4 ORGANIZATION VIS ION
To become a leading institute known for its diversity and renowned for its information
sharing excellence. We aspire to be internationally the number one provider of better
skills and services to lead a better career.

1.5 ORGANIZATION MISSION

 To bring out the talent in individuals to lead a better life
 Dedication to building support for our community of freelancers
 Empowering society by guaranteeing a state-of-the-art solution that increases the
trust in quality learning.
 To expand possibilities and prosperity by broadening the fields and prospects for
our future leaders.
 Using the strength of young people by representing and addressing the evolving
demands of both local and global networks.

1.6 MY POSITION IN THIS ORGANIZATION

I was appointed as the website designer and management intern with side of digital
marketing in the organization in 6th of January, with 4 moth of training period

 HTML5
 CSS3
 BootStarp
 SQL
 Database Design
 Testing
 Online Marketing

I have successfully completed those and I was given to design the pre version of the
website with Learning Platform, integration with LearnDash and Thinkfic style

10
1.7 ORGANIZATION STRUCTURE:

Figure 1. 1 Organizational Structure

11
Chapter: 02
PROJECT INTRODUCTION

12
2.1 INTRODUCTION:
Internship is a practical exposure of theoretically gained knowledge and can be
measured as a preliminary trial to be aware with any organization and to make oneself
confident enough to enter into service life and start building career. As the outside world
is very much competitive for anyone after graduation, IUBAT-International University
of Business Agricultural and Technology provides such an opportunity to build up the
capability with most appropriate opportunities. The student gets the chance to apply
his/her theoretical knowledge and practical skill that he/she has gained in the entire
under graduation student life. This documentation includes the details description of
my project work during my internship at Lancercode. The internship period was for last
4 months.

This report is generated to describe the processes and works done in different levels of
website design and management pre design. In this report I have described every part
of the development segments with proper illustrations. This E-learning management
system could be used by anyone and everyone and control over admin. It could be used
by individuals who have acquired a skill set for the passion of it, or have had an
experience of a lifetime and have certifications to prove it. An individual could use it
as an online learning platform. This project is the testing version for the internship with
base on my prior knowledge and would be upgraded over time with help of my senior
developers.

2.2 BACKGROUND OF STUDY:

The technology is used to develop the front-end of “Elearning Management System”
with help of Raw html, css, jquery, sql, apache database, php. It includes pHp and Html
CSS for object relationship model, PostgreSQL for Database. HTML and CSS with
Bootstrap makes it painless to create interactive UIs. Design simple views for each state
in UI, and SQL database just the right components when your data changes. The admin
and user part make it easy to make changes and see updates.

2.3 OBJECTIVES:
A flexible web-based learning experience allows you to go through a guided curriculum
or choose lessons on an as-needed basis. Following are the main objectives:-

13
  Ability to recall previously learned material – Students/learners can watch video
courses as many times as they need. If they forgot something during the course
they can come back and watch that specific part anytime.

 Creative way to present lesson – It is very creative way to present lectures. It

will surely enhance teaching ability of tutor.

 Low Cost – As nobody needs to travel or rent anything so it’s very cost efficient.

 High Quality – As tutor do not has time boundation so he can teach in his own
comfort time.

 Learn anytime from anywhere – Students/Learners can start learning anytime

from anywhere they just required internet connection with a compatible device.

 Improve course quality according to learner’s feedback – Tutor can improve

their course as per student’s feedback. It will help tutor to improve their ability
to teach.

 Earn Money Online– As courses are paid so we can say it’s an online teaching
business which has no boundaries means students/learners can join from across
the world so this system can make good business with good quality.

2.3.1 BROAD OBJECTIVE:

The broad objective of this project is to use my institutional educational experience in
the real life working environment by developing E-learning management system for
Lancercode. This project as titled “Lancercode (E-Learning Management System)” is
comes under the Web Based Application. This application is developed with the help
of HTML, CSS, Bootstrap, PHP, MySQL etc.

Web Based Application

14
2.3.2 SPECIFIC OBJECTIVES:
 To make Learning easier.
 To make admin management easier.
 To make customer believe that online learning is not a difficult thing.
 To make pen paper based work automated.
 To make it easier for Lancercode to track their customers.
 To make it easier for Admin to manage all the customers.
 To make it easier for admin to fixed the course and set up lessons.
 To make it easier for the HR having the full details of work
automatically.

2.4 PROPOSED SYSTEM’S BENEFITS:

The “E-learning Management System” will make learning more easier and organize.
The system benefits are given below:

2.4.1 EASY TO GET REGISTERED:

This application allows users to get registered very easily. Users have to fill-up
some basic information like name, phone, password, User have fill-up all the
information of the sign up page. Later on he/she can update their profile
information.

2.4.2 TIME EFFECTIVE:

The “E-learning management system” will save the HR, Admin and Customers
time. It’s easy to find courses and lessons once enroll.

2.4.3 IMPROVE EFFICIENCY:

Processes automated using software would mean that the processes will be taken
care of mechanically without any human intervention and this will instantly
ensure improved efficiency.

15
2.4.4 DATA SECURITY AND RETRIEVE-ABILITY:
All the personal information of user is safe and secured. Only the authorized
personnel getting access to it and retrieving the data in the minimum possible
time.

2.4.5 NEW TECHNOLOGY:

For building this system some new technologies concept like learndash and
thinkific system structure are used here which makes the faster compilation of
the system.

2.5 METHODOLOGY:

The development process on “E-learning Management System for Lancercode.” is

completed by following the structure described later on Software Analysis & Design.
The study of this project is tentative in nature. It aims to development of a system which
makes the service seeking and providing process easier. The variables identified to
manipulate through a handy inspection and from primary and secondary data.

2.5.1 DATA SOURCES:

For this project in data collection phase I collected two types of data

 Primary Data
 Secondary Data
Primary data are collected from customers who gives me a clear idea how the service
seeking process is carried on now-a-days. The clinics practical experience and
observation helped me generate the primary data.

Secondary data are generated by studying different articles, newspapers, research

papers and of course information collected via Internet. Data and facts collected from
different web sites and sources made us understand the project better.

2.6 SOFTWARE DEVELOPMENT PROCESS MODEL:

The Software Process Models are the various processes or methodologies that are being
selected for the development of the project depending on the project’s aims and goals.
There are many development life cycle models that have been developed in order to

16
achieve different required objectives. The models specify the various stages of the
process and the order in which they are carried out.

The selection of model has very high impact on the testing that is carried out. It will
define the what, where and when of our planned testing, influence regression testing
and largely determines which test techniques to use.

Choosing right model for developing of the software product or application is very
important. Based on the model the development and testing processes are carried out.

A Process Model describes the sequence of phases for the entire lifetime of a product.
Therefore it is sometimes also called Software Life Cycle. This covers everything from
the initial commercial idea until the final de-installation or disassembling of the product
after its use.

Figure 2. 2 Incremental Model Structure

In order to develop the project “LancerCode E-learning Platform” we have adopted the
Iterative Enhancement Model also known as Incremental Model. This model removes
the shortcoming of waterfall model. Since many facts of this system are already known.
It is not a new concept and hence no research is required. A working version can be
easily created and hence the system can start working. Rest of the functionalities can
be implemented in the next iteration and can be delivered later. As the requirement
analysis is also not required. It not being a new technology risk involved is also less.
So one need not perform detailed risk analysis. If redevelopment staff is less than

17
development can be started with less number of people and in next increments others
can be involved. As this model combines the advantage of waterfall model and
prototyping, clients are always aware of the product being delivered and can always
suggest changes and enhancements and can get them implemented. As less amount of
customer communication is required one need not apply spiral model in which all types
of analysis is done in detail. As the deadline is affordable one need not to for Rapid
Application Development model. Iterative enhancement model is useful when less
manpower is available for software development and the release deadlines are
specified. It is best suited for in house product development, where it is ensured that
the user has something to start with. The complete product is divided into releases and
the developer delivers the product release by release.

Figure 2. 2 Incremental Model Design

18
2.6.1 REASON FOR CHOOSING:
 Faster time to market
 Feedback from real customers
 Product definition is stable
 Technology is understood.
 There are no ambiguous requirements.
 Early risk reduction
 Better quality
 Efficiency, Predictability and Alignment
 Customer satisfaction
 Emergent outcomes

2.6.2 STEPS OF INCREMENTAL APPROACH:

Requirement Analysis: In this phase an analyst is concerned with correctly identifying
problems, opportunities, and objectives. This stage is critical to the success of the rest
of the project because no one wants to waste subsequent time addressing the wrong
problem.

Activity of this phase:

 Interviewing user management

 Summarizing the knowledge obtained
 Estimating the scope of the project
 Questionnaires
 Documenting the results
Output: Feasibility report containing problem definition and objective summaries from
which management can make a decision on whether to proceed with the proposed
project.

Design and Prototyping: In this phase, the system analyst uses the information
collected earlier to accomplish the logical design of the information system. In this
phase the system and software design is prepared from the requirement specifications
which were studied in the first phase. System Design helps in specifying hardware and

19
system requirements and also helps in defining overall system architecture. The system
design specifications serve as input for the next phase of the model.

In this phase the testers comes up with the Test strategy, where they mention what to
test, how to test.

Development: On receiving system design documents, the work is divided in

modules/units and actual coding is started. Since, in this phase the code is produced so
it is the main focus for the developer. This is the longest phase of the software process
model life cycle.

Quality Assurance: After the code is developed it is tested against the requirements to
make sure that the product is actually solving the needs addressed and gathered during
the requirements phase. During this phase all types of functional testing like unit testing,
integration testing, system testing, acceptance testing are done as well as non-functional
testing are also done.

Deployment: After successful testing the product is delivered / deployed to the

customer for their use.

As soon as the product is given to the customers they will first do the beta testing. If
any changes are required or if any bugs are caught, then they will report it to the
engineering team. Once those changes are made or the bugs are fixed then the final
deployment will happen.

Release to market: Once when the customers starts using the developed system then
the actual problems comes up and needs to be solved from time to time. This process
where the care is taken for the developed product is known as maintenance.

Then the product is ready to release to the market. It should be noted that systems work
is often cyclical. When an analyst finishes one phase of systems development and
proceeds to the next, the discovery of a problem may force the analyst to return to the
previous phase and modify the work done there.

20
2.7 FEASIBILITY STUDY
A feasibility study is an analysis of how successfully a project can be completed.
Feasibility study is made to see if the project on completion will serve the purpose of
the organization for the amount of work effort and the time that spend on it. Feasibility
study lets the developer foresee the future of the project and the usefulness. A feasibility
study of a system proposal is according to its workability; which is the impact on the
organization, ability to meet their user needs and effective use of resources. Thus when
a new application is proposed it normally goes through a feasibility study before it is
approved for development.

The document provide the feasibility of the project that is being designed and lists
various areas that were considered very carefully during the feasibility study of this
project such a Technical, Economic and Operational feasibilities. The following are its
features:

2.7.1 TECHNICAL FEASIBILITY

Technical feasibility centers on the existing computer system (Hardware, Software etc.)
and to what extent it supports the existing system. As the existing system computer
system is viable so there is no matter of technical feasibility that is the system is
technically feasible. In this type of feasibility study it is checked whether there is a need
of new hardware/software or not. What are the basic requirements of the project? If
there is need then how it can be fulfilled. In this context, this project doesn’t need any
special hardware or software. It can run on window 7/10 platform. However, Internet
and a Web browser is needed to run the web application.

Technical issues raised during the investigation are:

 Is it possible to develop the proposed system using the current technical

resource?
 If not, can current technical resources be upgraded or added to in a manner that
fulfills the request under consideration?
 Is there technology in existence that meets the specifications?
Though the concept of “E-learning Management System” is pre version and the process
of finding provider is easy and effective so I hope users will take this application as
their daily service seeking process.

21
At the same time as the process of using this application is easy so the users of this
application are technically proficient to accomplish the objectives.

This project is developed using ORM and thus it will need very low technical ability to
operate and react will also give the Single page feel.

2.7.2 ECONOMIC FEASIBILITY

The project has shown the economic feasibility by the study of the fact that by using
this software the increased number of the users can be given service effectively and
efficiently and can save a lot time and saving time means saving money. The cost and
benefit analysis has shown that cost that have incurred in developing the project is
less than the benefits that the project is going to provide once it is developed, so this
project has passed the feasibility test

The following are some of the important financial questions asked during preliminary
investigation:

 The costs conduct a full system investigation.

 The cost of the hardware and software.
 The benefits in the form of reduced costs or fewer costly errors.
Since the proposed system is developed as part of my practicum defense completion,
there is no manual cost to spend for the proposed system. Also all the resources that are
needed to develop the system are already available, it give an indication of the system
is economically possible for development.

2.7.3 OPERATIONAL FEASIBILITY

Operational feasibility determines if the human resources are available to operate the
system once it has been installed. Users that do not want a new system may prevent it
from becoming operationally feasible.

In this feasibility study it is determined whether there is need of well qualified operator
or simple user. Is there need to train the operator or not? This project is supporting the
User friendly Web application; hence operating this project is so simple. Even a person

22
who has a little knowledge of computer can easily handle this well. There is no need of
trained operator.

This includes the following questions:

 Is there sufficient support for the users?

 Will the proposed system able to fulfil the user needs?
The project would be beneficial because it satisfies the objectives when it developed
and installed. All behavioral aspects are considered carefully and conclude that the
project is behaviorally and operationally feasible.

23
Chapter: 03
REQUIREMENT ENGINEERING

24
3.1 REQUIREMENT ANALYSIS:
Requirements analysis is a software engineering task that bridges the gap between
system engineering and system design. Requirements analysis allows the software
engineer to define the software allocation and build the models of the data, functional
and behavioral domains that will treat by software. Requirement analysis provides the
software designer with a representation of information, function and behavior of the
system.

Requirements analysis is the first stage in the software development process. It

encompasses those tasks that go into determining the needs or conditions to meet for a
new or altered product, taking account of the possibly conflicting requirements of the
various stakeholders, such as beneficiaries or users.

Analysis the requirement is critical to the success of a development project.

Requirements must be actionable, measurable, testable, related to identified business
needs or opportunities, and defined to a level of detail sufficient for system design.
Requirements can be functional and nonfunctional.

There are 6 phases of requirement analysis which is described below:

Requirement Initiation: I submit a proposal on the project entitled “E-learning

Management Platform”.

Requirement Elicitation: Eliciting requirements is the task of communicating with

customers and users to determine what their requirements are. This is sometimes also
called requirements gathering.

New systems change the environment and relationships between people, so it is

important to identify all the users, take into account all their needs and ensure they
understand the implications of the new systems.

I also try to understand the user's needs and constraints for the system. I analyze User’s
work. In this phase I do mainly two works:

 Analyze the Requirement

 Recording User Requirements
Requirement Elaboration: This is the process of collecting user's needs and
constraints. How the entities of the system will interact with each other.

25
Requirement Negotiation: This is the process of negotiating with the client about the
software cost and other facilities will be provided with the system.

Requirement Specification: A software requirements specification (SRS) is a

complete description of the behavior of the system to be developed. It includes a set of
use cases that describe all of the interactions that the users will have with the software.
In this stage I specified the manpower requirements, and technologies required for the
deployment of the system.

Requirement Verification: I verify all the requirements of the user whether they need
any modification or not.

3.2 REQUIREMENTS ENGINEERING:

Requirements engineering is, as its name suggests, the engineering discipline of

establishing user requirements and specifying software systems. There are many
definitions of Requirements Engineering; however, they all share the idea that
requirements involves finding out what people want from a computer system, and
understanding what their needs mean in terms of design. Requirements engineering is
closely related to software engineering, which focuses more on the process of designing
the system that users want.

 User requirements
 System requirements
 Functional requirements

3.2.1 USER REQUIREMENTS

1. Admin can login in admin panel.
2. Students can login in student panel
3. Admin can create Course, Chapter, Lessons
4. Students can get access to Course, chapter, lessons on enrolment
5. Admin can approve Student, Check Student List, and Delete Student.
6. Admin can add, edit or delete course.
7. Student can provide feedback.
8. Admin can approve and delete feedback but can’t edit.
9. Student can pay for course.
10. Admin can check payment details and sells report.

26
3.2.2 SYSTEM REQUIREMENTS:
Admin:
1. Can login into panel
1.1. Fill name
1.2. Fill password field
1.3. Click login
1.4. Call the API in GET method for validation if validations are true then login
successful otherwise unsuccessful
1.5. Login is successful then redirect to the panel for admin
1.6. If any error occur then give a message and redirect to the login page again
2. Admin can see courses amount.
3. Admin can see student list.
4. Admin can add students.
5. Admin can check student enrollment course

Student:
1. Can create an account.
1.1. Fill up Name
1.2. Fill password field
1.3. Fill confirm password field
1.4. Click the register button
1.5. Call the API in POST(it will automatically give the conflicted registration
message because of REST API) method for confirmation or validation
1.6. Phone number exists or not
1.7. If no conflicted phone number then login is successful
1.8. If successful then give confirm message
1.9. If error then also give a message

2. Can log in
2.1. Fill up name or email
2.2. Fill password field
2.3. Click login
2.4. Call the API in GET method for validation if validations are true then login
successful otherwise unsuccessful
2.5. Login is successful then redirect to the panel for Student
2.6. If any error occur then give a message and redirect to the login page again

27
3. Can update his personal information
3.1. Click on edit
3.2. All field will come
3.3. Fill what needs to be updated
3.4. Click on save
3.5. Call the API in PUT method
3.6. Then redirect to profile page again.

4. Can see course list

4.1. Student will click in course list.
4.2. Call the API in GET method and get the all course list
4.3. All the campaign will come as a list in a table
4.4. All campaign will have a name

5. Can see course details for his own.

5.1. A specific course clicked
5.2. Call the API in GET method and get all the information about the course
5.3. Show each information in a separate tab

6. Can do payment
6.1. Click to take a course
6.2. Enroll a course
6.3. Go to checkout
6.4. Do payment online
6.5. Click save
6.6. Call API in PUT method
6.7. If successful then load the show data collection checklist component
6.8. If unsuccessful then give an error message

3.2.3 FUNCTIONAL REQUIREMENTS

1. Admin can add new Admin and update his/her own profile.
2. Admin can narrow down and filter the user list.
3. Admin can approve any service after seeker transaction.
4. Admin can check review to approve or delete but can’t edit.
5. Admin can narrow down and filter the course list.
28
3.2.4 NON-FUNCTIONAL REQUIREMENTS:
1. No length of password set. It can be letter or digit or combination of both.
2. Only Admin can add new Admin.
3. Only Admin and can remove Student from choose list.
4. Without filling up all the field the sing up form won’t submitted.
5. Without providing valid information the form won’t submitted.
6. For submitting update or registration user have to login to his/her account

A use case diagram at its simplest is a representation of a user's interaction with the
system that shows the relationship between the user and the different use cases in which
the user is involved. A use case diagram can identify the different types of users of a
system and the different use cases and will often be accompanied by other types of
diagrams as well. The use case technique is used to capture a system's behavioral
requirements by detailing scenario-driven threads through the functional requirements.

3.3.1 USE CASE SYMBOLS:

Actor: An actor represents a set of roles that users of use case play when interacting
with these use cases. Actors can be human or automated systems.

Use case: A use case represents a user goal that can be achieved by accessing the system
or software application. A use case is the specification of a set of actions performed by
a system, which yields an observable result that is typically of value for one or more
actors of the system.

Association: Actor and use case can be associated to indicate that the actor participates
in that use case. Therefore, an association correspond to a sequence of actions between
the actors and use case in achieving the use case.

29
Include: An include relationship specifies how the behavior for the inclusion use case
is inserted into the behavior defined for the base use case.

Extend: An extend relationship specifies how the behavior of the extension use case
can be inserted into the behavior defined for the base use case.

System: The use cases of the system are placed inside the system shape, while the actor
who interact with the system are put outside the system. The use cases in the system
make up the total requirements of the system.

30
3.3.2 USE CASE DIAGRAM:

Figure 3. 1 Use case Diagram

31
3.3.3 USE CASE TEXT:
Use case title- Add new Course

Actor- Admin

Description- Only Admin is allowed to add new Course from the system module.
Admin can sign up by providing their full valid information.. If any field is not fill up
with valid information then an error message will show.

Use case title- Login

Actor- Admin, Student

Description- User will get different login page to get access into the system. User have
to give email address and password, system will match it with user role id and then give
access to respective user home page.

Use case title- User Profile

Actor- Admin, Student

Description- Admin can view full user profile with contact information. Admin can see
all the student profile. All user can view and update their own profile.

Use case title- Transaction

Actor- Admin, Students

Description- Students have to complete transaction process to confirm the booking.

After the transaction Admin will get a notification and Admin have to approve the
service. Then provider will get a notification for the service confirmation. Admin can
view the transaction details.

Use case title- Write Feedback

Actor- Students

Description- Students can send feedback from his/her choose list. An image of seeker
with the text will send to the admin. Admin will get notification for messages. Admin
will approve the feedback and it will show in the from page under feedback section

32
Chapter: 04
SYSTEM PLANNING

33
4.1 SCOPE OF PROJECT
A project scope is the clear identification of the work required to successfully complete
or deliver a given project. Project scope control and management is often overlooked
in the management ranks. Software scope determination is the first and most important
activity in software project planning. The statement of software scope must bind. The
software should have ability to manage the members, operators and package
information’s and the database. This project has given the power of re-usability. Present
developers are hard to strict towards giving the system a fully dynamic come across.

4.2 FUNCTIONS OF PROPOSED SYSTEM:

Functions of this proposed system are given below:

Login into the System F1

Add user F2

Update profile F3

Choose user F4

Communicate user F5

Book user F6

Transaction Update F7

Rate and review user F8

Generate report F9

4.2.1 FUNCTION DESCRIPTION

Function description descriptive the function in details. It concerns on three factors:
what is the possible input, possible output for a particular function and which table of
the database uses by that function.

34
Input Module

In order to complete the tasks of E-learning and to get output by using this application
work, there is need of some input based on the work that is to be carried out by using
it. Different kinds of input are required for different purposes.

 Student/Learner Registration

 Course

 Lesson

 Feedback

 Payment Status

Output Module

The project named “LancerCode E-Learning Management System” is being made

keeping in mind to solve the activities that are carried out in the Education. By using
this, Admin can easily do many things like as:

 Student/Learner List

 Course Detail

 Lesson Detail

 Sell Report

 Payment Receipt

Modularization Detail

Without Registration

 Home – This module contains all the links of the application such as Courses,
Payment Status, Login, Sign Up, Feedback Section and Contact.

 Courses – This module contains list of all the courses which are available at
Lancercode.
35
  Payment Status – This module is used to check Payment status after purchasing
a course.

 Login – This module is used to login into Student/Learner Panel.

 Sign Up – This module is used to register for the Student/Learner Panel.

 Feedback – This section shows feedback given by registered students/learners.

 Contact – Learner can use this section to contact the admin/tutor for any kind of
queries.

Student Panel

 Profile – This module contains all the details about Student/Learner as well as
Student can update their details.

 My Courses – This module contains list of all purchased courses.

 Feedback – This module is used to write feedback.

 Change Password – Students can use this module to change password.

 Logout – This module is used to return back to Home Page.

Admin Panel

 Dashboard – This module displays overview of whole application.

 Courses – This module contains all the courses.

 Lessons – This module contains all the lesson depends on course id.

 Students – This module displays all the registered student details.

 Sell Report – This module is used to view and print sells report.

 Payment Status – This module displays payment status in more details.

 Feedback – This module displays feedback given by students.

 Change Password – Admin can use this module to change password.

 Logout – This module is used to return back to Home Page.

36
Process Logic

Home:

When the user click on this tab, it will display the other modules and pages of the
website such as courses, payment status, login, sign up, popular section, feedback
section, contact and admin login. This module will be used to display the brief
introduction of the project and will show the title of the project.

Courses:

Student can view all available courses by clicking on courses tab where he can choose
course according to his own interest and by clicking on a particular course, will display
more details with lesson title of the course, if he wants to purchase he will be able to
make payment (required login).

Payment Status:

After purchasing course student will be provided an order id which can be used to get
the status of payment using Payment status tab. If student wants he can get print out of
his payment status.

Login:

This is a login form. Student/Learner can use their own email and password to login
into the student panel.

Sign Up:

This is a Registration form for new Students/Learners. New Students/Learners can fill
up the form for registration and after successful registration they can use their email id
and password to login into the application.

Feedback:

This is very simple section which displays feedback given by the registered student.

Contact:

Learner can use this section to contact the admin/tutor for any kind of queries.

37
Student Panel:-

Profile:

Students/Learners can view their student id, registered email id, name, occupation,
profile picture as well as they can modify and update the new data if they need.

My Courses:

Students can view all courses which they purchased. This is the place where they can
start watching lectures by clicking on Watch Course button which leads to course
playlist where they can watch the entire lesson of course.

Feedback:

Students can view/write feedback.

Change Password:

Students can use this module to change password.

Logout:

This module is used exit student panel and return back to Home Page.

Admin Panel:-

Dashboard:

This module displays overview of whole application such as number of course, number
of registered students etc.

Courses:

This is the most important module of admin panel where Admin can view list of course
as well as add new courses and modify or delete courses.

Lessons:

Admin can view lesson based on course id as well as new lesson can be added to the
course and modification or deletion is also possible using this module.

Students:

38
Admin can view registered students details. Admin can add, edit and delete student.

Feedback:

Admin can view/delete feedback given by student.

Sell Report:

Analyzing sales is very import for any kind of business and this module is perfect for
analyzing sales based on date. It will generate sells report which can be possible to print
out for office records.

Payment Status:

If student file any complaints regarding payment Admin can use this module to display
payment status in more details such as bank name, transaction id, payment date etc.

Change Password:

Admin can use change password.

Logout:

This module is used exit admin panel and return back to Home Page.

4.3 SYSTEM PROJECT PLANNING:

Before starting any project, it is compulsory to estimate the work to be done, the
resources that will be required, the time that will elapse from start to finish and to
analyze the project to determine whether it is feasible or not. Software project planning
is the second activity of CPF. Software project management commences with a set of
activities that collectively called software project planning. Through the software
project planning I estimate the work to be done, the resources that will be required, the
time that will elapse from start to finish and finally I analyze the project to determine
whether it is feasible or not.

The following activities of software project planning that have followed in this project
are:

 Function Point Estimation of the project

 Process Based Estimation

39
  Task scheduling
 Project Schedule Chart
 Personnel requirements
 Resource requirements
 Estimation of the software cost

4.3.1 SYSTEM PROJECT ESTIMATION

The accuracy of a software project estimate predicated based on a number of things:

 Properly estimated the size of the product to build. The ability to translate the
size estimation into human effort, calendar time and money.
 The degree to which the project plan reflects the abilities of the software team
or engineer.
 The stability of the product requirements and the environment that supports the
software engineering effort.
 Software size estimation is the most important matter that I have to consider
during the software project. If the software size is not calculated properly, then
this will cause various problems such as scheduling problems, budget problem
etc. As the project is going on, before estimating the software size, I have to
confirm that software scope is bounded.
Software size estimation is the most important matter that I have to consider during the
software project. If the software size not calculate properly, then this will cause various
problems such as scheduling problems, budget problem etc. As the project goes on
before estimating the software size, I have to confirm that software scope is bounded.

4.3.2 FUNCTION ORIENTED METRICS

Function point based estimation focuses on information domain values rather than
software values. Function points are computed by comparing five information domain
characteristics.

Data Functions

 External Inputs [EI]

 External Output [EO]
 External Inquiries [EQ]

40
Transaction Functions

 Internal Logical Files [ILF]

 External Interface Files [EIF]
Number of external inputs: Each user input that provides distinct application-oriented
data to the software is counted inputs should be distinguished from inquires.

Number of external outputs: Each user output that provides application-oriented

information to the user is counted.

Number of external inquires: An inquiry defined as an on-line input those results in

the generation of some immediate software response in the form of an on-line output.
Each distinct inquiry counted.

Number of Internal Logical files: Each logical internal file is a logical grouping of
data that resides within the application's boundary and is maintained via external inputs.

Numbers of external interfaces: All machine-readable interfaces that used to transmit

information to another system counted. The weights of the domains are fixes, which are
provided in appropriate table location. Weights can be divided into three categories
according to the functionality of the system. They are simple, average and complex.
The total system is a complex system but the part of the total system. Once these data
has collected, a complexity value is associated with each count.

Functional Complexity: The first adjustment factor considers the Functional

Complexity for each unique function. Functional Complexity is determined based on
the combination of data groupings and data elements of a particular function. The
number of data elements and unique groupings are counted and compared to a
complexity matrix that will rate the function as low, average or high complexity. Each
of the five functional components (ILF, EIF, EI, EO and EQ) has its own unique
complexity matrix. The following is the complexity matrix for External Outputs.

After the components have been classified as one of the five major components (EI‟s,
EO‟s, EQ‟s, ILF‟s or EIF‟s), a ranking of low, average or high is assigned. For
transactions (EI‟s, EO‟s, EQ‟s) the ranking is based upon the number of files updated
or referenced (FTR‟s) and the number of data element types (DET‟s). For both ILF‟s
and EIF‟s files the ranking is based upon record element types (RET‟s) and data
element types (DET‟s). A record element type is a user recognizable subgroup of data

41
elements within an ILF or EIF. A data element type is a unique user recognizable, non-
recursive, field. The value adjustment factor (VAF) is based on 14 general system
characteristics (GSC's) that rate the general functionality of the application being
counted. The degrees of influence range on a scale of zero to five, from no influence to
strong influence. Once these data has collected, a complexity value is associated with
each count And the FP estimated is calculated by the equation

FP estimated=count-total*[0.65+0.01*ΣFi]

The following formula is used to estimate the function points

 FP count = {(opt+4*likely + pessimistic)/6}*weight

 Complexity adjustment factor = [0.65 + 0.01 x Sum of Factor Values]
 FP estimated = count total x Complexity adjustment factor
 Function Point Estimation = Total FP estimated/No. of function point per day.

4.3.2.1 COMPLEXITY MATRIX

Table I: Complexity Matrix

EI 1-4 DETs 5-15 DETs 16 or more DETs

1 FTR Low Low Average
2 FTRs Low Average High
3 or more FTRs Average High High

EO/EQ 1-5 DETs 6-19 DETs 20 or more DETs

1 FTR Low Low Average
2 to 3 FTRs Low Average High
3 or more FTRs Average High High

ILF/ ELF 1-19 DETs 20-50 DETs 50+ DETs

1 RET Low Low Average
2 to 5 RETs Low Average High
6 or more RETs Average High High

42
4.3.2.2 COMPLEXITY MATRIX FOR UFP
Table II- Complexity Matrix for UFP

Complexity Transaction Function Type

EI/EQ EO
L (Low) 3 4
A (Average) 4 5
H (High) 6 7

Complexity Data Function Type

ILF EIF
L (Low) 7 5
A (Average) 10 7
H (High) 15 10

4.4 IDENTIFYING COMPLEXITY:

4.4.1 IDENTIFYING COMPLEXITY OF TRANSITION FUNCTION:

Table III- Transaction Function point count

Transition Field/ file involve FTRs DETs

function

Search Customers Fields: insert id, insert name, choose 2 7

list (EQ) user type, choose gender, insert
profession, insert city, choose rating

File: user, studentlist

Search choose user Fields: insert id, insert name, choose 2 5

(EQ) student, insert profession, insert city

File: user, student list

Search enroll Fields: insert id, insert course name, 2 5

Courses (EQ) choose details, insert details, insert title

File: user, courselist

43
Search enroll list Fields: insert name, course name, insert 1 4
(EQ) title, insert id

File: user

Search sell report Fields: insert id, choose courses, insert 2 5

(EQ) transaction, insert payment details,
success payment

File: user, payment

Add new Admin Fields: Add new option, first name, last 2 14
(EI) name, email, password, confirm
password, select course, contact number,
date of birth, address, country, city, zip
code, , add admin button.

File: user, user_role

Add new Courser Fields: Sign up, select user type, first 2 10
(EI) name, last name, email, password,
course details. Lessons, id

File: user, user_role

Add new Student Fields: Sign up, first name, last name, 2 6
(EI) email, password, confirm password,
File: user, user_role

Update Student Fields: Dropdown header, update profile 1 16

profile (EI) option, first name, last name, password,
confirm password, contact number, date
of birth, address, country, city, zip code,
, profession, , choose image button,
submit button, update profile button.

File: user

Generating Fields: select transaction option, combo 1 4

transaction graph box for year, combo box for month,
for provider (EO) select graph type.

44
 File: transaction

Generating profit Fields: select transaction option, combo 1 4

graph for provider box for year, combo box for month,
(EO) select graph type.

File: transaction

Generating report Fields: Select transaction option, refresh 2 4

for admin (EO) button, print button, download option

File: Transaction, user

Generate profile Fields: View profile button, name 1 3

view (EO) option to view profile, submit button

File: User

Generating Fields: select transaction option, combo 1 4

transaction graph box for year, combo box for month,
for admin (EO) select graph type.

File: transaction

Generating profit Fields: select transaction option, combo 1 4

graph for admin box for year, combo box for month,
(EO) select graph type.

File: transaction

Generating report Fields: Select transaction option, refresh 1 3

for admin (EO) button, print button, download option

File: Transaction, user

Insert message (EI) Fields: Choose user, chat button 1 3

message field, send button,

File: review

Add transaction (EI) Fields: booked user, transaction button, 1 9

from date, to date, booking hour, net bill,
billing contact number, transaction id,
submit button

45
 File: transaction

Review (EI) Fields: transact user, review option, 1 7

review button, clicking on name option,
rating radio button, comment textbox,
submit button.

File: review

Remove booked or Fields: booked option, choose option, 1 4

choose user (EI) clicking on name option, remove button

File: addstudent

4.4.2 IDENTIFYING COMPLEXITY OF DATA FUNCTION:

Table IV- Data function point count

Data function Fields/File involve RETs DETs

User (ILF) Fields: first_name, last_name, password, 1 16

confirm password, gender, email,
contact_number, dob, address, country,
city, zip code, nid number, profession,
experience, image.

File: user

User role (ELF) Field: role_id, name 1 2

File: user_role

User category (ILF) Field: user_role, service_map_status, 3 6

user_id, user_name, user_profession,
proce_rate.

File: user, user_role, service_map

Transaction (ELF) Field: seeker_name, provider_name, 2 9

user_id, id, net_amount,

46
 dervice_duration, transaction_id,
billing_contactno

File: transaction, user

User review (ELF) Field: seeker_id, provider_id, 2 5

user_name, review, rating

File: user, review

User Field: seeker_id, provider_id, 2 4

communication user_name, comment
(ELF) File: user, comment

47
4.4.3 UNADJUSTED FUNCTION POINT CONTR IBUTION:
Table V- Unadjusted function point contribution of transition function

Transition function FTRs DETs Complexity UFP

Search Student list (EQ) 2 7 Average 4

Search choose Course (EQ) 2 5 Low 3

Search enroll user (EQ) 2 5 Low 3

Search course list (EQ) 1 4 Low 3

Search lesson list (EQ) 2 5 Low 3

Add new admin (EI) 2 15 Average 4

Add new student (EI) 2 13 Average 4

Add new Course (EI) 2 13 Average 4

Update user profile (EI) 1 20 Average 4

Generating transaction graph for 1 4 Low 4

provider (EO)

Generating profit graph for admin 1 4 Low 4

(EO)

Generating report for admin (EO) 2 4 Low 4

Generate profile view (EO) 1 3 Low 4

Generating transaction graph for 1 4 Low 4

admin (EO)

Generating profit graph for admin 1 4 Low 4

(EO)

Generating report for admin (EO) 1 3 Low 4

Review (EI) 1 3 Low 3

Add transaction (EI) 1 9 Low 3

Remove booked or choose user (EI) 1 4 Low 3

Total 69

48
 Table VI- Unadjusted function point contribution of data function

Data Function RETs DETs Complexity UFP

User (ILF) 1 16 Low 7

User role (ELF) 1 2 Low 5

User category (ILF) 3 6 Low 7

Transaction (ELF) 2 9 Low 7

User review (ELF) 2 5 Low 7

User communication (ELF) 2 4 Low 7

Total 40

4.4.4 PERFORMANCE AND ENVIRONMENTAL IMPACT:

Table VII- Complexity Adjustment Value Count

GSC (General System Characteristics) DI

1. Data communication 4

2. Distributed data processing 0

3. Performance 5

4. Heavily used configuration 2

5. Transaction rate 2

6. Online data entry 0

7. End user efficiency 3

8. Online update 0

9. Complex processing 3

10. Reusability 4

11. Installation ease 3

12. Operational ease 3

13. Multiple sites 0

14. Facilitate change 3

Total Degree of Influence(TDI) 32

49
Value Adjustment Function (VAF) = (0.65+ (0.01*TDI))

= 0.65 + (0.01* 32) = 0.97

4.4.5 COUNTING ADJUSTED FUNCTION POINT:

Unadjusted Function Point (UFP) = UFP (Data Function) + UFP (Transition Function)

= 69+ 40

= 109

Adjusted Function Point Count (AFP) = UFP * VAF = 116 *0.97 = 105.73

Efforts for PHO = AFP * Productivity

= 105.73 * 15.5 [Productivity of Php]

= 1638.554 person hours

= 1638.554/ 8 [Working hour is 8 hours per day]

= 204.81925/ 2 person

= 102.97 /24 days

=4.25 months

4.6 PROCESS BASED ESTIMATION

In process-based estimation, process is decomposed into a relatively small set of tasks

and the effort required to accomplish each task is estimated. Process based estimation
begins with a delineation of software functions obtained from the project scope. A
series of software process activities must be performed for each function.

50
 Table VIII- process based estimation

Activity CC Planning Engineering Construction Imp. Total

Analysis Design Code Test
Function
F1 0.003 0.0155 0.12 0.15 0.34 0.12 0.06 0.81
F2 0.001 1.0054 1.17 1.17 2.24 2.12 0.05 7.76
F3 0.002 0.112 0.19 0.25 0.45 0.11 0.06 1.17
F4 0.001 1.111 2.12 1.25 2.45 2.16 0.04 9.13
F5 0.004 0.113 0.3 0.25 0.55 0.13 0.05 1.3
F6 0.005 0.212 3.54 1.25 3.75 2.13 0.06 10.9
F7 0.003 1.034 1.36 0.25 2.45 0.30 0.04 5.6
F8 0.1 0.225 1.42 1.65 2.45 2.15 0.1 8.1
F9 0.01 1.113 2.74 0.50 2.74 1.14 0.09 8.88
Total 0.129 3.91 13 8.72 16.75 10.49 0.55 53.55
Effort 0.24% 7.30% 24.27% 16.28% 31.3% 19.6% 1% 100%

4.6.1 EFFORT DISTRIBUTION

The project estimation technique leads to estimates of work units required to complete
the software development. A recommended distribution of effort across the definition
and development phases referred as the 40-20-40 rule. Forty percent of all effort
allocated to front-end analysis and design, twenty percent allocated to coding and the
remaining forty percent allocated to back-end testing. This rule used as a guideline only.

In this project, 45% of full software development has been allocated to analysis and
design, 35% has allocated to coding and the remaining 20% is allocated to software
testing and support.

51
 Effort Based Estimation
1% 0.24%
7.30%
19.60%

24.27%

31.3%
16.28%

CC Planing Analysis Design Code Test Implementation

Figure 4. 1 Effort Based Estimation

Description:

 (3% - Customer Communication)

 (6% - Planning)
 (25.02% - Analysis)
 (16.50% - Design)
 (31% - Coding)
 (25% - Testing)
 (1% - Implementation)

4.6.2 PROJECT SCHEDULE

Work Breakdown: The following under noted work breakdown activities needs to be
carried out for every products of the project:

a. Design & Specification: Design & specification phase activity deals with modeling
the component/product.

b. Coding: Programming of the design for the component/product carries out in this
phase.

c. Test Plans: In this phase test plans need to be developed to test each
product/component and then integration of all the products/components.
52
d. Testing: Under the test plans, code needs to be tested at each component level and
also when it is integrated with other components. Test results need to be evaluated at
individual component level and at the level of integration also.

4.6.3 PROJECT SCHEDULE CHART

Total system development is a combination of set of tasks. These set of tasks should
done sequentially and timely. Project schedule works as the guideline of the system
developer. The following is the schedule chart of this project:

4.7. Cost Estimation Figure 4. 2 Project Schedule Chart

The approximation of the cost of a program is cost estimation. In this project, there are
five factors to analyze and calculate the cost. Given bellow,

 Personnel cost
 Software cost
 Hardware cost
 Other cost
Personnel cost:

 Number of days in a year = 365

 Number of government holidays in a year =24
 Number of weekly holidays in a year =52
 Total number of working days to develop the project = 365-(52+24) = 289 days
 Total number of working days per months to develop the project = 289/12
=24.083 days
 Organization working hours per day = 8 hours
 Organization working hours per month=24.083*8 = 192.66 hours
 Total working hour in 4 months = 24*8*4 = 768
53
 Table IX- personnel cost

Position Salary/month Salary/hour

System Analyst 40,000 207.62

Designer 35,000 181.67

Coder 30,000 155.71

Tester 20,000 103.81

Total salary of Analyst in 4 months = TK 768*207.62= TK 159,452.16

Total Salary of Designer in 4 months= TK 768*181.67= TK 139,522.56

Total Salary of Coder in 4 months= TK 768*155.71= TK 119,585.28

Total Salary of Tester in 4 months= TK 768*103.81= TK 79726.08

Table X- personnel cost

Designation Person Working Salary Total Salary

Hours

System One 768 159,452.16

Analyst 498,286.08
Designer One 768 139,522.56

Coder One 768 119,585.28

Tester One 768 79,726.08

Hardware cost

Cost of a Computer = 38,000

Computer life = 3 years

Computer Usage = 3+2+1 = 6

Year 1 = 3/6 = 0.5 Year 2 = 2/6 = 0.334 Year 3 = 3/6 = 0.1667

Computer Cost in year 3 = 38000*0.1667 = 6334.6 BDT

54
 Table XI- Hardware cost

Hardware Cost

Computer (2) 12,669.2

Modem 2000

Printer 5000

Total 19,669.2 BDT

Software cost

Table: software cost

IntelliJ IDEA cost for 1 year = 42057.72 TK

IntelliJ IDEA cost for 4 months = (42,057.72/12)*4 = 14,019.24 BDT

Table XII- Software Cost

Name Price

Microsoft Office 8500

Windows 10 7500

PHP Free

Apache Free

Webserver Free

My SQL Free

Total 16,000.00 BDT

Other cost:

Table XIII- Other cost

Name Price

Transport 1200

55
House rent 2000

Electric bill 1500

Other 500

4.7 ACCOUNTS TABLE:

Table XIV- Account Table

Particulars TK TK

Salary-
 System Analyst 159,452.16
139,522.56
 Designer
119,585.28
 Coder
79,726.08
 Tester

4,98,286.08
Hardware cost-
 Computer (2) 12,669.2
 Modem 2000
 Printer 5000

19,669.2
Software cost-
 Microsoft Office 8500
 Windows 10 7500
 Node.js Free
 Visual Code Free
 IntelliJ IDEA 14,019.24
 My SQL Free

16,000.00
Others-
 Transport 1200
 House rent 2000
 Electric bill 1500
 Other 500
5200
Total 539,155.28

56
Chapter: 05
RISK MANAGEMENT

57
5.1 RISK MANAGEMENT
Risk analysis and management are a series of works that help a system development
team to understand and manage uncertainty. Many problems can arise while developing
a system. A risk is a potential problem. It may happen may not.

There are several steps to analyze and manage risks. The first step is risk identification.
Next each risk is analyzed to determine the likelihood that it will occur and the damage
that it will do if it does occur. Once this information is established risks are remarked.
Finally, a plan is developed to manage those risks with high probability and impact.

5.1.1 STAGES OF RISK:

There are different Stages of risks. They are:

 Risk Identification
 Risk Classification
 Risk Assessment
 Risk Analysis
 Risk Management Implementation

Risk Identification:

Risk Identification is the process of detecting potential risks or hazards through data
collection. A range of data collection and manipulation tools and techniques exists. The
team is using both automated and manual techniques to collect data and begin to
characterize potential risks to Web resources. Web crawling is one effective way to
collect information about the state of Web pages and sites.

Risk Classification:

Risk Classification is the process of developing a structured model to categorize risk

and fitting observable risk attributes and events into the model. The team combines
quantitative and qualitative methods to characterize.

58
Risk Assessment:

Risk Assessment is the process of defining relevant risk scenarios or sequences of

events that could result in damage or loss and the probability of these events. Many
sources focus on risk assessment. Rosenthal describes the characteristics of a generic
standard for risk assessment as "transparent, coherent, consistent, complete,
comprehensive, impartial, uniform, balanced, defensible, sustainable, flexible, and
accompanied by suitable and sufficient guidance.

Risk Analysis:

Risk Analysis determines the potential impact of risk patterns or scenarios, the possible
extent of loss, and the direct and indirect costs of recovery. This step identifies
vulnerabilities, considers the willingness of the organization to accept risk given
potential consequences, and develops mitigation responses.

Risk Management Implementation:

Risk Management Implementation defines policies, procedures, and mechanisms to

manage and respond to identifiable risks. The implemented program should balance the
value of assets and the direct and indirect costs of preventing or recovering from
damage or loss.

To make comprehensive care of web based system we must consider the following
points:

Hardware and software environment, including any upgrades to the operating

system and web server, the installation of security patches, the removal of insecure
services, use of firewalls etc.

HRistrative procedures, including contracting with reputable service providers,

renewing domain name registration etc.

Network configuration and maintenance, including load balancing, traffic

monitoring, traffic management, usage monitoring etc.

Backup and archiving policies and procedure, including the choice of backup media,
media replacement interval, number of backups made and storage location.

59
5.1.2 CATEGORIES OF RISK:
There are different categories of risk that should be considered in any software project.
The following categories of risk have been considered in this project:

 Project Risks
 Technical Risk
 Business Risk
Project risk: These risks threaten the project plan. If these risks become real, it is likely
that the project schedule will slip and that costs will increase. Project risks identify
potential budgetary, schedule, personnel, resource, customer and requirement problems
and their impact on the software project.

Technical risk: these risks threaten the quality and timeliness of the software to be
produced. If a technical risk becomes a reality, implementation may become difficult
or impossible. Technical risks identify potential design, implementation, interface,
verification and maintenance problems. Moreover, specification ambiguity, technical
uncertainly, technical obsolescence are also risk factors.

Business risk: These risks threaten the viability of the software to be built. The business
risks can be market risks, strategic risks, changing business needs, management risks,
budget risks etc.

5.2 THE RMMM PLAN

Table XV- Business risks

RMMM Plane No: BR-01 Type of risk

Description Installment risk for the project Business Risk

Impact It will make misunderstanding between client and Disaster

organization

Prevention We will try to sell the project with full down

payment.

Cure License code implementation

Status Working on process

60
 RMMM Plane No: BR-02 Type of risk

Description The project obsolescence to the clients Business Risk

Impact It will effect to clients when they organized it. Disaster

Prevention Some extra features include within the projects. It

will help us.

Cure Reduce the project system for clients and develop

much updated way.

Status Done

RMMM Plane No: BR-03 Type of risk

Description Competition of different market competitors. Business Risk

Impact It will increase the competition among Disaster

organizations.

Prevention Include some extra features within the projects. It

will help us to convince the clients.

Cure Reduce the project cost for clients and focus on

Status Done

RMMM Plane No: BR-04 Type of risk

Description Privacy and security risk of project. Business Risk

Impact Client will hamper and hopeless about the system. Disaster

Prevention Included extra privacy and security system.

Cure Resell the project very strongly by password

system

Status Done

61
 Table XVI- Technical risks

RMMM Plane No: TR-01 Type of risk

Description Lack of adept technical persons for organization Technical

Risk

Impact If it is happening, then the client organization will Marginal

be unable to operate the system.

Prevention Arrange the training session for operators.

Cure To send an expert process to the client

organization for solve this problem

Status Done

RMMM Plane No: TR-02 Type of risk

Description Lack of implementation for organization Technical

Risk

Impact The client falls in danger situation. Marginal

Prevention It will manage for the client to operate the system.

Cure For solving this problem, modify this system with

more implement.

Status Done

62
 RMMM Plane No: TR-03 Type of risk

Description Responsive for different devices. Technical

Risk

Impact If the system is not responsive then it will not Disaster

possible to browse the site by different devices.

Prevention Develop the system as responsive.

Cure If problem arise then need to update the system

for responsive.

Status Working on process.

63
 Table XVII- Project risks

RMMM Plane No: PR-01 Type of risk

Description Lack of required knowledge or skill Project Risk

Impact The development will hamper. Marginal

Prevention Make detail conversation with the clients about

their requirement before.

Cure To needed update the system according the

client’s requirements.

Status Working on process.

RMMM Plane No: PR-02 Type of risk

Description Poor Quality Documentation Project Risk

Impact The development will hamper. Disaster

Prevention Meetings will be held routinely to offer

documentation suggestions and topics.

Cure We will call a meeting and discuss about quality

improvement of documentation.

Status We are monitoring it.

64
Chapter: 06
ANALYSIS MODELING

65
6.1 SOFTWARE ANALYSIS PATTERN
Software analysis patterns or analysis patterns in software engineering are conceptual
models, which capture an abstraction of a situation that can often be encountered in
modelling. An analysis pattern can be represented as a group of related, generic objects
(meta-classes) with stereotypical attributes (data definitions), behaviors (method
signatures), and expected interactions defined in a domain-neutral manner. By analysis
modeling developer can finalize the specifications of the system. It is mandatory -

 To describe what the customer require

 To establish a basis for the creation of a software design
 To define a set of requirements that can be validated once the software is built.

6.2 ACTIVITY DIAGRAM

Activity diagram is an important behavioral diagram in UML diagram to describe

dynamic aspects of the system. Activity diagram is essentially an advanced version of
flow chart that modeling the flow from one activity to another activity.

Activity Diagram Symbols:

Start Symbol: This symbol is used for representing the beginning of a workflow in an
activity diagram. This can be used alone or along with a note symbol which explains
the starting point.

Activity Symbol: This symbol is one of the major components of an activity diagram.
This shape represents the activities, which completes a modeled process.

Join Symbol: This symbol is used to combine two concurrent activities and make them
into a single activity.

66
Decision Symbol: This symbol is represented with a diamond shape, which represents
branching of control flows.

Note Symbol: This symbol used to interact with other messages that do not fit within
the diagram.

End Symbol: This symbol is used to represent the completion of a workflow of the
activity.

67
Activity Diagram for “ADMIN”:

Figure 6. 1 Activity Diagram for “Admin”:

68
Activity Diagram for “Student”:

Figure 6. 2 Activity Diagram for “Student”

69
6.3 SWIMLANE DIAGRAM
A Swimlane diagram is a type of flowchart that delineates who does what in a process.
Using the metaphor of lanes in a pool, a Swimlane diagram provides clarity and
accountability by placing process steps within the horizontal or vertical “Swimlanes”
of a particular employee, work group or department. It shows connections,
communication and handoffs between these lanes, and it can serve to highlight waste,
redundancy and inefficiency in a process.

Swimlane is a way to group activities performed by the same actor on an activity

diagram or activity diagram or to group activities in a single thread.

Swim lanes are visual elements (parallel lines) which divide the diagram into the lanes
for visually distribution the processes, sub-processes of a business process, decisions at
these lanes and widely used at Flowcharts, Flow Diagrams and Maps, Process Flow
Diagrams and Process Models, Cross-Functional Flowcharts, BPMN and UML
diagrams.

The Swimlane diagrams of “Shujog Community Leader Management System” is given

below:

70
Swimlane Diagram for “Admin”:

Figure 6. 3 Swimlane Diagram for “Admin”

71
Swimlane Diagram for “Student”:

Figure 6. 4 Swimlane Diagram for “Student”

72
Chapter: 07
DESIGNING

73
7.1 INTERFACE DESIGN
Application home page:

Application sign up page:

Figure 7. 1 Application home page

Figure 7. 2 Student sign up page

74
Student sign in page:

Figure 7. 3 Student sign in page

Admin dashboard:

Figure 7. 4 Admin dashboard

75
Admin Login page:

Figure 7. 5 Admin Login

Course Add/Edit/Delete:

Figure 7. 6 Course Add/Edit/Delete

76
Student Profile page:

Figure 7. 7 Student Profile

Student Feedback:

Figure 7. 8 Student Feedback

77
Lesson Dashboard:

Figure 7. 9 Lesson Dashboard

Online Courses:

Figure 7. 10 Online Courses

78
7.2 DATA FLOW DIAGRAM:
A data flow diagram is a graphical representation that depicts information flow and the
transforms that are applied as data move from input to output. It is known as data flow
graph or bubble chart.

The DFD may be used to represent a system or software at any level of abstraction.
DFD may be partitioned into levels that represent increasing information flow and
functional detail. Therefore, the DFD provides a mechanism for functional modeling as
well as information flow modeling.

A level 0 DFD, which is also known as fundamental system model or a Context model,
represents the entire software or system element into as a single bubble with input and
output data indicated by in Coming and outgoing arrows respectively. Then bubble of
context model should be decomposed into several levels.

In DFD, there are four symbols:

 A square defines a source or destination that is external entity of system data.

 An arrow identifies data flow that data is motion. It is pipeline through which
information flows.
 A circle or a bubble represents a process that transforms incoming data flow(s)
into outgoing data flow(s).
 An open rectangle is a data store or a temporary repository of data.

79
7.2.1 DFD OF PROJECT:
Context level diagram:

Figure 7. 11 Context Level Diagram

80
Level 1 DFD:

Figure 7. 12 Level 1 DFD

81
7.3 DATABASE DESIGN:
A database is an organized collection of data. A relational database, more restrictively,
is a collection of schemas, tables, queries, reports, views, and other elements. Database
designers typically organize the data to model aspects of reality in a way that supports
processes requiring information, such as (for example) modeling the availability of
rooms in hotels in a way that supports finding a hotel with vacancies.

Database design is the process of producing a detailed data model of database. This
data model contains all the needed logical and physical design choices and physical
storage parameters needed to generate a design in a data definition language, which can
then be used to create a database. A fully attributed data model contains detailed
attributes for each entity.

Two-step process for database design:

1. Information-level design: In this step, user requirements are gathered together and
a database is designed which will meet these requirements as clearly as possible. This
step is called Information Level Design. Information level design is completed
independently of any particular DBMS.

Information-Level Design Method:

For each user view:

 Represent the user view as a collection of tables

 Normalize these tables
 Identify all keys in these tables

2. Physical-level design: Information level design is transferred into a design for the
specific DBMS that will be used to implement the system in question. This step is called
Physical Level Design, concerned with the characteristics of the specific DBMS.

 Information-level design adapted for the specific DBMS that will be used
 Must consider characteristics of the particular DBMS
 Undertaken after information-level design completion
 Most DBMSs support primary, candidate, secondary, and foreign keys
 To enforce restrictions, DB programmers must include logic in their programs

82
In the field of relational database design, normalization is a systematic way of ensuring
that a database structure is suitable for general-purpose querying and free of certain
undesirable characteristics—insertion, update, and deletion anomalies that could lead
to loss of data integrity.

7.3.1 ENTITY RELATIONSHIP MODEL:

An entity–relationship model (ER model) describes inter-related things of interest in a
specific domain of knowledge. An ER model is composed of entity types (which
classify the things of interest) and specifies relationships that can exist between
instances of those entity types.

An entity relationship model, also called an entity-relationship (ER) diagram, is a

graphical representation of entities and their relationships to each other, typically used
in computing in regard to the organization of data within databases or information
systems. An entity is a piece of data-an object or concept about which data is stored.

IDENTIFYING ENTITIES
Identifying the entities according to the conceptual design-

 user
 userRole
 message
 service_map
 payment
 review
 notification

ENTITY RELATIONSHIP DIAGRAM

An entity relationship diagram (ERD) shows the relationships of entity sets stored in a
database. An entity in this context is a component of data. In other words, ER diagrams
illustrate the logical structure of databases.

An Entity Relationship (ER) Diagram is a type of flowchart that illustrates how

“entities” such as people, objects or concepts relate to each other within a system. ER
Diagrams are most often used to design or debug relational databases in the fields of
software engineering, business information systems, education and research. Also
83
known as ERDs or ER Models, they use a defined set of symbols such as rectangles,
diamonds, ovals and connecting lines to depict the interconnectedness of entities,
relationships and their attributes. An ER diagram is a means of visualizing how the
information a system produces is related.

Common Entity Relationship Diagram Symbols:

Entity: A definable thing—such as a person, object, concept or event—that can have
data stored about it. Think of entities as nouns. Examples: a customer, student, car or
product. Entities are typically shown as a rectangle.

Relationship: How entities act upon each other or are associated with each other. Think
of relationships as verbs. Relationships are typically shown as diamonds or labels
directly on the connecting lines.

Attribute: Attribute is a property or characteristic of an entity. It is often shown as an

oval or circle. A key attribute is the unique, distinguishing characteristic of the entity.

Multiple Attribute: A multiple attribute can have more than one value. For example,
an employee entity can have multiple skill values.

Primary key: A primary key: is a special relational database table column (or
combination of columns) designated to uniquely identify all table records. A primary
key's main features are: It must contain a unique value for each row of data. It cannot
contain null values.

Foreign key: In the context of relational databases, a foreign key is a field in one table
that uniquely identifies a row of another table or the same table.

84
ENTITY RELATIONSHIP DIAGRAM OF THE SYSTEM

Figure 7. 13 Entity Relationship Diagram

85
7.3.2 DATABASE TABLE STRUCTURE
Table XVIII- Admin (Stores Admin Detail)

Attribute Data Type Description

admin_id # int(11) Stores Admin ID

admin_name varchar(255) Stores Admin Name

admin_email varchar(255) Stores Admin Email ID

admin_pass varchar(255) Stores Admin Password

Table XIX- Student (Stores Student Detail)

Attribute Data Type Description

stu_id # int(11) Stores student ID

stu_name varchar(255) Stores student Name

stu_email varchar(255) Stores student Email ID

stu_pass varchar(255) Stores student Password

stu_occ varchar(255) Stores student occupation

stu_img text Stores student profile picture

Table XX- Feedback (Stores Feedback Detail)

Attribute Data Type Description

f_id # int(11) Stores Feedback ID

f_content text Stores Feedback content

stu_id int(11) Stores Student ID

86
 Table XXI- Course (Stores Course Detail)

Attribute Data Type Description

course_id # int(11) Stores Course ID

course_name text Stores course Name

course_desc text Stores course description

course_author varchar(255) Stores course

author/instructor

course_img text Stores course display picture

course_duration text Stores course duration

course_price int(11) Stores course selling price

course_original_price int(11) Stores course original price

Table XXII- Lesson (Stores Lesson Detail)

Attribute Data Type Description

lesson_id # int(11) Stores Lesson ID

lesson_name text Stores Lesson name

lesson_desc text Stores lesson description

lesson_link text Stores lesson video link/video

file

course_id int(11) Stores course ID

course_name text Stores course Name

87
 Table XXIII- Courseorder (Stores Course order Detail)

Attribute Data Type Description

co_id # int(11) Stores course order ID

order_id varchar(255) Stores Order ID (Random)

stu_email varchar(255) Stores student email id

course_id int(11) Stores course id

status varchar(255) Stores payment status

respmsg text Stores payment response

msg

amount int(11) Stores course amount

order_date date Stores purchase date

88
7.3.3 FLOW CHART
A flowchart is a diagram that depicts a process, system or computer algorithm. They
are widely used in multiple fields to document, study, plan, improve and communicate
often complex processes in clear, easy-to-understand diagrams.

Login

Add Lesson

Figure 7. 14 Flow Chart

89
7.3.4 CLASS DIAGRAM
Class diagrams are the main building block in object-oriented modeling. They
are used to show the different objects in a system, their attributes, their
operations and the relationships among them.

Classes in class diagrams are represented by boxes that are partitioned into
three:-

 The top partition contains the name of the class.

 The middle part contains the class’s attributes.

 The bottom partition shows the possible operations that are

associated with the class.

Figure 7. 14 Class Diagram

90
Chapter: 08
QUALITY ASSURANCE

91
8.1 SYSTEM QUALITY MANAGEMENT
A strategy for software testing integrates software test case design methods into a well-
planned series of steps that result in the successful construction of a software. The
strategy provides a road map that describes the steps to be conducted as part of testing.

The quality of software is assessed by a number of variables. These variables can be

divided into external and internal quality criteria. External quality is what a user
experiences when running the software in its operational mode. Internal quality refers
to aspects that are code-dependent, and that are not visible to the end-user. External
quality is critical to the user, while internal quality is meaningful to the developer only.

Some quality criteria are objective, and can be measured accordingly. Some quality
criteria are subjective, and are therefore captured with more arbitrary measurement.

There are mainly two types of quality:

Internal quality:

 Test coverage
 Testability
 Portability
 Thread-safeness
 Conciseness
 Maintainability
 Documentation
 Legibility
 Scalability

External quality:

 Features
 Speed
 Space
 Network usage
 Stability
 Robustness

92
  Ease-of-use
 Determinism
 Back-compatibility
 Security
 Power consumption

8.1.1. SOFTWARE QUALITY MANAGEMENT PROCESS:

 The aim of Software Quality Management (SQM) is to manage the quality of
software and development and of its development process
 A quality product is one which meets its requirements and satisfies the user
 A quality culture is an organization environment where quality is viewed as
everyone’s responsibility

Some of the specific SQM processes defined in standard:

Quality assurance process:

Quality Assurance makes sure the project will be completed based on the previously
agreed specifications, standards and functionality required without defects and possible
problems. Its monitors and tries to improve the development process from the beginning
of the project to ensure this.it is oriented to „‟prevention‟‟.

Verification & validation process:

In software project management, software testing, and software engineering,

verification and validation (V&V) is the process of checking that a software system
meets specifications and that it full fill its intended purpose. It is normally the
responsibility of software testers as part of the software development lifecycle.

In the verification, a client will either view the software, or see it implemented in a test
situation. At this point it is imperative that the client who is needed of the software is
able to ascertain that this software is hitting all the parameters initially requested or
desired .only when this assurance is made should the next part of the verification and
validation process be started. While this is not the last chance to “tweak” the software
into doing the tasks required it is part of the last steps before a project is completed, and

93
in being too quick to approve the software as this could cause problems later, and could
also result in more money required for the software’s later changes.

The next step of verifications &validation of software is simple. Client Company will
approve the software and validate it as being what is required. This stage usually means
a systematic checking off various requirements. While this might sound tedious, it is
necessary part of the procedure to insure that again, the result is exactly to the
specifications of all concerned. The entire verification and validation process is part of
a normal sequence of quality control for software.

Review& Audit Process:

A software audit review, or software audit, is a type of software review in which one or
more auditors who are not members of the software development organization conduct
“An independent examination of a software product, software process, or set of
software processes to assess compliance with specifications, standards, contractual
agreements, or other criteria”

Five types of reviews or audits presented in the standard:

Management reviews:

The purpose of a management review is to monitor progress, determine the status of

plans and schedules, confirm requirements and their system allocation, or evaluate the
effectiveness of management approaches used to achieve fitness for purpose. This
support decisions about changes and corrective actions that are required during a
software project.

Technical reviews:

The purpose of technical review is to evaluate a software product to determine its

suitability for its intended use. The objective is to identify discrepancies from approved
specifications and standards. The result should provide management with evidence
confirming (or not) that the product meets the specifications and adheres to standards
and that changes are controlled”. A technical review requires that mandatory inputs be
in place in order to proceed:

94
  Statements of objectives
 A specific software product
 The specific project management plan

Inspections:

The purpose of an inspection is to detect and identify software product anomalies. Two
important differentiators of inspections as opposed to reviews are as follows:

 An individual holding a management position over any member of the

inspection team shall not participate in the inspection
 An inspection is too led by an impartial facilitator who is trained in inspection
techniques.

The inspection exit must correspond to one of the following three criteria:

 Accept with no or at minor reworking

 Accept with rework verification
 Re inspect

Inspection meetings typically last a few hours, whereas technical reviews and audits are
usually broader in scope and take longer.

Walk-through:

The purpose of a walk-through is to evaluate a software product. A walk-through may

conduct for educating an audience regarding a software product. The major objectives
are to:

 Find anomalies
 Improve the software product
 Consider alternative implementations
 Evaluate conformance to standards and specifications

The purpose of a software audit is to provide an independent evaluation of the

conformance of software products and processes to applicable regulations, standards,
guidelines, plans, and procedures. The audit is a formally organized activity, with
participants having specific roles, such as lead auditor, another auditor, a recorder, or

95
an initiator, and includes a representative of the audited organization. The audit will
identify instances of nonconformance and produce a report requiring the team to take
corrective action.

8.2 SYSTEM TESTING

Black box testing: You don’t need to know the internal design in detail or have
knowledge about the code for this test. It’s mainly based on functionality and
specification, requirements.

White box testing: This testing is based on detailed knowledge of the internal design
and code. Tests are performed for specific code statements and coding styles.

Unit testing: The most micro scale of testing to test specific functions or code modules.
Typically done by the programmer and not by testers, as it requires detailed knowledge
of the internal program design and code. Not always easily done unless the application
has a well-designed architecture with tight code, may require developing test driver
modules or test harnesses.

Incremental integration testing: Continuous testing of an application as new

functionality is added. Requires that various aspects of applications functionality be
independent enough to work separately before all parts of the programmer are
completed or that test drivers be developed as needed. Done by programmers or by
testers.

Integration testing: Testing of combined parts of an application to determine if they

function together correctly. It can be any type of application which has several
independent sub applications, modules.

Functional testing: Black box type testing to test the functional requirement of an
application. Typically done by software testers but software programmers should also
check if their code works before releasing it.

System testing: Black box type testing that is based on overall requirements
specifications. Covers all combined parts of a system.

End to End testing: It’s similar to system testing. Involves testing of a complete
application environment similar to real world use. May require interacting with a

96
database, using network communications, or interacting with other hardware,
applications, or systems.

Sanity testing or smoke testing: An initial testing to determine if a new software version
is performing well enough to start for a major software testing. For example, if the new
software is crashing frequently or corrupting database then it is not a good idea to start
testing before all these problems are solved first.

Regression testing: Re-testing after software is updated to fix some problem. The
challenge might to be determining what need to be tested, and all the interactions of the
functions, especially near the end of the software cycle. Automated testing can be useful
for this type of testing.

Accepting testing: This the final testing done based on the agreements with the
customer.

Load / stress / performance testing: Testing an application under heavy loads. Such as
simulating a heavy traffic condition in a voice or data network, or a web site to
determine at what point the system start causing problems or fails.

Usability testing: Testing to determine how user friendly the application is. It depends
on the user or customer. User interviews, surveys, video recording of user sessions, and
other techniques can be used. Programmers and testers are usually not appropriate as
usability testers.

Install / Uninstall testing: Testing of full, partial, or upgrade install / uninstall processes.

Recovery / failover testing: Testing to determine how well a system recovers from
crashes, failures, or other major problems.

Security testing: Testing to determine how well the system protects itself against
unauthorized internal or external access and intentional damage. May require
sophisticated testing techniques.

Compatibility testing: Testing how well software performs in different environments.

Particular hardware, software, operating system, network environment etc. Like testing
a web site in different browsers and browsers and browsers versions.

97
Exploratory testing: Often taken to mean a creative, informal software test that is not
based on formal test plans or test cases; testers may be learning the software as they test
it.

Ad-hoc testing: Similar to exploratory testing, but often taken to mean that the testers
have significant understanding of the software before testing it.

Context driven testing: Testing driven by an understanding of the environment, culture,

and intended use of software. For example, the testing approach for life critical medical
equipment software would be completely different than for a low cost computer game.

Comparison testing: Comparing software weakness and strengths to competing

products.

Alpha testing: Testing of an application when development when development is

nearing completion. Minor design changes may still be made as a result of such testing.
Typically done by end users or others, not by programmers or testers.

Beta testing: Testing when development and testing are essentially completed and final
bugs and problems need to be found before final release. Typically done by end users
or others, not by programmers or testers.

Mutation testing: A method for determining if a set data or test case is useful, by
deliberately introducing various code changes and retesting with the originals test data/
cases to determine if the defects are detected. Proper implementation requires large
computation resources.

98
8.3 TESTING:
Table XXIV- Login

Test Case Test Test Pre- Test Test Expected Actual Status
ID Scenari Case Conditi Steps Data Result Result Pass/Fa
o on il
TC_Login Verify Enter Need a 1. Enter Valid Successf Successf Pass
_1 Login Valid valid userna userna ul login, ul login,
userna usernam me me Main Main
me and e and 2. Enter Valid screen of screen of
valid passwor applicati applicati
Passwo passwor
passwor d to do on on
rd d
d login should displayed
3. Click displayed
Login
TC_Login Verify Enter Need a 1. Enter Valid No No Pass
_2 Login Valid valid userna userna Matched Matched
userna usernam me me Usernam Usernam
me and e and e/ e/
2. Enter Invalid
invalid passwor Password Password
Passwo Passwo
passwor d to do
rd rd
d login
3. Click
Login
TC_Login Verify Enter Need a 1. Enter Invalid No No Pass
_3 Login Invalid valid userna userna Matched Matched
userna usernam me me Usernam Usernam
me and e and 2. Enter Valid e/ e/
valid passwor Password Password
Passwo Passwo
passwor d to do rd rd
d login
3. Click
Login
TC_Login Verify Enter Need a 1. Enter Invalid No No Pass
_4 Login Invalid valid userna userna Matched Matched
userna usernam me me Usernam Usernam
me and e and 2. Enter Invalid e/ e/
invalid passwor Passwo Passwo Password Password
passwor d to do rd rd
d login
3. Click
Login

99
 Table XXV- User/Student Registration

Test Case Test Test Pre- Test Test Expected Actual Status
ID Scenario Case Conditi Steps Data Result Result Pass/F
on
ail
TC_SRE Verify Enter Need 1. Valid Successfu Successfu Pass
G_1 User valid valid Enter name, l, User l, User
Registrati name, Data to name valid Added Added
on Detail email, be 2. email, Successfu Successfu
new entered Enter valid lly lly
passwo passwo
email
rd rd
3.
Enter
Passwo
rd
4.
Click
Sign
up
TC_SRE Verify Enter Need 1. Valid Email ID Email ID Pass
G_2 Staff name, Data to Enter name, Already Already
Registrati already be name already Registere Registere
on Detail register entered 2. register d d
ed ed
Enter
email, Email email,
new valid
passwo 3. passwo
rd Enter rd
Passwo
rd
4.
Click
Sign
up
TC_SRE Verify Enterin - Click Nothin Fill Fill Pass
G_3 Staff g Sign g to required required
Registrati Nothin up enter field field
on Detail g, Requir
Requir ed
ed fields
Fields are
are blank
blank

100
 Table XXVI- Add Course

Test Case Test Test Pre- Test Test Expected Actual Status
ID Scenar Case Conditi Steps Data Result Result Pass/F
io on
ail
TC_Cours Verify Enter Need 1. Enter Valid Successfu Successfu Pass
e_1 Course Valid valid Valid Text l, Course l, Course
Detail and text and Data in and Added Added
correct number appropri Numbe Successfu Successfu
data Data to ate fields r Data lly lly
be
2. Click
entered
Submit
TC_Cours Verify Enter Need Enter Invalid Enter Enter Pass
e_2 Course invalid text and invalid Text Valid Valid
Detail and number Data in and Data Data
incorre Data to fields Numbe
ct data be r Data
entered
TC_Cours Verify Enterin - Click Nothin Fill Fill Pass
e_3 Course g Submit g to required required
Detail Nothin enter field field
g, Requir
Requir ed
ed fields
Fields are
are blank
blank

101
Chapter: 09
CONCLUSION

102
9.1 PRACTICUM AND ITS VALUE
In career development – as with most life issues – there is direct relationship between
effort and reward. To me, practicum can be as a transition from engineering college
study life to a real world workplace through hands on experience of engineering
practices.

There are several major advantages for students completing a guided Practicum:

 Demonstration of practical application of studies

 Development of deeper skills in the selected research area
 Increases employability

Practicum does not offer hands-on experience only, but also the trait of “coping up” in
the society. Meeting with different types of people and encountering situations gives
practical orientation to life. There are many more upright issues of practicum, which
only the person experiencing it can sense and believe.

It is the gateway to the professional life, bridge between theoretical and practical
knowledge. Now these days, engineering job recruiters no longer consider high grand’s
rather they value the particle working experience, for which practicum proves to be
vantage for the fresh entry level engineers in the job market.

Student of College of Engineering and Technology (CEAT) at IUBAT go for this

practicum program carrying 9 credit hours weight, which goes for a semester long and
usually after the completion of the course work. A report submitted after the completion
of the practicum followed by a presentation and a comprehensive examination on the
overall four years education.

9.2 CONCLUSION
The Lancercode E-Learning Maintenance Managment System has been computed
successfully and was also tested successfully by taking "Test Cases". It is user friendly,
and has required options, which can be utilized by the user to perform the desired
operations.

The Software is developed using HTML, CSS, JS as front end and PHP, MySql as back
end in windows environment.

103
The goals that are achieved by the software are:

 Simplification of the operations

 Less processing time and getting required information

 User friendly

 Portable and flexible for further enhancement

9.3 LIMITATIONS

 Only one tutor can access at a time

 It’s not SEO friendly
 Risk unauthorized accessibility
 Support is good in modern web browsers but not in legacy ones
.

9.4 FUTURE PLAN

 More than one tutor can be added

 Interaction between Student and Tutor can be improved by introducing

Discussion forum

 Quiz Facility may enhance this application’s market value

 Live Class can be added

104
BIBLIOGRAPHY

105
Books:

 Kendall, E. & Kendall (1999), System Analysis and Design. 4th Ed. New Delhi:
Prentice Hall.
 Silberschattz, Abraham, Korth, Henry F., &Sudrashan S. (2002). Database
System Concepts. 4th ed. Boston: McGraw Hill.
 Pressman, Roger S. (2004). Software Engineering: A Practitioner’s Approach.
5th ed. Boston: McGraw Hill.
 IGNOU Blocks of Systems Analysis and Design
 IGNOU Blocks of Introduction to Software Engineering
 The Complete Reference PHP
Head First SQL: Your Brain on SQL by Lynn Beighley

Websites:

 Organizational Incremental Approach: Continuous Software Development

Excellence Process. [Online] Available at: ixorasolution.com/process
 Longstreet, David. (2005). Fundamentals of Function Point Analysis. [Online]
Available at: http://www.softwaremetrics.com/fpafund.htm
 How to calculate function points. (2018, Aug 03). Available at:
http://stackoverflow.com/questions/34473698/how-to-calculate-function-
points
 Tutorials Point. (2015). Database Management System. (2018, June 30).
Available at: https://www.tutorialspoint.com/dbms/dbms_tutorial.pdf
 Shingote, S. Explain incremental Process Model with example. (2018, Aug 09).
Available at: http://www.ques10.com/p/21784/explain-incremental-process-
model-with-example/
 www.google.co.in
 www.wikipedia.org
 www.php.net
 www.stackoverflow.com
 www.getbootstrap.com
 www.fontawesome.com

106