LPU

ASSIGNMENT
NO4 OF
PRINCIPLES OF
SOFTWARE
ENGINEERING

SUBMITTED TO- SUBMITTED BY-

MR.AMANDEEP VARUN KATOCH
E3801B53
Q1. Explain the complete coding process for hostel management system for your
University.
Ans:
Codeing:-
<?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(30) NOT NULL,
'pass' VARCHAR(30) NOT NULL,
'pass_r' VARCHAR(30) 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.
Codeing
<?
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 ofStoring 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
Any change in the Hostel fee , food 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.

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.

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.

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

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

Ans:-This feature enables Firefox to hand off content to both web applications (like Google
Calendar) and to local applications that have been registered to handle this type of data (like
Mozilla Sunbird).

There is a large number of such data types and web/local application types. For our testing, we
will try to cover all of the most likely types and popular applications.

The list of popular

data formats and protocols that this feature aims to handle:

 mailto:
 hCalendar, (text/calendar), webcal:
 hCard (text/vcard)
 geo links (application/vnd.google-earth.kml)
 audio feeds (audio/x-mp3)
 video feeds
 RSS
 Image file type
 Application (executable) file type
 callto: protocol

Scope of planned testing

It is not possible to test every version of every application on every OS for every type of
feed/format combination. Doing so would result in a gigantic test matrix. We have instead taken
the view to test the most prominent applications for each of these items on each platform. We
will also run some automated tests against the code to verify that extension authors have the
required abilities to create their own protocol handlers and that users can associate other
applications to handle specific types of content.

Platform and Configurations

We will want to test with the most popular web and platform specific applications for each high-
priority type of format we want to support.
TODO: Is there a need to test cross platform products on more than one platform? Because at
some point, you end up testing that product and not the content handler integration.

Protocol/File Type Windows Apps

 Outlook 2007
mailto:  Windows Mail (Outlook Express)
 Thunderbird

 Outlook 2007
text/calendar  Outlook 2003
hCalendar, webcal:  Windows Calendar (Vista Only)
 Mozilla Lightning or Sunbird

 Outlook 2007
hCard and text/vcard  Outlook 2003
 Thunderbird

* Geo Links (type of microformat)

 TODO: Are there any thick clients for this?
 application/vnd.google-earth.kml

 Windows Media Player

Audio Feeds  iTunes
 (audio/x-mp3)  Real-Player
 TODO: Others?

 Windows Media Player

 iTunes
Video Feeds
 Democracy Player
 Real-Player

 Thunderbird
 RSS reader in Vista Desktop (not possible without changes to
RSS
Firefox)
 RssReader

Image Files  Paint

PDF Files  Adobe Reader

 Skype
callto:
 Gizmo

Asteriks designate items with Test Cases in Litmus

Major Test Areas
Major test areas are to test the applications in the table above with the proper type of content.
We must ensure that the content types are handled appropriately in the handoff between Firefox
and the third party application. We will probably use Litmus to test this

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.

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 sc

alable.

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