Internal Assessment Project

(1)

ACKNOWLEDGEMENT

Exchange of ideas generate the new object to work in a better way whenever a person is helped and cooperated by others his heart is bound to pay gratitude and obligation to them. To develop a project is not a one-man show. It is essentially a collective work, where every step taken with all precautions and care. Therefore our first duty is to thanks all persons who took pain in completing this project.

Firstly, we thank Mrs. RACHNA SETHI, who gave us inspiration to do work in this field and gave us her precious time whenever needed. Thanks may be matter of merely formality but with us it is expression of heartfelt gratitude to our project supervision. We are highly indebted for her gestures, invaluable suggestions and boosting confidence to make this successful. The success of this work is mostly due to her suitable guidance.

(2)

CERTIFICATE

This is to certify that the project entitled “INTERNAL ASSESSMENT EVALUATION

SYSTEM” prepared by us, Jigyasa Kaur & Inderpreet Singh for the partial fulfilment of

the requirements of the B.Sc. (Hons.) Comp. Sc. degree, embodies the work, we all are doing during 4th_{semester of our course under due supervision of the supervisor from this} college.

SIGNATURE

(3)

INDEX

1. PROJECT INTRODUCTION

1.1 OVERVIEW

1.2 DISADVANTAGES OF THE MANUAL SYSTEM 1.3 OBJECTIVE OF THE PROJECT

1.4 SCOPE OF THE PROJECT

2. PROJECT MANAGEMENT

2.1 INTRODUCTION 2.2 PROJECT PLAN

2.2.1 SOFTWARE PROCESS MODEL 2.2.2 PROJECT TEAM STRUCTURE 2.2.3 RISK ANALYSIS & MANAGEMENT

2.2.4 TIME-LINE CHART 2.3 COMPLEXITY TABLES

2.4 FUNCTION POINT ANALYSIS

3 . REQUIREMENT ANALYSIS & MANAGEMENT

3.

1 INTRODUCTION

3.2 FUNCTIONAL REQUIREMENTS 3.3 DATA DICTIONARY

3.4 ENTITY RELATIONSHIP DIAGRAM 3.5 DATA FLOW DIAGRAM

4. DESIGN

4.1

INTRODUCTION 4.2 DATA DESIGN 4.3 ARCHITECTURAL DESIGN 4.4 INTERFACE DESIGN

4.

5 SCREENS DESCRIPTION

(4)

CHAPTER 1 PROJECT

INTRODUCTION

(5)

1.1 OVERVIEW

The exact talent of a student cannot be judged, however hard a student may attempt, during the stipulated period of 3 hrs in the final exam.

Hence, Delhi University has earmarked 25% marks to be awarded to the college students on the basis of their individual performance during their stay in the college.

The university has advised the teachers that the internal assessment should be objective rather than subjective.

The marking scheme of the INTERNAL ASSESSMENT SYSTEM is grouped in 3 different categories i.e.

10% for house examination marks, 5% for the attendance &

10% for assignments and project submitted by each.

The students secure only what they deserve out of the above mentioned 3 categories.

(6)

1.2 DISADVANTAGES OF THE MANUAL SYSTEM

1. Maintaining records as paperwork is a cumbersome task.

2. Too many calculations done manually leads to chances of errors which in turn can

disrupt the final outcome of the software.

3. There can be threat to the security of the records, since anyone can easily

(7)

1.3 OBJECTIVE OF THE PROJECT

The objective of our project is to computerize the revised Internal Assessment

Evaluation Scheme for B.Sc(H) Computer Science, Delhi University.

This software also enhances the security features (by using passwords) that are void in the traditional ways of implementation of the information storage.

(8)

1.4 SCOPE OF THE PROJECT

The software product INTERNAL ASSESSMENT EVALUATION SYSTEM will be a reporting application that will be used for calculating the internal assessment of students.

The user is allowed to access the software only if he enters the correct password. Thereby, providing security from unauthentic users .



Each lecturer marks daily attendance and at the close of the session, marks not amounting to more than 5% are awarded to each student depending on the

percentage of lectures attended by each to the total lectures.



Again, students submit their assignments periodically which are corrected by teacher concerned & when the session ends, marks amounting to not more than

10% are awarded to the student keeping in view his/her performance.



Similarly, marks obtained in the house examination are taken into consideration & on the basis of actual performance each student is awarded marks at the close of the session which don’t exceed 10%.

(9)

Thus various records to be maintained are: 1. User information

2.

Course year 3. Semester 4. Current semester 5. Subjects 6. Faculty information 7. Faculty & subjects

8.

Database of the students

9.

Students attendance

10.

Internal assignments/project

11. House examination marks

12.

Total internal assessment marks

USER INFORMATION

The security of the software will be maintained with the following inputs:

username user id password

(10)

COURSE YEAR

The course information is maintained as follows:

year no.

year description

SEMESTER

The semester record contains the following fields:

semester no. course year no.

CURRENT SEMESTER

It includes the following fields:

current year

SUBJECT

This record contains following fields:

subject name subject code semester no. course year no.

(11)

FACULTY INFORMATION

The faculty information includes:

faculty name faculty code

FACULTY & SUBJECTS

This record includes:

current year semester faculty code

subject code

DATABASE OF THE STUDENTS

The database of each student is inclusive of :

semester no. year

enrollment no. university roll no. student’s name birth date father’s name mother’s name address phone no.

(12)

STUDENTS ATTENDANCE

The attendance record will contain the following fields:

current year semester subject code

enrollment no. total lectures lectures attended

ASSIGNMENTS / PROJECT

Following are the fields to be included in this record:

enrollment no.

assignments/project submitted max. marks

marks scored

HOUSE EXAMINATION MARKS

The house examination marks record will contain the following:

enrollment roll no. max. marks marks scored

(13)

TOTAL INTERNAL ASSESSMENT MARKS

This is the final record including:

enrollment no. attendance marks

assignment/project marks house exam marks marks of each subject total marks out of 125

(14)

CHAPTER - 2

PROJECT

MANAGEMENT

(15)

2.1 INTRODUCTION

Project management involves the planning , monitoring and control of the people ,

process and events that occur as software evolves from a preliminary concept to an operational implementation.

Effective software project management focuses on the 4 P’s

People , Product , Process , Project.

THE PEOPLE

Software engineering institute has developed a people management capability maturity model (PM-CMM). The people management maturity model defines the key practice areas [KPA’s] for software people like :-

recruiting , selection , performance management , training , compensation , carrier development , organization and work design ,and team / culture development.

(16)

THE PRODUCT

Before a project can be planned, product objectives and scope should be established, alternative solutions should be considered and technical and management constraints should be identified.

Objectives identify the overall goal of the product from customer’s point.

Scope identifies the primary data, functions and behaviours that characterize the product. Alternatives enable managers to select the best approach given constraints imposed by

technical interfaces , personnel availability , delivery deadlines and budgetary restrictions.

Thus, the product factor helps to define the accurate cost estimation , effective risk assessment and a manageable project schedule.

THE PROCESS

A software process provides the framework from which a comprehensive plan for software development can be established

Framework activities are populated with tasks , milestones , work products and

quality assurance points. These activities characterize the software product and the project team.

Umbrella activities i.e. software quality assurance , software configuration management and measurement overlay the process model.

(17)

THE PROJECT

Planned and controlled software projects are conducted to manage complexity. To avoid project failure, the project manager must

avoid a set of common warning signs , understand critical success factors and

develop a common sense approach for planning , monitoring and controlling the project.

2.2

2.3

2.4

2.5

2.6

(18)

2.2 PROJECT – PLAN

2.2.1 SOFTWARE PROCESS MODEL

To solve a particular problem, the project team must incorporate a development strategy that encompasses the process, methods and tools. This strategy is often referred to as a process model or a “SOFTWARE ENGINEERING PARADIGM”. The use of a particular process model or software paradigm is based on the nature of the application.

The following points state the need of a particular software paradigm for development of a software.



To improve the quality of software.



To increase the productivity of software development.



To develop software on time.



To produce a reliable software.

(19)

The project has been made following the WATERFALL MODEL .

Waterfall Model / Linear Sequential Model

This is sometimes called the Classic Life Cycle or Linear Sequential Model.

It suggests a systematic approach to software development that begins at the system level and progress through analysis, design, coding, testing and support.

The following are the activities that the Linear Sequential Model

applies:-System/Information engineering and modeling

It is essential when software must interact with other elements such as hardware, people and database. System engineering and analysis encompass requirement gathering at the

ANALYSIS

SYSTEM/INFORMATION

ENGINEERING

(20)

system level with a small amount of top-level design and analysis. Information engineering encompass requirement gathering at the strategic business level and at the business area level.

Software Requirement Analysis

It is a necessary step to understand the nature of the problem to be built. This phase gathers the input, output, etc. Requirement for both the system and the software are documented leading to the requirement specification report.

Design

This phase focuses on the software architecture, data structures, tables, flow diagrams, interface representations and procedural details. The design translates requirements into a presentation of software that can be assessed and reviewed before code generation begins.

Code Generation

The design developed above has to be translated into a machine-readable form. The code generation step performs this task.

Testing

After the code has been generated, program testing begins. Testing is done to uncover errors and ensure that defined input produces the actual results as required by the user.

Support

This is a phase when software will undoubtedly undergo change after it is delivered to the customer. Change will occur because errors have been encountered, because the software must be adapted to accommodate changes in its external environment, or because the customer requires functional or performance enhancements. Software

(21)

support/maintenance reapplies each of the preceding phases to an existing program rather than a new one.

2.2.2 TEAM STRUCTURE

The “best” team structure depends on the :-management style of the organization

the number of people who will populate the team and their skill levels and the overall problem difficulty.

The three generic team organizations are:

Democratic decentralized (DD)

This software engineering team has no permanent leader. Task coordinators are appointed for short duration and then replaced by others who may coordinate different tasks. Communication among team members is horizontal.

Controlled decentralized (CD)

This software engineering team has a defined leader who coordinates specific tasks

and secondary leaders that have responsibility for subtasks. Problem solving remains a group activity. Communication among subgroups and individuals is

horizontal.

Controlled centralized (CC)

Top- level problem solving and internal team coordination are managed by a team

(22)

We use democratic decentralized [DD] team structure in our project. Our team comprises of two members:

JIGYASA KAUR (7008718)

INDERPREET SINGH (7008742)

Advantages



Generate better solutions



Have greater probability of success when working on difficult problems.



Best applied to programs with low modularity because of the higher volume of communication needed



Results in high morale

(23)

2.2.3 RISK ANALYSIS & MANAGEMENT

Risk always involves two

characteristics:-UNCERTAINITY LOSS

Risk analysis and management is a series of steps that help a software team to

understand and manage uncertainty. Many problems can plague a software project. A risk is a potential problem-it might happen, it might not. But regardless of the outcome, it’s really a good idea to identify it, assess its probability of occurrence, estimate its impact, and establish a contingency plan should the problem actually occur.

Types of risk

PROJECT RISK

They identify potential budgetary, schedule, personnel, resource, custom potential and requirements problem and there impact on software project. They threaten the project plan.

TECHNICAL RISK

They identify potential design, implementation, interface verification, and maintenance problem. They threaten the quality and timeliness of software to be produced.

(24)

They often jeopardizes the project or the product and

includes market risk, strategic risk, management risk and budget risk.

Risk strategies

REACTIVE

A reactive strategy monitors the risk project for likely risk and set aside resources to deal with them, should they become actual problems. Software team does nothing about risks until something goes wrong.

PROACTIVE

A proactive strategy begins long before technical work is initiated. Potential risks are identified, their probability impact is assessed, and they are ranked by importance.

Risk analysis

Risk analysis is a technique to identify and assess factors that jeopardize the success of a project or achieving a goal. This technique also helps define preventive measures to reduce the probability of these factors from occuring and identify counter measures to successfully deal with these constraints when they develop to avert possible negative effects on the competitiveness of the company.

This is achieved

by:- Risk avoidance  Risk monitoring

(25)

 Risk management and contingency plan

RMMM PLAN (Risk Mitigation, Monitoring and Management Plan)

It documents all work performed as a part of risk analysis and is used by project manager as a part of overall project plan.

Once RMMM has been documented and the project has begun, risk mitigation and monitoring steps commence.

Risk management

Following steps can be taken for resolution of the mentioned risks:

REQUIREMENT GATHERING AND ANALYSIS 1.1 Course 26.12.2007 30.12.2007 1.2 Faculty 2.1.2008 6.1.2008 1.3 Students 7.1.2008 9.1.2008 1.4 Internal assessment 11.1.2008 20.1.2008 1.5 FPA 23.1.2008 27.1.2008 1.6 Data dictionary 28.1.2008 1.2.2008 1.7 ERD 3.2.2008 9.2.2008 1.8 DFD 10.2.2008 17.2.2008

2

DESIGN 2.1 Data design 19.2.2008 22.2.2008 2.2 Architectural design 24.2.2008 29.2.2008 2.3 Interface design 1.3.2008 10.3.2008 2.4 Pseudocode 11.3.2008 15.3.2008

(28)

(29)

2.3 COMPLEXITY TABLES

Files complexity

FILES

NO. OF FIELDS RECORDS COMPLEXITY

USER INFO. 3 (username,user

id,password)

1 LOW

COURSE

INFO

4 (course year, sem, subcode,sub name)

1 LOW

FACULTY INFO 4 (subcode, faculty name, sem, year)

1 LOW

DATABASE OF STUDENTS 10 (sem,year,enr no, univ rno., student name, birthdate, father name, mother's name, add., ph no.)

1 LOW

ATTENDENCE RECORD

6 (sem, subcode, enr no.,attendance, marks out of 5, year)

1 LOW

ASSIGNMENT/ PROJECT RECORD

6 (sem, subcode, enr no., assign/ project submitted, marks out of 10, year)

1 LOW

HOUSE EXAM RECORD

7 (sem, subcode, enr no., student name, total marks scored, mrks out of 10, year)

1

(30)

INTERNAL ASSESSMENT RECORD 24(sem,subcode,enr no.,uni rno,student name,att. mrks (out of 5), assign mrks (out of 10), house exam marks (out of 10), mrks of each

1 LOW

Input screen complexity

SCREENS FILES

NO. OF FIELDS COMPLEXITY

COURSE

INFO 1 (Course info)

4 (subcode, subname, sem,course year) LOW

FACULTY

INFO 1 (Faculty info)

14 ( subcode , faculty for each sub, sem, year) LOW

ATTENDANCE RECORD

1 (Attendance record)

5 ( sem ,sub code, enr no. , attend., year) LOW ASSIGNMENT/ PROJECT RECORD 1 (Assign/ project rec)

6 ( sem , sub code , enr no,assig mrks , project mks,year) LOW HOUSE EXAMS RECORD 1 (House exam record)

6 ( sem , sub code , enr no., student name, marks out of 50, year)

(31)

Output screen complexity

SCREENS FILES NO. OF FIELDS COMPLEXITY

SUBJECT

INFO 1 [Course info]

3 ( sem, subcode,

sub name ) LOW

DATABASE OF

STUDENTS

1 [Database of students]

10 ( sem, year,enr no, univ rno., student name,

birthdate, father's name, mother's name, add., ph no.)

LOW

FACULTY

INFO 1 [Faculty info]

4 ( sub code, faculty name, sem no., year) LOW

(32)

(33)

2.4 FUNCTION POINT ANALYSIS

SCREENS FILES

NO. OF FIELDS COMPLEXITY

LOGIN SCREEN 1 (User info) 2 (username,password] LOW

ATTENDANCE RECORD

1 (Attendance record)

6 (sem, subcode, enr no., attendance,

marks out of 5,year)

LOW ASSIGNMENT/ PROJECT RECORD 1 (Assign/ project rec)

5 (sem, subcode, enr no., marks out of 10, year) LOW

HOUSE EXAM RECORD

1 (House exam record)

7 (sem, subcode, enr no., student name, marks out of 50, mrks out of 10, year) LOW INTERNAL ASSESSMENT RECORD 1 (Internal assessment

record) 24(sem,subcode,enr no.,uni rno,student name,att. mrks (out of 5), assign mrks (out of 10), house exam marks (out of 10), mrks of each sub(out of 25), total mrks (out of 125) )

(34)

FP = UFP x [0.65 + 0.01 x Σfi]

= 99 x [0.65 + 0.01 x 42]

FPs =

105.93

CATE GORY SIMPLE AVERAGE COMPLEX TOTA L NO. OF INPUTS 5 X 3 = 15 0 X 4 = 0 0 X 6 = 0 15 NO. OF OUTPUTS 3 X 4 = 12 0 X 5 = 0 0 X 7 = 0 12 NO. OF FILES 8 X 7 = 56 0 X 10 = 0 0 X 15 = 0 56 NO. OF QUERIES 5 X 3 = 15 1 X 4 = 1 0 X 6 = 0 16

UNADJUSTED FUNCTION POINT(UFP) = 99

(35)

CHAPTER - 3

REQUIREMENT

ANALYSIS

&

MANAGEMENT

(36)

3.1 INTRODUCTION

Requirement analysis is a software engineering task that bridges the gap between

system level requirements engineering and software design.

The software requirements analysis may be divided into five areas of

efforts:-Problem recognition

Recognition of basic problem elements as perceived by the users.

Evaluation and synthesis

Define all data objects, evaluate the flow and content of information, define and elaborate all functions, understand software behavior and establish interface characteristics

System

level

engineering

Requirement analysis

Software

design

(37)

Modeling

Functional models represent the information that software transforms, functions enabling the transformation, and behavior of the system during transformation.

Specification

States the goals and objectives of the software, describing it in context of the computer based system.

Review

Changes to the specification may be recommended.

Analysis Principles

 The information domain of a problem must be represented and understood.

 The functions to be performed by software must be defined.

 The behaviour of the software must be represented.



The models that depict information , function and behaviour must be partitioned in a manner that uncovers detail in a layered fashion.



The analysis process should move from essential information towards implementation detail

(38)

3.2 FUNCTIONAL REQUIREMENTS

1. System should incorporate security services.

2.

It should provide facility for updating the next semester on the completion of last one.

3.

It should be able to update the faculty information at the commencement of every semester.

4.

The system should update the course information.

5.

It should be able to maintain records for attendance, assg, house examination for each semester.

6. There should be a provision to calculate attendance marks out of 5

7.

It should be able to calculate assg marks out of 10

8.

Facility should be provided to calculate house examination marks out of 10.

9.

At the end system should be able to sum up all the above mentioned marks out of 25 for each subject and finally out of 125.

(39)

(40)

Analysis model

The analysis model achieves three primary

objectives:- To describe what the customer requires

To establish a basis for the creation of software design.

To define set of requirements that can be validated.

It uses a combination of text and diagrammatic form to depict requirements for

(41)

3.3 DATA DICTIONARY

S NO. FIELD NAME DESCRIPTION

TYPE

LENGTH

1 User Info

Contains all details

about various users

1.1 User name

It stores the user name of the faculty

and administrators

Character

30

1.2 Password

It stores the password

of the corresponding user id

Alphanumeric

6

1.3 User id

It stores the id of each

user

Numeric

4

2. Course year

Contains all details about course years

2.1 Year No.

It stores the course year nos.

Numeric

1

2.2 Year

description

It stores description of the course years

.

(42)

3 Semester

Contains all details about semesters in course years

3.1 Semester

No.

It stores the no. of each semester

Numeric

1

3.2 Course year

No.

.It stores the info. To which year no. a particular sem belongs

(43)

S no. Field name

Description

Type

Length

4 Current

semester

Contains all details about prevailing semesters

4.1 Current

year

It stores the year of

current semesters

Numeric

4

5 Subjects

Contains all details about subjects in all the semesters

5.1 Subject

Name

It stores the name of each subject

Character

30

5.2 Subject

Code

It stores the code of each subject.

Numeric

3

5.3 Sem no.

It stores the semester no. to which a particular each subject belong

Numeric

1

6 Faculty

Info

Contains all details about faculty

6.1 Faculty

name

It stores the name of

each lecturer

Character

30

6.2 Faculty

code

It stores the code of

(44)

S no. Field name

Description

Type

Length

7 Faculty&

subject

Contains all details about the faculty assosciated with subjects.

7.1

Current year semester

It stores the prevailing

semester no.

Numeric

1

7.2

faculty code It stores the code of

each lecturer.

Numeric

4

7.3

subject code It stores the subject code assosciated with that lecturer

(45)

8 Student

Info

Contains info of students of each course year.

8.1 Name

It stores the name of

each student

Character

30

8.2 Enroll.

no.

It stores enrollment no.

of each student.

Numeric

4

8.3 Univ.

Roll no.

It stores the university

roll no. of each student

Numeric

7

8.4 Mother’s name

It stores the mother’s

name of each student

Character

30

8.5 Father’s name

It stores the father’s

name of each student

Character

30

8.6 Address

It stores the address of

the student

Character

30 8.7 Ph no.

It stores the phone

(46)

S no. Field name

Description

Type

Length

9 Student

Attendance

record

Contains all details about attendance of students in each subject

9.1 Current year

semester

It stores the prevailing semester no.

Numeric

1

9.2 Subject code

It stores the subject code to which the attendance of each student belongs.

Numeric

3

9.3 Enr no.

It stores the enr no. of each student

Numeric

4

9.4 Total

lectures

It stores the total no. of lectures delivered by teacher.

Numeric

2

9.5 Lectures

attended

It stores the no. of lectures attended by each student

(47)

10 Student

ass/project

record

Contains all details about the assignments & project submitted by each student

10.1 Current year

semester

semester no.

Numeric

2 10.2 Subject code

It stores the subject code to which the assgn marks of each student belong

Numeric

3 10.3 Enroll no.

It stores the enr no. of

each student

Numeric

4 10.4 Max marks

It stores the max assgn

marks

Numeric

2 10.5 Marks scored

It stores marks scored

(48)

S no Field name Description

Type

Length

11 House

exam

marks

Contains all details about the house exams conducted

11.1

Current year semester

marks

It stores the max.

marks of the exam

numeric

3

11.5 Marks

scored

It stores details of the

(49)

12 Internal

assessment

record

Contains info total assessment of each student.

12.1 Current year

semester

semester no.

Numeric

2

12.2 Subject code

It stores the marks out

of 10 in assigns

Numeric

2 12.6 House exam

marks

of 10 in house exams

Numeric

2 12.7 Subject

marks

of 25 of each subject

Numeric

2

12.8 Total marks

It stores the sum of marks of each subject out of 125

(50)

(51)

SEMESTER YEAR DESC. HA SS SS STUDENT FATHE R NAME MOTHER NAME SUBJECTS FACULTY FACULT Y NAME FACULT Y CODE FACULTY SUBJECTS HA S HA SS ARE FRO M SUB CODE SUB. NAME

CURRENT

SEMESTER STUDENT ATTENDENCE

STUDENT ASS/PROJECT HOUSE EXAM. MARKS TOTAL INTERNAL ASSESSMENT HA S TOTA L LECT. LECT. ATTEN D HA S HA S ASS (10) ATTD. (10) MAR K (125) OUT OF 25 MARKS SCORED TOTAL MARKS ASSG. SUBMTD PROJECT SUBMTD CURR . YEAR COURSE YEAR YEAR NO. SEM NO. NAME UNIV. ROLL NO ADD_. ENR NO. PH. NO.

3.4 ENTITY RELATIONSHIP DIAGRAM

HA SS

(52)

3.5 DATA FLOW DIAGRAM

LEVEL0

COURSE INFO ,

STUDENT REC.

FACULTY INFO

TOTAL

INTERNAL

ASSESSMENT

ATT. REC,

ASS. REC

HOUSE EXAM

RECORD

ADMIN

INTERNAL

ASSESSMENT

EVALUATION

SYSTEM

STUDENT

FACULTY

(53)

LEVEL1

NAME,ENR NO.

UNIV. NO, ADD.

STUDENT

UPDATE

DATA STORE

STUDENT DETAILS

STUDENT

DETAILS

FACULTY INFO.

FACULTY SUBJECT INFO.

FACULTY &

& SUB.

SUBJECTS

DETAILS DATA STORE

FACULTY &SUB.

DETAILS

ENR NO.,ATTD.,ASSIG

ENR NO. , HOUSE EXAM MARKS

ATTD.

ASSIG.

ASSESSMENT

H.EXAM

DATA STORE

MARKS

TOTAL INTERNAL

ASSESSMENT

ADMINISTRATOR

1.0 STUDENT

UPDATE MGT.

2.0 FACULTY &

SUBJECT MGT.

3.0 ASSESSMENT

MGT.

FACULTY

(54)

2.0 Faculty Info. Subject Info.

Faculty Details Subject Details

FACULTY DATA SUBJECT DATA

STORE STORE

Fac & Sub Details

FACULTY & SUBJECTS

DATA STORE

ADMINISTRATION

2.1 ADD

FACULTY

2.2 DELETE

FACULTY

2.3 UPDATE

FACULTY

2.4 ADD

SUBJECT

2.5 DELETE

SUBJECT

2.6 UPDATE

SUBJECT

2.7 ASSOSCIATE

FACULTY &

SUBJECTS

(55)

2.0 Faculty Info. Subject Info.

Faculty Details Subject Details

FACULTY DATA SUBJECT DATA

STORE STORE

Fac & Sub Details

FACULTY & SUBJECTS

DATA STORE

ADMINISTRATION

2.1 ADD

FACULTY

2.2 DELETE

FACULTY

2.3 UPDATE

FACULTY

2.4 ADD

SUBJECT

2.5 DELETE

SUBJECT

2.6 UPDATE

SUBJECT

2.7 ASSOSCIATE

FACULTY &

SUBJECTS

(56)

(57)

3.0 TOTAL ATTENDENCE ENROLL NO. ENROLL NO.

LECTURES ATTENDED ASSG SUBMITTED MAX MARKS

ENROLL NO. MARKS SCORED

ATTD. DATA ASSG. DATA H.EXAM MARKS

STORE STORE DATA STORE

ATT DETAILS

ASSG DETAILS

MARKS DETAILS

MARKS OUT

MARKS OUT OF 10 MARKS OUT

OF 5 OF 10

ASSESSMENT DATA STORE

MARKS OUT OF 125

FACULTY

3.1 GET

ATTENDANCE

3.2 GET

ASSIGNMENT

MARKS

3.3 GET

H. EXAM

MARKS

3.4 PROCESS

ATTD

3.5 PROCESS

ASS.

MARKS

3.6 PROCESS

H.EXAM

MARKS

3.7 TOTAL

EVALUATION

(58)

CHAPTER - 4

DESIGN

(59)

4.1 INTRODUCTION

Design phase of the software development deals with transforming the requirements of

the client into a form implement able using a programming language.

Software design is applied regardless of the software process model that is used. Beginning once software requirements have been analyzed and specifies, software design is the first of three technical activities—design, code generation, tests that are required to build and verify the software.

A good software design is a series of step-by-step procedures to do the desired act.

Design task comprises

of:--Data Design

It transforms the information domain model created during analysis into the data structures that will be required to implement the software.

Architectural Design

It defines the relationship between major structural elements of the software.

Interface Design

It describes how the software communicates within itself, with systems that interoperate with it, and with the users who use it.

Component Level Design

It transforms structural elements of software architecture into a procedural description of software components.

(60)

DESIGN MODEL

D

M

COMPONENT LEVEL DESIGN INTERFACE DESIGN ARCHITECTURAL DESIGN

DATA

DESIGN

(61)

4.2 DATA DESIGN

USER INFO

S NO.

FIELD

TYPE

CURRENT SEMESTER

FACULTY

S NO.

FIELD

TYPE

LENGTH

MANDATORY(M)

OR

OPTIONAL(O)

PRIMARY

KEY

1. 2. SUBJECT NAME SUBJECT CODE CHAR NUMERIC 30 1 O M ----YES

S NO. FIELD

TYPE

LENGTH

MANDATORY(M)

OR

OPTIONAL (O)

PRIMARY

KEY

1. CURRENT YEAR NUMERIC 4 M YES

(64)

FACULTY & SUBJECTS

S NO.

FIELD

TYPE

LENGTH

MANDATORY(M)

OR

OPTIONAL(O)

PRIMARY

KEY

1.

2.

FACULTY NAME FACULTY CODE CHAR NUMERIC 30 4 O M ---YES

S NO.

FIELD

(70)

4.3 ARCHITECTURAL DESIGN

ADMINISTRATION

FACULTY &

SUBJECTS

INTERNAL

ASSESSMENT

STUDENT

SUBJECT

MGT.

ASSOSCIATE

FAC. & SUB.

MGT.

STUDENT

MGT.

TOTAL

ASSESSMNT

HOUSE

EXAM

MGT

ASS/PROJECT

MGT.

ATTEND.

MGT.

FACULTY

MGT.

-ADD

-DELETE

-UPDATE

-ADD

-DELETE

-UPDATE

(71)

4.4 INTERFACE DESIGN

(72)

(73)

(74)

(75)

(76)

(77)

(78)

(79)

(80)

(81)

(82)

(83)

(84)

(85)

(86)

(87)

(88)

(89)

(90)

4.5 SCREENS DESCRIPTION

LOGIN SCREEN

The access of the system is given to the faculty & the administrator.

When the faculty logs in, the following screens appear

SEMESTER ALLOTED

This screen lists the current semester allotted to the teacher who has logged in.

The teacher selects a particular semester

SUBJECTS ALLOTED

This screen gives details of the subjects allotted to that teacher in that particular

semester.

When the teacher selects a particular subject, the foll. menu screen is displayed

SUBJECTS INFORMATION

This is a subject menu screen. It has the following options.

ATTENDANCE RECORD

ASSIGNMENT / PROJECT RECORD

HOUSE EXAM RECORD

(91)