Department of Computer Science & Engineering

Practical File

SUBJECT: SOFTWARE ENGINEERING LAB

[BTCS 506-18]

B.Tech – 5th Semester

[Batch 2019-23]

CGC College of Engineering

Landran, Mohali-140307

Submitted To: Submitted By:

Ms. Gurleen Kaur Harsh Jindal
Roll no: 1914282
Group – 5 ‘B’
 Index

S.No Name Page No

1 To Create Gantt charts from work breakdown structure 3-4

2 To add resource management to an existing OpenProj project 5-6

to predict total project cost.

3 To establish deadline and milestones to track the progress of 7

project.

4 Study and usage of OpenProj or similar software to draft a 8-11

project plan.

5 Study and usage of Openproj to track the progress of a project. 12-14

6 P Preparation of Software Requirement Specification Document 15-23

and Design Documents.

7 Preparation of Software Testing phase document of some 24-30

problem.

8 To perform unit testing and integration testing. 31-34

9 To perform various white box and black box testing 35- 39

techniques.

10 Preparation of the Software Configuration management and 40-43

Risk management related documents.

11 Study and usage of any Design phase CASE tool. 44-46

 Experiment No.1

Title: To Create Gantt charts from work breakdown structure

S/W Requirements: OpenProj S/W Edition 1.4
Theory:

Creating a New Project

1. Start OpenProj.
2. Click through the Tips or Donate dialog. Sometimes these dialogs are not shown.
3. On the Welcome to OpenProj dialog, make sure Create Project is selected and click OK.
4. The new project dialog appears. Enter a project name and your name as manager. Verify Forward
scheduling is checked. Enter some comments in the if desired. Then click OK

Entering a Work Breakdown Structure

OpenProj starts with a worksheet for entering tasks from the work breakdown structure. Perform the
following steps to enter tasks:
1.Move the division bar (dotted bar with two arrows at the top) between the form and chart as
necessary for entering tasks.
2. In the Name column, enter the first task of Place Order
3. Hit the down arrow and enter the other task names of Receive Parts, Build Project, and Ship to
Customer.
4. Move the cursor to the Predecessors column.
5. For tasks 2-4, enter the prior task (1-3) as a predecessor. Again, use down arrow to move among
rows. Note OpenProj automatically adjusts start and stop dates for the dependent tasks.
6. Move the dividing bar back so the Gantt chart is visible. Use the zoom controls to adjust the chart
to a suitable time scale.

The following figure is a specimen of the work breakdown structure form:

 Fig. 1.1 Work Breakdown Structure

The following figure is a specimen of the resulting Gantt chart:

Fig. 1.2 Gantt chart

Result: The following figure is a specimen of the resulting Gantt chart

Outcome: Students will learn how to make Gantt Chart using work breakdown structure.
 Experiment No.2

Title: To add resource management to an existing OpenProj project to predict total project cost.
S/W Requirements: OpenProj S/W Edition 1.4
Theory:

Entering a Resource Breakdown Structure

Perform the following steps to create resources and assign them to tasks:
1.Click the Resource button, fourth from top left, to show the resources editor.
2. In the Name column, enter Designer, Coder, and Tester row by row.
Assigning Resources to Tasks
There are two ways to assign a resource to a task: directly specify the assignment in the resource
breakdown structure or use the assign resource editor in the work breakdown structure.
a)Direct Assignment:
To manually assign tasks, edit the RBS column by entering a comma separated list of task identifiers.
Assign the Designer to the first task, the Coder to all coding tasks, and the Tester to all testing tasks
as shown in the following figure :

Fig. 2.1 Gantt chart

The task identifiers entered in the RBS column must match the work breakdown structure identifiers.
b) Assignment via Work Breakdown Structure:
Resources may be assigned to tasks in the work breakdown structure editor. First, click on the desired
task and then use of Assign Resource under the tools menu. A dialog similar to this appears :
 Fig. 2.2 Assignment via Work Breakdowm Structure
i)To perform the assignment, click the resource name, then the Assign button.
ii)To perform another assignment, the work breakdown structure selection to a different task in and
this assignment document will switch to the new selection automatically.
Adding Cost Parameters
Perform the following steps to add cost estimation to the resource breakdown structure:
1. Slide the RBS worksheet to the left so that the Standard Rate and Overtime Rate columns are visible.
2. Enter some per hour Standard Rate labor charges for the Designer, Coder, and Tester. Use a guess
based on the local going rates.
3. For all resources, add a 25% higher rate in the Overtime Rate column.
4. Browse all of the reports in the OpenProj's vertical toolbar to see how the rates used in the RBS are
applied to the entire project.

Result: The total project Cost is predicted.

Outcome: Students will learn how to predict the total cost of the project.
 Experiment No.3

Title: To establish deadline and milestones to track the progress of project.

S/W Requirements: OpenProj S/W Edition 1.4
Theory:

I)Establishing Milestones
Milestones are important completion or decision points in a project that are often tied to a deliverable.
The start and finish of a phase should always be defined by a milestone. Milestones represent project
status (not activities); thereby, they will have date values but as a rule, they will have no duration.
i) Enter a new task into the schedule (e.g. Design Complete) and give this task a duration of 0 (zero).
The task will now appear in the Gantt chart as a black diamond shape.
ii)Set the milestones of a phase to be at the same indent level as the Summary Task (not the indented
task level), and then link the milestones directly to the Summary Task. Dependencies can only be set
between elements on the same indent level.
iii) In the next step, we will create start milestones and end milestones for each phase. We need to link
the end-milestones of the previous phase to the start milestones of the next phase.
iv) Now the project timeline is represented by a sequence of phases. The final milestones represent
the results of each phase, the deliverable. The tasks within the phases describe the activities which are
necessary to produce the phase result or deliverable.

II)Setting Deadlines
Deadlines are used to monitor the progress of individual tasks. A deadline set for a particular date will
trigger a notification as soon as that date slips and an icon in the indicator column is displayed.
Deadlines also appear in the Gantt chart as yellow diamonds.
To set a deadline:
_ Select the task in Name column for which you’d like to apply a deadline.
_ Open the task information Dialog Box by double-clicking the task name, or click the icon.
_ Select the Advanced tab and enter the desired date into the Deadline: field.
_ Confirm your entry and click Close.

Result: The progress of the project is tracked.

Outcome: Students will learn how to track the progress of the Project.
 Experiment No.4
Aim: - Study and usage of OpenProj or similar software to draft a project plan.
Introduction: - Project managers can use OpenProj, a free task tracking application, when
creating effective plans. OpenProj delivers functionality that rivals the capabilities of
commercial software. This can save thousands of dollars in startup costs. Of course, saving a
lot of money can be foolish if the required tasks can't be done. This is not the case with
OpenProj. Luckily the OpenProj application gives managers a full set of tools that aretypically
used to track projects. Useful aids such as critical path analysis, resource tracking and task
comments are all present in OpenProj. The tool is ideal for simple project management but is
capable of larger efforts as well.

Fig no: -1

For the purposes of the example project plan, the following assumptions are made:
-The OpenProj software has already been installed and correctly configured on a workstation
with an attached printer
- The goal is to launch a new marketing effort in 6 months, called "Anganwadi"
- There are three full-time staff resources, including the manager
- Budget is not a consideration
- Schedule is the primary consideration
- The target implementation date is 6 months away but is not an absolute fixed date

Step 1: Create the project plan shell:

The first step is to use OpenProj to identify the basic parameters. The manager starts the
OpenProj application and presses the "Create Project" button. The file is named,
("Anganwadi"), and a starting date is given. You can forward schedule which is the default.
This allows you to enter the required tasks and OpenProj will calculate a completion date. If
required, you can schedule a finish date and have OpenProj work backwards for you. This
alternate method works best if there is a hard drop-dead date, such as a launch date. The project
manager can also add initial project notes. These might refer to locations of phase initiation
documentation or other optional information.
 Fig no: -2

Step 2: Identify the project resources

Use the resources view to enter the particulars of all of the project team. The names and roles
of the team members can be specified. If required, you can enter hourly rates, overtime and
availability information for each team member. For this example, three 100% resources will
be entered.

Fig no: -3

Step 3: Identify the high-level tasks

For this example, the project is similar to an earlier effort that was completed successfully. That
work required tasks for initiation, research, contracting, development and launch. The project
manager enters these tasks into the Gantt view of OpenProj. The duration estimates
are based on the values previously seen for similar tasks. There is no ordering of tasks or
dependencies. The raw Gantt list is below.

Notice that the task "Application Development" is shown with a red duration bar while all other
tasks have blue bars. This task is identified as the project critical path. It is the longest running
task in the project. Since all tasks default to the start date of the project, the analysisof the
critical path is quite premature at this time. The project manager must now modify
dependencies.

Step 4: Identify the task dependencies for critical path analysis

During a effort, some tasks can't start until others have been completed. This is true for the
"Test launch" task. There is nothing to test until the development is completed. As well, the
"News Shower" launch is dependent on every other task. The project manager, in discussions
with team members or sponsors as appropriate, determines the task dependencies. The modified
Gantt view now shows a realistic schedule.
Notice that there is now a critical path, shown as a red bar, that is comprised of two tasks. The
other tasks are completed in parallel and don't affect the critical path. At this point, no resources
have been assigned to the tasks. No tasks have been split into components.

Fig no: -4

Step 5: Assign project resources to tasks

Each of the tasks can have one or more resources assigned. The column "Resource Names"
on the Gantt View allows direct data entry of this information. Enter the name of a resource
in the field. The default action is to have each named resource work 100% of their time on the
task. The field also supports the direct entry of multiple resources. Enter the resource names
separated by a semi-colon.
 Fig no: -5
Step 6: Task elaboration

An important feature of project management applications is the ability to allow the manager
to split tasks into smaller sub-tasks. This can allow better accuracy in schedule estimating. It
also allows team members to be specified in a just-in-time fashion for their assignments. The
example project has some opportunities for task elaboration.

Fig no: -6
Step 7: Evaluate the project plan

With all of the tasks entered, and sub-tasks specified, the plan has really evolved. It now shows
a lot of information which can be useful in project reporting. The first item is the critical path.
This of the highest importance to the project manager and the organization. Reports showing
the tasks can be presented to company executives. An analysis of workloads can be done.
Task reports can be printed. In time, as completion percentages are entered for tasks, the project
manager can run status reports showing progress and schedule tracking.
 Experiment No.5

Aim: - Study and usage of Openproj to track the progress of a project.

Finding the right project management solution for your team can be very hard. Finding an open
source project management solution may be even harder. That's the mission of solution that
allows teams to collaborate throughout the project life cycle. Additionally, the project aims to
replace proprietary software like Microsoft Project Server or Jira.

The OpenProject objectives:

1. Establish and promote an active and open community of developers, users, and
companies for continuous development of the open source project.
2. Define and develop the project vision, the code of conduct, and principles of the
application.
3. Create development policies and ensure their compliance.
4. Define and evolve the development and quality assurance processes.
5. Provide the source code to the public.
6. Provide and operate the OpenProject platform.

Mission of OpenProject
The mission of OpenProject can be quickly summarized: we want to build excellent open source
project collaboration software. And when I say open source, I meant it. We strive to make
OpenProject a place to participate, collaborate, and get involved—with an active, open-
minded, transparent, and innovative community.
Companies have finally become aware of the importance of project management software
and also the big advantages of open source. But why is it that project teams still tend to switch
to old-fashioned ways of creating project plans, task lists, or status reports with Excel,
PowerPoint, or Word—or having other expensive proprietary project management software
in use? We want to offer a real open source alternative for companies: free, secure, and easy
to use.

Progress of the project is as below:-

Maintenance will keep on going till lifetime of this project.
 Experiment No.6

Preparation of Software Requirement Specification Document and Design Documents.

Title: Preparation of Software requirement specification document, Design document and Testing
phase document of some problem.
Theory:

I) Software Requirement Specification Document

1.Introduction
The introduction of the Software Requirements Specification (SRS) provides an overview of the entire
SRS with purpose, scope, definitions, acronyms, abbreviations, references and overview of the SRS.
The aim of this document is to gather and analyze and give an in-depth insight of the complete
Electronics and Home Entertainment software system by defining the problem statement in detail.
Nevertheless, it also concentrates on the capabilities required by stakeholders and their needs while
defining high-level product features. The detailed requirements of the Electronics and Home
Entertainment are provided in this document.
1.1 Purpose
The purpose of the document is to collect and analyze all assorted ideas that have come up to define
the system, its requirements with respect to consumers. Also, we shall predict and sort out how we
hope this product will be used in order to gain a better understanding of the project, outline concepts
that may be developed later, and document ideas that are being considered, but may be discarded as
the product develops.
In short, the purpose of this SRS document is to provide a detailed overview of our software product,
its parameters and goals. This document describes the project's target audience and its user interface,
hardware and software requirements. It defines how our client, team and audience see the product and
its functionality. Nonetheless, it helps any designer and developer to assist in software delivery
lifecycle (SDLC) processes.
1.2 Scope
Primarily, the scope pertains to the E-Store product features for making Marvel Electronics and Home
Entertainment project live. It focuses on the company, the stakeholders and applications, which allow
for online sales, distribution and marketing of electronics.
This SRS is also aimed at specifying requirements of software to be developed but it can also be
applied to assist in the selection of in-house and commercial software products. The standard can be
used to create software requirements specifications directly or can be used as a model for defining a
organization or project specific standard. It does not identify any specific method, nomenclature or
tool for preparing an SRS.

1.3 Definitions, Acronyms, and Abbreviations

Configuration It means a product which is available / Selected from a catalogue can be
customized.
FAQ Frequently Asked Questions
CRM Customer Relationship Management
RAID 5 Redundant Array of Inexpensive Disk/Drives

1.4 Overview
The remaining sections of this document provide a general description, including characteristics of
the users of this project, the product's hardware, and the functional and data requirements of the
product. General description of the project is discussed in section 2 of this document. Section 3 gives
the functional requirements, data requirements and constraints and assumptions

made while designing the E-Store. It also gives the user viewpoint of product. Section 3 also gives
the specific requirements of the product. Section 3 also discusses the external interface requirements
and gives detailed description of functional requirements. Section 4 is for supporting information.

2. Overall Description
This document contains the problem statement that the current system is facing which is hampering
the growth opportunities of the company. It further contains a list of the stakeholders and users of the
proposed solution. It also illustrates the needs and wants of the stakeholders that were identified in the
brainstorming exercise as part of the requirements workshop. It further lists and briefly describes the
major features and a brief description of each of the proposed system.
The following SRS contains the detail product perspective from different stakeholders. It provides the
detail product functions of E-Store with user characteristics permitted constraints, assumptions and
dependencies and requirements subsets.

3. Specific Requirements
The specific requirements are –
3.1Functionality
Introduction – This subsection contains the requirements for the e-store. These requirements are
organized by the features discussed in the vision document. Features from vision documents are then
refined into use case diagrams and to sequence diagram to best capture the functional requirements of
the system. All these functional requirements can be traced using tractability matrix.
3.1.1 Sell Configured to Ordered Products
3.1.1.1 The system shall display all the products that can be configured.

3.1.1.2 The system shall allow user to select the product to configure.

3.1.1.3 The system shall display all the available components of the product to configure

3.1.1.4 The system shall enable user to add one or more component to the configuration.

3.1.1.5 The system shall notify the user about any conflict in the current configuration.

3.1.1.6 The system shall allow user to update the configuration to resolve conflict in the current
configuration.

3.1.1.7 The system shall allow user to confirm the completion of current configuration
3.1.2Provide comprehensive product details.

3.1.2.1 The system shall display detailed information of the selected products.

3.1.2.2 The system shall provide browsing options to see product details.
3.1.3 Detailed product Categorizations
The system shall display detailed product categorization to the user.
3.1.4 Provide Search facility.
3.1.4.1 The system shall enable user to enter the search text on the screen.
3.1.4.2 The system shall enable user to select multiple options on the screen to search.
3.1.4.3 The system shall display all the matching products based on the search
3.1.4.4 The system shall display only 10 matching result on the current screen.
3.1.4.5 The system shall enable user to navigate between the search results.
3.1.4.6 The system shall notify the user when no matching product is found on the search.
3.1.5 Maintain customer profile.
3.1.5.1 The system shall allow user to create profile and set his credential.
3.1.5.2 The system shall authenticate user credentials to view the profile.
3.1.5.3 The system shall allow user to update the profile information.
3.1.6 Provide personalized profile
3.1.6.1 The system shall display both the active and completed order history in the customer profile.
3.1.6.2 The system shall allow user to select the order from the order history.
3.1.6.3 The system shall display the detailed information about the selected order.
3.1.6.4 The system shall display the most frequently searched items by the user in the profile.
3.1.6.5 The system shall allow user to register for newsletters and surveys in the profile.
3.1.7 Provide Customer Support.
3.1.7.1 The system shall provide online help, FAQ’s customer support, and sitemap options for
customer support.
3.1.7.2 The system shall allow user to select the support type he wants.
3.1.7.3 The system shall allow user to enter the customer and product information for the support.
3.1.7.4 The system shall display the customer support contact numbers on the screen.
3.1.7.5 The system shall allow user to enter the contact number for support personnel to call.
3.1.8 Email confirmation.
3.1.8.1 The system shall maintain customer email information as a required part of customer profile.
3.1.8.2 The system shall send an order confirmation to the user through email.

3.1.9 Detailed invoice for customer.

3.1.9.1The system shall display detailed invoice for current order once it is confirmed.
3.1.9.2 The system shall optionally allow user to print the invoice.
3.1.10 Provide shopping cart facility.
3.1.10.1 The system shall provide shopping cart during online purchase.
3.1.10.2 The system shall allow user to add/remove products in the shopping cart.
3.1.11.Provide multiple shipping methods.
3.1.11.1 The system shall display different shipping options provided by shipping department.
3.1.11.2 The system shall enable user to select the shipping method during payment process.
3.1.11.3 The system shall display the shipping charges.
3.1.11.4 The system shall display tentative duration for shipping.
3.1.12 Online tracking of shipments
3.1.12.1 The system shall allow user to enter the order information for tracking.
3.1.12.2The system shall display the current tracking information about the order.
3.1.13 Allow multiple payment methods.
3.1.13.1 The system shall display available payment methods for payment.
3.1.13.2 The system shall allow user to select the payment method for order.
3.1.14 Allow online change or cancellation of order.
3.1.14.1 The system shall display the orders that are eligible to change.
3.1.14.2 The system shall allow user to select the order to be changed.
3.1.14.3 The system shall allow user to cancel the order
3.1.14.4 The system shall allow user to change shipping, payment method.
3.1.14.4 The system shall notify the user about any changes made to the order.
3.1.15 Allow Online Product reviews and ratings
3.1.15.1 The system shall display the reviews and ratings of each product, when it is selected.
3.1.15.2 The system shall enable the user to enter their reviews and ratings.
3.1.16 Offer financing options.
3.1.16.1 The system shall display all the available financing options.
3.1.16.2 The system shall allow user to select the financing option.
3.1.16.3 The system shall notify the use about the financing request.
3.1.17 Provide detailed sitemap.
3.1.17.1 The system shall allow user to view detailed sitemap.
3.1.18 Offer online promotions and rewards.
3.1.18.1 The system shall display all the available promotions to the user.
3.1.18.2 The system shall allow user to select available promotion.
3.1.19 Online Purchase of products.
3.1.19.1 The system shall allow user to confirm the purchase.
3.1.19.2 The system shall enable user to enter the payment information.

3.2 Usability
3.2.1 Graphical User Interface
The system shall provide a uniform look and feel between all the web pages.
The system shall provide a digital image for each product in the product catalog.
The system shall provide use of icons and toolbars.
3.2.2 Accessibility
The system shall provide handicap access.
The system shall provide multi language support.
3.3 Reliability & Availability
3.3.1 Back-end Internal Computers
The system shall provide storage of all databases on redundant computers with automatic switchover.
The system shall provide for replication of databases to off-site storage locations.
The system shall provide RAID V Disk Stripping on all database storage disks.
3.3.2 Internet Service Provider
The system shall provide a contractual agreement with an internet service provider for T3 access with
99.9999% availability.
The system shall provide a contractual agreement with an internet service provider who can provide
99.999% availability through their network facilities onto the internet.
3.4 Performance
The product shall be based on web and has to be run from a web server.
The product shall take initial load time depending on internet connection strength which also depends
on the media from which the product is run.
The performance shall depend upon hardware components of the client/customer.

3.5 Security
3.5.1 Data Transfer
The system shall use secure sockets in all transactions that include any confidential customer
information.
The system shall automatically log out all customers after a period of inactivity.
The system shall confirm all transactions with the customer’s web browser.
The system shall not leave any cookies on the customer’s computer containing the user’s password.
The system shall not leave any cookies on the customer’s computer containing any of the user’s
confidential information.
3.5.2 Data Storage
The customer’s web browser shall never display a customer’s password. It shall always be echoed
with special characters representing typed characters.
The customer’s web browser shall never display a customer’s credit card number after retrieving from
the database. It shall always be shown with just the last 4 digits of the credit card number.
The system’s back-end servers shall never display a customer’s password. The customer’s password
may be reset but never shown.
The system’s back-end servers shall only be accessible to authenticated administrators.
The system’s back-end databases shall be encrypted.
3.6 Supportability
3.6.1 Configuration Management Tool

The source code developed for this system shall be maintained in configuration management tool.

3.7 Design Constraints

3.7.1 Standard Development Tools
The system shall be built using a standard web page development tool that conforms to either IBM’s
CUA standards or Microsoft’s GUI standards.
3.7.2 Web Based Product
There are no memory requirements.
The computers must be equipped with web browsers such as Internet explorer.
The product must be stored in such a way that allows the client easy access to it.
Response time for loading the product should take no longer than five minutes.
A general knowledge of basic computer skills is required to use the product.
3.8 On-line User Documentation and Help System Requirements
As the product is E-store, On-line help system becomes a critical component of the system which shall
provide –
It shall provide specific guidelines to a user for using the E-Store system and within the system.

To implement online user help, link and search fields shall be provided.

3.9 Interfaces

There are many types of interfaces as such supported by the E-Store software system namely; User
Interface, Software Interface and Hardware Interface.
The protocol used shall be HTTP.
The Port number used will be 80.
There shall be logical address of the system in IPv4 format.

3.9.1 User Interfaces

The user interface for the software shall be compatible to any browser such as Internet Explorer,

Mozilla or Netscape Navigator by which user can access to the system.

The user interface shall be implemented using any tool or software package like Java Applet, MS
Front Page, EJB etc.

3.9.2 Hardware Interfaces

Since the application must run over the internet, all the hardware shall require to connect internet will
be hardware interface for the system. As for e.g. Modem, WAN – LAN, Ethernet Cross-Cable.

3.9.3 Software Interfaces

1. The e-store system shall communicate with the Configurator to identify all the available
components to configure the product.

2. The e-store shall communicate with the content manager to get the product specifications,
offerings and promotions.

3. The e-store system shall communicate with billPay system to identify available payment
methods , validate the payments and process payment.

4. The e-store system shall communicate to credit management system for handling financing
options.

5. The e-store system shall communicate with CRM system to provide support.

6. The e-store system shall communicate with Sales system for order management.

7. The e-store system shall communicate with shipping system for tracking orders and
updating of shipping methods.
 8. The e-store system shall communicate with external Tax system to calculate tax.

9. The e-store system shall communicate with export regulation system to validate export
regulations.

10. The system shall be VeriSign like software which shall allow the users to complete secured
transaction. This usually shall be the third party software system which is widely used for
internet transaction.

3.9.4 Communications Interfaces

The e-store system shall use the HTTP protocol for communication over the internet and for the
intranet communication will be through TCP/IP protocol suite.

II) Design Document

1 Introduction

(i) This section provides an overview of the entire document and a description of the scope of the
system and its intended usage. The scope should also describe external interfaces to the system,
external dependencies and provide a brief overview of the ‘characteristics’ of the system,
commenting on aspects such as real-time use, security considerations, concurrency of users
etc.

(ii) The operating system, development language to be used for the system development and any
COTS packages that will be used, such as databases etc. should also be referred to in the
introduction. This should be sufficient for the casual reader to gain a good appreciation of the
key building blocks of the system. The reader should also be introduced to the security
measures that need to be included within the system. Where strong authentication models are
required this may need to show how aspects such as authentication of users may need to be
implemented using PKI for example.

1.1 Purpose
(i) This section should:
a) describe the purpose of this document;
b) Specify the intended readership of this document.

1.2 Scope
(i) This section should:
(a) identify the products to be produced;
(b) explain what the proposed system will do (and will not do, if necessary);
(c) define relevant benefits, objectives and goals as precisely as possible;
(d) define any security risks associated with the system;
(e) be consistent with similar statements in higher-level specifications, if they exist.

1.3 Definitions, Acronyms and Abbreviations

(i ) This section should define all terms, acronyms and abbreviations used in this document. Particular
care should be taken to define terms that are specific to the application.

(ii ) Terms covering the development of software using the Unified Modelling Language (UML)
approach – which is recommended if an OOD view of the system is to be developed – should
be included for completeness.

(iii ) The following is a list of definitions for this template based on the UML approach to system
design:

Class Diagram Describes the structure of a system

Object Diagram Expresses possible object combinations of a specific Class
Diagram
State chart Diagram Expresses possible states of a class (or a system)
Activity Diagram Describes activities and actions taking place in a system
Sequence Diagram Shows one or several sequences of messages sent among a
set of objects
Collaboration Describes a complete collaboration among a set of objects
Diagram
Use-case Diagrams Illustrates the relationships between use cases
Component A special case of a Class Diagram used to describe
Diagram components within a software system
Deployment A special case of a Class Diagram used to describe
Diagram hardware within the overall system architecture
System Block A diagram showing the major components of the system
diagram with its interconnections and external interfaces

Result: The SRS Document and Design Phase Document is prepared.

Outcome: Students will learn how to prepare the SRS Document and Design phase document.
 Experiment No. 7

Title: Preparation of Software Testing phase document of some problem.

Theory:

Testing Phase Testing

1. Introduction
This approach document is designed for the Information and Technology Services System
Development Life Cycle (SDLC) projects.
A. Purpose
The intent of Development/Unit Testing is to efficiently and accurately develop, unit test, and provide
documentation for Designs produced. Repeatable, consistent processes and comprehensive
documentation support this goal. The end result should be increased quality (fewer bugs), and the
reduction of delivery time and effort needed for subsequent projects.

2. Approach

A. Approach Description
The general methodology/approach for SDLC Development/Unit Testing at ITS will involve the
following steps:
1. Initial planning efforts for this phase will include the establishment of:
a. A project status reporting approach.
b. A defect tracking approach.
c. A metric collection approach for the phase.
2. (If New Hardware or Configuration) Perform SDLC Environment Setup & Validation Process
(9000)
3. The guidelines for Development and Unit Test work will be:
a. Eliminate Objects to be obsoleted. System Testing will be the only verification of
success for these changes.
b. For Objects with Design Documents (S300 – Design Document) the following steps
are performed:
i. Code the Design.
ii. Develop the Unit Test Plan.
iii. Review Code and Unit Test Plan if functionality has been added or changed.
iv. Unit Test the Coded Objects.
v. Review and Approve the Unit Testing results.
4. The order in which the Objects should be Developed and Unit-Tested will be based upon all
of the following:
a. Priority assigned.
b. Grouping of all objects for a Business Process.
c. Direction of the SDLC Lead or Project Manager.
d. Ordering of System Testing and Acceptance activities.
e. Ordering of Objects from Design Phase.
f. Availability of Test Data.
5. Steps involved in Coding are as follows:
a. Review and understand the information in the S300 Design Document.
b. Determine exactly which objects will need to be changed and update the S300 Design
Document to include that information.
c. Notify any other ITS units affected by the changes made to the S300 Design Document.
d. Code the Object using the PS Programming Standards and Guidelines in Lotus Notes.
Also refer to the Development and Unit Test Checklists as informational guidelines.
e. Notify the Project Manager of any needed changes or additions to the PS Programming
Standards and Guidelines. An interim working standard will be developed to meet this
need.
6. Steps to develop an S404 Unit Test Plan for each S300 Design Document:
• Define the conditions to be tested based on functional requirements and include
conditions that exercise every path of new or changed logic.
• Follow the Unit Test Process Guidelines in Lotus Notes.
• Refer to the Upgrade Unit Test Checklist as an informational guide in the creation,
execution and review of the Unit Test Plan.
• Organize testing into cycles to simplify troubleshooting and analysis of results.
• Prepare the test model with input data and expected results.
• Determine and document test data.
o Test good data and boundary conditions.
o Ask for Designer’s assistance if needed when identifying and/or creating
data needed for testing.
o Follow Test Data Creation Guidelines in Lotus Notes.
7. Conduct Code and Test Plan Review.
• Attendees could include: Tech Lead, Peer, and Designer.
 • Verify the following of Programming and Unit Testing Standards and Guidelines
found in Lotus Notes.
• Utilize the Software Development and Unit Test Checklists as informational
guidelines during reviews.
• Update the Unit Test Plan with the appropriate Signoff/Approval signatures.
• If the Code and/or Test Plan is not approved, make necessary changes and conduct
a re-review.
8. Execute the Test Plan.
• Check the output against the expected results
• Evaluate any unexpected results
• Make sure that any required corrections are carried out and re-tested
• Make sure that final testing components (conditions, input, and expected results)
are accurate, complete and documented in such a way to make them repeatable and
re-usable.
• Document results by updating the S404 Unit Test Plan
9. Review and obtain signoff of Unit Test results, updating the S404 Unit Test Plan with the
appropriate Signoff/Approval signatures.
10. Update the Tracking Spreadsheet/Database.
11. Migrate the Object(s) to the System Test environment in a planned release.

3. Status and Reporting

A. Defect Tracking Approach
During Development/Unit Testing, problems encountered will be tracked within the Tracking
Spreadsheet/Database.

B. Time Tracking & Reporting

The Project Manager will be responsible for ensuring that time is entered into PlanView and that
Monthly Status Reports are created.

C. Metrics To Utilize
Metrics that will be tracked include but are not limited to:
1. Percentage of Objects with Unit Testing complete

a. From Planview or the Tracking Spreadsheet/Database.

b. Also include interim milestones by objects.

 2. Effort Completed as Percentage of Estimated Effort.

a. From Planview – Time Reported and ETC (Estimated Time to Completion) updates.

3. Percentage of Effort Earned. (Actual vs. Planned work completed).

4. Percentage of Effort Remaining – only 100% completion factored in.

5. Effort Rate

6. Burn Rate

7. Green/Yellow/Red tasks.

D. Status/Issues Meetings
During Development/Unit Testing, it is recommended that a weekly status meeting be held at the same
scheduled time on the same day each week. This meeting will support a communication process to
inform the project team of status, problems or issues, and changes. The Agenda will include a review
of open high and medium issues, Unit Test plans, and any action items from the previous week.
Meeting minutes should be taken that include a list of attendees, discussion points, and action items.
TIO/AIG, Module Leads, Data Delivery, Access Services groups etc. should be represented in the
meeting, as needed.

E. Acknowledgement
Where deliverables require “acknowledgement”, this means that the responsible party has reviewed
the documentation and feels that the documentation was sufficient. It is important to define who is
responsible for reviewing and approving any results or documentation early in the project lifecycle.
4. Assumptions and Risks
A. Assumptions
The following assumptions are critical to the successful accomplishment of this Approach to
Development/Unit Testing:
❑ An S404 Unit Test Plan is created for each S300 Design Document.

❑ If the Design included cross-functional input and review, then the unit test should also
include cross-functional input and review.

❑ Both Technical and Functional knowledge resources should have input to test plan and
results review.

❑ The Designs should be referenced with the Unit Test Plan through document naming and
repository standards as a minimum.
 ❑ Test Plan and Results Signoff may be different for each team. A provision should be made
for Reviewer and cross-functional Review if needed.

❑ Database tuning help will be available if needed.

❑ Retesting will occur after tuning.

This approach makes the following assumptions for the System Test Phase:
❑ Testing will be conducted for each Business Process.

❑ Reusable test conditions will be utilized, which may include the use of reusable test scripts.

❑ Every business condition will be tested.

❑ Testing will be especially detailed in areas having new functionality.

❑ Regression and integration testing is covered.

❑ Data plans will be included in the System Test Plans.

B. Risks
❑ Completion of Design Phase misses targeted schedule.

❑ Insufficient resource levels.

• Production Support activities pull resources away.

• Design Phase activities pull developers away.

❑ Infrastructure Changes that impact work processes.

❑ Tasks underestimated for effort and/or duration.

5. Deliverables
A. Deliverables from the Project Manager
The following deliverables are required.
• Updated Development/Unit Test Phase Approach Document, if needed.

• Updated Metrics/Tracking Reports

• Work Breakdown Structure (WBS)/Schedule - updated tasks and adjusted hours. This
is required at the beginning of the Development/Unit Test Phase, in order to put the
WBS into PlanView for tracking and reporting.
 B. Deliverables from the Phase
The following deliverables are required from the Development/Unit Test Phase for it to be considered
completed.
• S404 - Unit Test Plan

• Unit Test Results

• S405 - Dev/Unit Test Phase Completion Checklist

• A coded, Unit-Tested Application

C. Deliverables from the Methodology Team

The following deliverables are required.
• Updated Process Flows, Templates, or Tools if necessary, based upon project team
feedback regarding successes and challenges.

Appendix
A. Definitions

Test Phases Focus

Unit Test Testing individual modules and programs, and testing them in
sufficient context to insure that work flows correctly through the
affected business process.

Integration/System Test Validates that all processes, including customizations and

interfaces, work together to support the business functions

Volume/Stress Test Validates that critical functions will meet production performance
requirements

User Test Validating production-ready functionality and data integrity

Regression Test Ensures that the application doesn’t negatively impact previously
migrated objects/modules. Re-tests the application to ensure that
the application performs correctly after a package upgrade or
change.

Result: The Testing Phase Document is prepared.

Outcome: Students will learn how to prepare the testing phase document.
 Experiment No:8

Aim: -To perform unit testing and integration testing.

Unit Testing:- Unit testing, a testing technique using which individual modules are tested to
determine if there are any issues by the developer himself. It is concerned with functional
correctness of the standalone modules. The main aim is to isolate each unit of the system to
identify, analyze and fix the defects.

Unit Testing Life cycle:-

Advantages of unit testing:

• Defects are found at an early stage. Since it is done by the dev team by testing individual
pieces of code before integration, it helps in fixing the issues early on in source code without
affecting other source codes.
• It helps maintain the code. Since it is done by individual developers, stress is being put on
making the code less inter dependent, which in turn reduces the chances of impacting
other sets of source code.
• It helps in reducing the cost of defect fixes since bugs are found early on in the development
cycle.
• It helps in simplifying the debugging process. Only latest changes made in the code need
to be debugged if a test case fails while doing unit testing.
Disadvantages:
• It’s difficult to write good unit tests and the whole process may take a lot of time
• A developer can make a mistake that will affect the whole system.
 • Not all errors can be detected, since every module it tested separately and later
different integration bugs may appear.
• Testing will not catch every error in the program, because it cannot evaluate every
execution path in any but the most trivial programs. This problem is a superset of the
halting problem, which is un decidable.
• The same is true for unit testing. Additionally, unit testing by definition only tests the
functionality of the units themselves. Therefore, it will not catch integration errors or
broader system-level errors (such as functions performed across multiple units, or
non-functional test areas such as performance).
• Unit testing should be done in conjunction with other software testing activities, as
they can only show the presence or absence of particular errors; they cannot prove a
complete absence of errors.
• To guarantee correct behaviour for every execution path and every possible input,
and ensure the absence of errors, other techniques are required, namely the
application of formal methods to proving that a software component has no
unexpected behaviour.
Unit Testing Techniques:
1. Black Box Testing - Using which the user interface, input and output are tested.
2. White Box Testing - used to test each one of those functions behavior is tested.
3. Gray Box Testing - Used to execute tests, risks and assessment methods.
Integration Testing:- It tests integration or interfaces between components, interactions to
different parts of the system such as an operating system, file system and hardware or interfaces
between systems.
• Also after integrating two different components together we do the integration testing.
As displayed in the image below when two different modules ‘Module A’ and ‘Module
B’ are integrated then the integration testing is done.

• Integration testing is done by a specific integration tester or test team.

• Integration testing follows two approach known as ‘Top Down’ approach and
‘Bottom Up’ approach as shown in the image below:

Below are the integration testing techniques:

1. Big Bang integration testing: - In Big Bang integration testing all components or
modules are integrated simultaneously, after which everything is tested as a whole. As per
the below image all the modules from ‘Module 1’ to ‘Module 6’ are integrated
simultaneously then the Testing is carried out.
 .

Advantage: Big Bang testing has the advantage that everything is finished before
integration testing starts.

Disadvantage: The major disadvantage is that in general it is time consuming and difficult
to trace the cause of failures because of this late integration.

2. Top-down integration testing: Testing takes place from top to bottom, following the
control flow or architectural structure (e.g. starting from the GUI or main menu).
Components or systems are substituted by stubs. Below is the diagram of ‘Top down
Approach”

Advantages of Top-Down approach:

• The tested product is very consistent because the integration testing is basically
performed in an environment that almost similar to that of reality
• Stubs can be written with lesser time because when compared to the drivers then Stubs
are simpler to author.

Disadvantages of Top-Down approach:

• Basic functionality is tested at the end of cycle
3. Bottom-up integration testing: Testing takes place from the bottom of the control
flow upwards. Components or systems are substituted by drivers. Below is the image of
‘Bottom up approach’:
Advantage of Bottom-Up approach:
• In this approach development and testing can be done together so that the product or
application will be efficient and as per the customer specifications.

Disadvantages of Bottom-Up approach:

• We can catch the Key interface defects at the end of cycle
• It is required to create the test drivers for modules at all levels except the top control

System Testing: - System Testing (ST) is a black box testing technique performed to
evaluate the complete system the system's compliance against specified requirements. In
System testing, the functionalities of the system are tested from an end-to-end perspective.
System Testing is usually carried out by a team that is independent of the development team
in order to measure the quality of the system unbiased. It includes both functional and Non-
Functional testing.
 Experiment No:9

Aim: - To perform various white box and black box testing techniques.
White Box Testing: -
White Box Testing is the testing of a software solution's internal coding and infrastructure. It
focuses primarily on strengthening security, the flow of inputs and outputs through the
application, and improving design and usability. White box testing is also known as Clear
Box testing, Open Box testing, Structural testing, Transparent Box testing, Code-Based testing,
and Glass Box testing.
It is one of two parts of the "box testing" approach of software testing. Its counter-part, black
box testing, involves testing from an external or end-user type perspective. On the otherhand,
White box testing is based on the inner workings of an application and revolves around internal
testing.
The term "white box" was used because of the see-through box concept. The clear box or white
box name symbolizes the ability to see through the software's outer shell (or "box")into its
inner workings. Likewise, the "black box" in "Black Box Testing" symbolizes not being able
to see the inner workings of the software so that only the end-user experience can be tested.

What do you verify in White Box Testing

White box testing involves the testing of the software code for the following:
• Internal security holes
• Broken or poorly structured paths in the coding processes
• The flow of specific inputs through the code
• Expected output
• The functionality of conditional loops
• Testing of each statement, object and function on an individual basis
The testing can be done at system, integration and unit levels of software development. One
of the basic goals of white box testing is to verify a working flow for an application. It involves
testing a series of predefined inputs against expected or desired outputs so that when a specific
input does not result in the expected output, you have encountered a bug.
How do you perform White Box Testing
To give you a simplified explanation of white box testing, we have divided it into two basic
Steps. This is what testers do when testing an application using the white box testing technique:
Step 1) Understand the source code
The first thing a tester will often do is learn and understand the source code of the application.
Since white box testing involves the testing of the inner workings of an application, the tester
must be very knowledgeable in the programming languages used in the applications they are
testing. Also, the testing person must be highly aware of secure coding practices. Security is
often one of the primary objectives of testing software. The tester should be able to find security
issues and prevent attacks from hackers and naive users who might inject malicious code into
the application either knowingly or unknowingly.
Step 2) Create test cases and execute
The second basic step to white box testing involves testing the application's source code for
proper flow and structure. One way is by writing more code to test the application's source
code. The tester will develop little tests for each process or series of processes in the application.
This method requires that the tester must have intimate knowledge of the code and is often
done by the developer. Other methods include Manual Testing, trial and error testing and the
use of testing tools as we will explain further on in this article.

White Box Testing Techniques

The 3 main White Box Testing Techniques are:
• Statement Coverage
• Branch Coverage
• Path Coverage
Let’s understand these techniques one by one with a simple example.
• Statement coverage:
In a programming language, a statement is nothing but the line of code or instruction for the
computer to understand and act accordingly. A statement becomes an executable statement
when it gets compiled and converted into the object code and performs the action when the
program is in a running mode.
Hence “Statement Coverage”, as the name itself suggests, it is the method of validating whether
each and every line of the code is executed at least once.
• Branch Coverage:
“Branch” in a programming language is like the “IF statements”. An IF statement has two
branches: True and False. So in Branch coverage (also called Decision coverage), wevalidate
whether each branch is executed at least once.
In case of an “IF statement”, there will be two test conditions:
• One to validate the true branch and,
• Other to validate the false branch.
Hence, in theory, Branch Coverage is a testing method which is when executed ensures that
each and every branch from each decision point is executed.
• Path Coverage:
Path coverage tests all the paths of the program. This is a comprehensive technique which
ensures that all the paths of the program are traversed at least once. Path Coverage is even more
powerful than Branch coverage. This technique is useful for testing the complex programs.
Types of White Box Testing
White box testing encompasses several testing types used to evaluate the usability of an
application, block of code or specific software package. There are listed below --

Unit Testing: It is often the first type of testing done on an application. Unit testing is
performed on each unit or block of code as it is developed. Unit Testing is essentially done by
the programmer. As a software developer, you develop a few lines of code, a single function or
an object and test it to make sure it works before continuing. Unit testing helps identify majority
of bugs, early in the software development lifecycle. Bugs identified in this stage are cheaper
and easy to fix.
Testing for Memory Leaks: - Memory leaks are the most important causes of slowerrunning
applications. A QA specialist who is experienced at detecting memory leaks is essential in cases
where you have a slow running software application. There are many tools available to assist
developers/testers with memory leak testing, example, Rational Purify for windows application.
Apart from above a few testing types are part of both black box and white box testing. They are
listed as below:
White Box Penetration Testing: In this testing, the tester/developer has full information of
the application's source code, detailed network information, IP addresses involved and all server
information the application runs on. The aim is to attack the code from several angles to expose
security threats
White Box Mutation Testing: Mutation testing is often used to discover the best coding
techniques to use for expanding a software solution.
Integration Testing: - Integration testing is a level of software testing where individual units
are combined and tested as a group. The purpose of this level of testing is to expose faults in
the interaction between integrated units. Test drivers and test stubs are used to assist in
Integration Testing.
Advantages of White Box Testing: -
• Code optimization by finding hidden errors.
• White box tests cases can be easily automated.
• Testing is more thorough as all code paths are usually covered.
• Testing can start early in SDLC even if GUI is not available.
Disadvantages of White Box Testing: -
• White box testing can be quite complex and expensive.
• Developers who usually execute white box test cases detest it. The white box testing by
developers is not detailed can lead to production errors.
• White box testing requires professional resources, with a detailed understanding of
programming and implementation.
• White-box testing is time-consuming, bigger programming applications take the time to test
fully
Black Box Testing
Black box testing is a software testing techniques in which functionality of the software under
test (SUT) is tested without looking at the internal code structure, implementation details and
knowledge of internal paths of the software. This type of testing is based entirely on the
software requirements and specifications. In Black Box Testing we just focus on inputs
and output of the software system without bothering about internal knowledge of thesoftware
program.

Black Box Testing – Steps: -

Here are the generic steps followed to carry out any type of Black Box Testing.
• Initially requirements and specifications of the system are examined.
• Tester chooses valid inputs (positive test scenario) to check whether SUT processes them
correctly. Also some invalid inputs (negative test scenario) are chosen to verify that the
SUT is able to detect them.
• Tester determines expected outputs for all those inputs.
• Software tester constructs test cases with the selected inputs.
• The test cases are executed.
• Software tester compares the actual outputs with the expected outputs.
• Defects if any are fixed and re-tested.
Types of Black Box Testing
There are many types of Black Box Testing but following are the prominent ones -
• Functional testing - This black box testing type is related to functional requirements of a
system; it is done by software testers.
• Non-functional testing - This type of black box testing is not related to testing of a specific
functionality, but non-functional requirements such as performance, scalability, usability.
• Regression testing - Regression Testing is done after code fixes, upgrades or any other
system maintenance to check the new code has not affected the existing code.

Black box testing strategy:

Following are the prominent Test Strategy amongst the many used in Black box Testing
• Equivalence Class Testing: It is used to minimize the number of possible test cases to an
optimum level while maintains reasonable test coverage.
• Boundary Value Testing: Boundary value testing is focused on the values at boundaries.
This technique determines whether a certain range of values are acceptable by the system
 or not. It is very useful in reducing the number of test cases. It is mostly suitable for the
systems where input is within certain ranges.
• Decision Table Testing: A decision table puts causes and their effects in a matrix. There
is unique combination in each column.

Advantages of Black Box Testing

Tester can be non-technical.
• Used to verify contradictions in actual system and the specifications.
• Test cases can be designed as soon as the functional specifications are complete

Disadvantages of Black Box Testing

• The test inputs needs to be from large sample space.
• It is difficult to identify all possible inputs in limited testing time. So writing test cases is
slow and difficult
• Chances of having unidentified paths during this testing
 Practical 10
Aim: - Preparation of the Software Configuration management and Risk management
related documents.

Software Configuration management

SCM or Software Configuration management is a Project Function (as defined in the
SPMP) with the goal to make technical and managerial activities more effective. Software
configuration management (SCM) is a software engineering discipline consisting of
standard processes and techniques often used by organizations to manage the changes
introduced to its software products. SCM helps in identifying individual elements and
configurations, tracking changes, and version selection, control, and baselining.

SCM is also known as software control management. SCM aims to control changes
introduced to large complex software systems through reliable version selection and
version control.
The SCM system has the following advantages:
• Reduced redundant work.
• Effective management of simultaneous updates.
• Avoids configuration-related problems.
• Facilitates team coordination.
• Helps in building management; managing tools used in builds.
• Defect tracking: It ensures that every defect has traceability back to its source.
Benefits of Software Configuration Management
SCM provides significant benefits to all projects regardless of size, scope, and complexity.
Some of the most common benefits experienced by project teams applying the SCM disciplines
described in this guide are possible because the SCM system:
• Organization
Being that Configuration Management is like the framework for greater information
management programs, it should go without saying that it is critical for greater
management and organization of information as a whole. With a well-ordered system in
place, a good IT worker should be able to see all of the past system implementations of
the business, and can better address future needs and changes to keep the system up to
date and running smoothly.
• Reliability
Nothing is worse than an unreliable system that is constantly down and needing repairs
because a company’s configuration management team is lacking in organization and pro-
activeness. If the system is used correctly, it should run like the well-oiled machine that it
is, ensuring that every department in the company can get their jobs done properly.
Increased stability and efficiency of the system will trickle down into every division of a
company, including customer relations, as the ease and speed in which their problems
can be solved and information can be accessed will surely make a positive impact.
• Cost Reduction and Risks
Like anything else in business, a lack of maintenance and attention to details can have
greater risks and cost down the line, as opposed to proactive action before a problem
arises. Configuration Management saves money with the constant system maintenance,
record keeping, and checks and balances to prevent repetition and mistakes. The
organized record keeping of the system itself saves time for the IT department and reduces
wasted money for the company with less money being spent on fixing recurring or
nonsensical issues.
SCM Process
The software configuration management process defines a series of tasks that have four
primaryobjectives:
1. To identify all the items that collectively defines the software configuration.
2. To manage changes to one or more of these items.
3. To facilitate the construction of different versions of an application.
4. To ensure that software quality is maintained as the configuration evolves over time.

Figure 4.1:- SCM process

Risk Management
1. A risk is any anticipated unfavourable event or circumstance that can occur while project
is being developed
2. The project manager needs to identify different type of risk in advance so that the project
deadlines don’t get extended
3. There are three main activities of risk management
Risk identification
1. The project manager needs to anticipate the risk in project as early as possible so
that theimpact of risk can be minimised by using defective risk management plans
2. Following are the main types of risk that need to be identified
3. Project risk:- these include
• Resource related issues
• Schedule problems
• Budgetary issues
• Staffing problem
• Customer related issues
4. Technical risk := includes
• Potential design problems
• Implementation and interfacing issues
• Incomplete specification.
• Changing specification and technical uncertainty
• Ambiguos specification
• Testing and maintenance problem
5. Business risk :-
• Market trend changes.
 • Developing a product similar to the existing applications
• Personal commitments
4. In order to be able to successfully identify and foresee the different type of risk that might
affect a project it is good idea to have a company disaster list
5. The company disaster list contains al the possible risk or events that can occur in similar
projects
Risk assessment: -
1. The main objective of risk assessment is to rank the risk in terms of their damage causing
potential
2. The priority of each list can be computed using the equation p=r*s, where p is priority with
whichthe risk must be handled , r is probability of the risk becoming true and s is severity
of damage caused due to the risk becoming true
3. If all the identified risk are prioritised than most likely and damaging risk can be handled
first and others later on
Risk containment: -
1. Risk containment include planning the strategies to handle and face the most likely and
damagingrisk first
2. Following are the strategies that can be used in general
a. Avoid the risk :- eg:- in case of having issues in designing phase with reference to
specified requirements , one can discuss withe customer to change the specifications
and avoid the risk
b. Transfer the risk :-
i. This includes purchasing and insurance coverage
ii. Getting the risky component developed by Third party
Risk reduction: - leverage factor:
a) The project manager must consider the cost of handling the risk and the
corresponding reduction of the risk
b) Risk leverage = ( risk exposure before reduction - risk exposure after reduction) /
cost ofreduction
 Practical: 11
Aim: - Study and usage of any Design phase CASE tool.CASE
Tools: -
CASE stands for Computer Aided Software Engineering. It means, development and
maintenance of software projects with help of various automated software tools. CASE tools
are set of software application programs, which are used to automate the SDLC activities.
CASE tools are used by software project managers, analysts and engineers to develop software
system.
Reasons for using case tools:
• The primary reasons for using a CASE tool are:
– To increase productivity
– To help produce better quality software at lower cost
– To decrease the development time and cost.
• Various tools are incorporated in CASE and are called CASE tools, which are used to
support different stages and milestones in a software development lifecycle.
Architecture Of CASE tools: -

Figure: - 11.1

• Layer 1 is the user interface whose function is to help the user to interact with core of
the system. It provides a graphical user interface to users using which interaction with the
system become easy.
• Layer 2 depicts tool management system (TMS) which constitutes multiple tools of
different category using which automation of the development process can be done. TMS
may include some tools to draw diagrams or to generate test cases.
• Layer 3 represents object management system (OMS) which represents the set of objects
generated by the users. Group of design notations, set of test cases (test suite) are treated
as the objects.
• Layer 4 represents a repository which stores the objects developed by the user. Layer 4 is
nothing but a database which stores automation files.
Components of CASE Tools: - CASE tools can be broadly divided into the followingparts
based on their use at a particular SDLC stage:
➢ Central Repository - CASE tools require a central repository, which can serve as a
source of common, integrated and consistent information. Central repository is a central
place of storage where product specifications, requirement documents, related reports and
diagrams, other useful information regarding management are stored. Central repository
also serves as data dictionary.
➢ Upper Case Tools - Upper CASE tools are used in planning, analysis and design stages
of SDLC.
➢ Lower Case Tools - Lower CASE tools are used in the implementation, testing and
maintenance stages.
➢ Integrated Case Tools - Integrated CASE tools are helpful in all the stages of SDLC,
from Requirement gathering to Testing and documentation.

Figure: - 11.2

Why CASE Tools are developed?

• Main purpose of the CASE tools is to decrease the development time and cost and
increase the quality of software.
• CASE tools are developed for the following reasons:
– Firstly Quick Installation
– Time saving by reducing coding and testing time.
– Enrich graphical techniques and data flow.
– Enhanced analysis and design development.
– Create and manipulate documentation
– The speed during the system development increased.
Types of CASE tools: - Major categories of CASE tools are:
– Diagram tools
– Project Management tools
– Documentation tools
– Web Development tools
– Quality Assurance tools
– Maintenance tools

Benefits of CASE tools

1. Project Management and control is improved: CASE tools can aid the project
management and control aspects of a development environment. Some CASE tools allow
for integration with industry-standard project management methods (such as PRINCE).
Others incorporate project management tools such as PERT charts and critical path
 analysis. By its very nature, a CASE tool provides the vehicle for managing more
effectively the development activities of a project.
2. System Quality is improved: CASE tools promote standards within a development
environment. The use of graphical tools to specify the requirements of a system can
also help remove the ambiguities that often lead to poorly defined systems.
Therefore, if used correctly, a CASE tool can help improve the quality of the
specification, the subsequent design and the eventual working system.
3. Consistency checking is automated: Large amounts of information about a
business area and its requirement are gathered during the analysis phase of an
information systems development project. Using a manual system to record and
cross reference this information is both time-consuming and inefficient. One of the
advantages of using CASE tool is that all data definitions and other relevant
information can be stored in a central repository that can then be used to cross check
the consistency of the different views being modelled.
4. Productivity is increased: One of the most obvious benefits of a CASE tool is that
itmay increase the productivity of the analysis team. If used properly, the CASE tool
will provide a support environment enabling analysts to share information and
resources, manage the project effectively and produce supporting documentation
quickly.
5. The maintenance effort is better supported: It has been argued that CASE tools
help reduce the maintenance effort required to support the system once it is
operational. CASE tools can be used to provide comprehensive and up-to-date
documentation – this isobviously a critical requirement for any maintenance effort.
CASE tools should result in better systems being developed in the first place.

Problems associated with CASE tools

1. Need for organization - wide commitment: To be used effectively, CASE tools
require the commitment of the organisation. Every member of the development team
must adhere to the standards, rules and procedures laid down by the CASE tool
environment.
2. Unrealistic expectations: CSE tools cannot replace experienced business/systems
analysts and designers. They cannot automatically design a system nor can they
ensure that the business requirements are met. Analysts and designers still need to
understand thebusiness environment and identify the system requirements. CASE
tools can only support the analytical skills of the developers, not replace them.
3. Long learning curve: CASE is technical software. It will take time for the
development team to get use to flow and use it effectively for development work.
4. Costs of CASE tools: CASE tools are complicated software packages and are,
therefore, expensive to buy. In addition to the initial costs, there are many ‘soft’
costs that have to be considered. These ‘soft costs’ include integration of the new
tool, customising the new tool, initial and on-going training of staff, hardware costs
and consultancy provided by the CASE tool vendor.