Project Report

1. P a g e | 1
Internal Assessment System
Project Report
(MCS-102 Artificial Intelligence)
2017
Department of Computer Science
University of Delhi
Submitted by (Name and Roll No.): Supervisor:
Shivam Agarwal (34) Poonam Bedi
Shreshth Saxena (38)

2. P a g e | 2
Contents
Problem Statement...............................................................................................
Process Model......................................................................................................
1. Software Requirement Specification..............................................................
1.1 Introduction
1.1.1 Purpose
1.1.2 Scope
1.1.3 Definition, Acronyms and Abbreviations
1.2 Overall Description...................................................................................
1.2.1 Product Functions........................................................................
1.2.2 User Characteristics.....................................................................
1.2.3 General Constraints.....................................................................
1.2.4 Assumption and Dependencies....................................................
1.3 External Interfaces Requirements.............................................................
1.3.1 User Interfaces.............................................................................
1.3.2 Hardware Interfaces.....................................................................
1.4 Functional Requirements...........................................................................
1.5 Performance Requirement.........................................................................
1.6 Design Constraints.....................................................................................
1.7 Data Flow Diagram....................................................................................
1.8 Data Dictionary..........................................................................................
2. Scheduling.........................................................................................................
3. Risk Management..............................................................................................
4. Design................................................................................................................
4.1 Data Design................................................................................................
4.2 Conceptual Design......................................................................................
5. Testing................................................................................................................
6. References..........................................................................................................

3. P a g e | 3
Problem Statement
The Internal Assessment System is developed to maintain and update the marks of students enrolled in a
particular course of a university. It enables a secure and efficient storage as well as retrival of records. The
data can be accessed and modified over phones and computers with the help of any standard brower
allowing more flexibility to the user. IAS is built with a clean and simple interface making it easier to
familiarise with and used efficiently by its users. That said, the security features have not been
compromised with. Users have different set of rights and permissions depending on their roles (Teacher or
Student).
IAS is built on a free and open-source web framework Django, written in Python, which follows the model-
view-template architectural pattern. MySQL is used for maintaining database and the front-end is developed
on HTML, CSS and Javascript making it accessible over various platforms. All resources used are free and
openly available as stated before, preventing any copyright or purchase issues.
The IAS is structured as:
 There are different faculties in a University, each faculty has no. of departments. Each department
has some courses, each course belongs to only one department. Each course divided into a no. of
semesters and each semester has some mandatory subjects along with some elective subjects (may
be 0).
 Each teacher belongs to a department and can teach a no. of subjects in different courses. A
teacher can teach in another department as a guest lecturer. Each teacher has a unique-id and
password.
 Each student is enrolled in one course only. A student can study various fixed no. of subjects in
which he is enrolled in his current semester. A student has to take all mandatory subjects in a
semester and can choose among a provided elective subject. Each student has unique roll no. we
have to keep track of student marks in internals. Each student’s internal marks are categorized in 4
categories (2 tests, 1 assignment and 1 attendance). There will be a deadline corresponding to a
course for updating internal marks.

4. P a g e | 4
Process Model
The Software Process Model used is the Incremental Model. The choice for this model is in the light of the
enhancements that we foresee for the future. The enhancements would be in the area of Networks being
introduced into the software.
Advantages of Incremental model:
 Generates working software quickly and early during the software life cycle.
 This model is more flexible – less costly to change scope and requirements.
 It is easier to test and debug during a smaller iteration.
 In this model, the customer can respond to each built.
 Lowers initial delivery cost.
1. Software Requirement Specification Document
A software requirements specification (SRS) is a document that captures complete description about how
the system is expected to perform.
1.1 Introduction –Internal Assessment System aims to deliver a user-friendly interface for
maintaining, updating and retrieving the internal assessment marks of students.
1.1.1 Purpose –The Internal Assessment System is a portal for students and teachers, where
students are able to view their score in assessments/projects and teachers have access to
update those marks accordingly. The IAS is effective and provides a platform
independent experience to students and teachers. The IAS is completely online and uses
efficient data storage to reduce the number of hard copies required for maintaining
University records.
Communication Planning Modeling Construction Deployment
#Build 1
#Build 2
#Build 3
Communication Planning Modeling Construction Deployment
Communication Planning Modeling Construction Deployment
Figure: Incremental Process Model

5. P a g e | 5
1.1.2 Scope -There are two users – Students and Teachers. Users can operate through their
private devices with the help of a browser and internet connection. The interface is kept
simple for ease of use.
1.1.3 Definitions, Acronyms and abbreviations
 IAS – Internal Assessment System
 Django- Django is a free and open-source web framework, written in Python, which
follows the model-view-template architectural pattern.
 Visual Studio Code-Visual Studio Code is a source code editor developed by
Microsoft for Windows, Linux and macOS. It includes support for debugging,
embedded Git control, syntax highlighting, intelligent code completion, snippets, and
code refactoring
 Python- Python is a widely used high-level programming language for general-
purpose programming. Python has a design philosophy that emphasizes
code readability (notably using whitespace indentation to delimit code blocks rather
than curly brackets or keywords), and a syntax that allows programmers to express
concepts in fewer lines of code than might be used in languages such as C++ or Java
 HTML -Hypertext Markup Language is the standard markup language for creating
web pages and web applications. With Cascading Style Sheets and JavaScript it
forms a triad of cornerstone technologies for the World Wide Web
 CSS - Cascading Style Sheets is a style sheet language used for describing the
presentation of a document written in a markup language
 Javascript - JavaScript, often abbreviated as JS, is a high-level, dynamic, weakly
typed, prototype-based, multi-paradigm, and interpreted programming language. It is
used to make webpages interactive and provide online programs, including video
games.
1.1.4 References-:
Django Documentation - https://www.djangoproject.com/start/
1.2 Overall Description
Internal Assessment Website helps you to access internal marks on your computer. It is an online
websie where teachers can easily add, update internal marks of students.
Product Functions: Website will take data such as Login Email ID, subjects name, students name,
marks etc. from admin for future use.
Expected User: The intended user will be faculty members and students of the department.
General Constraints:
i. This website does not return any information about personal information of the user. The
processing logic should also be identified.
ii. There should be clear understanding on how final IA marks will be calculated. Remember
to handle cases like a student absent in one of the exam.
iii. How would you like teacher to enter and modify marks – one student at a time or many
students at a time?
iv. What will you store as marks for students who do not appear in exam as against those who
get zero in exam.
Assumption and Dependencies: The software’s functionality will be dependent upon browsers.

6. P a g e | 6
Various records to be maintained are:
i. Student information
ii. Teacher information
iii. Course details
iv. Semesters
v. Department Information
vi. Subjects
vii. Marks
viii. Internal assignments/project
1.3 External Interfaces Requirements
External Interface Requirements means specification of all the interaction of the software with people,
hardware, and other software.
1.3.1 User Interfaces: The user interface will be simple. It will give relaxing effect on looking at its
GUI. The application will be easy to use. If any user is doing something wrong, he/she will be informed
in a friendly manner.
1.3.2 Hardware Interfaces: This application will work on any browser.
1.4 Functional Requirements
Functional Requirments specify which outputs should be produced from the given inputs. They describe
the relationship between the inputs and outputs of the system.
In order to make this application functional, we require the following:
 Faculty
Should be able to enter the marks of all students in his/her subject
Should be able to modify the already entered marks
Would like system to calculate Perccentage/Grade from marks and also list top scorers &
students below average
 Students
Students should be able to view their marks.
1.5 Performance Requirements
The requirements in this section specifies the performance constraints on the software system.
1. Updation: The updation feature should be prominent and easy for the user.
2. Response Time: The response time should not be more than 5 seconds if the user has a proper
internet connection.
3. Fault Tolerance: The fault tolerance of the system should be very good. If the system loses the
connection to the Internet or the system gets some unknown input, the user should be informed.
1.6 Design Constraints
Following are the requirements that application requires from the mobile on which it is installed.
 Software Limitations:
1. Internet Connection: It requires internet permissions so that it can fetch records from the server.

7. P a g e | 7
 Security Requirements:
1. Admin Login Security: If an admin tries to log in to the application with a non-existing account
then the admin should not be logged in.
2. Admin Account Security: There should be the security of admin accounts. An admin and IP
address should not be able to log-in to the application for a certain time period after three times
of failed log-in attempts.
3. User Create Account Security: The security of creating an account for users of the system should
be maintained. If a user wants to create an account and the desired username is occupied, the
user should be asked to choose a different username.
1.7 Data Flow Diagram
A DFD shows the flow of data through a system. It views a system as a function that transforms the
inputs into desired outputs.
 Level 0 DFD OR Context Diagram:
A system context diagram in software engineering and systems engineering is a diagram that defines
the boundary between the system, or part of a system, and its environment, showing the entities that
interact with it. This diagram is a high-level view of a system.
 Level 1 DFD:
Level 1 DFD’s aim to give an overview of the full system. They look at the system in more detail.
Major processes are broken down into sub-processes. Level 1 DFD’s also identifies data stores
that are used by the major processes.
Figure 1.1: Level 0 DFD OR Context Diagram

8. P a g e | 8
Figure 1.2: Level 1 DFD
1.8 Data Dictionary
The Data Dictionary is a repository of various data flow defined in a DFD.
Username = [alphabet | digit | special character]*
Password = [alphabet | digit | special character]*
Subject Info = [alphabet]*
Course Info = [alphabet | dgit | special character]*
Student Details = [alphabet]*
Teacher Details = [alphabet]*
ScoreCard = [alphabet | digit]*
Marks = [digit]*
Verification = [0 | 1]
Digit =0|1|2|3|4|5|6|7|8|9
Alphabet =a…...z|A…Z
Special character =’/’|’|’|’,’|’*’|’@’|’.
Figure 1.3: Data Dictionary

9. P a g e | 9
2. Scheduling
The objective of software project scheduling is to create a set of engineering tasks that will enable to
complete the job in time.
Time-Line Chart: Timeline charts, or also called Gantt charts, are developed for the entire project, for
tracking and control of all activities that need to be performed for project development.
Work Tasks
Week
1
Week
2
Week
3
Week
4
Week
5
Week
6
Week
7
Week
8
Week
9
Week
10
Week
11
Week
12
1. Identify Problem and need of s/w
Define Problem Statement
Design Process model
Milestone: Product Stmt. defined
2. Document SRS
Define Product Functions
Document User Characteristics
Document General Constraints
Define Assumption. and Dependency
Milestone: s/w descriptions documented
3. External Interface Requirements
Document User Interfaces
Document Hardware Interfaces
Document Software Interfaces
Milestone: Interface documented
4. Document Function Requirements
Identify Performance Requirement
Design Data Flow Diagram
Design Data Dictionary
Milestone: SRS documented
5. Scheduling
Generation of Scheduling Table
Milestone: Scheduling table generated
6. Risk Management
Generation of Risk Table
Milestone: Risk table generated
7. Design
System designing
Data designing
Milestone: Designs Documented
7. Coding
Coding of all modules
9. Testing
Calculation of Cyclomatic Complexity
Performing testing
11. References
Documenting references
Milestone: All references documented
Figure 3.1: Time-Line Chart

10. P a g e | 10
3. Risk Management
Risk projection, also called risk estimation, attempts to rate each risk in two ways- (1) the likelihood or
probability that the risk is real and (2) the consequences of the problems associated with the risk, should
it occur.
A project team begins by listing all risks in the first column of the table. Each risk is categorized in
the second column. The probability of occurrence of each risk is entered by team members individually.
Next, the impact of each risk is assessed.
Once the first four columns of the risk tables have been completed, the table is sorted by probability
and by the impact. High-probability, high-impact risks percolate to the top of the table, and low-
probability risks drop to the bottom. The column labeled RMMM contains a pointer into a risk
mitigation, monitoring and management plan.
Impact values: Category:
1-catastrophic PS: Product Size
2-critical DE: Development Environment
3-marginal ST: Staff Size
4-negligible BU: Business Impact
A risk management strategy can be included in the software project plan or the risk management steps can
be organized into a separate Risk Mitigation, Monitoring and Management Plan. The RMMM plan
documents all work performed as part of risk analysis and are used by the project manager as part of the
overall project. Each risk can be documented individually using a risk information sheet (RIS). In most
cases, the RIS is maintained using a database system, so that creation and information entry, priority
ordering, searches, and other analysis may be accomplished easily.
Risks Category Probability Impact RMMM
1. Lack of training on tools. DE 85% 2 Meet experts of technology.
2. Inexperienced Developer ST 70% 2 Meet with experts of the project.
3. Customer will change
requirements.
PS 55% 3 Verify all the requirements from
SRS.
4. End user resists system BU 40% 3 Meet with customers.
5. Components developed
separately cannot be integrated
easily
DE 35% 3 Redesigning is required.
6.Delivery deadline will be
tightened
BU 30% 2 Meet with higher authority and try
to resolve the problem.
7.Staff turnover ST 20% 4 Every possible effort like
counseling must be done to stop
this.
Table 4.1: Risk Table

11. P a g e | 11
4. Design
During design, we determine what modules should the system have and which have to be developed. The
design of a system is essentially a blueprint or a plan for a solution for the system.
Data Design
Data design is the first and most important design activity. Here the main issue is to select the
appropriate data structure. That is the Data design focuses on the definition of data structures.
Attribute Type Width Remarks
Admin_ID String 20 For registration and login
User_name String 30 For login
Roll_No Integer 2 For Identification
Password String 15 For authorizaton
Name String 20 For Registration
Course_Id String 10 For identifying course
Department Name String 30 For identifying department
Subject_Id String 10 For identifying subject
Test1_marks Integer 2 Record test 1 marks
Test2_marks Integer 2 Record test 2 marks
Assessment_marks Integer 1 Record assessment marks
Table 5.1: Data Types

12. P a g e | 12
Conceptual Design
Conceptual design creates a representation of the subsystems.
5. Testing
Testing is a set of activities that can be planned and conducted systematically. Software testing is one
element of a broader topic that is often referred to as verification and validation (V&V). A strategy for
software testing must accommodate low-level tests that are necessary to verify that a small source code
segment has been correctly implemented as well as high-level tests that validate major system functions
against customer requirements.
 White-Box Testing
White-box testing, sometimes called glass-box testing, is a test-case design philosophy that uses the
control structure described as part of the component-level design to derive test cases. Using white-
box testing methods, you can derive test cases that (1) guarantee that all independent paths within a
module have been exercised at least once, (2) exercise all logical decisions on their true and false
sides, (3) execute all loops at their boundaries and within their operational bounds, and (4) exercise
internal data structures to ensure their validity.
Figure 5.3: Pseudo Code for IA System
Application
IASystem( )
{
String User, Verification, Check;
IF ( User = = Admin )
DO
Enter Username and Password;
Submit Username and Password;
Verification=Verify_user( );
IF ( Verification = = Failed)
THEN Check = False;
ELSE
Check = True;
ENDIF
WHILE( Check = = False )
ENDDO
add_IAmarks( );
update_IAmarks( );
ELSE
Student_IAMarks( );
ENDIF
}END IASystem

13. P a g e | 13
 Basis Path Testing
Basis path testing is a white-box testing technique enables the test-case designer to derive a logical
complexity measure of a procedural design and use this measure as a guide for defining a basis set of
execution paths.
 Flow Graph Notation: The flow graph depicts logical control flow.
 Independent Path Sets: An independent path is any path through the program that introduces at
least one new set of processing statements or a new condition.
A set of independent paths for the flow graph illustrated in Figure 7.1 is
Path 1: 1-2-3-4-5-6-7-8-10-11-12-13-14-16
Path 2: 1-2-3-4-5-6-7-9-10-11-12-13-14-16
Path 3: 1-2-3-4-5-6-7-8-10-11-4-5-6-7-9-10-11-12-13-14-16
Path 4: 1-2-15-16
Cyclomatic complexity is a software metric that provides a quantitative measure of the logical
complexity of a program.
1. The number of regions of the flow graph corresponds to the cyclomatic complexity.
Number of Regions: 4
2. Cyclomatic complexity V(G) for a flow graph G is defined as
V(G) = E - N + 2
where E is the number of flow graph edges and N is the number of flow graph nodes.
E = 15
N = 13
V(G) = 15 - 13 + 2 = 4
3. Cyclomatic complexity V(G) for a flow graph G is also defined as
V(G) = P + 1
P = 3
V(G) = 3 + 1 = 4
Figure 6.3 Pseudo Code for IA System
IASystem( )
{
String User, Verification, Check;
IF ( User = = Teacher )
DO
Enter Username and Password;
Submit Username and Password;
Verification=Verify_user( );
IF ( Verification = = Failed)
THEN Check = False;
ELSE
Check = True;
ENDIF
WHILE( Check = = False )
ENDDO
add_IAmarks( );
update_IAmarks( );
ELSE
Student_IAMarks( );
ENDIF
}END IASystem

14. P a g e | 14
 Black Box Testing
Black-box testing, also called behavioral testing, focuses on the functional requirements of the
software. That is, black-box testing techniques enable you to derive sets of input conditions that will
fully exercise all functional requirements for a program.
Black-box testing attempts to find errors in the following categories: (1) incorrect or missing
functions, (2) interface errors, (3) errors in data structures or external database access, (4) behavior
or performance errors, and (5) initialization and termination errors.
Figure 7.1 Flow Graph
1
1
2
m
3
h
4,5
ghg
6,7
ghg
8
g
9g
hg
10
11
12
13,14
15
16

15. P a g e | 15
6. References
1. Software Engineering- A Practitioner’s Approach by Roger S. Pressman: 6th
edition McGraw
Hill, 2005
2. An Integrated Approach to Software Engineering by Pankaj Jalote: 3rd
edition Springer, 2005