Department of Computer Science Engineering & Information Technology

Jaypee Institute of Information Technology, Noida

PROJECT BATCH 2006-10

Notice: Attention all VIII Semester CSE & IT Students Date: 27/02/10

Kindly go through the instructions related with Mid Semester Project Seminar:

1. Mid Semester Project Seminar is to be conducted from 8 March 2010 to 20 March 2010.

2. Students are supposed to prepare a Project Report (See page 2 and 3 for format)

3. List of Panel Members will be available at \\Fileserver1\computer science & it\even

sem 2010\Btech\4 year\Project 2009 - 10\\Project 2009-10.xls

4. Fix date and time of your Mid Semester Project Seminar with the consent of all the panel members
between the mentioned periods. No viva will be conducted, if students have not reported the
respective panel during the mentioned period.

5. Kindly bring following during the Mid Semester Project Seminar:

Project Report duly signed by Project Supervisor

Presentation Slides
Log Book duly signed by Project Supervisor

Manish K Thakur
Project Coordinator
Department of CSE & IT
JIITU Noida
 Title of Project

Enrollment No -
Name of Student -
Name of supervisor -

March – 2010

Bachelor of Technology
In
Computer Science Engineering/ Information Technology
(Include whichever is applicable)

Department of Computer Science Engineering & Information Technology

Jaypee Institute of Information Technology, Noida
 Table of Contents

Chapter Page No

Chapter 1: Introduction

1.1 General
1.2 Problem Statement

Chapter 2: Background Material

2.1 Annotated Bibliography

2.2 Literature Integration

Chapter 3: Design, Analysis, and Modeling

3.1 Requirement Analysis

3.2 Design
3.3 Modeling

Chapter 4: Implementation, Risk Management, and Results

4.1 Implémentation
4.1.1 Implémentation
4.1.2 Debugging (see the template at page 4)
4.1.3 Error and Exception Handling
4.2 Risk Management (see the template at page 5)
4.3 Results

Chapter 5 : Conclusion

Références

Appendix A: Work Plan

Appendix B: Description of Tools/ Open Source Used
Appendix C: Quality Assurance (see page 6 onwards for Quality Assurance Template)
 Template for Risk Management

1. Arrange the identified risks (in given format) in your project according to priority.
2. Analyze your identified risks and then give your inference

Impact Recovery
Risk
Cause Performance or Methodology
Description Timeline Quality
Functionality of Project Used

For reference

1. Some common risks associated with a project

• Uncertainties due to use of open source or third party software (not working well, sufficient
documentation/help not available)
• Technology Risks: Anticipated risks relating tools used and solutions proposed ( e.g. limited bandwidth,
No support for large database, platform)
• Deployment risks
e.g. (may not be able to show working/performance of a project specifically related to networking in
cloud or grid.)
• Working on new concepts and tools, learning may be elongated.
• Requirements and solution approach change according to feedback from various vivas by panels.
• Dependencies among modules not clear.
• Assumptions made on part of end user while designing.
• Unforeseen Risks:
• Loss of data due to crash of computer/theft.
• Team member quitting for placement
• Team member falling ill
• Social Problems (e.g. Death of a relative)

• Time wasted at the beginning of project, never regained.

• Forced to choose an area one does not understands/likes or because of his own uncertainties
• Choosing a wrong path (after implementation/ sufficient design algorithm doesn’t work as expected)
• Compromises in project performance more often due to deadlines e.g. test plans.
• Unrealistic estimates and assumptions made at the beginning
• Gold Plating

2.\\Fileserver1\computer science & it\even sem 2010\Btech\4 year\Software Risk Engineering

 Template for Debugging

1. Arrange the identified bugs (in given format) in your project according to priority.
2. Analyze your identified bugs and then give your inference

Bug Description Cause of Bug Time required to remove it

User can get
recommendations
according to his
Incomplete
own profile even 2 hr
analysis.
if he is searching
for someone else.

Variable 15 min
Count of clicks counting
on restaurant 0 number of
clicks not
static
No connectivity Improper 10 min
with database server name in
web config
Text box not Not 20 min
showing the typecasted to
value string

For reference

\\Fileserver1\computer science & it\even sem 2010\Btech\4 year\Software Construction

 Appendix C

Following items to be dealt in appendix C:

Prioritize quality parameters for your project (refer section 1 of the template below). For example, Q12
(Security) may be priority-1 for a banking system but may be priority-12 for a gaming application. After
assigning the priority, you are supposed to discuss your plans to achieve a particular quality (refer section 3 of
the template below). For example for Q8, a sample plan is presented below:

“…To achieve the usability, I would insure that all the functional requirements are clearly defined in the
SRS. Later I would show a prototype to the potential users/ other students/ industry professionals/ supervisor at
a periodic interval of 15 days as a V&V activity…..”

Quality parameters Q1, Q2, Q6 Q7and Q8 are mandatory to be dealt by all project students. Whereas student
can incorporate other (left 7) quality parameters in their project if required, if not required then justify why?

Template of Software Quality (For Final Year B. Tech.- CSE/IT Students)

Section-1: List of quality parameters

Parameter No Name of Quality Parameter

Q1 Understandability
Q2 Completeness
Q3 Conciseness
Q4 Portability
Q5 Consistency
Q6 Maintainability
Q7 Testability
Q8 Usability
Q9 Reliability
Q10 Structuredness
Q11 Efficiency
Q12 Security
Section 2: Description of Quality Parameters

Q1. Understandability –clarity of purpose. This goes further than just a statement of purpose; all of the
design and user documentation must be clearly written so that it is easily understandable. This is obviously
subjective in that the user context must be taken into account: for instance, if the software product is to be used
by software engineers it is not required to be understandable to the layman.

Q2. Completeness –presence of all constituent parts, with each part fully developed. This means that if
the code calls a subroutine from an external library, the software package must provide reference to that library
and all required parameters must be passed. All required input data must also be available.

Q3. Conciseness –minimization of excessive or redundant information or processing. This is important

where memory capacity is limited, and it is generally considered good practice to keep lines of code to a
minimum. It can be improved by replacing repeated functionality by one subroutine or function which achieves
that functionality. It also applies to documents.

Q4. Portability –ability to be run well and easily on multiple computer configurations. Portability can
mean both between different hardware—such as running on a PC as well as a smartphone—and between
different operating systems—such as running on both Mac OS X and GNU/Linux.

Q5. Consistency – uniformity in notation, symbology, appearance, and terminology within itself.

Q6. Maintainability –propensity to facilitate updates to satisfy new requirements. Thus the software
product that is maintainable should be well-documented, should not be complex, and should have spare capacity
for memory, storage and processor utilization and other resources.

Q7. Testability –disposition to support acceptance criteria and evaluation of performance. Such a
characteristic must be built-in during the design phase if the product is to be easily testable; a complex design
leads to poor testability.

Q8. Usability –convenience and practicality of use. This is affected by such things as the human-
computer interface. The component of the software that has most impact on this is the user interface (UI), which
for best usability is usually graphical (i.e. a GUI).

Q9. Reliability –ability to be expected to perform its intended functions satisfactorily. This implies a time
factor in that a reliable product is expected to perform correctly over a period of time. It also encompasses
environmental considerations in that the product is required to perform correctly in whatever conditions it finds
itself (sometimes termed robustness).

Q10. Structuredness –organization of constituent parts in a definite pattern. A software product written
in a block-structured language such as Pascal will satisfy this characteristic.

Q11. Efficiency –fulfillment of purpose without waste of resources, such as memory, space and processor
utilization, network bandwidth, time, etc.

Q12. Security –ability to protect data against unauthorized access and to withstand malicious or
inadvertent interference with its operations. Besides the presence of appropriate security mechanisms such as
authentication, access control and encryption, security also implies resilience in the face of malicious,
intelligent and adaptive attackers.
Section 3: Reporting of the Quality parameters

Q1. Understandability

S No Parameters Value
1 No of Requirements (Functional and Non-Functional)
2 No. of Feasible Requirements
3 No. of Non Feasible Requirements
4 Reasons for Non Feasibility

Q2. Completeness

S No Parameters Value
1 No of Requirements
2 No of Characteristics of your Project. Which one of 1 and 2 is greater? Justify
3 No of Requirements fulfilled
4 No of requirement unfulfilled
5 Reason for Non fulfillment
6 Does any process fail for lack of resources or programming?
7 Are all potential pathways through the code accounted for, including proper
error handling and remedy?

Q3. Conciseness

S No Parameters Value(1-10), 10: Highest

1 Is all code reachable?
2 Is any code redundant?
3 How many statements within loops could be placed outside the
loop, thus reducing computation time?
4 Are branch decisions too complex?
5 How have you involved “Optimization Technique” for your
project?

Q4. Portability

S No Parameters Value(1-10), 10: Highest

1 Strategies for portability: Does your system fulfill any of
following Conditions.
• Installed program files may be transferred to another
computer.
• The program may be reinstalled (from the distribution
files) on another computer.
• The source files may be compiled for another computer.
2 The systems ported between were:
 • Similar systems
• Different operating systems, using similar processors
• Different processors
3 Scale portability of your system out of 10 and what effect it will
have on development cost. Justify.

Q5. Consistency
Describe how there is uniformity in notation, symbology, appearance, and terminology in your
documentation and in coding?

Q6. Maintainability

S No Parameters Value
1 Rate following parameter on the scale of 1-10 ( 10 Highest) for your project
• Ease of correcting defects
• Ease of meeting new requirements
• Ease of making future maintenance easier
• Ease of coping with a changed environment
2 Maintainability Index is calculated with certain formulae from lines-of-code
measures, McCabe measure and Halstead measures. Which one you adopted
and what was the result

Q7. Testability

S No Parameters Value (1-10), 10: Highest

(The testability of software components (modules, classes) is
determined by following factors)
1 What is the degree of Controllability of your module? (ie. The
degree to which it is possible to control the state of the
component under test as required for testing.)

2 What is the degree of observability in your System

ie. The degree to which it is possible to observe (intermediate
and final) test results.
3 What is the degree of isolateability in your System
ie. The degree to which the component under test can be tested
in isolation.
4 How will you define for your Project:
separation of concerns: The degree to which the component
under test has a single, well defined responsibility.
5 How will you define for your Project:
understandability: The degree to which the component under
test is documented or self-explaining.
6 How will you define for your Project:
automatability: The degree to which it is possible to automate
testing of the component under test.
 7 How will you define for your Project:
heterogeneity: The degree to which the use of diverse
technologies requires to use diverse test methods and tools in
parallel.
8 Are you following Test-driven development cycle Y/N

Q8. Usability

S No Parameters Value
1 No of GUI ‘s
2 No of Help Manual
3 No self explanatory error messages.
4 What have you done to help the user
troubleshoot his mistakes himself?
5 Is your Tool/System helpful in other
Application? How?
6 Have you tested the system on real users
using behavioral measurements
7 Are all the user requirements met?

Q9 / Q12. Reliability/ Security

Describe is your project outcome is reliable? If yes , justify. ( i.e the circumstances in which you are sure
that outputs are reliable etc)

Is your project is secure? In what ways? What have to done to ensure the securities?
Have you yourself tried to breach the security to make it more robust?

Q10. Structuredness

For OOD, give LOCM etc

For Non-OOD, Present architecture diagram (Fan-in / Fan-out etc)

Q11. Efficiency

What have you done to ensure that you are not wasting the resources, such as memory, space and processor
utilization, network bandwidth, time?