Report of Change)

8/2/2019 Report of Change)

1/79

K.C.E.S C O E I T, Jalgaon

Competancy Management System 1

CHAPTER 1

INTRODUCTION

1.1NEED OF SYSTEMWith global economy and the world becoming a global village, firms have

become more aware of the need for having competent employees and developing

distinguished competencies for every organization. This need arose due to the

following reasons:

Increased cost of manpower Need for ensuring that competent people are available for performing

various critical roles.

Downsizing adds to the consequent need to get a lot of thing done withfewer people and thus reduce manpower costs and pass on the advantage to

the customer.

Recognition that technology, finances, customers and markets, systems andprocesses can all be set right or managed effectively if we have the right

kind of human resources.

The need for focus in performing roles-need for time management, nurturingof competence, increased emphasis on performance management systems.

And recognition of the strategic advantage given by employee competenciesin building the core competencies of the organization.

Several organizations have realized the importance of this in the last one decade

and hence the rush for competency mapping.

In good organizations with competent HR managers, competency mapping should

already be in existence. Traditionally HR directors and their top management have


2/79



always paid attention to competencies and incorporated them in their appraisal

system. For example when L&T, LIC or NDDB, HLL, Bharat Petroleum, etc.

revised their performance appraisal systems, they focused on the assessment of

competencies

The following figure summarizes the need for competency mapping

Figure 1.1: Need for Competency Mapping

Competency mapping therefore is important and is an essential exercise. Every

well managed firm should have well defined roles and list of competencies

required for performing each role effectively. Such list should be used for

recruitment, performance management, promotions, placement and training needs

identification.


3/79



1.2 Detailed Description1.2.1What is the Competency Management System (CMS)?

CMS is an Agency-wide application used to measure and monitor the

Agency's knowledge base. CMS helps the Agency match the talents and strengths

of their employees with the positions that can best utilize those skills.

The formal definition of a competency is: A collection of tasks with the

associated skills, knowledge, abilities, and wherewithal (tools, methods,

information, doctrine, procedures, materials, etc.) needed to perform the tasks to a

predetermined, measurable, performance standard. The tasks are usually related as

parts of a larger process in support of or contributing to the goals of the

organization, unit, or work group.

1.2.2Components of Competency

Competency has three major components which are as follows:

o Knowledgeo Skillso Attitude


4/79



Figure 1.2.2: Components of Competency

Knowledge:

It refers to the information a person possesses about specific areas, knowledge

comprises many factors like memory, numerical ability, linguistic ability, and is,

therefore, a complex competency. It can be either:

Scientific KnowledgeTechnical KnowledgeJob Knowledge

Skill:

It represents intelligent application of knowledge, experience, and tools.

This is the procedural "know how" knowledge (what one can do), either covert

Self Concept

Traits & Motives

Value

Attitude

Knowledge

Skill

Surface

Competencies

Most easily

Core

Competencies

Most difficult to


5/79



(e.g., deductive or inductive reasoning) or observable e.g. "active listening" skill in

an interview. They are demonstrated abilities or proficiencies, which are developed

and learned from past work and life experience.

Attitudes:

Attitudes are predispositions to other individuals, groups, objects, situations,

events, issues, etc. For example attitude to a particular occupation or type of

machine or a particular technology all influence our behavior. If a person does not

have a positive attitude to computers or IT, he is not likely to use a computer. If he

is not positive about the uses of ERP or SAP, he is not likely to use the ERP or

SAP. Attitudes determine the kind of things we choose and whether we are likely

to approach a particular situation or not or whether we are open to try out the

technology or meet the customer or sell a particular product with high motivation,

etc.

1.2.3 Who Identifies competencies?

Competencies can be identified by one of more of the following category of

people:

Experts HR Specialists Job analysts Psychologists Industrial Engineers etc.

In consultation with: Line Managers, Current & Past Role holders, Supervising

Seniors, Reporting and Reviewing Officers, Internal Customers, Subordinates of

the role holders and other role set members of the role.


6/79



1.3 Presently Available Systems for the same

At Ambuja Cements, competency mapping is at its nascent stage. Here

performance management is a cyclical process aimed at improving performance

(e.g.: achievement of business objectives). This process is implemented by

following the principles underlying Performance Management, namely:

Measuremento establish performance measureso establish measurable behavioral goals that will improve performanceo measure current behaviors

Appraisalo compare the current behaviors with the behavioral goals and identify

the main differences

Actiono For each difference, you plan how to bring actual behaviors in line

with the goals, in order to improve the performance

o implement the plan Monitoring

o Check that the new plans are being followedo At an appropriate time, you return to the appraisal stage to assess the

impact of the changes on the behavioral and performance measures .

1.4 Objective:

To have a system for an organization that focuses on various competencies

essential for organization growth.

1. Competency Building

2. Competency Management.


7/79



Maintaining details of competencies acquired and upgraded by the employee.

1.5 Organization Of Report:

IntroductionIn this chapter we have covered need of the system, detailed

description, objectives and future prospects of the system.

AnalysisWe have covered in this chapter the existing system, proposed system,

project plan, methods, team structure, data requirements, databases

table, and feasibility report.

DesignWe have covered in this chapter software requirement specification

and risk assessment.

System modelingIn this chapter we have covered UML diagrams, Data flow diagrams

and E-R diagrams.

CodingIn this chapter we have covered functional requirements, non

functional requirements, software requirements, hardware

requirements, tools to be used, programming language used, coding

style.

TestingIn this chapter we have covered formal technical review, test plan, test

cases and test result, manual testing.

Software cost estimationIn this chapter we have covered COCOMO model and find out the

cost using automated costing tools.


8/79



Limitations & scopeIn this chapter we have covered future scope, limitations, conclusion,

bibliography, snapshots.

1.6 Future prospects

The following improvements can be made to improve the system in all

aspects:

Better Performance: To achieve better performance, we can use bettersoftware tools for developing the system. Using the latest technology is

important. The technology used should be updated and the system should be

designed to work on the latest technologies.

Faster Speed: We can improve the speed of the system by applying betteralgorithms for performing the required operations. Algorithms play a very

important role in the speed of the system. Inefficient algorithms create

confusion and take more time in computation.

Reliability: The reliability of the system against threats is an important issue.The reliability can be improved by using advanced technologies.

Data Consistency: We can improve the data consistency by applying betteralgorithms and use of advanced database.


9/79



CHAPTER-2

ANALYSIS

Initiating the system analysis the first goal was to understand the existing maual

tending system and the functionality provided by it,and more importantly ,the

objective is that needed to be achieving objective .The entire analysis is performed in

different phases.

Fig 2.1: System analysis and Design

Planning

Analysis

Detail System Design

Implementation

Testing

Installation

Maintenance


10/79



PlanningIt consists of initial assessment & feasibility study. During initial assessment

& feasibility study the technical aspects of hardware were determined as to which

hardware & software should be used to develop the project. Also the cost needed

to develop the project was estimated.

AnalysisIt consists of user requirement, existing system evaluation & logical system

design. During this stage the requirement needed by the user were analyzed,

microanalysis of both the individual needs & organization needs were made.

Logical system design was created specifying the inputs, processes, & the

expected output requirement. The existing Hardware & Software system were

also studied during the analysis phase.

Detailed System DesignedDuring these phase the complete design of the system including all the technical

specifications for the pages, menus were made.

ImplementationDuring the implementation phase, the complete coding of the system was done.

The actual database was created & the system was customized by the creation of

tables, user authorizations & so on.

InstallationDuring the installation stage the website was installed on the server including all

the forms & database.

MaintenanceIn the system maintenance phase activities performed will be as follows:

* Corrective maintenance in response to system errors.

* Perfective maintenance to enhance the system.


11/79



2.1 Existing System:

The existing system is

1. Maintaining manually competencies of employee of an organization in formrecords, Excel sheets and Access Reports.

2.1.1 Problems in Existing System:

1. Employee cannot create, update his profile.

2. Updating the employee details is difficult.

3. Deleting the data from the record/report will permanently delete the data of

particular employee.

4. Handling large amount of data manually is difficult.

5. No backup is available for storing the data.

6. Accessing a particular record is time consuming

7. Supervisor has to generate the score cards of employee manually.

8. Lack of security.

2.2 Proposed System:

To overcome the above problems of the existing system we are developing the

application that with the following features.

1. We are providing user friendly GUI screens.

2. Facility to create his/her profile containing all the details of employee.

3. Maintaining database which can store and can have backup of data.


12/79



4. Creating authorized access to the system.

5. Automatic mailing feature and automatic creation of scorecard of the employee.

6. This system is secure, fast and reliable.

2.3 PROJECT PLAN

The objective of software project planning is to provide a framework

trainable the manager to make reasonable estimates of resources, cost and schedule.

In addition, estimate should attempt to define best-case and worst-case scenario so

that project outcomes can be bounded. Although there is an inherent degree of

uncertainty, the software team embarks on a plan that has been established as a

consequence of planning tasks.

2.3.1 Task identification Plan

Initiating the system analysis to first goal was to understand the existing manual

tending system and the functionality provided by it, and more importantly ,the

objective is that needed to be achieving objective. We have analyzed the entire

system for an organization. The entire analysis is performed in different phase:

1. Understand the definition

2. Primary goal of the system

3. Scope and objective

4. System boundary

5. System and current scenario

6. User requirement

7. Technical requirement

8. functional requirement

9. task planning

10. User interface


13/79



11. Number of engine

12. Tools and technology

A. Details of software

B. Details of hardware

13. Important Features

14. ER diagram

15. System flow chart

16. System security

17. Planning

18. Managerial aspect

19. Team works

20. Efforts

21. Business rules

22. Database schema

2.4 Method used for Requirement analysis (FAST)

FAST is a unique approach to customer and developer interaction and

bringing in a more friendly way of communication between them to gather the

requirements more efficiently. This way benefits like requirement analysis, scope

of the project, objective of the project and detection of errors in the project offering

the greatest potential for improving requirements quality and avoiding cost

overruns in the development of software systems, both for the customer(s) and the

developers. We have proposed a number of extra features for the traditional FAST

(Facilitated Application Specification Techniques), providing more benefits to both

the parties than it is doing now. In our approach we have defined what the

facilitator (the one who is responsible for conducting meetings between the two

parties i.e. the customer and the developer) should really do and specifically who


14/79



should it be, more over certain terms that can come in front in FAST meetings are

looked upon and that how can one be careful about them, keeping things straight

and simple between both the parties. Moreover Verification and Validation is

provided in all the early stages of the software development, being discussed in

every FAST meeting and monitored by the facilitator. Facilitated Application

Specification Techniques (FAST) is a team-oriented approach which is carried out in

early stages of analysis and specification. Analyses the types of competencies in an

organization. Competencies in organizations tend to fall into following broad

categories:

Generic Competencies Managerial Competencies Functional/Technical Competencies

2.5 Efforts Allocation

As our project group has three members so all project efforts are divided

between three members. This include requirement gathering is done by All

members of Project of us by studing various web sites like Gmail,yahoo,rediffmail

etc . Design and some amount of development is done by both and some coding is

done by one member and testing is done by another member. In this way we

allocated our efforts.


15/79



Fig: 2.5 - Effort allocation using pie-chart for Duplicate mail detection

2.6 TEAM STRUCTURE:

Sr.No Designation Person Name

1 Team Leader Vinit Warke

2 System AnalystAnkush Nikam

Vinit Warke

4 Quality AnalystKomal Shinkar

Dhanashree Kolhe

5 Programmers

Dhanashree Kolhe

Komal Shinkar

Vinit Warke

Ankush Nikam

6 Tester Ankush Nikam

7 Database Design Vinit Warke

Table 1: Team structure

Project Planning

10%

Requirement

Analysis

20%

Requirement

Modelling

15%

Design

20%

Development

25%

Testing

10%

Effort AllocationProject Planning

Requirement

Analysis

RequirementModelling

Design

Development

Testing


16/79



2.7 Data Requirement

The proposed system stores the information that is made as tables in oracle

database. The table contain various attributes that can be described certain. Each

table also contains different constraints. Following are the tables used in our

system:

Employee table (EMPLOYEE)

The employee table identifies every emtabployee by an employee number

and lists basic personnel information.

Table 2: Employee


17/79



Table 3: Training

Table 4: Senior Management


18/79



Table 5: Training Dept

2.8 FEASIBILITY REPORT

2.8.1 TECHNICAL FEASIBILITY:

Evaluating the technical feasibility is the trickiest part of a feasibility study. This is

because, at this point in time, not too many detailed design of the system, making it

difficult to access issues like performance, costs on (on account of the kind of

technology to be deployed) etc. A number of issues have to be considered while

doing a technical

analysis.

i) Understand the different technologies involved in the proposed system:Before commencing the project, we have to be very clear about what are the

technologies that are to be required for the development of the new system.


19/79



ii) Find out whether the organization currently possesses the requiredtechnologies:

o Is the required technology available with the organization?o If so is the capacity sufficient?

For instance

Will the current printer be able to handle the new reports and forms

required for the new system?

2.8.2 OPERATIONAL FEASIBILITY:

Proposed projects are beneficial only if they can be turned into informationsystems that will meet the organizations operating requirements. Simply stated,

this test of feasibility asks if the system will work when it is developed and

installed. Are there major barriers to Implementation? Here are questions that will

help test the operational feasibility of a project:

Is there sufficient support for the project from management from users? Ifthe current system is well liked and used to the extent that persons will not

be able to see reasons for change, there may be resistance.

Are the current business methods acceptable to the user? If they are not,Users may welcome a change that will bring about a more operational and

useful systems.

Have the user been involved in the planning and development of the project? Early involvement reduces the chances of resistance to the system and in General and increases the likelihood of successful project.

Since the proposed system was to help reduce the hardships encountered. In the

existing manual system, the new system was considered to be operational feasible.


20/79



2.8.3 ECONOMIC FEASIBILITY:

Economic feasibility attempts 2 weigh the costs of developing and

implementing a new system, against the benefits that would accrue from having the

new system in place. This feasibility study gives the top management the economic

justification for the new system.

A simple economic analysis which gives the actual comparison of costs and

benefits are much more meaningful in this case. In addition, this proves to be a

useful point of reference to compare actual costs as the project progresses. There

could be various types of intangible benefits on account of automation. These

could include increased customer satisfaction, improvement in product quality

better decision making timeliness of information, expediting activities, improved

accuracy of operations, better documentation and record keeping, faster retrieval of

information, better employee morale.


21/79



CHAPTER-3

DESIGN

3.1 Software Requirement Specification (SRS)

The software requirement specification is produced at the culmination of the

analysis task. The function and performance allocated to software as a part of

system engineering. Validation criteria are the most important and ironically the

most often neglected section of the software requirements specifications (SRS). It

is a complete description of the system to be developed. It includes a set of use

cases that describe all the interaction the user will have with the software. Use

cases are also known as functional requirement. In addition to use cases, the SRS

also contain non functional requirement. Non functional requirement are

requirement which impose constraint on the design or implementation.

Based on this SRS we decided the various validation criteria of our project

(An Efficient & Secure Competency Management System).It also explain the

front end and the back end, which is used in the project. We are using Front end

JAVA and Backend DB2.

3.2 Risk Assessment

The majority of software teams rely solely on reactive risk strategies. A

proactive strategy begins long before technical work is initiated. Potential risks are

identified, their portability and impacts are accessed, and they are ranked by

importance.

3.2.1 Performance Risk

The degree of uncertainty that the product will meet its requirements and be

fit for the intended use and make consumer satisfied.


22/79



3.2.2 Cost Risk

The degree of uncertainty that the project budget will be maintained as

estimated and the modules that were required will be designed in the decided

budget.3.2.3 Support Risk

The main motto of our project was the adaptability of and easy use of the

project. The different modules of the project were designed with ease

communication objects and forms. Thus the degree of uncertainty that the resultant

software will be easy to correct, adapt and enhance in the future.

3.2.4 Schedule Risk

The degree of uncertainty that the project schedule will be maintained and

that the product will be delivered on time.

Components Activity Risk Impact

Performance

Failure to meet requirement would degrade

performance.

Critical

Reduction in technical Performance. Catastrophic

CostFinancial Results Marginal

Financial Shortages Critical

Schedule Affect if schedule not Achieved Critical

Support No responsive or Unsupportable s/w Catastrophic


23/79



CHAPTER-4

SYSTEM MODELLING

A model is abstraction of something for the purpose of understanding it before

building it. Abstraction is a fundamental human capacity that permits us to deal

with complexity. Model serves several purposes:

Testing a physical entity before building it. Communication with customers. Visualization. Reduction of complexity.

4.1 UML DIAGRAM

Unified Modeling Language is a standard language for writing the software

blueprints.

The Unified Modeling Language (UML) is a general purpose visual modeling

language that is used to:

Specifying the artifact of a software system. Visualizing the artifact of a software system. Constructing the artifact of a software system. Documenting the artifact of a software system.

4.1.1 Use Case Diagram:

A use case diagram is a type of behavioral diagram defined by the UnifiedModeling Language (UML) and created from a Use-Case analysis. Its purpose is to

present a graphical overview of the functionality provided by a system in terms of

actor , their goals (represented as use cases) , and any dependencies between

those use cases.


24/79



Fig.4.1: Use case Diagram of Appraisal dept


25/79



Fig. 4.2: Use case Diagram of Employee


26/79



Fig.4.3: Use case Diagram of HR-Dept


27/79



Fig. 4.4: Use case Diagram of Senior Manager


28/79



Fig.4.4: Use case Diagram of Training Dept


29/79



4.1.2 Activity Diagrams:-

Fig.4.5: Activity Diagram of Appraisal Dept


30/79



Fig.4.6: Activity Diagram of HR-Dept


31/79



Fig.4.7: Activity Diagram of Senior Manager


32/79



Fig.4.8: Activity Diagram of Training Dept


33/79



4.1.3 Class Diagram:

Fig.4.9: Class Diagram of CMS


34/79



4.1.4 Sequence Diagram:

Fig.4.10: Sequence Diagram of CMS

s:senior

Manager w:Web Server Database h:HR Manager t:Traning Dept a:Appraisal Depselect position

build competency

submit

competency update database store in DB

post text

comment

get position detail

view competency

info get position detail

w:Web Server

update DB

get success

submit training

programupdate DB

show success

submit appraisal

plan

get position detail

show success

update DB

show success

viewtext

comment

trainingprogramresponse


35/79



4.1.5 Component Diagram:

Fig.4.11: Component Diagram of CMS


36/79



4.1.6 Deployment Diagram:

Fig.4.12: Deployment Diagram of CMS


37/79



4.2 DATA FLOW DIAGRAMS

A Data flow diagram (DFD) is a graphical representation of the flow of data

through an information system. It differs from the system flowchart as it shows the

flow of data through processes instead of hardware. A data flow diagram can also

be used for the visualization of data processing (structured design).

0-Level DFD

This level shows all processes at the first level of numbering, data stores,

external entities and the data flows between them. The purpose is show the major

high level processes of the system and their interrelation. A process model will

have one, and only one, level 0 diagram. A level 0 diagram must be balanced withits parent context level diagram, i.e there must be the same data flows.

Fig.4.11. Level 0 DFD of CMS

Competency

management

systemCompetency

Database

Employee HR Dept


38/79



Level 1DFD:

Gap

analysisTraining Dept

Employee

Senior mgmt

Task and

competency

Generate

score card

Suggest

Promotions

Conduct training

Training plans

Fig.4.12: Level 1 DFD

HR

Dept


39/79



4.3 ER-Diagram:

Fig4.13: ER-Dig of CMS

HR dept

Dept name

Dept id

Employee

eid

ename

Competency

Score

Training dept

Provide

training

1...*

1

Score card

Generates

1

1..*

Dept id Training

lans

Maintain

competency

1...*

Create, Update,

Delete position

Senior management

Id

Suggest

position


40/79



CHAPTER 5

CODING

5.1 Functional Requirements

The high level functional requirement for the Competency Management

System (CMS) for an Organization is represented in the Use Case diagram shown

below. The remaining sections in the document describe the major use cases.

Following are the identified functional requirements of the CMS System

a. Provide role based access to the system (Authentication and Authorization)

1. HR DepartmentTo fill up the Score along with the supporting evidence as text

comments.

2. Employee - to create, update, delete data on competencies acquired by him for

his/her position.

3. Appraisal & Compensation departmentTo devise Appraisal plans

4. Training department - to create, update, delete training program and maintain

centralized data of the same.

5. Senior Management To create, update, and delete various Positions and

competencies required for these positionsCompetency Building.

5.2 Non functional requirements

1.Secure access of confidential data (users details).2. 24 X 7 availability3.Support min 300 users at a time.4.Flexible service based architecture will be highly desirable for future extension


41/79



5.3 SOFTWARE REQUIREMENT

Operating System : Windows XP

User Interface : HTML

Client-side Scripting : JavaScript

Programming Language : Java

Web Applications : JDBC, Servlets, JSP

IDE/Workbench : Rational Application Developer 7.5,

RSA for Web Sphere 7.5.4

Database : DataBase2

Server Deployment : Web sphere Application Server

5.4 HARDWARE REQUIREMENTS

Processor : Pentium IV

Hard Disk : 40GB

RAM : 2 GB

Tools Required:

WEBSPHERE APPLICATION SERVERIBM Information Server is a revolutionary new software platform that helps

organizations derive more value from the complex heterogeneous information that

is spread across their systems. It enables organizations to integrate disparate dataand deliver trusted information wherever and whenever needed, in line and in

context, to specific people, applications, and processes.

IBM Web Sphere Information Analyzer is a data profiling and analysis tool

that is a critical component of IBM Information Server. It is designed to help


42/79



business and data analysts understand the content, quality, and structure of their

data sources by automating the data discovery process. Bundled with IBM Web

Sphere Information Analyzer is Audit Stage, a data rule monitoring tool that is

designed to help business and data analysts validate data and assess ongoing data

quality trends.

RAD APPLICATIONRational Application Developer provides developers with smart tools that

promote best practices, team productivity, innovation, and agility. This award-

winning integrated development environment enables developers to quickly build,

test, analyze, and publish Java EE 6, Web 2.0, and Service Oriented Architecture

(SOA) applications on the latest versions of Web Sphere Application Server and

Web Sphere Portal Server. Integration with Rational Team Concert provides

a team-based environment that helps developers share information and work

collaboratively. Code quality tools help teams find and correct problems early

before they escalate into expensive problems. Here are some links to help you

understand what's been updated.

RSA7.5.The IBM Rational Software Architect for Web Sphere Software Version

7.5.x releases contain cumulative fixes, enhancements, and new features, meaning

that they include all new features or enhancements, as well as additional fixes to

Eclipse, from earlier releases

5.5 Programming Language Used

JAVA:

Java is a programming language originally developed by James Gosling at

Sun Microsystems
http://en.wikipedia.org/wiki/Programming_languagehttp://en.wikipedia.org/wiki/James_Goslinghttp://en.wikipedia.org/wiki/Sun_Microsystemshttp://en.wikipedia.org/wiki/Sun_Microsystemshttp://en.wikipedia.org/wiki/James_Goslinghttp://en.wikipedia.org/wiki/Programming_language


43/79



5.5.1 Java features:

With this feature of Java. Java gives you the best of both worlds. You need

not pointers for everyday constructs like string and arrays. You have the power of

pointers if you need it, for example, for like lists. And you have always-complete

safety, since you can never access a bad pointer or make memory allocation errors.

1. Secure:

Java enables the contraction of virus-free, temper-free systems. Here is a

sample of what Javas security features are supposed to keep a Java programming

from doing:

1.1 Over running the runtime stack.

1.2 Corrupting memory outside its own process space.

1.3 Reading or writing local files when invoked through a security-conscious class

loader like Web browser.

2 Architecture Neutral:

The compiler generates an architecture neutral object file format- the

compiled code is executable on many processors, given the presence of Java

runtime system

3. Portable:

Unlike C and C++, they are no "implementation dependent" aspects of the

specifications. The sizes of the primitives data types are specified, as is the

behavior of arithmetic on them.


44/79



4. Interpreted:

The Java interpreters can execute Java byte codes directly on any machine to

which the interpreter has been ported. Since linking is amore incremental and

lightweight process, the development process can be much more rapid and

explanatory.

5. High Performance:

While the performance of interpreted byte codes is usually more than

adequate, there are situations higher performance is required .The byte codes can

be translated on fly into machine code for the particular CPU the application isrunning on .

6. Multithreaded:

In a number of ways, Java is more dynamic language than C or C++. It was

designed to adapt to an evolving environment. Library scan freely add new

methods and instance variables without any effect on their clients. In Java , finding

out run time type information is straightforward .

7. Object-oriented:

To be an Object Oriented language, any language must follow at least the

four characteristics:

Inheritance Encapsulation Polymorphism

As the languages like Objective C, C++ fulfills the above four characteristics

yet they are not fully object oriented languages because they are structured as well

as object oriented languages. But in case of java, it is a fully Object Oriented


45/79



language because object is at the outer most level of data structure in java. No

stand alone methods, constants, and variables are there in java. Everything in java

is object even the primitive data types can also be converted into object by using

the wrapper class.

5.6 Coding Style Followed

This document describes a set of standards and guidelines for developing

programs in the Java language with a consistent style. It is meant to be used not

only by programmers directly writing Java code, but also by programmers creating

programs which automatically generate Java code. The importance and benefits of

a consistent coding style are well known. A consistent style:

Improves the readability, and therefore, maintainability of code

Facilitates sharing of code among different programmers, especially teams of

programmers working on the same project.Allows easier development of

automated tools to assist in program development, such as tools which

automatically format or pretty-print source code.

Makes it easier to conduct code reviews, another software engineering process

with well-known benefits. In turn, a practice of regular code reviews can help

enforce a consistent style. saves development time, once the guidelines are

learned, by allowing programmers to focus on the semantics of the code, rather

than spend time trying to determine what particular format is appropriate for a

given situation. However, these standards are not meant to be rigidly enforced

without exception. This document does not cover all possible situations.

Experience and informed judgment should be used wherever doubt exists.

Consistency of coding style is more important than using a particular style.


46/79



5.7 System Calls

The System Call is a request made by any program to the OS for performing

task picked from predefined set- which said program does not have required

permission to execute in its own flow of execution. System calls provide the

interface between process and the OS. Most operation interacting with the system

require permission not available to the user level process, e.g. I/O perform with a

device present on the system, or any form of communication with other processes

requires the use of system calls.


47/79



CHAPTER 6

TESTING

6.1 Formal Technical Review

Formal Technical Review (FTR) is a process used to improve work products

through team efforts. Any deliverable that is produced during the development life

cycle is eligible to be reviewed and should be at any early stage, beginning in the

specification stage and recurring at each identifiable milestone. A description of

the review process as implemented at Fermi lab is available as well as the list of

reviews that have been held. Many additional references are available. Unless

otherwise stated all Fermi FTR documentation will include the symbol shown at

the top of this page to distinguish it from outside information.

The following guidelines should help in setting up an FTR,

1. Choose the work product to be reviewed.2. Determine the type of FTR to use.3. Follow the description of specific FTR in question.

It is important to remember when determining the type of FTR to use that no

process will work for every organization. Feedback to review process is an

important part of having a process. The process evolves as experience and

participant comments are folded back into it. In some sense it is not only the work

product which is being reviewed but the review process as well. What is important

is to develop an FTR process that works for your organization and to stick with

that process when performing a review.


48/79



6.2 Test Plan

A test plan is a systematic approach to testing a system such as machine or

software. The plan typically contains a detailed understanding of what the eventual

workflow will be. A test plan documents the strategy that will be used to verify and

ensure that a product or a system meets its design specifications and other

requirements. A test plan is usually prepared by or with significant input from Test

Engineer. Depending on the product and the responsibility of the organization to

which the test plan applies, a test plan may include one or more of the following:

Design verification or Compliance test to be performed during thedevelopment or approval stages of the product, typically on a small sample

of units.

Manufacturing or Product test to be performed during preparation orassembly of the product in an ongoing manner for purposes of performance

verification and quality control.

Acceptance or Commissioning test to be performed at time of delivery orinstallation of the product.

Service and Repair test to be performed as required over the service lifeof the product..

Regression Test to be performed on an existing operational product, toverify that existing functionality didnt get broken when other aspects of the

environment are changed (e.g., upgrading the platform on which existing

application runs).


49/79



A complex system may have a high level test plan to address the overall

requirement and supporting test plan to address the design details of subsystem and

component. Test plan document formats can be varied as the products.

6.3 Test Cases and Test Results

Testing is generally described as a group of procedures carried out to

evaluate some aspect of a piece of software. It helps to identify the correctness,

completeness, security and quality of developed software. It also identifies

variance (if any) between actual and expected results.

Testing is an integral element of software development. Exhaustive testiness

not feasible but testing is said to be optimum when defect rate falls below a certain

predefined level

Testing is performed at the following levels:

1. Unit testing

2. Integration testing

3. System testing

6.3.1 Unit Testing

Unit testing focuses verification effort on the smallest unit of software

design-the software component or module. Using the component-level design

description as a guide, important control paths are tested to uncover errors withinthe boundary of the module.

Unit testing is a software development process in which the smallest testable

parts of an application, called units, are individually and independently scrutinized

for proper operation. Unit testing is often automated but it can also be done


50/79



manually. This testing mode is a component of Extremes Programming (XP), a

pragmatic method of software development that takes a meticulous approach to

building a product by means of continual testing and revision.

6.3.2 Integration Testing

Integration testing is a logical extension of unit testing. In its simplest form,

two units that have already been tested are combined into a component and the

interface between them is tested. A component, in this sense, refers to an integrated

aggregate of more than one unit. In a realistic scenario, many units are combined

into components, which are in turn aggregated into even larger parts of the

program. This method reduces the number of possibilities to a far simpler level of

analysis.

You can do integration testing in a variety of ways but the following are

three common strategies:

The top-down approach to integration testing requires the highest-levelmodules be test and integrated first. This allows high-level logic and data

flow to be tested early in the process and it tends to minimize the need for

drivers. However, the need for stubs complicates test management and low-

level utilities are tested relatively late in the development cycle. Another

disadvantage of top-down integration testing is its poor support for early

release of limited functionality.

The bottom-up approach requires the lowest-level units be tested andintegrated first. These units are frequently referred to as utility modules. By

using this approach, utility modules are tested early in the development

process and the need for stubs is minimized. The downside, however, is that

the need for drivers complicates test management and high-level logic and


51/79



data flow are tested late. Like the top-down approach, the bottom-up

approach also provides poor support for early release of limited

functionality.

The third approach, sometimes referred to as the umbrella approach, requirestesting along functional data and control-flow paths. First, the inputs for

functions are integrated in the bottom-up pattern discussed above. The outputs

for each function are then integrated in the top-down manner. The primary

advantage of this approach is the degree of support for early release of limited

functionality.

There are two major ways of carrying out an integration test, called the

bottom-up method and the top-down method.

6.4Manual Testing

Oldest and most rigorous type of software testing. It is performed by a

human sitting in front of a computer carefully going through application screens,

trying various usage and input combinations, comparing the results to the expected

behavior and recording their observations about our concern project.

6.4.1 Steps for Manual Testing

1. Writing test cases

2. Executing test cases

3. Reporting results of test cases

Some of the test cases:


52/79



Test Case

ID

Test Case

Name

Test Case

Description

Test Step Tes

Resu

ltStep Test Data Expected

Result

Actual

Result

Login _01 USER &

Password

Password

Checking

1.Enter

password

2.Enter

password

Correct

Password

Incorrect

password

Successfully

login

Reenter

Password

Successfully

login

Successfully

login

P

F

Production

Form_02

Course DisplayEnroll

History

1.Click onenrollment

history tab

& retrieve

records

from Emp

table.

2.Click on

enrollment

history tab& retrieve

records

from Emp

table.

Test tablename

Test table

name

Successfullytaken

Successfully

taken

Successfullytaken

Data not

fetch

P

F

Human

Resource

form _04

Employee

skills

Display

emp skills

1.click on

emp skill

set tab &

retrieve

data fromtraining

table

1.click on

emp skill

Test training

table

Test training

Successfully

taken

Successfully

taken

P

F


53/79



set tab &

retrieve

data from

training

table

table Successfully

taken

Data not

fetch

Senior

management

form_05

Emp

position

Display

emp

position

1.click on

all open

position

tab

2.click on

all open

position

tab

Retrieve

responsibility

&

competency

Retrieve

responsibility

&

competency

Successfully

taken

Successfully

taken

Successfully

taken

Data not

fetch

P

F

Training

form _06

Course of

emp

status &

action

Check

action

1.Click on

enrollment

request

tab

2. Click

on

enrollment

request

tab

Check action

approved or

reject

Check action

approved or

reject

Successfully

approved

Successfully

approved

Successfully

approved

Action

rejected

P

F


54/79



CHAPTER 7

SOFTWARE COST ESTIMATION

7.1 Using COCOMO

The COnstructive COst MOdel (COCOMO) is an algorithmic Software

Cost Estimation Model developed by Barry Boehm. The model uses a basic

regression formula, with parameters that are derived from historical project data

and current project characteristics

Basic COCOMO is a static, single-valued model that computes software

development effort (and cost) as a function of program size expressed in estimated

lines of code.

COCOMO applies to three classes of software project:

1. Organic Projects - are relatively small, simple software projects in which small

teams with good application experience work to a set of less than rigid

requirements

2. Semi-detached Projects - are intermediate (in size and complexity) software

projects in which teams with mixed experience levels must meet a mix of rigid

and less than rigid requirements.

3. Embedded projects - developed within a set of "tight" constraints. It is also

combination of organic and semi-detached projects.

The basic COCOMO equations take the form

Effort Applied (E) = ab(KLOC)bb [man-months]Development Time (D) = cb(Effort Applied)

db [months]

People required (P) = Effort Applied / Development Time [count]

Where, KLOC is the estimated number of delivered lines (expressed in

thousands ) of code for project, The coefficients ab, bb, cb and db are given in the

following table.
http://en.wikipedia.org/wiki/Man-monthhttp://en.wikipedia.org/wiki/Man-monthhttp://en.wikipedia.org/wiki/Man-monthhttp://en.wikipedia.org/wiki/Man-month


55/79



Software project ab bb cb db

Organic 2.4 1.05 2.5 0.38

Semi-detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

Line of Code:

This is the number of lines of the delivered source code of the software,

excluding comments and blank lines and is commonly known as LOC [10].

Although LOC is programming language dependent, it is the most widely used

software size metric. Most models relate this measurement to the software cost.

However, exact LOC can only be obtained after the project has completed.

Estimating the code size of a program before it is actually built is almost as hard as

estimating the cost of the program.

Function points:

This is a measurement based on the functionality of the program and was

first introduced by Albrecht. The total number of function points depends on the

counts of distinct (in terms of format or processing logic) types in the following

five classes:

1. User-input types: data or control user-input types.

2. User-output types: output data types to the user that leaves the system.

3. Inquiry types: interactive inputs requiring a response.


56/79



4. Internal file types: files (logical groups of information) that are used and shared

inside the system

5. External file types: files that are passed or shared between the system and other

systems

FPs can be used to estimate LOC depending on the average number of LOC

per FP for a given language:

LOC = AVC * number of function points

AVC is a language dependent factor varying from 200300 for assembles

language to 240 for a 4GL.

COST ANALYSIS:

SYSTEM PARTS COST ($)

IBM Software Cost

(RSA,RAD,DB2,Webspeare)

7000

Man Power((4*50(avg. per month

day))*4)

20,000/-

Electrical Charges per day = 160*2 320/-

TOTAL COST 27,320/-

SCHEDULING:

Analysis : 30 days

Design of modules : 40 days

Coding : 50 days

Testing and Implementing : 25 days

Total days : 145 days


57/79



7.2 Using Automated Costing Tool (Costar)

Costar is a software estimation tool based on the Constructive Cost Model

(COCOMO) described by Barry Boehm in his books Software Engineering

Economics and Software Cost Estimation with COCOMO II. Software project

managers use Costar to produce estimates of a project's duration, staffing levels,

effort, and cost. Costar lets you make trade-offs and experiment with "what-if"

analyses to arrive at the optimal project plan.


58/79




59/79




60/79



By using this Costar cost estimation tool we got the cost of our project i.e

40,000/- Rs.


61/79



CHAPTER 8

LIMITATIONS & SCOPE

8.1 Future Scope

1. According to the post of the employees we are preparing the scorecard and

skills of the employees. Presently we are doing this work offline. The software is

to be installed by us separately for use. In future we are intending to implement it

online. The application will be available on internet and then we can prepare the

scorecard online.2. Also presently very few training courses are available but in future we are

intending to adjust training of all the courses according to the demand of the up

gradations.

3. Presently, in this application only 300 peoples are login at the time. But in future

we are increasing the capacity of peoples to login this application.

8.2 Limitations

1.The maintain of a set of competencies in an organization of say 40000

employees are practically.

2. Classroom based on training courses are not easy to use to provide scale

necessary to maintain competencies of such large number of peoples.

3. This process is completely depending upon paper work or offline.

4. After giving information all employees it cannot be changed further.


62/79



CONCLUSION

Competency Mapping therefore, is a process of identifying key

competencies for an organization and/or a job and incorporating those

competencies throughout the various processes (i.e. job evaluation, training,

recruitment) of the organization.

A lot is going on in recent times on the issue of competency mapping. A lot

of resources are spent and consultants are being invited to do competency

mapping. Increased manpower costs, need for ensuring that competent people man

critical positions, and the need to be competitive and recognition of the strategic

advantages of having good human resources have compelled firms to be more

competency driven.

In the report we have discussed how competent employees have become

need of the hour in every organization and it is now essential that they undertake

competency mapping, identify models, gaps and imbibe this as an everyday

practice in an organization.

Often competency mapping runs the risk of being just another new-fangled

process that happens to be the flavor of the season. Such a powerful organizational

tool is often resorted just because rival organizations have implemented it and not

because there is genuine appreciation of its benefits. Competency mapping shouldnot be seen as just another means to apportion and dispense rewards.

All the stakeholders must see in the exercise an opportunity for long-term

growth. The key is to look at competency mapping as going beyond mere


63/79



processes. And to see in it an exercise that has a significant and lasting value to

project managers as well as to the organization.

BIBLIOGRAPHY

Sites

[1] http://e-learning.zjgsu.edu.cn/servlet_api/javax/servlet/package-summary.html

http://harikrishnan83.wordpress.com/2009/01/24/access-gmail-with-imap-using-

java-mail-api/

[2]http://www.campaignmonitor.com/templates/

[3]http://e-learning.zjgsu.edu.cn/servlet_api/javax/servlet/package-summary.html

[4]http://www.roseindia.net/javamail/ReadMultipartMail.shtm

[5]http://www.w3school/ajax/example/.

[6]http://blog.emailaddressmanager.com/outlook/outlook-add-ins/discounts-

special-deals.html

[7]http://www.google.com/support/forum/p/gmail/rss_v2_0_msgs.xml?tid=0a407b

efaaaee8a2&hl=en

[8]http://office.microsoft.com/en-us/duplicate-email-remover

M001111246.aspx?CTT=1

[9] Hamer , The Implementation of Competence Management: How to

Approach it and the Pitfalls to watch out for.

[10]http://www.trainingreference.co.uk/learning_management_systems/competenc

e_manageme

nt..htm
http://e-learning.zjgsu.edu.cn/servlet_api/javax/servlet/package-summary.htmlhttp://www.campaignmonitor.com/templates/http://e-learning.zjgsu.edu.cn/servlet_api/javax/servlet/package-summary.htmlhttp://e-learning.zjgsu.edu.cn/servlet_api/javax/servlet/package-summary.htmlhttp://www.campaignmonitor.com/templates/http://e-learning.zjgsu.edu.cn/servlet_api/javax/servlet/package-summary.html


64/79



Books

[1] Herbert Schildt, Java the complete reference Fifth Edition,Tata McGraw-

Hill ED.,5th Edition,PgNo:954-979,Year 2008.

[2] Pressman, software engineering 6th edition, Tata McGraw-Hill Ed. 6th

edition, PgNo:227-230,year2005.


65/79



APPENDIX A

SNAPSHOTS


66/79



Fig: Snapshot for login of senior manager

Fig: Snapshot for Welcome page of senior manager

Documents

Report of Change)