INDEX

S no. Title Page. no Sign.

 2101867

Practical-1

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 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.
2|Page
 2101867

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
3|Page
 2101867

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.

4|Page
 2101867

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

5|Page
 2101867

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.

Result: The total project Cost is predicted

6|Page
 2101867

Practical-2
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

7|Page
 2101867

8|Page
 2101867

9|Page
 2101867

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.

10 | P a g e
 2101867

Practical- 3
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

11 | P a g e
 2101867

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.

12 | P a g e
 2101867

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.
13 | P a g e
 2101867

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.
14 | P a g e
 2101867

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
15 | P a g e
 2101867

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.
16 | P a g e
 2101867

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.

17 | P a g e
 2101867

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

18 | P a g e
 2101867

(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.

19 | P a g e
 2101867

(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 Diagram A special case of a Class Diagram used to describe components
within a software system
Deployment Diagram A special case of a Class Diagram used to describe hardware
within the overall system architecture
System Block A diagram showing the major components of the system with its
diagram interconnections and external interfaces

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

20 | P a g e
 2101867

Practical -4
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.
21 | P a g e
 2101867

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.
● Test good data and boundary conditions.
● Ask for Designer’s assistance if needed when identifying and/or creating data
needed for testing.
● 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
22 | P a g e
 2101867

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

23 | P a g e
 2101867

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
24 | P a g e
 2101867

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

Result: The Testing Phase Document is prepared.

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

25 | P a g e
 2101867

Practical-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
26 | P a g e
 2101867

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
27 | P a g e
 2101867

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

28 | P a g e
 2101867

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.

29 | P a g e
 2101867

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

30 | P a g e
 2101867

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.
31 | P a g e
 2101867

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 organization. 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
32 | P a g e
 2101867

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, customizing 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.

33 | P a g e