Submitted by: - submitted to:

Deepty mam Narendra Kumar

Reg. no. 10809874
Section: E3803
Roll no. A17

Q1. Explain the complete coding process for hostel management system for your
University.
Ans: - 1. Student account creation
This section provides an online form to the students which can be filled by them, and a
copy of the filled page can be taken in the printed form. This is later submitted to the
Hostel authorities who can be verified by them before allotting them to the respective
hostels.
Code
<?php
session_start();
$a=$_POST["user1"];
$b=$_POST["pass1"];
$c=$_POST["pass1"];
$_SESSION['user1']=$user1;
$_SESSION['pass1']=$pass1;
$cc=mysql_connect("localhost","root","");
mysql_select_db("hostel");
$abc="CREATE TABLE IF NOT EXISTS 'adm_account'(
'id' INT(20) NOT NULL AUTO_INCREMENT,
'user' VARCHAR(60) NOT NULL,
'pass' VARCHAR(60) NOT NULL,
'pass_r' VARCHAR(60) NOT NULL,PRIMARY KEY('id'))";
mysql_query($abc);
$sql="insert into adm_account (user,pass,pass_r) values ('$user1','$pass1','$pass1')";
mysql_query($sql);
mysql_close($cc);
?>

2. Administrator Login
The Administrator can:
1. Allot different students to the different hostels.
2. Vacate the students for the hostels.
3. Control the status of the fee payment.
4. Edit the details of the students & modify the student records.
Code
<?
session_start();
if(isset($_REQUEST['sub1']))
{
$user=$_REQUEST['user1'];
$pass=$_REQUEST['pass1'];
$cc=mysql_connect("localhost","root","");
mysql_select_db("hostel");
$sql="SELECT * FROM adm_account where user1='$user' AND pass1='$pass'";
$res=@mysql_query($sql);
//$a=@mysql_affected_rows();
//if($a>=1)
$num=mysql_num_rows($res);
if($num>0)
{
$_SESSION['pass']=$pass;
$_SESSION['user']=$user;
header("location:admin_home.php");
}
else
{
$flag=1;
$msg="Wrong username or password";
}
}
3. Application form
4. Allotment
There will be pre-defined criteria for the admission to the hostels. He checks the attested
Application forms of the students obtained from the internet and varify it with the student
database. If the students are found eligible then they are allotted to the hostel.
Code
function validate(f)
{
if((f.user.value=="")||(f.user.value.length<5))
{
alert("Please enter a valid username");
f.user.focus();
return false;
}
if((f.pass.value=="")||(f.pass.value.length<6))
{
alert("Please enter a valid password");
f.pass.focus();
return false;
}
return true;
}

5. Vacating and editing

As the student’s course is over they will vacate their rooms. So it is required for the
administrator to remove their records from the database tables. This section includes the
option for the room vacation and the deletion of the particular record from the database.
Code
<?php
session_start();
if(!(isset($_SESSION['user'])) && !(isset($_SESSION['pass'])))
header("location:index.php");
include_once("include_files/db.php");
$con=new dbconnect();
$con->open();
//accepting values from form and inserting them into database
if(isset($_REQUEST['edit']))
{
//receives data from current form
$year=$_REQUEST['year'];
$message="For"." "."-".$year.""."Batch";
$table=$year.'r';
$f1=0;
$f2=0;
$table_a=$year.'a';
$sql="SELECT * FROM $table_a";
$result=@mysql_query($sql);
$total_num=@mysql_num_rows($result);
if($total_num<=0)
{
$f1=1;
}
$table_i=$year.'i';
$sql="SELECT * FROM $table_i";
$result=@mysql_query($sql);
$total_num=@mysql_num_rows($result);
if($total_num<=0)
{
$f2=1;
}
$s_code=substr($sem,1,1);
$stud_num=$_REQUEST['stud_num'];
for($i=1;$i<=$stud_num;$i++)
{
$id[$i]=$_POST["id".$i];
$roll_no[$i]=$_POST["roll_no".$i];
$reg_no[$i]=$_POST["reg_no".$i];
$name[$i]=$_POST['name'.$i];
$email[$i]=$_POST['email'.$i];
}
for($i=1;$i<=$stud_num;$i++)
{
$sql="UPDATE $table SET
roll_no='{$roll_no[$i]}',reg_no='{$reg_no[$i]}',name='{$name[$i]}',
email='{$email[$i]}' WHERE id='{$id[$i]}'";
$con->update($sql);
if($f1==0)
{
$sql_a="UPDATE $table_a SET roll_no='{$roll_no[$i]}',name='{$name[$i]}'
WHERE id='{$id[$i]}'";
$con->update($sql_a);
}
if($f2==0)
{
$sql_i="UPDATE $table_i SET roll_no='{$roll_no[$i]}',name='{$name[$i]}'
WHERE id='{$id[$i]}'";
$con->update($sql_i);
}
}
header("location:stud_edit.php?year={$year}");
}
if(isset($_REQUEST['delete']))
{
$year=$_REQUEST['year'];
$table=$year.'r';
$sql="DROP TABLE $table";
@mysql_query($sql);
header("location:admin_home.php");
}
?>
Code of Storing values from database
$i=1;
while($row=@mysql_fetch_array($result))
{
$id[$i]=$row['id'];
$roll_no[$i]=$row['roll_no'];
$reg_no[$i]=$row['reg_no'];
$name[$i]=$row['name'];
$email[$i]=$row['email'];
$i++;
}

6. Notice Board
All the 9 hostels have their Notice boards. Any change in the Hostel fee, mess fee will be
shown in this. It can be also used for different notifications.

Q2. As a project manager, issue basic guidelines to your debuggers, developers

in context of testing of your project.

 Ans: - Know how to debug multithreaded applications.

 Introducing threads to a program can cause it to fail in new ways. Everything that
you do in a single-threaded environment to help debug applications become more
important as the number of threads increases. For example, you might not always
catch the error at the point it occurs. Usually the error is caught later, possibly in
another thread. In these situations, you cannot even walk back up the call stack to
find the problem; the error was in another thread, with another stack. Being as
proactive as possible will help the debugging process in general.

 Learn how to do remote debugging.

Remote debugging occurs when you want to debug a problem that is occurring on
another computer while continuing to work from your own computer. Developers
frequently do this when a segment of code runs fine on their own computer but
crashes on another system. They may want to debug it on the other system
remotely, without having to go sit in front of the other computer. For more
information.

 Learn to debug on live servers.

Debugging procedures are different when you are trying to debug code on a live
server that customers are accessing. This is getting more common as more code is
written for the Web. For more information, see "Troubleshooting Common
Problems with Applications: Debugging in the Real World".

 Comment all bug fixes.

When you fix a bug, include in the code a version number, bug ID, and your alias.
If someone looks at the code afterward and has a question about the fix, they can
contact you for information.

 Review all bug fixes.

You should code review all fixes. Get at least one other person to examine your
code —a peer review.

 Verify subtle bug fix before check-in.

Avoid fixing the same bug twice. Use a build to verify that the fix is correct,
especially for subtle bugs.

 Use a test release document to report all bug fixes.

Coordinate with test team by documenting all your bug fixes in a test release
document (TRD) and sending it to the test team in e-mail.

 Use Symbol Server to index and archive your product symbols.

 By permitting Symbol Server to index and archive your product symbols, you
make debugging from any system, including customer systems, fast and easy.

Q3. Write down the basic standards you will follow while coding in your project.

Ans: - the basic standards that we follow while coding in our project are:-

1. We use source control.

2. We can make a build in one step.
3. We make daily builds.
4. We have a bug database.
5. We fix bugs before writing new code.
6. We have an up-to-date schedule.
7. We have a spec.
8. Programmers have quiet working conditions.
9. We use the best tools money can buy.
10. We have testers.
11. New candidates write code during their interview.
12. We do hallway usability testing.

PART B
Q1. Create black/white box testing document for your software project.

Ans:- Black Box testing of a software is based on two primary things –

1. Customer Requirements Document
2. Functionality of the software

Purpose of the Black Box Testing is to ensure, that means, that –

1. The software meets are customer requirements as specified in the Customer
Requirements Document (business needs)
2. And the software meets user requirements (user needs)
By user requirements we don’t mean that it has to meet every user’s requirements but
more appropriately the appropriate usage requirements.

Black Box Testing is the most widely used testing and is used to used to check if the
product meets per se customer’s all requirements. The tester is not worried about how the
software has been built, what queries have been written, whether the coding is technically
optimal or not, but focuses more as if the customer is working on the system and feels
like customer when he tests the software.

A basic requirement of Black Box Testing is that nothing should be presumed about the
functionality of the software while testing the software, rather the tester is supposed to
check each and every functionality of a unit, module and the product as specified in the
customer requirement document. So the fundamental of this testing is the Customer
Requirement Document, based on which the appropriate test plan, test cases and test
scenarios are built and ultimately test results are drawn as a Test Report (or Bugs Report).

Equivalence Partitioning: This is a technique of testing with minimum of test classes or

data input to identify between valid and invalid input.

Prior to starting actual testing, a tester must verify and validate:

1. Customer Requirements
2. Functional Specifications of the software
3. Test Plan
4. Test Cases
5. Test Data
6. Test case execution

White box testing document

The purpose of any security testing method is to ensure the robustness of a system in the
face of malicious attacks or regular software failures. White box testing is performed
based on the knowledge of how the system is implemented. White box testing includes
analyzing data flow, control flow, information flow, coding practices, and exception and
error handling within the system, to test the intended and unintended software behavior.
White box testing can be performed to validate whether code implementation follows
intended design, to validate implemented security functionality, and to uncover
exploitable vulnerabilities.

White box testing requires access to the source code. Though white box testing can be
performed any time in the life cycle after the code is developed, it is a good practice to
perform white box testing during the unit testing phase.

White box testing requires knowing what makes software secure or insecure, how to
think like an attacker, and how to use different testing tools and techniques. The first step
in white box testing is to comprehend and analyze available design documentation,
source code, and other relevant development artifacts, so knowing what makes software
secure is a fundamental requirement. Second, to create tests that exploit software, a tester
must think like an attacker. Third, to perform testing effectively, testers need to know the
different tools and techniques available for white box testing. The three requirements do
not work in isolation, but together.

The white box provides a graphic depiction of the security testing process. This same
process applies at all levels of testing, from unit testing to systems testing. The use of this
document does not require subscribing to a specific testing process or methodology.
Readers are urged to fit the activities described here into the process followed within their
organization.

The general outline of the white box testing process is as follows:

 1. Perform risk analysis to guide the whole testing process. In Microsoft’s SDL
process, this is referred to as threat modeling [Howard 06].
2. Develop a test strategy that defines what testing activities are needed to
accomplish testing goals.

3. Develop a detailed test plan that organizes the subsequent testing process.

4. Prepare the test environment for test execution.

5. Execute test cases and communicate results.

6. Prepare a report.

In addition to the general activities described above, the process diagram introduces
review cycles, reporting mechanisms, deliverables, and responsibilities.

Q2. Design all the possible test cases to test Windows Media Player Application
of Windows 7 or Windows Vista. User can try to play any kind of file available in
the system so derive the test case accordingly.

Q3. Identify the situations which can cause project failure during testing

Ans: - Poor up-front planning

This is probably the most common problem. If you have ever been on a troubled project,
chances are you looked back and said "We should have spent more time planning."
Projects that start execution without fully understanding the work to be done (and getting
the sponsor to agree) are usually destined for problems. By the time you realize that you
are not in synch with your sponsor, it's usually very difficult to get back on track within
the allocated budget and timeframe.

Incomplete or vague project workplan

Your work plan (schedule) is the roadmap that describes how you are going to complete
the work. You'll have problems if your work plan is at too high a level, incomplete or not
up-to-date. You may get away with it on a small project, but it will be fatal on a larger
effort.

Weak ongoing project management discipline

Some project managers do a great job in the upfront planning process, but then don't
manage the project effectively from that point on. This includes having problems
managing scope change, resolving issues, communicating proactively and managing
project risks.

Inadequate resources
This covers a lot of areas. You may not have the right level of resources because you
didn't estimate the work correctly. You might have estimated the work correctly, but your
management has not allocated the proper level of staffing. It's possible that you have
enough bodies, but you don't have people with the right skill mix. All of these may lead
to major project failures.

People problems

In my experience, people tend to get along fine when the project is on track. However, if
the project gets into trouble, people start to work longer hours, feel more stress, get more
edgy and have more personality conflicts. While it is certainly possible that these
problems are actually causing the project to slip, it is also likely that other problems are
causing the problem and that the people problems are a later symptom.

Lifecycle problems

There are many opportunities for project problems throughout the lifecycle. Many of
these will cascade as the project progresses, leading to major trouble. Examples of
lifecycle problems include:

 A failure to clearly and completely define the requirements, resulting in building

the wrong features or leaving gaps in the features needed.
 New or state of the art technology may cause unanticipated problems.
 A poor technical design is not allowing the solution to be easily modified or is not
scalable.
 Requirements are not frozen late in the project and continued change requests
start to cause the project to drift.
 Technology components do not fit together as designed.
 Poor initial testing techniques cause repeated errors and rework in later tests