Department of Computer Science & Engineering

Chandigarh Engineering College

Chandigarh Group of Colleges Landran, Mohali
Punjab
Lab File

Subject: SE LAB (BTCS 503-18)

5th Semester (B-TECH)

(Branch: CSE)

Submitted by: Submitted to:

CHANDAN SHARMA MS. RENU
2237687
5B2
S.No PRACTICALS DATE SIGNATURE
1. Study and usage of OpenProj
or similar software to draft a
project plan.
2. Study and usage of OpenProj
or similar software to track the
progress of a project
3. Preparation of Software
Requirement Specification
Document, Design Documents
and Testing Phase
4. Related documents for some
problems.

5. Preparation of Software
Configuration Management
and Risk Management related
documents
6. Study and usage of any Design
phase CASE tool
7. To perform unit testing and
integration testing
8. To perform various white box
and black box testing
techniques
9. Testing of a web site or any
suitable software
problem/product.
10. To create Collaboration
Diagram of Specific Projects
INDEX
 EXPERIMENT-1

AIM: Study and usage of Open Proj 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 are
typically 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 analysis
of 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.

Fig no: -4

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 component

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 work loads
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.

Result:The total project Cost is predicted.

Outcome: Students will learn how to predict the total cost of the project.
 EXPERIMENT-2

AIM: Study and usage of Open proj 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:-
 Figures 2.1-2.4:-Project Progress Screenshots

Maintenance will keep on going till lifetime of this project.

Result:The progress of the project is tracked.

Outcome: Students will learn how to track the progress of the Project.
 EXPERIMENT-3

AIM: Preparation of Software Requirement Specification Document

and Design.

Documents

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

Configuratio It means a product which is available / Selected from a catalogue can be

n 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-4

AIM: Preparation of Testing Phase related documents for some problem

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-5

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
primary objectives:

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 5.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 the impact 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

● Ambiguous 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 which the 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 prioritized 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 damaging risk 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 manger 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 of reduction

Result:The Software configuration management document is prepared.

Outcome: Students will learn how to prepare the software configuration management.
 EXPERIMENT -6

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: - 6.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 following
parts 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: - 6.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 it may
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 is
obviously 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 the
business 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.

Result: The Design phase CASE tool document is prepared.

Outcome: Students will learn how to prepare Design phase CASE tool document.