Report of Change)

K.C.E.
S C O E I T, Jalgaon
CHAPTER 1 INTRODUCTION
1.1 NEED OF SYSTEM
With 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 with fewer people and thus reduce manpower costs and pass on the advantage to the customer. Recognition that technology, finances, customers and markets, systems and processes 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, nurturing of competence, increased emphasis on performance management systems. And recognition of the strategic advantage given by employee competencies in 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
Competancy Management System 1
K.C.E.S C O E I T, Jalgaon
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.
Competancy Management System
1.2
Detailed Description
CMS is an Agency-wide application used to measure and monitor the
1.2.1What is the Competency Management System (CMS)?

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 Knowledge o Skills o Attitude
Surface Competencies Most easily developed Self Concept Value Skill
Traits & Motives
Attitude Knowledge Core Competencies Most difficult to develop
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 Knowledge Technical Knowledge Job Knowledge
Skill:
It represents intelligent application of knowledge, experience, and tools. This is the procedural "know how" knowledge (what one can do), either covert
(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.
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:
Measurement
o o o
establish performance measures establish measurable behavioral goals that will improve performance measure current behaviors
Appraisal
o
compare the current behaviors with the behavioral goals and identify the main differences
Action
o
For each difference, you plan how to bring actual behaviors in line with the goals, in order to improve the performance
implement the plan
Monitoring
o o
Check that the new plans are being followed 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.
Maintaining details of competencies acquired and upgraded by the employee.
1.5 Organization Of Report:

Introduction In this chapter we have covered need of the system, detailed description, objectives and future prospects of the system. Analysis We have covered in this chapter the existing system, proposed system, project plan, methods, team structure, data requirements, databases table, and feasibility report. Design We have covered in this chapter software requirement specification and risk assessment. System modeling In this chapter we have covered UML diagrams, Data flow diagrams and E-R diagrams. Coding In this chapter we have covered functional requirements, non functional requirements, software requirements, hardware
requirements, tools to be used, programming language used, coding style. Testing In this chapter we have covered formal technical review, test plan, test cases and test result, manual testing. Software cost estimation In this chapter we have covered COCOMO model and find out the cost using automated costing tools.
Limitations & scope In 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 better software 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 better algorithms 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 better algorithms and use of advanced database.
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.
Planning Analysis Detail System Design Implementation Testing Installation Maintenance
Fig 2.1: System analysis and Design

Planning
It 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.
Analysis
It 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 Designed
During these phase the complete design of the system including all the technical specifications for the pages, menus were made.
Implementation
During 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.
Installation
During the installation stage the website was installed on the server including all the forms & database.
Maintenance
In the system maintenance phase activities performed will be as follows: * Corrective maintenance in response to system errors. * Perfective maintenance to enhance the system.
10
2.1 Existing System: The existing system is 1. Maintaining manually competencies of employee of an organization in form records, 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.
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
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
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.
14
Project Planning 10%
Effort Allocation
Project Planning Testing 10% Requirement Analysis 20% Requirement Analysis Requirement Modelling Design Development Testing Design 20% Requirement Modelling 15%
Development 25%
Fig: 2.5 - Effort allocation using pie-chart for Duplicate mail detection 2.6 TEAM STRUCTURE: Sr.No 1 2 Designation Team Leader System Analyst Vinit Warke 4 Komal Shinkar Quality Analyst Dhanashree Kolhe Dhanashree Kolhe 5 Komal Shinkar Programmers Vinit Warke Ankush Nikam 6 7 Tester Database Design Ankush Nikam Vinit Warke Person Name Vinit Warke Ankush Nikam
Table 1: Team structure

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
16
Table 3: Training
Table 4: Senior Management
17
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.
ii)
Find out whether the organization currently possesses the required technologies: 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 information systems 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? If the 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.
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.
20
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.
21
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 Failure to meet requirement would degrade Performance performance. Reduction in technical Performance. Financial Results Financial Shortages Schedule Support Affect if schedule not Achieved No responsive or Unsupportable s/w Catastrophic Marginal Critical Critical Catastrophic Risk Impact Critical
Cost
22
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 Unified Modeling 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.
Fig.4.1: Use case Diagram of Appraisal dept
24
Fig. 4.2: Use case Diagram of Employee
25
Fig.4.3: Use case Diagram of HR-Dept
26
Fig. 4.4: Use case Diagram of Senior Manager
27
Fig.4.4: Use case Diagram of Training Dept
28
4.1.2 Activity Diagrams:-
Fig.4.5: Activity Diagram of Appraisal Dept
29
Fig.4.6: Activity Diagram of HR-Dept
30
Fig.4.7: Activity Diagram of Senior Manager
31
Fig.4.8: Activity Diagram of Training Dept
32
4.1.3 Class Diagram:
Fig.4.9: Class Diagram of CMS

4.1.4 Sequence Diagram:
s:senior Manager
select position
w:Web Server
Database
h:HR Manager
t:Traning Dept
a:Appraisal Dept
build competency
w:Web Server update database store in DB
submit competency
show success
get position detail

view competency info
get position detail
update DB
post text comment
view text comment
get success response update DB
training program
submit training program
show success get position detail update DB
submit appraisal plan

show success
Fig.4.10: Sequence Diagram of CMS
34
4.1.5 Component Diagram:
Fig.4.11: Component Diagram of CMS
35
4.1.6 Deployment Diagram:
Fig.4.12: Deployment Diagram of CMS
36
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 with its parent context level diagram, i.e there must be the same data flows.
Employee Competency
Competency management system
HR Dept
Database
Fig.4.11. Level 0 DFD of CMS
37
Level 1DFD:
Senior mgmt Suggest Promotions HR Dept Task and competency Gap analysis Training Dept Generate score card
Conduct training
Employee
Training plans
Fig.4.12: Level 1 DFD
38
4.3 ER-Diagram:
Dept name Dept id HR dept 1 1 Maintain competency eid Score 1...* Employee 1...* Create, Update, Delete position Provide training Senior management ename Competency
Id 1 Training dept 1 Dept id Training plans Suggest position
Generates
Score card
1..* .*
Fig4.13: ER-Dig of CMS

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 Department To 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 department To 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 positions Competency Building. 5.2 Non functional requirements 1. Secure access of confidential data (users details). 2. 24 X 7 availability 3. Support min 300 users at a time. 4. Flexible service based architecture will be highly desirable for future extension
40
5.3 SOFTWARE REQUIREMENT
Operating System User Interface Client-side Scripting Programming Language Web Applications IDE/Workbench
: : : : : :
Windows XP HTML JavaScript Java JDBC, Servlets, JSP Rational Application Developer 7.5, RSA for Web Sphere 7.5.4
Database Server Deployment
: :
DataBase2 Web sphere Application Server
5.4 HARDWARE REQUIREMENTS Processor Hard Disk RAM Tools Required:

WEBSPHERE APPLICATION SERVER
: : :
Pentium IV 40GB 2 GB
IBM 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 data and 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
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 APPLICATION
Rational Application Developer provides developers with smart tools that promote best practices, team productivity, innovation, and agility. This awardwinning 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
42
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.
43
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 is running 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
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.
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.
46
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.
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 the development or approval stages of the product, typically on a small sample of units. Manufacturing or Product test to be performed during preparation or assembly 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 or installation of the product. Service and Repair test to be performed as required over the service life of the product.. Regression Test to be performed on an existing operational product, to verify that existing functionality didnt get broken when other aspects of the environment are changed (e.g., upgrading the platform on which existing application runs).
48
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 within the 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
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-level modules 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 lowlevel 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 and integrated 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
50
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, requires testing 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.4 Manual 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:
51
Test Case ID
Test Case Test Case Name Description Step
Test Step Test Data Expected Result Actual Result
Test Resu lt
Login _01
USER & Password
Password Checking
1.Enter password 2.Enter password
Correct Password Incorrect password
Successfully Successfully login login Reenter Password Successfully login
Production Form_02
Course
Display Enroll History
1.Click on enrollment history tab & retrieve records from Emp table. 2.Click on enrollment history tab & retrieve records from Emp table.
Test table name
Successfully Successfully taken taken
Test table name
Successfully Data not taken fetch
Human Resource form _04
Employee skills
Display emp skills
1.click on emp skill set tab & retrieve data from training table
Test training table
Successfully Successfully taken taken
1.click on emp skill

Test training
F
52
set tab & retrieve data from training table
table
Successfully Data not taken fetch
Senior management form_05
Emp position
Display emp position
1.click on all open position tab
Retrieve Successfully Successfully responsibility taken taken & competency
2.click on all open position tab
Successfully Data not Retrieve fetch responsibility taken & competency
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
Successfully Successfully approved approved
Check action approved or reject
Successfully Action approved rejected
53
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.
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.
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 IBM Software Cost (RSA,RAD,DB2,Webspeare) Man Power((4*50(avg. per month day))*4) Electrical Charges per day = 160*2 TOTAL COST 320/27,320/20,000/COST ($) 7000
SCHEDULING: Analysis Design of modules Coding Testing and Implementing Total days
: 30 days : 40 days : 50 days : 25 days : 145 days

56
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.
57
58
59
By using this Costar cost estimation tool we got the cost of our project i.e 40,000/- Rs.
60
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.
61
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 should not 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
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-usingjava-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/discountsspecial-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
Books [1] Herbert Schildt, Java the complete reference Fifth Edition,Tata McGrawHill ED.,5th Edition,PgNo:954-979,Year 2008. [2] Pressman, software engineering 6th edition, Tata McGraw-Hill Ed. 6th edition, PgNo:227-230,year2005.
64
APPENDIX A SNAPSHOTS
65
Fig: Snapshot for login of senior manager
Fig: Snapshot for Welcome page of senior manager
66
Fig: Snapshot for View all position

Fig: Snapshot for Login of training dept
68
Fig: Snapshot for View training program
69
Fig: Snapshot for Add training schedule
70
Fig: Snapshot for View Enrollment Request
71
Fig: Snapshot for login of Appraisal dept
72
Fig: Snapshot for View All Employee Score
73
Fig: Snapshot for View All Positions
74
Fig: Snapshot for login of HR-Dept
75
Fig: Snapshot for view All Employee Skills
76
Fig: Snapshot for login of Production_Dept
77
Fig: Snapshot for View All Training History
78
Fig: Snapshot for All available upcoming Training schedule
79

Report of Change)

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Report of Change)

Diunggah oleh

Hak Cipta:

Format Tersedia

K.C.E.

Figure 1.1: Need for Competency Mapping

Competancy Management System

1.2.1What is the Competency Management System (CMS)?

Competancy Management System

Surface Competencies Most easily developed Self Concept Value Skill

Traits & Motives

Attitude Knowledge Core Competencies Most difficult to develop

Figure 1.2.2: Components of Competency

1.2.3 Who Identifies competencies?

1.3 Presently Available Systems for the same

implement the plan

Maintaining details of competencies acquired and upgraded by the employee.

1.5 Organization Of Report:

1.6 Future prospects

Competancy Management System

Planning Analysis Detail System Design Implementation Testing Installation Maintenance

Fig 2.1: System analysis and Design

Competancy Management System

Competancy Management System

Project Planning 10%

Table 1: Team structure

2.7 Data Requirement

Employee table (EMPLOYEE)

Competancy Management System

Table 4: Senior Management

Competancy Management System

Table 5: Training Dept 2.8 FEASIBILITY REPORT

2.8.2 OPERATIONAL FEASIBILITY:

2.8.3 ECONOMIC FEASIBILITY:

Competancy Management System

3.2 Risk Assessment

Competancy Management System

3.2.2 Cost Risk

Competancy Management System

CHAPTER-4 SYSTEM MODELLING

Fig.4.1: Use case Diagram of Appraisal dept

Competancy Management System

Fig. 4.2: Use case Diagram of Employee

Competancy Management System

Fig.4.3: Use case Diagram of HR-Dept

Competancy Management System

Fig. 4.4: Use case Diagram of Senior Manager

Competancy Management System

Fig.4.4: Use case Diagram of Training Dept

Competancy Management System

4.1.2 Activity Diagrams:-

Fig.4.5: Activity Diagram of Appraisal Dept

Competancy Management System

Fig.4.6: Activity Diagram of HR-Dept

Competancy Management System

Fig.4.7: Activity Diagram of Senior Manager

Competancy Management System

Fig.4.8: Activity Diagram of Training Dept

Competancy Management System

4.1.3 Class Diagram:

Fig.4.9: Class Diagram of CMS

4.1.4 Sequence Diagram:

w:Web Server update database store in DB

get position detail

get position detail

post text comment

view text comment