Posts: 133
Threads: 62
Joined: May 2011
ABSTRACT
With advancement of technology and human brain it becomes very difficult to gather all views of each individual and then proceed according to some strategy planned out over these views.
So, it become quite natural a mismanaged way of handling such important task for which only management is responsible. Looking into his problem, the need of computerization was looking a good step into picture, which is very systematic way of handling such huge information.
The development of this project was taken in to consideration the key objective of managing the information coming from different sources to be displayed for an screen viewing of the database, analyzing the system and designing the system in such a way that it can meet out user’s utmost requirement. The result of all the information is given in the form of enquiry screen which help the user in decision-making.
The system is developed using VB and MS Access. So, this contain all the features of VB which makes the system much faster accurate and easy to understand and also the software is designed in a user friendly way. Helpful message are also displaying in the system whenever one face the problem.
Requirement Specification
An organization in its daily routine deals with various departments. At the time of booking, the marketing & IT department members face various problems. Problems encountered with the existing system depends upon manual operation, that is, all the records are kept in single files and thus the data is maintained. But any minor mistake may lead to a major problem.
The Projects are of various kinds and maintaining the details and information manually in an efficient manner is quite difficult.
The problems encountered in the manual system at the time of dealing with projects are as under: -
1. Maintaining Applicant details: - It becomes very difficult to track of details of all applicants manually in an organization.
2. Irregularity in keeping records: - Due to manual errors, there are irregularities in keeping the exact records.
3. Searching of Records: - Searching of a particular record within all records becomes very difficult task.
4. A large staff is needed for proper maintenance of records.
5. Incorrect entry / handling of records also become an obstacle in maintenance of records.
6. Organization has to keep up a lot of files for records. So, it is very cumbersome to maintain all the files.
7. Manual work done is not always correct and becomes too late.
Keeping all these problems under focus it was decided to generate a computerized Real Estate system that will automate the complete procedure of keeping records and provide functionalities to overcome these problems. The ultimate goal of developing this system is to provide effective maintenance and smooth functioning of keeping record.
Implementation
Conversion Strategies:--
Parallel conversion
The old system is used along with the new system for a predetermined period of time.
It minimizes risk of the failure of the new system.
It is costly because of the expenses associated with running two systems.
Direct cutover (=cold turkey) conversion
The old system is discarded, and the new one takes over the entire business operation.
It is highly risky, but can be inexpensive, if successful.
Phased conversion
A System is broken up into functional modules that can be phased into operation one at a time.
It keeps risk fairly low.
It can delay the full implementation of the new system.
Pilot conversion
The new system is introduced in a single unit for a predetermined period of time before it is implemented in other business units.
It reduces risks.
It can delay the full implementation of the new system.
Stubs
Stub programming is the implementation analogue of top-down and stepwise refinement. It supports incremental program development by allowing for error and improvement. A stub program is a stripped-down, skeleton version of a final program. It doesn't implement details of the algorithm or fulfill all the job requirements. However, it does contain rough versions of all subprograms and their parameter lists. Furthermore, it can be compiled and run. Extensive use of procedures and parameter are the difference between stub programs and prototypes. Quick and dirty prototypes should be improved--they should be rewritten. A stub program helps demonstrates that a program's structure is plausible. Its procedures and functions are unsophisticated versions of their final forms, but they allow limited use of the entire program. In particular, it may work for a limited data set. Often the high-level procedures are ready to call lower-level code, even if the more detailed subprograms haven't even been written. Such sections of code are commented out. The comment brackets can be moved, call by call, as the underlying procedures are actually written.
Incremental program development:
As program become more complex, changes have a tendency to introduce unexpected effects. Incremental programming tries to isolate the effects of changes. We add new features in preference to adding new functions, and add new function rather than writing new programs. The program implementation model becomes:
--- define types/compile/fix;
--- add load and dump functions/compile/test;
---add first processing function/compile/test/fix;
--- add features/compile/test/fix;
---add second processing function/compile/test/fix;
---keep adding features/and compiling/and testing / and fixing.
This application uses Direct Cutover (=turkey conversion) strategy: --
The old system is discarded, and the new one takes over the entire business operation.
It is highly risky, but can be inexpensive, if successful.
Since the older system was totally manual we have replaced the whole system with the newer one that is fully computerized.
TESTING (Testing Techniques and Testing Strategies)
We have tested each module separately i.e. have completed unit testing first and system testing was done after combining /linking all different Modules with different menus and thorough testing was done. Testing is a very important part of SDLC and takes approximately 50%of the time.
Once the system is a live one, Maintenance phase is important. Service after sale is a must and users/ clients must be helped after the system is implemented. If he/she faces any problem in using the system, one or two trained persons from developer’s side can be deputed at the client’s site, so as to avoid any problem and if any problem occurs immediate solution may be provided.
SYSTEM TESTING:
Testing: Testing involves executing the program (or part of it) using sample data and inferring from the output whether the software performs correctly or not. This can be done either during module development (unit testing) or when several modules are combined (system testing).
Defect Testing: Defect testing is testing for situation where the program does not meet its functional specification. Performance testing tests a system's performance or reliability under realistic loads. This may go some way to ensuring that the program meets its non-functional requirements.
Debugging: Debugging is a cycle of detection, location, repair and test. Debugging is a hypothesis testing process. When a bug is detected, the tester must form a hypothesis about the cause and location of the bug. Further examination of the execution of the program (possible including many returns of it) will usually take place to confirm the hypothesis. If the hypothesis is demonstrated to be incorrect, a new hypothesis must be formed. Debugging tools that show the state of the program are useful for this, but inserting print statements is often the only approach. Experienced debuggers use their knowledge of common and/or obscure bugs to facilitate the hypothesis testing process. After fixing a bug, the system must be reset to ensure that the fix has worked and that no other bugs have been introduced. This is called regression testing. In principle, all tests should be performed again but this is often too expensive to do.
Preparation of test data:
Testing needs to be planned to be cost and time effective. Planning is setting out standards for tests. Test plans set out the context in which individual engineers can place their own work. Typical test plan contains:
>Overview of testing process.
>Requirements traceability (to ensure that all requirements are tested)
>List of item to be tested
>Schedule
>Recording procedures so that test results can be audited
>Hardware and software requirements
>Constraints
OVERVIEW OF TESTING STRATEGIES:
Large system usually tested using a mixture of strategies. Different strategies may be needed for different parts of the system or at a stage of the process.
Top-down testing:
This approach tests high levels of system before detailed components. This is an appropriate when developing the system top-down likely to show up structural design errors early (and therefore cheaply) has advantage that a limited, working system available early on. Validation (as distinct from verification) can begin early. Its disadvantage is that stubs needs to be generated (extra effort) and might be impracticable if component is complex. Test output may be difficult to observe (needs creation of artificial environment). This is not appropriate for OO systems (except within a class).
Bottom-up testing:
This is opposite of top-down testing. This testing test low-level unit then works up hierarchy. Its advantages and disadvantages of bottom-up mirror those of top-down. In this testing there is need to write test drivers for each unit. These are as reusable as the unit itself. Combining top-down development with bottom-up testing means that all parts of system must be implemented before testing can begin, therefore does not accord with incremental approach discussed above. Bottom-up testing less likely to reveal architectural faults early on. However, bottom-up testing of critical low-level components is almost always necessary. Appropriate for OO systems.
Stress testing:
Test system's ability to cope with a specified load (e.g. transactions per second). Plan tests to increase load incrementally. Go beyond design limit until system fails (this test particularly important for distributed systems (check degradation as network exchange data).
Back-to-back testing:
Comparison of test results from different versions of the system (e.g. compare with prototype, previous version or different configuration). Process - Run first system, saving test case results. Run second system, also saving its results. Compare results files. Note that no difference doesn’t imply no bugs. Both systems may have made the same mistake.
Defect testing:
A successful defect test is a test that causes the system to behave incorrectly. Defect testing is not intended to show that a program meets its specification. If tests don't show up defects it may mean that the tests are not exhaustive enough. Exhaustive testing is not always practicable. Subset has to be defined (this should be part of the test plan, not left to the individual programmer). Possible methods:
>Usual method is to ensure that every line of code is executed at least once.
>Test capabilities rather than components (e.g. concentrate on tests for data loss over ones for screen layout).
>Test old in preference to new (users less affected by failure of new capabilities).
>Test typical cases rather than boundary ones (ensure normal operation works properly).
Three approaches to defect testing. Each is most appropriate to different types of component. Studies show that black box testing is more effective in discovering faults than white-box testing. However, the rate of fault detection (faults detected per unit time) was similar for each approach. Also showed that static code reviewing was more effective and less expensive than defect testing.
Black-box (Functional) Testing:
Testing against specification of system or component. Study it by examining its inputs and related outputs. Key is to devise inputs that have a higher likelihood of causing outputs that reveal the presence of defects. Use experience and knowledge of domain to identify such test cases. Failing this a systematic approach may be necessary. Equivalence partitioning is where the input to a program falls into a number of classes. E.g. positive numbers vs. negative numbers. Programs normally behave the same way for each member of a class. Partitions exist for both input and output. Partitions may be discrete or overlap. Invalid data (i.e. outside the normal partitions) is one or more partitions that should be tested. Test cases are chosen to exercise each portion. Also test boundary cases (atypical, extreme, zero) since these frequently show up defects. For completeness, test all combinations of partitions. Black box testing is rarely exhaustive (because one doesn't test every value in an equivalence partition) and sometimes fails to reveal corruption defects caused by "weird" combination of inputs. Black box testing should not be used to try and reveal corruption defects caused, for example, by assigning a pointer to point to an object of the wrong type. Static inspection (or using a better programming language!) is preferable for this.
White-box (structural) Testing:
Testing based on knowledge of structure of component (e.g. by looking at source code). Advantage is that structure of code can be used to find out how many test case need to be performed. Knowledge of the algorithm (examination of the code) can be used to identify the equivalence partitions. Path testing is where the tester aims to exercise every independent execution path through the component. All conditional statements tested for both true and false cases. If a unit has n control statements, there will be up to 2n possible paths through it. This demonstrates that it is much easier to test small program units than large ones. Flow graphs are a pictorial representation of the paths of control through a program (ignoring assignments, procedure calls and I/O statements). Use flow graph to design test cases that execute each path. Static tools may be used to make this easier in programs that have a complex branching structure. Tools support. Dynamic program analyzers instrument a program with additional code. Typically this will count how many times each statement is executed. At end, print out report showing which statements have and have not been executed. Problems with flow graph derived testing:
> Data complexity not taken into account.
> Does not test all paths in combination.
> Really only possible at unit and module testing stages because beyond that complexity is too high.
Interface testing:
Usually done at integration stage when modules or sub-systems are combined. Objective is to detect errors or invalid assumptions about interfaces between modules. Reason these are not shown up in unit testing is that test case may perpetuate same incorrect assumption made by module designer. Particularly important when OO development has been used. Four types of interface:
1. Parameter: data (or occasionally function references) passed from one unit to another.
2. Shared memory: block of memory shared between units (e.g. global variable) .One places data there and the other retrieves it.
3. Procedural: object-oriented or abstract data type form of interface, encapsulating several procedures.
4. Message passing: one sub-system requests a service by passing a message. Client-server interface also used by some OO architectures.
Three common kinds of interface error:
>Interface misuse: caller gives wrong number/types/order of parameters or sends invalid message.
>Interface misunderstanding: caller misunderstanding specification of called component and provides or receives data in legal but unexpected form.
> Timing errors: producer/consumer of data operates at different speeds and data is accessed before being ready. "Race conditions".
Common manifestations are when each unit assumes the other one is checking for invalid data (failure to check return status) and the consequences of when such a fault is propagated to other units.
Testing with live data
1. DUPLICACY:--
By entering the data in the data base we just make sure that data is not duplicated and found system don’t accept duplicated values
2. UNIQUE RECORDS:-
Constraints applied to the system are checked for uniqueness and found they are working properly.
3. BACKUPS & RECOVERY:-
The system takes auto back ups of the records which are stored in the log file of the SQL server .This can be a convenient and handy tool in case of accidental data erasures.
4. Unauthorised Access:-
Unauthorized access is protected with the help of proper passwords.
5. NULL RECORDS:--
The system does not allow null record entries, the validation implemented will deliver an illegal object error if the record being retrieved or searched is null in the database, therefore enforcing entity integrity at all points of time.
6. VALIDATED DATA ENTRY
Appropriate Message will be provided by the system.
Get the full report here:
http://4sharedget/mjwGkbiq/Real_Estate_Project_Report.html
