Sr. No - Topics of Coverage

Sr. No .
Topics Of Coverage
1 2 3 4 5 6 7 8 9 10 11 12
Detailed Problem statement for the project SRS in IEEE format for the project Cost estimation of the project using COCOMO II model Develop a risk table for the project Use project management tool to schedule project plan. Draw State Transition Diagram for the system Draw Activity Diagram for the system Draw Data Flow Diagrams for the system Architectural Design for the system Black-Box Testing White-Box Testing Implementation
Experiment No . 01 Detailed Problem Statement

Example system: Problem Definition for Online Recruitment System(ORS): This software System will be an Online Recruitment System for job Seeker (Fresher or experienced) and Company. This System will be designed to provide more flexibility to job Seeker to apply for particular Companies and can maintain privacy, which otherwise would have done less transparently. The Requirements comparing and sorting Seekers list is done by System so that it eases Company to select the candidates. More specifically, this System will allow the Seeker to upload his Rsum and for the Company to put its requirement on website. The System will provide the list of Companies that match Seekers Rsum details. Then Seeker can personally put his reference in the Companys account for further consideration. The job Seeker is free to choose between Companies. No one knows if an individual has started looking for a new job. This System also contain relational database that maintains the list of Seekers, Companies, placements etc. Functional Requirements:
1. Create
new account: The Seeker visits the website to create a new account by giving personal details (With Rsum) and registers with a monthly subscription.
2. Update
Rsum: The Seeker can edit the Rsum any time after registering to the system. After editing the Rsum, Seeker saves the Rsum to update the database.
3. Renewing
account: Seeker has to renew his/her account after the expiration of the monthly subscription. After renewing the account, Seeker will be able to access his/her account.
4. View
requirements: The Seeker can view requirements of any Company irrespective of whether he is eligible for it. This will help the Seeker to know which technologies he/she has to learn so as to be eligible for the Company for which he/she wants to apply.
5. Check
Company list: The Seeker can check the list of companies whose requirements match with his/her Rsum details. This list can be viewed on the website after login or in the mobile device by using the mobile application developed for the same purpose.
6. Send
Rsum to Company: Once Seeker gets the list of matching companies, he/she has to select the companies for which he/she wants to apply for the job. Seeker can apply to only those companies whose requirements match with his/her Rsum details. After selecting the companies, Seeker can send his/her Rsum to those companies.
7. Put
requirements: The Company can put or edit requirements by logging into the account and if does not have any account then it can edit in its own database which is accessible to the System. 8. Select candidate: The Company can view candidates list sorted by the System according to requirements. The Company can view each Rsum and can personally contact any candidate.
9. Control overall
System: The Admin has central control over all functionalities. He has to monitor the database and take advertisements from various advertisers.
10. Provide
Periodic Reports: The Admin generates the periodic reports for Seekers and Companies. These reports help him to know whether there is need for any improvement in the System.
11. Creating
account for the Companies: Companies cannot directly register to the System. For registration, Company managers have to contact the Admin who will create the account for the Company. Non-Functional Requirements: The whole System will be on a server with high speed Internet capability. The software developer here assumes the use of a tool such as Tomcat or Glassfish for connection between the Web pages and the database. The speed of the Seekers connection will depend on the hardware used rather than characteristics of this System. The System also accesses some Companys database (External database) directly (with the help of Middleware Technology). The software developer here assumes that Company will provide support. The Seekers mobile device should provide support to J2ME (.jar file) technology.
Experiment No . 02 SRS in IEEE format for the project
Software Requirements Specification for Online Recruitment System (ORS)
<<Any comments inside double brackets such as these are not part of this SRS but are comments upon this SRS example to help the reader understand the point being made.
Refer to the SRS Template for details on the purpose and rules for each section of this document. >>
Table of Contents
Table of Contents...............................................................................................................................................i 1.0. Introduction..............................................................................................................................................iii 1.1. Purpose.................................................................................................................................................iii 1.2. Scope of Project....................................................................................................................................iii 1.3. Glossary................................................................................................................................................iv 1.4. References............................................................................................................................................iv 1.5. Overview of Document........................................................................................................................iv 2.0. Overall Description....................................................................................................................................v 2.1 System Environment...............................................................................................................................v 2.2 Functional Requirements Specification..................................................................................................v 12. 2.2.1 Seeker Use Case...............................................................................................................................vi Use case: Create new account............................................................................................................vi Use case: Update Rsum .................................................................................................................vii Use case: Renew account...................................................................................................................vii Use case: View requirements............................................................................................................viii Use case: Check Company list..........................................................................................................viii Use case: Send Rsum To Company.................................................................................................ix 13. Company Use Case.....................................................................................................................................x Use case: Putting requirement..............................................................................................................x Use case: Selecting candidate..............................................................................................................xi 14. Admin Use Case........................................................................................................................................xi Use case: Control overall System......................................................................................................xii Use case: Provide periodic reports....................................................................................................xii Use case: Granting account to Company ...........................................................................................xii 2.3 User Characteristics.............................................................................................................................xiii 2.4 Non-Functional Requirements.............................................................................................................xiv 3.0. Requirements Specification....................................................................................................................xiv 3.1 External Interface Requirements.........................................................................................................xiv 3.2 Functional Requirements.....................................................................................................................xiv 15. 3.2.1 Create new account........................................................................................................................xiv 16. 3.2.2 Update Rsum ...............................................................................................................................xv 17. 3.2.3 Renewing account...........................................................................................................................xv 18. 3.2.4 View requirements.........................................................................................................................xvi 19. 3.2.5 Check Company list.......................................................................................................................xvi 20. 3.2.6 Send Rsum to Company............................................................................................................xvii 21. 3.2.7 Put requirements............................................................................................................................xvii 22. 3.2.8 Select candidate............................................................................................................................xviii 23. 3.2.9 Control overall System.................................................................................................................xviii 24. 3.2.10 Provide periodic reports...............................................................................................................xix 25. 3.2.11 Creating account for the Companies............................................................................................xix 3.3 Detailed Non-Functional Requirements...............................................................................................xx 26. 3.3.1 Logical Structure of the Data..........................................................................................................xx 27. 3.3.2 Security........................................................................................................................................xxiii Index...............................................................................................................................................................24 28. When to Use: State Diagrams...................................................................................................................36 29. How to Draw: State Diagrams..................................................................................................................36 30. When to Use: Activity Diagrams.............................................................................................................39 31. How to Draw: Activity Diagrams.............................................................................................................39
List of Figures
Figure 1 - System Environment........................................................................................................................v Figure 2 - Logical Structure of Online Recruitment System..........................................................................xx
ii
1.0. Introduction 1.1. Purpose

The purpose of this document is to present a detailed description of the Online Recruitment System. It will explain the purpose and features of the System, the interfaces of the System, what the System will do, the constraints under which it must operate and how the System will react to external stimuli. This document is intended for both the stakeholders and the developers of the System and will be proposed to Charushila maam for its approval.
1.2. Scope of Project

This software System will be an Online Recruitment System for job Seeker (Fresher or experienced) and Company. This System will be designed to provide more flexibility to job Seeker to apply for particular Companies and can maintain privacy, which otherwise would have done less transparently. The Requirements comparing and sorting Seekers list is done by System so that it eases Company to select the candidates.
More specifically, this System will allow the Seeker to upload his Rsum and for the Company to put its requirement on website. The System will provide the list of Companies that match Seekers Rsum details. Then Seeker can personally put his reference in the Companys account for further consideration. The job Seeker is free to choose between Companies. No one knows if an individual has started looking for a new job. This System also contain relational database that maintains the list of Seekers, Companies, placements etc.
iii
1.3. Glossary
Term Seeker Rsum Definition Person (Fresher or experienced) searching for a job. The document that contain all personal and educational information about Seeker. Database Collection of all the information monitored by this System. Company Any Company conducting Recruitment. Requirement Expectation of Company about candidates. Placement Seeker getting a job. Recruitment Process of selecting candidate for a Company. Software Requirements A document that completely describes all of the functions Specification(SRS) of a proposed System and the constraints under which it must operate. For example, this document. Stakeholder Any person with an interest in the project who is not a developer. User Seeker or Company.
1.4. References
IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society, 1998.
1.5. Overview of Document

The next chapter, the Overall Description section, of this document gives an overview of the functionality of the website. It describes the informal requirements and is used to establish a context for the technical requirements specification in the next chapter. The third chapter, Requirements Specification section, of this document is written primarily for the developers and describes in technical terms the details of the functionality of the website. Both sections of the document describe the same software product in its entirety, but are intended for different audiences and thus use different language.
iv
2.0. Overall Description 2.1 System Environment
Figure 1 - System Environment
The Online Recruitment System has three active actors and one cooperating System. The Seeker, Company and the Admin access the System functions through the Internet and mobile by log in. << The entire System is divided into two component parts, the Online System and the mobile application, further details will make a clear explanation about them. >>
2.2 Functional Requirements Specification

This section outlines the use cases for the active Seeker, Company, and Admin.
2.2.1
Seeker Use Case
Use case: Create new account Diagram:
Brief Description The Seeker visits the website to create a new account by giving personal details (With Rsum) and taking subscription. Initial Step-By-Step Description Before this use case can be initiated, the Seeker has already accessed the Online Recruitment Website. 1. 2. 3. 4. The Seeker chooses create new account option. The System will display input form. The Seeker fills personal details. The System presents Rsum builder to Seeker.
vi
5. The Seeker fills the Rsum details. 6. The Seeker chooses appropriate subscription offer. 7. The System provides transaction facility to Seeker. Xref: Section 3.2.1, Create new account
Use case: Update Rsum Diagram:
Brief Description The author can edit the Rsum or add more details. Initial Step-By-Step Description Before this use case can be initiated, the Author has already log in to his account. 1. 2. 3. 4. The Seeker chooses the edit Rsum option. The System shows original Rsum and edit button in front of each field. The Seeker can edit field by pressing the edit button. Finally to save changes, Seeker presses the submit button.
Xref: Section 3.2.2, Update resume
Use case: Renew account Diagram:
Brief Description After the subscription period is over, the Seeker needs to renew account. Initial Step-By-Step Description Before this use case can be initiated, the Seeker has already logged in to the Online Recruitment System.
vii
1. 2. 3. 4.
The Seeker log in to his account. The System provides a renew option. The Seeker has to choose an appropriate subscription offer. The Seeker makes online payment.
Xref: Section 3.2.3, Renewing account
Use case: View requirements Diagram:
Brief Description The Seeker can view requirements of any Company irrespective of whether he is eligible for it. Initial Step-By-Step Description Before this use case can be initiated, the Author has already logged in to account. 1. 2. 3. 4. The Seeker chooses the view requirement option. The System provides the list of Companies. The Seeker will enter the name of any desired Company. The System shows the desired Companys requirement (If any).
Xref: Section 3.2.4, View requirement
Use case: Check Company list Diagram:
Brief Description
viii
The Seeker can view deserved Company list on website or on mobile. Initial Step-By-Step Description Before this use case can be initiated, the Author has already logged in to the Online Recruitment System through computer or mobile. 1. 2. 3. 4. The Seeker logs into his account. The System shows the Account home page. The Seeker chooses check deserved Company option. The System provides the list of matching Companies.
Xref: Section 3.2.5, Check company list
Use case: Send Rsum To Company Diagram:
Brief Description The Seeker can send his Rsum to selected Companies only. Initial Step-By-Step Description Before this use case can be initiated, the Author has already view deserved Companies list. 1. The Seeker chooses the desired Companies from the list. . 2. The Seeker presses the send Rsum button. Xref: Section 3.2.6, Send resume to company
ix
Company Use Case
Use case: Putting requirement Diagram:
Brief Description The Company can put or edit requirements by logging into the account and if does not have any account then it can edit in its own database which is accessible to the System. Initial Step-By-Step Description Before this use case can be initiated, the Company is already connected to the Online Recruitment System. 1. 2. 3. 4. 5. The Company logs into its account. Then Company selects the update requirement option. The System will show original requirement and edit button in front of each field. The Company can edit each requirement field by pressing the edit button. The changes can be saved by pressing the submit button.
x
Use case: Selecting candidate Diagram:
Brief Description The Company can view candidates list sorted by the System according to requirements match. The Company can view each Rsum and can personally contact any candidate. Initial Step-By-Step Description Before this use case can be initiated, the Company has already logged into the Online Recruitment Website. 1. 2. 3. 4. The Company chooses the view candidates option. The System shows list of candidates that have put their reference to the Company. The Company can view each Rsum. The Company can reply or reject the candidate.
Xref: Section 3.2.8, select candidate Admin Use Case
xi
Use case: Control overall System Diagram:
Brief Description The admin has central control to all functionality. Xref: Section 3.2.9, Control overall system Use case: Provide periodic reports Diagram:
Brief Description The admin generates the periodic reports for Seekers and Companies. Initial Step-By-Step Description Before this use case can be initiated, the Admin is already connected to the Online Recruitment System. 1. The admin logs in to his account. 2. The admin write queries (DDL/DML commands). 3. The admin updates the results in representational form on the website. Xref: Section 3.2.10, Provide periodic report Use case: Granting account to Company Diagram:
xii
Brief Description The admin can only grant account to Companies. Initial Step-By-Step Description Before this use case can be initiated, the admin has already connected to the Online Recruitment System. 1. The admin logs into his account. 2. The admin selects the create Company account option. 3. The admin provides username and password to the Company. Xref: Section 3.2.11, Granting account to company
2.3 User Characteristics

The Seeker is expected to be Internet literate and be able to use an e-commerce for money transfers. The Seeker is expected to be mobile literate so that he can view Company list on mobile application. The Companys Manager (HR) is expected to be Internet literate and should be able to use button, pull-down menus, and similar tools for putting requirement.
xiii
The detailed look of these pages is discussed in section 3.2 below.
2.4 Non-Functional Requirements

The whole System will be on a server with high speed Internet capability. The software developer here assumes the use of a tool such as Tomcat or Glassfish for connection between the Web pages and the database. The speed of the Seekers connection will depend on the hardware used rather than characteristics of this System. The System also accesses some Companys database (External database) directly (with the help of Middleware Technology). The software developer here assumes that Company will provide support. The Seekers mobile device should provide support to J2ME (.jar file) technology.
3.0. Requirements Specification 3.1 External Interface Requirements

If any Company provides direct access to their databases then by using middleware technology we can directly extract the requirements. So Company neednt manually log in and put requirements.
3.2 Functional Requirements

The Logical Structure of the Data is contained in Section 3.3.1.
3.2.1 Create new account

xiv
Use Case Name XRef Trigger Precondition Basic Path
Alternative Paths Post Condition Exception Paths Other
Create new account Section 2.2.1, Create new account SDD, Section 7.1 The Seeker clicks on Sign Up button The Web is displayed with Sign Up option 1. The Seeker selects Create new account option. 2. The input form is displayed on the screen. 3. The Seeker fills his/her personal details. 4. The System provides Rsum builder to enter the educational information of the Seeker. 5. The Seeker enters the data in his/her Rsum. 6. The Seeker selects a transaction method which suits him/her better from the provided options. 7. The System provides transaction facility to the Seeker as selected by him/her. None The information provided by the Seeker is submitted to the System and stored in the Systems database. The Reader may abandon the Sign Up activity at any time. The personal information includes the Seekers name, address, Date of birth, contact number and email id.
3.2.2 Update Rsum

Use Case Name XRef Trigger Precondition Basic Path Update Rsum Section 2.2.1, Update Rsum The Seeker selects the Edit Rsum link. The Seeker selects Update Rsum option. 1. The Seeker clicks on the Edit Rsum link. 2. The original Rsum with Edit button next to each field is displayed on the screen. 3. The Seeker edits the information. 4. The Seeker clicks on Submit button to save the Rsum. None The changes made by the Seeker are stored in the database. The attempt may be abandoned at any time. None
3.2.3 Renewing account

Use Case Name XRef Renewing account Section 2.2.1, Renewing account
xv
Trigger Precondition Basic Path
The Seeker selects to renew his/her account. The Seeker has created the account and has done the required transactions. 1. The Seeker logs in the Online Recruitment System. 2. The Seeker selects the renew account option. 3. The Seeker selects the suitable transaction option from the given options. 4. The Seeker clicks on the Submit button. If in step 2, either field is blank, the Editor is instructed to add an entry. No validation for correctness is made. The Seekers account is reactivated after successful transaction. The Seeker may abandon the operation at any time. The transaction option includes periods of different lengths.
3.2.4 View requirements

Use Case Name XRef Trigger Precondition Basic Path View requirements Section 2.2.1, View requirements The Seeker selects to view requirements of any Company. The Seeker has already logged in. 1. The Seeker selects the View requirements option. 2. The System displays the list of Companies. 3. The Seeker can click on the name of any Company to view the requirements of that Company. 4. The requirements of the selected Company are displayed if listed by the Company. In step 2, the Seeker can also find the required Company by typing its name in the search box. The Company requirements are displayed on the screen. The Seeker may abandon the operation at any time. The Company list includes the links to the requirements page of the particular Company from its account.
3.2.5 Check Company list

Use Case Name XRef Trigger Precondition Check Company list Sec 2.2.1 Check Company list; The Seeker selects to check the list of Companies whose requirements match to his/her Rsum . The Seeker has already logged in to the System.
xvi
Basic Path
1. The Seeker logs in to the System either through the computer or through the mobile application provided by the System. 2. The Seeker is directed to his account. 3. The Seeker clicks on the Check Possible Companies link. 4. The list of Companies whose requirements match with the Seekers Rsum is displayed on the screen with descending order of matches. None The list is displayed on the screen. If the Seekers Rsum does not match with any of the Companies requirements then a message No match found is displayed. The Company can specify some mandatory requirements which must be satisfied by the Seeker.
3.2.6 Send Rsum to Company

Use Case Name XRef Trigger Precondition Basic Path Alternative Paths Post Condition Exception Paths Other Send Rsum to Company Section 2.2.1, Send Rsum to Company The Seeker selects the desired Companies from the matched Companies list to send the Rsum . The Seeker has visited the Check Possible Companies link. 1. The Seeker selects the desired Companies from the list to send his/her Rsum . 2. The Seeker presses the Send Rsum button. None The link to the Seekers Rsum is sent to the specified Companies. The Seeker may not want to send the Rsum to any of the listed Companies. The Seeker is not allowed to send the Rsum to the Companies which are not displayed in the list.
3.2.7 Put requirements

Use Case Name XRef Trigger Precondition Basic Path Put requirements Section 2.2.2, Put requirements The manager of the Company selects to add requirements to the account. The manager has already logged in to the System. 1. The manager logs in to the System. 2. The manager selects the Update Requirements option.
xvii
Alternative Paths
Post Condition Exception Paths Other
3. The requirements are displayed on the screen with the Edit button next to each field. 4. The manager can edit any requirement by pressing the Edit button. 5. The changes are saved to the database by clicking on the Submit button. In step 1, the manager can update requirements from Companys own database if he doesnt have the account created on the website. These requirements are accessible to the Online Recruitment System. The requirements are updated in the respective databases. None New requirements may be added or existing requirements may be deleted along with updating the existing requirements.
3.2.8 Select candidate

Use Case Name XRef Trigger Precondition Basic Path Select candidate Section 2.2.2, Select candidate The Company manager views the posted Rsum to the account. The manager has already logged in to the System. 1. The manager clicks on the View Candidates link. 2. The System displays the list of candidates with the descending order of matches with the Companys requirements. 3. The manager can see each Rsum . 4. The manager can decide to reply to the candidates who suit to the Companys requirements. The remaining Rsum of the candidates are rejected. None The rejected candidates are deleted from the list and the notification of rejection is sent to those candidates. None The rejected candidates are deleted from the list so that these names do not occur again when the manager logs in for the next time.
3.2.9 Control overall System

Use Case Name Control overall System
xviii
XRef Trigger Precondition Basic Path Alternative Paths Post Condition Exception Paths Other
Section 2.2.3, Control overall System None The Admin has already logged in to the System. The Admin maintains the overall System and has the control over all the functionalities of the System. None. None None None
3.2.10 Provide periodic reports

Use Case Name XRef Trigger Precondition Basic Path Provide periodic reports Section 2.2.3 Provide periodic reports None The Admin has already logged in to his account. 1. The Admin logs in to his account. 2. The Admin writes the different queries to get the desired output. 3. The Admin updates the website. None. The website has been updated. None The Admin uses the information obtained to improve the websites functionality.
3.2.11 Creating account for the Companies

Use Case Name XRef Trigger Precondition Basic Path Creating accounts for the Companies Section 2.2.3, Creating accounts for the Companies The Admin clicks on the Sign Up button. The Admin has visited the websites home page. 1. The Admin logs in through his account. 2. The Admin selects Create Company Account option. 3. The Admin creates account for the Company and provides username and password for the Company.
xix
None. The account for Company is created. None The Admin informs about username and password to the Company via email.
3.3 Detailed Non-Functional Requirements

3.3.1 Logical Structure of the Data The logical structure of the data to be stored in the ORS database is given below.
Figure 2 - Logical Structure of Online Recruitment System
The data descriptions of each of these data entities are as follows:

xx
Seeker Data Entity Data Item Type s_username Text password orig_name address dob phone_no email Text Text Text Date Number Text
Description Comment Username of Seekers It may not be same as the account Original name. Password of Seekers account Name of Seeker Address of Seeker Seekers date of birth Seekers phone number Seekers E-mail ID
Resume Data Entity Data Item Type s_username Pointer education Text exp Number domain language1 language2 language3 other Text Text Text Text Text
Description Seeker Entity The qualification of Seeker The experience of the seeker in years The working domain of the seeker(Web/App) The Comp. Programming language known to seeker Any other Specialty of the Seeker.
Comment 1 to 1 relationship
This is filled with the help of Automatic resume Builder.
Company Data Entity Data Item Type c_username Text password headquarter email contact Text Text Text Number
Description Comment Username of companys account Provided by the Admin after Password of companys Authentication. account Head Quarter of the Company Email address of the company. Contact number of the Company.
Requirement Data Entity Data Item Type c_username Pointer education Text
Description Company entity. The qualification
Comment 1 to 1 relationship the
xxi
experience domain platform language
Text Text Text Text
needed profile. The experience of the needed profile. with The working domain of the Filled Automatic needed Profile. The working platform of Builder. the needed Profile. The Computer language of the needed Profile.
the help Requirement
Transaction Article Entity Data Item Type Description s_username Pointer Seeker entity tno Number Transaction number of the transaction committed by the Seeker. start_date Date The Starting date of the subscription by the Seeker. exp_date Date The Expiry date of the account of Seeker. amount Currency Total amount of transaction
Comment 1 to many relationship. Along with s_username forms the Primary key. Helps in the renewal of Account Amount paid by Seeker
Applies Article Entity Data Item Type s_username Pointer c_username Pointer app_date Date
Description Seeker entity Company entity The date on which the seeker sends his resume to desired Company.
Comment Combination acts as a Primary key.(Many to Many relationship Between Seeker and Company)
Places Article Entity Data Item Type s_username Pointer c_username Pointer place_date Date
Description Seeker entity Company entity The date on which the
Comment Combination acts as a Primary key.(Many to Many relationship Between Seeker and Company)
xxii
company approved Seeker for interview.
the
Advertisement Article Entity Data Item Type Description Comment ad_name Text The name of Advertising Company. amount Currency The amount paid to the Admins account for the Advertisement. post_date Date The date on which the Advertisement was put on the Website. Helps in removal/renewal of exp_date Date The date on which the Advertisements. Advertisement will be removed from the Website. Admin Article Entity Data Item Type admin_id Number ad_name Text c_username Pointer
Description The ID of the Admin The name of the Admin Company entity
Comment For holding the records of the Company that are presently there in the System
3.3.2
Security The server on which the Seekers and companys detail resides will have its own
security to prevent unauthorized write/delete access. There is no restriction on read access for companys requirement. The use of email send by Company to Seeker is on the client Systems and thus is external to the System. Only the Admin will have physical access to the machine and the program on it.
xxiii
Index
Abstract..................................................xxii, xxiii add....................................................................xvi Articleiii, v, vi, vii, viii, ix, x, xi, xii, xiii, xiv, xv, xvii, xix, xxi, xxii, xxiii Author v, vii, viii, ix, x, xi, xv, xvi, xxi, xxii, xxiii Category...................................................xxi, xxii Company............................................................vi Database..................................iii, xiv, xvi, xix, xx Editor...............................................xiii, xvi, xxiii Field.................................................................xvi Form................................................................xvii Historical Society...............................................iii Online Journal.........................................v, vi, xix Reader............................iii, v, vi, vii, xiii, xiv, xv Review...............................................xii, xxi, xxii Reviewer...........v, xi, xii, xiii, xvi, xviii, xxi, xxii Security..........................................................xxiii Seeker......ii, iii, iv, v, vi, vii, viii, ix, xiv, xv, xvi, xvii, xxi, xxii, xxiii, 24 Status.......................................................xviii, xix User..................................................................xiii Web Publishing System.............................ii, iii, v
Experiment No . 03 Cost estimation of the project using COCOMO II model Theory: The COCOMO Model Barry Boehm introduced a hierarchy of software estimation models bearing the name COCOMO, for COnstructive COst MOdel. The original COCOMO model became one of the most widely used and discussed software cost estimation models in the industry. It has evolved into a more comprehensive estimation model, called COCOMO. Like its predecessor, COCOMO II is actually a hierarchy of estimation models that address the following areas: Application composition model. Used during the early stages of software engineering, when prototyping of user interfaces, consideration of software and system interaction, assessment of performance, and evaluation of technology maturity are paramount. Early design stage model. Used once requirements have been stabilized and basic software architecture has been established. Post-architecture-stage model. Used during the construction of the software. Like all estimation models for software, the COCOMO II models require sizing information. Three different sizing options are available as part of the model hierarchy: object points, function points, and lines of source code.
24
The COCOMO II application composition model uses object points and is illustrated in the following paragraphs. It should be noted that other, more
sophisticated estimation models (using FP and KLOC) are also available as part of COCOMO II. Like function points, the object point is an indirect software measure that is computed using counts of the number of (1) screens (at the user interface), (2) reports, and (3) components likely to be required to build the application. Each object instance (e.g., a screen or report) is classified into one of three complexity levels (i.e., simple, medium, or difficult) using criteria suggested by Boehm. In essence, complexity is a function of the number and source of the client and server data tables that are required to generate the screen or report and the number of views or sections presented as part of the screen or report. Once complexity is determined, the number of screens, reports, and components are weighted according to Table . The object point count is then determined by multiplying the original number of object instances by the weighting factor in Table 1 and summing to obtain a total object point count. When component-based development or general software reuse is to be applied, the percent of reuse (%reuse) is estimated and the object point count is adjusted: NOP = (object points) x [(100 _ %reuse)/100] where NOP is defined as new object points. To derive an estimate of effort based on the computed NOP value, a productivity rate must be derived. Table 2 presents the productivity rate PROD = NOP/person-month
for different levels of developer experience and development environment maturity. Once the productivity rate has been determined, an estimate of project effort can be derived as: estimated effort = NOP/PROD /* COCOMO Model */
#include<iostream.h> #include<conio.h> void main()

25
{ clrscr(); int screens,reports,software,views,sections; int servers,clients,total; int servers1,clients1,total1; int sv,rv,sfv,perreuse,effort; float op,nop,prod; cout<<"Enter no. of screens:"; cin>>screens; cout<<"Enter no. of views:"; cin>>views; cout<<"Enter no. of servers for screen:"; cin>>servers; cout<<"Enter no. of clients for screen:"; cin>>clients; cout<<"\nEnter no. of report:"; cin>>reports; cout<<"Enter no. of sections:"; cin>>sections; cout<<"Enter no. of servers for report:"; cin>>servers1; cout<<"Enter no. of clients for report:"; cin>>clients1; cout<<"\nEnter no. of software components:"; cin>>software; cout<<"\nEnter percentage reuse:"; cin>>perreuse; total=servers+clients; total1=servers1+clients1; if(views<3) { if(total<4) sv=1; else if(total<8) sv=1; else if(total>8) sv=2; } else if(views>=3 && views<=7)
26
{ if(total<4) sv=1; else if(total<8) sv=2; else if(total>8) sv=3; } else if(views>8) { if(total<4) sv=2; else if(total<8) sv=3; else if(total>8) sv=3; } if(sections<3) { if(total1<4) rv=2; else if(total1<8) rv=2; else if(total1>8) rv=5; } else if(sections>=3 && sections<=7) { if(total1<4) rv=2; else if(total1<8) rv=5; else if(total1>8) rv=8; } else if(sections>8) { if(total1<4) rv=5; else if(total1<8) rv=8; else if(total1>8) rv=8; }
27
cout<<"\nEnter complexity weight for software components"; cout<<"\nEnter 0 if no software component is present"; cout<<"\nEnter 1 for simple or medium"; cout<<"\nEnter 10 for difficult"; cout<<"\nEnter choice:"; cin>>sfv; cout<<"\nEnter productivitv"; cout<<"\nEnter 4 for very low"; cout<<"\nEnter 7 for low"; cout<<"\nEnter 13 for nominal"; cout<<"\nEnter 25 for high"; cout<<"\nEnter 50 for very high"; cout<<"\nEnter your choice:"; cin>>prod; if(sv==1) cout<<"\nComplexity for screen:SIMPLE"; if(sv==2) cout<<"\nComplexity for screen:MEDIUM"; if(sv==3) cout<<"\nComplexity for screen:DIFFICULT"; if(rv==2) cout<<"\nComplexity for report:SIMPLE"; if(rv==5) cout<<"\nComplexity for report:MEDIUM"; if(rv==8) cout<<"\nComplexity for report:DIFFICULT"; op=screens*sv+reports*rv+software*sfv; cout<<"\nOBJECT POINTS ARE:"<<op; nop=op-((100-perreuse)/100); cout<<"\nNEW OBJECT POINTS ARE:"<<nop; effort=nop/prod; cout<<"\nEFFORT:"<<effort; getch(); } /* OUTPUT Enter no. of screens:12 Enter no. of views:2 Enter no. of servers for screen:3 Enter no. of clients for screen:6
28
Enter no. of report:10 Enter no. of sections:2 Enter no. of servers for report:3 Enter no. of clients for report:6 Enter no. of software components:80 Enter percentage reuse:0 Enter complexity weight for software components Enter 0 if no software component is present Enter 1 for simple or medium Enter 10 for difficult Enter choice:1 Enter productivitv Enter 4 for very low Enter 7 for low Enter 13 for nominal Enter 25 for high Enter 50 for very high Enter your choice:7 Complexity for screen:MEDIUM Complexity for report:MEDIUM OBJECT POINTS ARE:154 NEW OBJECT POINTS ARE:153 EFFORT:21 */
29
Experiment No . 04 Develop a risk table for the project Theory:

SOFTWARE RISKS
Risk Characteristics are 1.Uncertaintythe risk may or may not happen; that is, there are no 100% probable risks. 2 Lossif the risk becomes a reality, unwanted consequences or losses will occur. When risks are analyzed, it is important to quantify the level of uncertainty and the degree of loss associated with each risk. To accomplish this, different categories of risks are considered. Project risks threaten the project plan. That is, if project risks become real, it is likely that project schedule will slip and that costs will increase. Project risks identify potential budgetary, schedule, personnel (staffing and organization), resource, customer, and requirements problems and their impact on a software project.project complexity, size, and the degree of structural uncertainty were also defined as project (and estimation) risk factors. Technical risks threaten the quality and timeliness of the software to be produced. If a technical risk becomes a reality, implementation may become difficult or impossible. Technical risks identify potential design, implementation, interface, verification, and maintenance problems. In addition, specification ambiguity, technical uncertainty, technical obsolescence, and "leading-edge" technology are also risk factors. Technical risks occur because the problem is harder to solve than we thought it would be. Business risks threaten the viability of the software to be built. Business risks often jeopardize the project or the product. Candidates for the top five business risks are (1) building a excellent product or system that no one really wants (market risk), (2) building a product that no longer fits into the overall business strategy for the company (strategic risk), (3) building a product that the sales force doesn't understand how to sell, (4) losing the support of senior management due to a change in focus or a change in people (management risk), and (5) losing budgetary or personnel commitment (budget risks). It is extremely important to note that simple categorization won't always work. Some risks are simply unpredictable in advance. Another general categorization of risks has been proposed by Charette . Known risks are those that can be uncovered after careful evaluation of the project plan, the business and technical environment in which the project is being developed, and other reliable information sources (e.g., unrealistic delivery date, lack of documented requirements or software scope, poor development environment). Predictable risks are extrapolated from past project experience (e.g., staff turnover, poor communication with the customer, dilution of staff effort as ongoing maintenance requests are serviced). Unpredictable risks are the joker in the deck. They can and do occur, but they are extremely difficult to identify in advance.
30
Risk Categories: Product sizerisks associated with the overall size of the software to be built or modified. Business impactrisks associated with constraints imposed by management or the marketplace. Customer characteristicsrisks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner. Process definitionrisks associated with the degree to which the software process has been defined and is followed by the development organization. Development environmentrisks associated with the availability and quality of the tools to be used to build the product. Technology to be builtrisks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system. Staff size and experiencerisks associated with the overall technical and project experience of the software engineers who will do the work. Risk Components and Drivers: The U.S. Air Force has written a pamphlet that contains excellent guidelines for software risk identification and abatement. The Air Force approach requires that the project manager identify the risk drivers that affect software risk components performance, cost, support, and schedule. In the context of this discussion, the risk components are defined in the following manner: Performance riskthe degree of uncertainty that the product will meet its requirements and be fit for its intended use. Cost riskthe degree of uncertainty that the project budget will be maintained. Support riskthe degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance. Schedule riskthe degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time. The impact of each risk driver on the risk component is divided into one of four impact categoriesnegligible, marginal, critical, or catastrophic. Referring to Figure below
31
Note: (1) The potential consequence of undetected software errors or faults. (2) The potential consequence if the desired outcome is not achieved. Developing a Risk Table: A risk table provides a project manager with a simple technique for risk projection.2 A sample risk table is illustrated in Figure below
32
Risk Information Sheet
33
Experiment No . 05 Use project management tool to schedule project plan. Scheduling of a software project does not differ greatly from scheduling of any multitask engineering effort. Therefore, generalized project scheduling tools and techniques can be applied with little modification to software projects. Program evaluation and review technique (PERT) and critical path method (CPM) [MOD83] are two project scheduling methods that can be applied to software development. Both techniques are driven by information already developed in earlier project planning activities: Estimates of effort A decomposition of the product function The selection of the appropriate process model and task set Decomposition of tasks Interdependencies among tasks may be defined using a task network. Tasks, sometimes called the project work breakdown structure (WBS), are defined for the product as a whole or for individual functions. Both PERT and CPM provide quantitative tools that allow the software planner to determine the critical paththe chain of tasks that determines the duration of the Timeline Charts When creating a software project schedule, the planner begins with a set of tasks (the work breakdown structure). If automated tools are used, the work breakdown is input as a task network or task outline. Effort, duration, and start date are then input for each task. In addition, tasks may be assigned to specific individuals. As a consequence of this input, a timeline chart, also called a Gantt chart, is generated. A timeline chart can be developed for the entire project. Alternatively, separate charts can be developed for each project function or for each individual working on the project. Figure 7.4 illustrates the format of a timeline chart. It depicts a part of a software project schedule that emphasizes the concept scoping task (Section 7.5) for a new wordprocessing (WP) software product. All project tasks (for concept scoping) are listed in the left-hand column. The horizontal bars indicate the duration of each task. When multiple bars occur at the same time on the calendar, task concurrency is implied. The diamonds indicate milestones. Once the information necessary for the generation of a timeline chart has been input, the majority of software project scheduling tools produce project tablesa tabular listing of all project tasks, their planned and actual start- and end-dates, and a variety of related information (Figure 7.5). Used in conjunction with the timeline chart, project tables enable the project manager to track progress.
34
An example timeline chart
An example project table
35
Experiment No . 06 Draw State Transition Diagram for the system
State diagrams are used to describe the behavior of a system. State diagrams describe all of the possible states of an object as events occur. Each diagram usually represents objects of a single class and track the different states of its objects through the system.
When to Use: State Diagrams

Use state diagrams to demonstrate the behavior of an object through many use cases of the system. Only use state diagrams for classes where it is necessary to understand the behavior of the object through the entire system. Not all classes will require a state diagram and state diagrams are not useful for describing the collaboration of all objects in a use case. State diagrams are other combined with other diagrams such as interaction diagrams and activity diagrams. 1
How to Draw: State Diagrams

State diagrams have very few elements. The basic elements are rounded boxes representing the state of the object and arrows indicting the transition to the next state. The activity section of the state symbol depicts what activities the object will be doing while it is in that state.
All state diagrams being with an initial state of the object. This is the state of the object when it is created. After the initial state the object begins changing states. Conditions based on the activities can determine what the next state the object transitions to.
36
Below is an example of a state diagram might look like for an Order object. When the object enters the Checking state it performs the activity "check items." After the activity is completed the object transitions to the next state based on the conditions [all items available] or [an item is not available]. If an item is not available the order is canceled. If all items are available then the order is dispatched. When the object transitions to the Dispatching state the activity "initiate delivery" is performed. After this activity is complete the object transitions again to the Delivered state.
State diagrams can also show a super-state for the object. A super-state is used when many transitions lead to the a certain state. Instead of showing all of the transitions from each state to the redundant state a super-state can be used to show that all of the states inside of the superstate can transition to the redundant state. This helps make the state diagram easier to read.
37
The diagram below shows a super-state. Both the Checking and Dispatching states can transition into the Canceled state, so a transition is shown from a super-state named Active to the state Cancel. By contrast, the state Dispatching can only transition to the Delivered state, so we show an arrow only from the Dispatching state to the Delivered state.
38
Experiment No . 07 Draw Activity Diagram for the system

Activity diagrams describe the workflow behavior of a system. Activity diagrams are similar to state diagrams because activities are the state of doing something. The diagrams describe the state of activities by showing the sequence of activities performed. Activity diagrams can show activities that are conditional or parallel.
When to Use: Activity Diagrams

Activity diagrams should be used in conjunction with other modeling techniques such as interaction diagrams and state diagrams. The main reason to use activity diagrams is to model the workflow behind the system being designed. Activity Diagrams are also useful for: analyzing a use case by describing what actions need to take place and when they should occur; describing a complicated sequential algorithm; and modeling applications with parallel processes. 1 However, activity diagrams should not take the place of interaction diagrams and state diagrams. Activity diagrams do not give detail about how objects behave or how objects collaborate. 1
How to Draw: Activity Diagrams

Activity diagrams show the flow of activities through the system. Diagrams are read from top to bottom and have branches and forks to describe conditions and parallel activities. A fork is used when multiple activities are occurring at the same time. The diagram below shows a fork after activity1. This indicates that both activity2 and activity3 are occurring at the same time. After activity2 there is a branch. The branch describes what activities will take place based on a set of conditions. All branches at some point are followed by a merge to indicate the end of the conditional behavior started by that branch. After the merge all of the parallel activities must be combined by a join before transitioning into the final activity state.
39
Below is a possible activity diagram for processing an order. The diagram shows the flow of actions in the system's workflow. Once the order is received the activities split into two parallel sets of activities. One side fills and sends the order while the other handles the billing. On the Fill Order side, the method of delivery is decided conditionally. Depending on the condition either the Overnight Delivery activity or the Regular Delivery activity is performed. Finally the parallel activities combine to close the order.
40
41
Experiment No . 08 Draw Data Flow Diagrams for the system The data flow diagram enables the software engineer to develop models of the information domain and functional domain at the same time. As the DFD is refined into greater levels of detail, the analyst performs an implicit functional decomposition of the system, thereby accomplishing the fourth operational analysis principle for function. At the same time, the DFD refinement results in a corresponding refinement of data as it moves through the processes that embody the application. A few simple guidelines can aid immeasurably during derivation of a data flow diagram: (1) the level 0 data flow diagram should depict the software/system as a single bubble; (2) primary input and output should be carefully noted; (3) refinement should begin by isolating candidate processes, data objects, and stores to be represented at the next level; (4) all arrows and bubbles should be labeled with meaningful names; (5) information flow continuity must be maintained from level to level, and (6) one bubble at a time should be refined. There is a natural tendency to overcomplicate the data flow diagram. This occurs when the analyst attempts to show too much detail too early or represents procedural aspects of the software in lieu of information flow. Considering the SafeHome product, a level 0 DFD for the system is shown in Figure 12.20. The primary external entities (boxes) produce information for use by the system and consume information generated by the system. The labeled arrows represent data objects or data object type hierarchies. For example, user commands and data encompasses all configuration commands, all activation/deactivation
Figure :Context-level DFD for SafeHome
commands, all miscellaneous interactions, and all data that are entered to qualify or expand a command. The level 0 DFD is now expanded into a level 1 model. But how do we proceed? A simple, yet effective approach is to perform a "grammatical parse" on the processing narrative that describes the context level bubble. That is, we isolate all nouns (and noun phrases) and verbs (and verb phrases) in the SafeHome narrative originally presented in Chapter 11. To illustrate, we again reproduce the processing narrative underlining the first occurrence of all nouns and italicizing the first occurrence of all verbs.3 SafeHome software enables the homeowner to configure the security system when it is installed,
42
monitors all sensors connected to the security system, and interacts with the homeowner through a keypad and function keys contained in the SafeHome control panel shown in Figure 11.2. During installation, the SafeHome control panel is used to "program" and configure the system. Each sensor is assigned a number and type, a master password is programmed for arming and disarming the system, and telephone number(s) are input for dialing when a sensor event occurs. When a sensor event is recognized, the software invokes an audible alarm attached to the system. After a delay time that is specified by the homeowner during system configuration activities, the software dials a telephone number of a monitoring service, provides information about the location, reporting the nature of the event that has been detected. The telephone number will be redialed every 20 seconds until telephone connection is obtained. All interaction with SafeHome is managed by a user-interaction subsystem that reads input provided through the keypad and function keys, displays prompting messages on the LCD display, displays system status information on the LCD display. Keyboard interaction takes the following form . . . Referring to the "grammatical parse," a pattern begins to emerge. All verbs are SafeHome processes; that is, they may ultimately be represented as bubbles in a sub-
Figure : Level 1 DFD for SafeHome
43
sequent DFD. All nouns are either external entities (boxes), data or control objects (arrows), or data stores (double lines). Note further that nouns and verbs can be attached to one another (e.g., sensor is assigned number and type). Therefore, by performing a grammatical parse on the processing narrative for a bubble at any DFD level, we can generate much useful information about how to proceed with the refinement to the next level. Using this information, a level 1 DFD is shown in Figure 12.21. The context level process shown in Figure 12.20 has been expanded into six processes derived from an examination of the grammatical parse. Similarly, the information flow between processes at level 1 has been derived from the parse. It should be noted that information flow continuity is maintained between levels 0 and 1. Elaboration of the content of inputs and output at DFD levels 0 and 1 is postponed until Section 12.7. The processes represented at DFD level 1 can be further refined into lower levels. For example, the process monitor sensors can be refined into a level 2 DFD as shown in Figure 12.22. Note once again that information flow continuity has been maintained between levels.
Figure :Level 2 DFD that refines the monitor sensors process The refinement of DFDs continues until each bubble performs a simple function. That is, until the process represented by the bubble performs a function that would be easily implemented as a program component.
44
Experiment No . 09 Architectural Design for the system Structured design is often characterized as a data flow-oriented design method because it provides a convenient transition from a data flow diagram to software architecture.7 The transition from information flow (represented as a DFD) to program structure is accomplished as part of a six-step process: (1) the type of information flow is established; (2) flow boundaries are indicated; (3) the DFD is mapped into program structure; (4) control hierarchy is defined; (5) resultant structure is refined using design measures and heuristics; and (6) the architectural description is refined and elaborated.The type of information flow is the driver for the mapping approach required in step 3. In the following sections we examine two flow types. Transform Flow Recalling the fundamental system model (level 0 data flow diagram), information must enter and exit software in an "external world" form. For example, data typed on a keyboard, tones on a telephone line, and video images in a multimedia application are all forms of external world information. Such externalized data must be converted into an internal form for processing. Information enters the system along paths that transform external data into an internal form. These paths are identified as incoming flow. At the kernel of the software, a transition occurs. Incoming data are passed through a transform center and begin to move along paths that now lead "out" of the software. Data moving along these paths are called outgoing flow. The overall flow of data occurs in a sequential manner and follows one, or only a few, "straight line" paths.8 When a segment of a data flow diagram exhibits these characteristics, transform flow is present.
Fig: Transaction Flow
45
Transaction Flow The fundamental system model implies transform flow; therefore, it is possible to characterize all data flow in this category. However, information flow is often characterized by a single data item, called a transaction, that triggers other data flow along one of many paths. When a DFD takes the form shown in Figure 14.4, transaction flow is present. Transaction flow is characterized by data moving along an incoming path that converts external world information into a transaction. The transaction is evaluated and, based on its value, flow along one of many action paths is initiated. The hub of information flow from which many action paths emanate is called a transaction center. It should be noted that, within a DFD for a large system, both transform and transaction flow may be present. For example, in a transaction-oriented flow, information flow along an action path may have transform flow characteristics.
TRANSFORM MAPPING
Transform mapping is a set of design steps that allows a DFD with transform flow characteristics to be mapped into a specific architectural style. Design Steps: Step 1. Review the fundamental system model. The fundamental system model encompasses the level 0 DFD and supporting information. In actuality, the design step begins with an evaluation of both the System Specification and the Software Requirements Specification. Both documents describe information flow and structure at the software interface. Step 2. Review and refine data flow diagrams for the software. Information obtained from analysis models contained in the Software Requirements Specification is refined to produce greater detail. Step 3. Determine whether the DFD has transform or transaction flow characteristics. In general, information flow within a system can always be represented as transform. However, when an obvious transaction characteristic (Figure 14.4) is encountered, a different design mapping is recommended. In this step, the designer selects global (softwarewide) flow characteristics based on the prevailing nature of the DFD. In addition, local regions of transform or transaction flow are isolated. These subflows can be used to refine program architecture derived from a global characteristic described previously. Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries. In the preceding section incoming flow was described as a path in which information is converted from external to internal form; outgoing flow converts from internal to external form. Incoming and outgoing flow boundaries are open to interpretation. That is, different designers may select slightly different points in the flow as boundary locations. In fact, alternative design solutions can be derived by varying the placement of flow boundaries. Although care should be taken when boundaries are
46
selected, a variance of one bubble along a flow path will generally have little impact on the final program structure. Step 5. Perform "first-level factoring." Program structure represents a top-down distribution of control. Factoring results in a program structure in which top-level modules perform decision making and low-level modules perform most input, computation, and output work. Middle-level modules perform some control and do moderate amounts of work. When transform flow is encountered, a DFD is mapped to a specific structure (a call and return architecture) that provides control for incoming, transform, and outgoing information processing. Step 6. Perform "second-level factoring." Second-level factoring is accomplished by mapping individual transforms (bubbles) of a DFD into appropriate modules within the architecture. Beginning at the transform center boundary and moving outward along incoming and then outgoing paths, transforms are mapped into subordinate levels of the software structure. Factoring is again accomplished by moving outward from the transform center boundary on the incoming flow side. Step 7. Refine the first-iteration architecture using design heuristics for improved software quality. A first-iteration architecture can always be refined by applying concepts of module independence (Chapter 13). Modules are exploded or imploded to produce sensible factoring, good cohesion, minimal coupling, and most important, a structure that can be implemented without difficulty, tested without confusion, and maintained without grief.
TRANSACTION MAPPING
In many software applications, a single data item triggers one or a number of information flows that effect a function implied by the triggering data item. The data item is called a transaction. Design Steps The design steps for transaction mapping are similar and in some cases identical to steps for transform mapping Step 1. Review the fundamental system model. Step 2. Review and refine data flow diagrams for the software. Step 3. Determine whether the DFD has transform or transaction flow characteristics. Steps 1, 2, and 3 are identical to corresponding steps in transform mapping. Step 4. Identify the transaction center and the flow characteristics along each of the action paths. The location of the transaction center can be immediately discerned from the DFD. The transaction center lies at the origin of a number of actions paths that flow radially from it. Step 5. Map the DFD in a program structure amenable to transaction processing. Transaction flow is mapped into an architecture that contains an incoming branch and a dispatch branch. The structure of the incoming branch is developed in much the same way as transform mapping. Starting at the transaction center, bubbles along the incoming path are mapped into modules. The structure of the dispatch branch contains a dispatcher
47
module that controls all subordinate action modules. Each action flow path of the DFD is mapped to a structure that corresponds to its specific flow characteristics. Step 6. Factor and refine the transaction structure and the structure of each action path. Each action path of the data flow diagram has its own information flow characteristics. We have already noted that transform or transaction flow may be encountered. The action path-related "substructure" is developed using the design steps discussed in this and the preceding section. Step 7. Refine the first-iteration architecture using design heuristics for improved software quality. This step for transaction mapping is identical to the corresponding step for transform mapping. In both design approaches, criteria such as module independence, practicality (efficacy of implementation and test), and maintainability must be carefully considered as structural modifications are proposed.
48
Experiment No . 10 Black-Box Testing Black-box testing, also called behavioral testing, focuses on the functional requirements of the software. That is, black-box testing enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program. Blackbox testing is not an alternative to white-box techniques. Rather, it is a complementary approach that is likely to uncover a different class of errors than white-box methods. Black-box testing attempts to find errors in the following categories: (1) incorrect or missing functions, (2) interface errors, (3) errors in data structures or external data base access, (4) behavior or performance errors, and (5) initialization and termination errors.Unlike white-box testing, which is performed early in the testing process, blackbox testing tends to be applied during later stages of testing. Because black-box testing purposely disregards control structure, attention is focused on the information domain. Tests are designed to answer the following questions: How is functional validity tested? How is system behavior and performance tested? What classes of input will make good test cases? Is the system particularly sensitive to certain input values? How are the boundaries of a data class isolated? What data rates and data volume can the system tolerate? What effect will specific combinations of data have on system operation? By applying black-box techniques, we derive a set of test cases that satisfy the following criteria : (1) test cases that reduce, by a count that is greater than one, the number of additional test cases that must be designed to achieve reasonable testing and (2) test cases that tell us something about the presence or absence of classes of errors, rather than an error associated only with the specific test at hand.
49
(A) Graph notation
(B) Simple example
The symbolic representation of a graph is shown in Figure A. Nodes are represented as circles connected by links that take a number of different forms. A directedlink represented by an arrow) indicates that a relationship moves in only one direction. A bidirectional link, also called a symmetric link, implies that the relationship applies in both directions. Parallel links are used when a number of different relationships are established between graph nodes. Equivalence Partitioning Equivalence partitioning is a black-box testing method that divides the input domain of a program into classes of data from which test cases can be derived. An ideal test case single-handedly uncovers a class of errors (e.g., incorrect processing of all character data) that might otherwise require many cases to be executed before the general error is observed. Equivalence partitioning strives to define a test case that uncovers classes of errors, thereby reducing the total number of test cases that must be developed. Test case design for equivalence partitioning is based on an evaluation of equivalence classes for an input condition. Using concepts introduced in the preceding section, if a set of objects can be linked by relationships that are symmetric, transitive, and reflexive, an equivalence class is present. An equivalence class represents a set of valid or invalid states for input conditions. Typically, an input condition is either a specific numeric
50
value, a range of values, a set of related values, or a Boolean condition. Equivalence classes may be defined according to the following guidelines: 1. If an input condition specifies a range, one valid and two invalid equivalence classes are defined. 2. If an input condition requires a specific value, one valid and two invalid equivalence classes are defined. 3. If an input condition specifies a member of a set, one valid and one invalid equivalence class are defined. 4. If an input condition is Boolean, one valid and one invalid class are defined. As an example, consider data maintained as part of an automated banking application. The user can access the bank using a personal computer, provide a six-digit password, and follow with a series of typed commands that trigger various banking functions. During the log-on sequence, the software supplied for the banking application accepts data in the form area codeblank or three-digit number prefixthree-digit number not beginning with 0 or 1 suffixfour-digit number passwordsix digit alphanumeric string commandscheck, deposit, bill pay, and the like The input conditions associated with each data element for the banking application can be specified as area code: Input condition, Booleanthe area code may or may not be present. Input condition, rangevalues defined between 200 and 999, with specific exceptions. prefix: Input condition, rangespecified value >200 Input condition, valuefour-digit length password: Input condition, Booleana password may or may not be present. Input condition, valuesix-character string. command: Input condition, setcontaining commands noted previously. Applying the guidelines for the derivation of equivalence classes, test cases for each input domain data item can be developed and executed. Test cases are selected so that the largest number of attributes of an equivalence class are exercised at once. Boundary Value Analysis For reasons that are not completely clear, a greater number of errors tends to occur at the boundaries of the input domain rather than in the "center." It is for this reason that Boundary value analysis (BVA) has been developed as a testing technique. Boundary value analysis leads to a selection of test cases that exercise bounding values. Boundary value analysis is a test case design technique that complements equivalence partitioning. Rather than selecting any element of an equivalence class, BVA leads to the selection of test cases at the "edges" of the class. Rather than focusing solely on input conditions, BVA derives test cases from the output domain as well. Guidelines for BVA are similar in many respects to those provided for equivalence partitioning:
51
1. If an input condition specifies a range bounded by values a and b, test cases should be designed with values a and b and just above and just below a and b. 2. If an input condition specifies a number of values, test cases should be developed that exercise the minimum and maximum numbers. Values just above and below minimum and maximum are also tested. 3. Apply guidelines 1 and 2 to output conditions. For example, assume that a temperature vs. pressure table is required as output from an engineering analysis program. Test cases should be designed to create an output report that produces the maximum (and minimum) allowable number of table entries. 4. If internal program data structures have prescribed boundaries (e.g., an array has a defined limit of 100 entries), be certain to design a test case to exercise the data structure at its boundary. Most software engineers intuitively perform BVA to some degree. By applying these guidelines, boundary testing will be more complete, thereby having a higher likelihood for error detection.
52
Experiment No . 11 White-Box Testing WHITE-BOX TESTING White-box testing, sometimes called glass-box testing, is a test case design method that uses the control structure of the procedural design to derive test cases. Using white-box testing methods, the software engineer can derive test cases that (1) guarantee that all independent paths within a module have been exercised at least once, (2) exercise all logical decisions on their true and false sides, (3) execute all loops at their boundaries and within their operational bounds, and (4) exercise internal data structures to ensure their validity. BASIS PATH TESTING Basis path testing is a white-box testing technique first proposed by Tom McCabe. The basis path method enables the test case designer to derive a logical complexity measure of a procedural design and use this measure as a guide for defining a basis set of execution paths. Test cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one time during testing. Flow Graph Notation Before the basis path method can be introduced, a simple notation for the representation of control flow, called a flow graph (or program graph) must be introduced. The flow graph depicts logical control flow using the notation illustrated in Figure 17.1. Each structured construct (Chapter 16) has a corresponding flow graph symbol. To illustrate the use of a flow graph, we consider the procedural design representation in Figure 17.2A. Here, a flowchart is used to depict program control structure.
Fig. Flow graph notation
Figure 17.2B maps the flowchart into a corresponding flow graph (assuming that no compound conditions are contained in the decision diamonds of the flowchart). Referring to Figure 17.2B, each circle, called a flow graph node, represents one or more procedural statements. A sequence of process boxes and a decision diamond can map into a single node. The arrows on the flow graph, called edges or links, represent flow of control and are analogous to flowchart arrows. An edge must terminate at a node, even if the node does not represent any procedural statements (e.g., see the symbol for the if-then-else construct). Areas bounded by edges and nodes are called regions. When counting
53
regions, we include the area outside the graph as a region.4 When compound conditions are encountered in a procedural design, the generation of a flow graph becomes slightly more complicated. A compound condition occurs when one or more Boolean operators (logical OR, AND, NAND, NOR) is present in a conditional statement. Referring to Figure 17.3, the PDL segment translates into the flow graph shown. Note that a separate node is created for each of the conditions a and b in the statement IF a OR b. Each node that contains a condition is called a predicate node and is characterized by two or more edges emanating from it. Cyclomatic Complexity Cyclomatic complexity is a software metric that provides a quantitative measure of the logical complexity of a program. When used in the context of the basis path testing method, the value computed for cyclomatic complexity defines the number of independent paths in the basis set of a program and provides us with an upper bound for the number of tests that must be conducted to ensure that all statements have been executed at least once.
54
An independent path is any path through the program that introduces at least one new set of processing statements or a new condition. When stated in terms of a flow
Fig. Flowchart, (A) and flow graph (B)
55
Fig. Compound logic
graph, an independent path must move along at least one edge that has not been traversed before the path is defined. For example, a set of independent paths for the flow graph illustrated in Figure 17.2B is path 1: 1-11 path 2: 1-2-3-4-5-10-1-11 path 3: 1-2-3-6-8-9-10-1-11 path 4: 1-2-3-6-7-9-10-1-11 Note that each new path introduces a new edge. The path 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 is not considered to be an independent path because it is simply a combination of already specified paths and does not traverse any new edges. Paths 1, 2, 3, and 4 constitute a basis set for the flow graph in Figure 17.2B. That is, if tests can be designed to force execution of these paths (a basis set), every statement in the program will have been guaranteed to be executed at least one time and every condition will have been executed on its true and false sides. It should be noted that the basis set is not unique. In fact, a number of different basis sets can be derived for a given procedural design. How do we know how many paths to look for? The computation of cyclomatic complexity provides the answer. Cyclomatic complexity has a foundation in graph theory and provides us with an extremely useful software metric. Complexity is computed in one of three ways: 1. The number of regions of the flow graph correspond to the cyclomatic complexity. 2. Cyclomatic complexity, V(G), for a flow graph, G, is defined as V(G) = E _ N + 2
56
where E is the number of flow graph edges, N is the number of flow graph nodes. 3. Cyclomatic complexity, V(G), for a flow graph, G, is also defined as V(G) = P + 1 where P is the number of predicate nodes contained in the flow graph G . Referring once more to the flow graph in Figure 17.2B, the cyclomatic complexity can be computed using each of the algorithms just noted: 1. The flow graph has four regions. 2. V(G) = 11 edges _ 9 nodes + 2 = 4. 3. V(G) = 3 predicate nodes + 1 = 4. Therefore, the cyclomatic complexity of the flow graph in Figure 17.2B is 4. More important, the value for V(G) provides us with an upper bound for the number of independent paths that form the basis set and, by implication, an upper bound on the number of tests that must be designed and executed to guarantee coverage of all program statements. Deriving Test Cases The basis path testing method can be applied to a procedural design or to source code. In this section, we present basis path testing as a series of steps. The procedure average, depicted in PDL in Figure 17.4, will be used as an example to illustrate each step in the test case design method. Note that average, although an extremely simple algorithm, contains compound conditions and loops. The following steps can be applied to derive the basis set: 1. Using the design or code as a foundation, draw a corresponding flow graph. A flow graph is created using the symbols and construction rules presented in Section 16.4.1. Referring to the PDL for average in Figure 17.4, a flow graph is created by numbering those PDL statements that will be mapped into corresponding flow graph nodes. The corresponding flow graph is in Figure 17.5. 2. Determine the cyclomatic complexity of the resultant flow graph. The cyclomatic complexity, V(G), is determined by applying the algorithms described in Section 17.5.2. It should be noted that V(G) can be determined without developing a flow graph by counting all conditional statements in the PDL (for the procedure average, compound conditions count as two) and adding 1. Referring to Figure 17.5, V(G) = 6 regions V(G) = 17 edges _ 13 nodes + 2 = 6 V(G) = 5 predicate nodes + 1 = 6
57
3. Determine a basis set of linearly independent paths. The value of V(G) provides the number of linearly independent paths through the program control structure. In the case of procedure average, we expect to specify six paths: path 1: 1-2-10-11-13 path 2: 1-2-10-12-13 path 3: 1-2-3-10-11-13 path 4: 1-2-3-4-5-8-9-2-. . . path 5: 1-2-3-4-5-6-8-9-2-. . . path 6: 1-2-3-4-5-6-7-8-9-2-. . . The ellipsis (. . .) following paths 4, 5, and 6 indicates that any path through the remainder of the control structure is acceptable. It is often worthwhile to identify predicate nodes as an aid in the derivation of test cases. In this case, nodes 2, 3, 5, 6, and 10 are predicate nodes. 4. Prepare test cases that will force execution of each path in the basis set. Data should be chosen so that conditions at the predicate nodes are appropriately set as each path is tested. Test cases that satisfy the basis set just described are
58
Flow graph for the procedure average Path 1 test case: value(k) = valid input, where k < i for 2 i 100 value(i) = _999 where 2 i 100 Expected results: Correct average based on k values and proper totals. Note: Path 1 cannot be tested stand-alone but must be tested as part of path 4, 5, and 6 tests. Path 2 test case: value(1) = _999 Expected results: Average = _999; other totals at initial values. Path 3 test case: Attempt to process 101 or more values. First 100 values should be valid. Expected results: Same as test case 1. Path 4 test case: value(i) = valid input where i < 100 value(k) < minimum where k < i Expected results: Correct average based on k values and proper totals. Path 5 test case: value(i) = valid input where i < 100 value(k) > maximum where k <= i
59
Expected results: Correct average based on n values and proper totals. Path 6 test case: value(i) = valid input where i < 100 Expected results: Correct average based on n values and proper totals. Each test case is executed and compared to expected results. Once all test cases have been completed, the tester can be sure that all statements in the program have been executed at least once. It is important to note that some independent paths (e.g., path 1 in our example) cannot be tested in stand-alone fashion. That is, the combination of data required to traverse the path cannot be achieved in the normal flow of the program. In such cases, these paths are tested as part of another path test.
60
61

Sr. No - Topics of Coverage

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sr. No - Topics of Coverage

Uploaded by

Copyright:

Available Formats

Sr. No .

Experiment No . 01 Detailed Problem Statement

Experiment No . 02 SRS in IEEE format for the project

Software Requirements Specification for Online Recruitment System (ORS)

1.0. Introduction 1.1. Purpose

1.2. Scope of Project

1.5. Overview of Document

2.0. Overall Description 2.1 System Environment

Figure 1 - System Environment

2.2 Functional Requirements Specification

Seeker Use Case

Use case: Create new account Diagram:

Use case: Update Rsum Diagram:

Xref: Section 3.2.2, Update resume

Use case: Renew account Diagram:

Xref: Section 3.2.3, Renewing account

Use case: View requirements Diagram:

Xref: Section 3.2.4, View requirement

Use case: Check Company list Diagram:

Xref: Section 3.2.5, Check company list

Use case: Send Rsum To Company Diagram:

Company Use Case

Use case: Putting requirement Diagram:

Use case: Selecting candidate Diagram:

Xref: Section 3.2.8, select candidate Admin Use Case

Use case: Control overall System Diagram:

2.3 User Characteristics

The detailed look of these pages is discussed in section 3.2 below.

2.4 Non-Functional Requirements

3.0. Requirements Specification 3.1 External Interface Requirements

3.2 Functional Requirements

3.2.1 Create new account

Use Case Name XRef Trigger Precondition Basic Path

Alternative Paths Post Condition Exception Paths Other

3.2.2 Update Rsum

Alternative Paths Post Condition Exception Paths Other

3.2.3 Renewing account

Trigger Precondition Basic Path

Alternative Paths Post Condition Exception Paths Other

3.2.4 View requirements

Alternative Paths Post Condition Exception Paths Other

3.2.5 Check Company list

Alternative Paths Post Condition Exception Paths Other

3.2.6 Send Rsum to Company

3.2.7 Put requirements

Post Condition Exception Paths Other

3.2.8 Select candidate

Alternative Paths Post Condition Exception Paths Other

3.2.9 Control overall System

3.2.10 Provide periodic reports

Alternative Paths Post Condition Exception Paths Other

3.2.11 Creating account for the Companies

Alternative Paths Post Condition Exception Paths Other

3.3 Detailed Non-Functional Requirements

Figure 2 - Logical Structure of Online Recruitment System

The data descriptions of each of these data entities are as follows:

This is filled with the help of Automatic resume Builder.

Description Company entity. The qualification

Comment 1 to 1 relationship the

experience domain platform language

Text Text Text Text

the help Requirement