Recruitment Management - Report Example

Recruitment Management Name Course Tutor Date TABLE OF CONTENT 1. Data Flow Diagrams………………………………………………………………………..3 1.1 Assumptions………………………………………………………………………………3 1.2 Context Diagram …………………………………………………………………………4 1.3 Level 1 Diagram …………………………………………………………………………5 1.4 Level 2 Diagrams ………………………………………………………………………..6 1.5 Recommendations ……………………………………………………………………….9 2. Entity Relationship Diagram………………………………………………………………10 2.1 Assumptions……………………………………………………………………………...11 2.2 Entities & Key Attributes ………………………………………………………………..11 2.3 Relationships……………………………………………………………………………...11 2.4 Cardinalities………………………………………………………………………………13 2.5 Recommendations ………………………………………………………………………..14 3. Data Dictionary ……………………………………………………………………………15 4. Bibliography ………………………………………………………………………………16 5. Appendices…………………………………………………………………………… 1. Data Flow Diagrams Data flow diagrams are representations of different related components in an information system indicating the flow of data. Here, information in a system is represented in form of data process. The data flow diagrams enable the designer visualize the entire operation of the system to accomplish various tasks. The high level details in a system are modeled in such a way that the inputs are transformed into outputs through various stages of processes. Data flow diagrams are a preferred method of representing information over the technical descriptions because of the following major reasons. First, DFDs are easily understood because they do not require expertise knowledge. They are hence easy to both create and understand. Secondly, these diagrams provide a detailed description and visual representation of an entire system. Since these representations are in visual forms, they are easier to design. Lastly, the data flow diagrams enable an overview of a high level system. These overviews have clear marked boundaries and connections between the various components. The designer is able to visualize the whole system and hence allow for necessary changes to be made. Data flow diagrams consist of various components which are: External entities which send data to the system and likewise receive information, processes which are responsible for manipulating data and information, data store for storing data and information in the system and lastly the data flow paths joining these components and indicating flow of information. Entity: this is an information and data source or sink. They are usually located outside of the system. The entities which input data to the system are regarded as information sources. On the other hand, information sinks are entities which receive data from the system. Entities are normally drawn in rectangular forms. Process: These are manipulations of data. They are responsible for performing calculations, logical decisions, computations and also the creating the path to be taken by the data from one entity to another. They are usually drawn in circular form. The process number is indicated in the circle together with the process name. Process name is usually a short verb indicating the work done by it. Data store: Here is where data and information is stored in the system. The information stored can be retrieved by the process in case needed. The data is stored in files and also tables. They are usually drawn in a rectangular box with the right side open. They can also be drawn in a rectangular box with both left and right sides missing. The store name is usually indicated inside the box region. Data flow: These are lines to indicate the movement/ flow of data/ information in the system. They are the connection elements between the entities, the process and also the data store. They are represented by an arrow. The data flow name is then written near the arrow. Rules and guidelines for developing and designing the data flow diagrams The first step in designing the data flow diagrams is to determine the various data items. From the case study on ABC Human service department, there were various entities and data stores. The entities included; hiring manager, recruitment agencies and university placement, website and lastly the candidates. Candidate information is taken as the data store. From the entities given above, the data sources to the system are the hiring manager, the website, the recruitment agencies and university placements, and also the candidates. Likewise, these entities served as information sinks as data was sent to the hiring manager, the candidates, the university placement and recruitment agencies and also the websites. The second step is determining the system boundaries. In involves indicating which entities are external to the system and which ones are internal. From the ABC human service case study, the hiring manager and websites are the entities internal to the system. The candidates, university placement and recruitment agencies are taken as entities external to the system. Level 0 DFD Here, all components in the system are drawn in a single box in the data flow diagram. The hiring manager, website, university placement and recruitment agencies, candidates and also the candidate information data store are drawn in a box. Data flow arrows are used to join these components to indicate the direction of flow of information. This information can flow to and from the process, the entities and the data store. Level 1 DFD Data flow diagrams are usually represented in different levels. Level 0 represents the interaction of the system with the outside world. The subsequent levels illustrate the system in details. The diagrams are usually in the same shapes as in level 0. When designing level 1 DFDs, the relationship with the environment must be preserved. (Bruza, 1989). This means that the data flow direction in level 1 must be the same as in level 0. Level 1 represents a higher view of the system. The incoming and outgoing data flow directions are clearly indicated. Using the case study information, it is seen that the human service process can be divided into four processes. These are: advertising process, job application process, application review process and lastly the contract establishment process. These processes are also drawn in a circle with the respective number process indicated on top of each process name. The various data flow arrows are also drawn to relate the entities and the processes. Level 2 DFD A lower level data flow diagram is drawn to break down the various sub-processes in the system. They enable for detailed observation of the system and its components. The various entities, data stores, process and data flow diagrams are represented in the same manner as in the other levels. From the case study information, various sub-processes are noted in the system. Under the advertising process, there are two sub-processes; handling the position descriptions and position advertising. In the job application process, there were three sub-processes; receiving job applications, sending acknowledgments and checking applications. Under the application review process there were two sub-processes; interview booking and interview status. Lastly, under the contract establishment process, there were five sub-processes; security and verification checking, contacting candidates, offer status, contacting unsuccessful candidates and receiving contracts from the candidates. Advantages of data flow diagrams There are various advantages of representing data systems using the data flow diagrams. First, data flow diagrams enable faster and easier to develop and understand. The symbols are easy to learn and draw. Naming the entities and data stores is also simple. Disadvantages of data flow diagrams There are however a few disadvantages of using the data flow diagrams. When designing a DFD for a large system, the process is quite cumbersome as the designer must know how to relate the various entities and data stores. They can be very confusing to the designer. They hence require great care in developing. 1.1. Assumptions The following assumptions are made in the data flow diagram drawn in the next page. First, it is assumed that human service has direct access to the databases storage. There are no security checks to validate entry to the data store. Secondly, it is also assumed that there is proper communication channel between the inputs and outputs to the HS. There occurs no loss of data input to the system by the candidate or by the hiring manager. There is also safe storage of data in the store as no loss is assumed to occur. It is assumed that the signed contracts are returned to the HS in due time. There is an effective communication channel between the HS and the candidates. The data flow diagram is shown in the next page. 1.2 Context Diagram Advert Application Candidate Candidate application form application Vacant positions Candidate application Candidate details Acknowledgments Interview Shortlist Phone call Successful candidates Verification Sign-off Information Contract Information Candidate Details Vacancy file Application file Interview file Contract information CANDIDATE INFORMATION 1.3 Level 1 Diagram Advert Application request Applications Applications Applications Vacancy Complete application incomplete application Shortlist Successful applicants Contract Sign-off Contract feedback Verification Signed hard copy CANDIDATE INFORMATION 1.4 Level 2 Diagram Position description VACANT POSITION FILE Update Email update Job application update Acknowledgement Incomplete verification JOB APPLICATION FILES CANDIDATE FILE Complete application complete application Level 2 (continuation) Shortlist notification Email INTERVIEW INFORMATION FILE Level 2 (continuation) VERIFICATION FILE Offer Feedback CONTRACT FILE Email HARD COPY CONTRACT Contract 1.5 Recommendation From the case study analysis and the data flow diagrams drawn in this report, we hereby recommend the several changes be implemented in the system to make it more effective. First, we recommend that the Human Service should be allowed direct update access to the recruitment agencies and university placement websites. This will speed up the advertisement speed and reduce the work done by recruitment agencies. Likewise, this will enable easy update of application information in case of changes. Secondly, we recommend that the application forms be in soft copy to speed up the HS scanning process. Scanning using manual process is quiet cumbersome and time consuming. It also requires additional manpower in terms of resources. Use of electronic means of counting scanning the application is faster and requires lesser resources. This saves both time and money for the organization. We would also like to recommend that the HS be given direct access to the candidate information related to the interview. Such access granted speeds up the selection process as the HS will be able to contact successful candidates by itself instead of waiting for official communication from the hiring manager. This will in turn speed up the hiring process. Lastly, we recommend that the human service be allowed to store contract information directly to a database instead of hard copy only. This process will enable the HS make changes to the contract without waiting for communication from the hiring manager. There should, however, be implemented a high security check to prevent unauthorized personnel from accessing this vital information. 2: Entity Relational Diagram(ERD) This is a data modeling technique used to develop a database by relating entities in an information system. They are used to set the stage for later development of a database. They are used to define data stored in a system at a high abstraction level. Entity relational diagrams are made up of entities, attributes and relationships. Entities: This is an object of interest to the user (Bagusi, 2003). They are usually used to represent similar kinds of information in a system. They are drawn in the shape of a rectangle. The entity name is then written inside the rectangular box. Attributes: These are characteristics of entities i.e properties of an entity. They are represented as fields of tables at the implementation level. They are drawn in oval shapes and the different attribute names written inside them. They are then connected to their respective entities using a line. There are two types of attributes; required attributes and optional attributes.(Sumathi, 2007) A required attribute requires to be filled with a value and can never be left empty. An optional attribute can be left empty without being filled with a value. Attributes can further be divided into four types; simple, composite, multiple and key attributes. Simple attributes are attributes that are not divisible. Composite attributes are composed of different simple attributes. Multiple attributes are a set of possible values for the same entity. Key attributes uniquely identify an entity. There are different types of primary keys which include; candidate key, primary key, alternate key and foreign key. A candidate key is a combination of attributes which uniquely identify an entity. A primary key is a single candidate key. Alternate key is the other candidate key not taken as the primary key. On the other hand, a foreign key is an attribute in one relation whose values match a primary key in another relation. Domain: This is a set of possible values that an attribute can contain. Attributes which are given the same name share a particular domain. . Relationships: This is defined as the interaction between entities. The entities that participate in a relationship are known as participants. Entities have relationships which operate in both directions. Relationships capture the rules of the entire system. There are three types of relationships; one-to-one, one-to-many, and many-to-many. One-to-one (1:1): In such a case, one instance in a parent entity refers to one instance in the child entity. One to many (1: M): Here, one instance in a parent entity related to one, two or many instances in the child entity. Many to many (M:N): In this relationship, many instances in the parent entity relate to many instances in the child entity and likewise many instances in the child entity relate to many instances in the parent entity. Cardinality: This is used to express the minimum and maximum number of tuples associated with one tuple of its entity (Sumathi, 2007). In entity relational diagrams, cardinality is represented by writing an appropriate number besides each entity. This is written in the format (a, b) such that the value ‘a’ represents the minimum number of associated tuples, while the value ‘b’ is used to indicate the maximum number of associated tuples. Existence dependence: In a situation where an entity can exist in a database only when it is associated with another entity, it is said to be an existence dependent. Strong entities: In a situation where an entity can exist in a system without dependence on the related entity, it is known as a strong entity. Relationship strength is based on how primary keys are defined in a group of entities(Bagusi, 2003). There are therefore two major types of relationships based on strength; strong relationships and weak relationships. In a strong relationship, the primary key of an entity appears as a foreign key in the related entity. Here, the primary key appears on the ‘one’ side of the one-to-many relationship while the foreign key appears on the ‘many’ side of the one-to-many relationship. On the other hand, a weak relationship exists if the primary key of the child entity does not have a primary key component on the parent entity. 2.1 Entity Relational Diagram (ERD) 2.1 Assumptions This entity relational diagram assumes that there is enough data storage for the candidate’s applications. It is also assumed that once the candidates send apply for the positions, all details are able to be stored without loss. 2.2 Entities and key Attributes Entities in the system are: Position description (PD), Job application form, Candidate file, Interview file, Reference and Security check file. Key attributes under each entity are as follows; 1. Position description: Id, department, job description, requirements, hiring manager, closing date, location, type and status. 2. Job description: Id, name, address, qualification, experience. 3. Interview file: id, interviewer, data, job application 4. Reference and security check file: Phone number, email address, security agency. 2.3 Relationships The relationship between Position Description file and the Application forms file is one to many. This means that one vacant position can have many application forms and many application forms can be for a single position. It is as shown in the diagram below. 1 M The relationship between the application file and the candidate file is a one to one. This means that only on application file is allowed for each candidate and each candidate can only have one application file. It is a shown in the diagram on the below. 1 1 The relationship between interview file and the candidate file is a many to many relationship, such that many interviews can be conducted for many candidates and likewise several candidates can participate in several interviews. It is as shown in the figure below. M N The relationship between interview file and security file is a one to many. This means that one interview file can pass through several security checks i.e. the reference checks by phone and email and also by a security agent, likewise a several security checks can be conducted on one interview file. The relationship diagram is as shown below. 1 M 2.4 Cardinality Position description and application file: One position can have one, two or many applications. Application file and candidate file: One application file for one candidate. Interview file and candidate file: One, two or many interview files for one, two or many Candidates Interview file and security checks: One or two security checks can be performed for one interview file. 2.5 Recommendations From the entity relational diagrams drawn, we hereby recommend a number of factors. First, the organization should create an entry to allow for uploading updates to the university placement and recruitment agencies. This will enable faster upload of updates and reduce the on recruitment time to handle the uploading the information to their websites. We would also like to recommend that the application process be done over online. This will eliminate the use of hardcopy forms which gather up much space in storage. Use of softcopy forms will save a large amount of time during scanning of candidates documents. Storage of this softcopy forms is easier as no physical space is needed. Space and time is hence saved. Thirdly, we recommend the candidate information file be shared with the HS. Since the HS has to wait for the selection process to be conducted by the hiring process and only on completion is the HS allowed to access these detail. This slows down the hiring process. Giving the HS these files will reduce the number of days used in recruitment process. Finally, we would like to recommend that the HS be given permission to store both the hard copy and softcopy contract detail. This will allow the human service to make changes if need be to the contract directly without waiting for the hiring manager to do this. The hiring manager will hence save more time. Likewise, in case of problems in the contract of a candidate, the HS can be able to handle this without going through the hiring manager. In a situation where the candidate declines the offer, the HS can be able to draft a new vacant position file without waiting for the hiring manager to make this decision. This will save time in the re-advertisement process. 3. Data dictionary A data dictionary is a tool used to record and process data and information in an organization’s. It can also be defined as a collection of data objects in a data model. In most cases it is usually integrated with the database system. Its main function is to illustrate the relationship between the conceptual and implementation view. A data dictionary has various advantages which include; easy data analysis, simplified programming, improved documentation and also reduction of data redundancy(Narayan, 1988) A data dictionary provides the following services; it should record and analyze data requirements independently and also design decisions in terms of database and file structure. The data dictionary should also provide the management with a several facilities. First, it should document all data and information collected in the system. Secondly, it should store detailed description of the application usage when the system is being implemented(Wertz, 1986). This is to enable analysis and re-design when needed. The data dictionary must also be able to access to system description easier. In the ABC human service case study, there were a number of databases were to be used in designing the online recruitment system. The position description entity consisted of the following fields; Id, department, job description, requirements, hiring manager, closing date, location, type and status. The job description entity was made up of the following field; Id, name, address, qualification, experience. In the interview entity, the following fields were needed; id, interviewer, data, job application. Lastly the reference and security check entity had the following fields; Phone number, email address, security agency. The data dictionary for the fields is shown in the following table. Data dictionary Field Name Data Type Description ID Autonumber Primary key Department Text Field size 50 Job_description Text Field size 50 Name Text Field size 50 Requirements Text Field size 50 Hiring_manager Text Field size 50 Deadline Date/time Format: Medium date Location Text Field size 50 Type Text Field size 50 Status Boolean Lookup: Married/Single Interviewer Text Field size 50 Data Text Field size 50 Job_application Text Field size 50 Phone Number Fieldsize 20 Presence check Email Text Fieldsize 20 Presence check 4. Bibliography Bagui S. & Earp R. (2003), “Database design using entity-relationship diagrams” Boca Raton, Pg 28-41 Bruza P. D. &Weide T. V. (1989), “The semantics of data flow diagrams”, Nijmegen, Netherlands, University of Nijmegen, Dept. of Informatics, Faculty of Mathematics and Informatics.Pg 10-36 France R. B. (1991), “Semantically extended data flow diagrams: a formal specification tool”, College Park Md, University of Maryland.Pg 7-10 Narayan R. (1988), “Data dictionary: implementation, use, and maintenance” Englewood Cliffs, N.J, Prentice Hall.pg 5-23 Sumathi S. &Esakkirajan S. (2007), “Fundamentals of Relational Database Management Systems”, Berlin, Heidelberg, Springer-Verlag, Berlin Heidelberg.Pg 14-34 Wertz C. J. (1986), “The data dictionary: concepts and uses” Wellesley, MA, QED Information Sciences.Pg 3-13 Read More