Acknowledgement

Any Project work has its definite goal that is to be achieved during its time frame. The project is a great opportunity for students to learn about the organizational environment and its work culture. This project is a first step towards the professional career from the student life. I had the greatest opportunity to learn the business ideas and understand the overall working procedure of an organization. There are many helping hands behind the successful completion of my project. I received a remarkable support and inspiration of various valued patrons and I take this opportunity to offer a sincere thanks to all of them. Firstly, I would like to express my gratitude towards MR. Ganesh Man Singh Basnyat, Principal of NCCSHSS Mr. Santosh Raj Maskey, Vice Principal of NCCSHSS, for giving us an opportunity and providing us a proper working environment. I would also like to thank Mr. Prajwal Baniya Chettri, co-ordinator of the NCCSHSS, for providing me a valuable guidance to complete my project titled NCCS Banking System. I would also like to repay my intellectual debt to Mr. Sabin Bajracharya (BIM Program Lectures, NCCS) and Mr. Tek Nath Pokhrel (BIM Program Lectures, NCCS) for providing a healthy and cooperative support and opportunity to prepare this project. I would also like to appreciate the kind support and cooperation of my friends, teachers and senior students for providing me the guidelines and advice, without whom the completion of this project would have been difficult. Lastly, I would like to thank NCCS and Tribhuvan University for running a course like BIM, which is the blend of IT and Management.

Abstract
The main objectives of the project were to gain the real knowledge about an organization and management system of todays business world. During the project period at the NCCS Development Bank we design and developed the Banking system which is a dextop application that uses the concept of Management Information System. This report includes the basic introduction of the organization of the organization under consideration, all the development phase that has been encountered in order to make the system. Information System in todays scenario is required for all the organization whether profitable or non-profitable organization. Computer dependency has simplified our life. the focus of our project is on developing and managing the Bank management system. It can track down the record of student staff, teachers etc, It also manages the all administrative work effectively and efficiently. Since Banking system is being developed according to the requirement of the organization, it can do performed user registration, staff, members registration, account information, tracks effectively all the account holders and members information. The provision of posting news and articles made the system updateable. Besides these there also the messaging features that can be implemented on the local network.

Contents
Introduction ................................................................................................................. 4 Background of study ..................................................................................................... 4 Proposed system ........................................................................................................... 5 Software Development Life Cycle Management .............................................................. 5 Requirements Phase .................................................................................................. 5 Analysis Phase .......................................................................................................... 6 Design Phase. ........................................................................................................... 6 Coding/Development Phase. ....................................................................................... 6 Testing Phase. ........................................................................................................... 6 Deployment Phase. .................................................................................................... 7 Maintenance Phase. ................................................................................................... 7 Life cycle model ........................................................................................................... 7 Feasibility Study ....................................................................................................... 9 Requirements analysis and specification .................................................................... 10 Design ................................................................................................................... 10 Coding and unit testing ............................................................................................ 11 Integration and system testing ................................................................................... 11 Maintenance Phase .................................................................................................. 12 Verification and Validation ...................................................................................... 12 System decommissioning ......................................................................................... 13 List of figures ............................................................................................................. 13 Gantt chart ............................................................................................................ 13 User Interface ....................................................................................................... 14 Login interface ...................................................................................................... 15 Activity flowchart of ATM ...................................................................................... 16 Interface for billing ................................................................................................ 17 Conclusion ................................................................................................................. 18 Bibliography .............................................................................................................. 19 Abbreviation .............................................................................................................. 20

Introduction
NCCS Development Bank, is a highly professional and experienced Bank based in Kathmandu which was established in 1999.It comprises of multitalented professionals considered among the best in the industry. It provides the banking facilities to all customer from household to industry, not only to face the challenges of the fast-moving industry but also to perform exceedingly well. NCCS Development Bank is fully dedicated in providing the highly sophisticated facilities to the entire customer. It is affiliated with in B Grade under the Nepal Rastra Bank. In this regard it is conducting the different cooperatives as a sister concern. It is since working for the national development.

Background of study
Since its establishment as a Bank it has been using the traditional system of information system. It is facing the problem in deploying the information to the Account holders and the outsiders. Before there was only one branch for the transaction, now it is taking charge of cooperative too which is known as National Creative Cooperatives which is a sister concern of NCCS Development Bank (NCCS). Now it has to handle the large amount of data regarding the information of the Bank. The old system used in NCCS is handling the information manually in files using human manpower. NCCS Development Bank (NCCS) is a highly professional and maintained bank. NCCS is using old and traditional way of handling the information. It is facing the problems and errors during its day to day activities. Now NCCS need to change its traditional way of keeping and handling information. For eradicating the existing problem, we have suggested a system described as below.

Proposed system
Now we have proposed a system for NCCS information system on the basis of its feasibility, requirements etc. We have proposed a automatic information system based on web technology. Any person or user can access our interface using internet and can get information desired. We have given administration facilities to the Bank administration such as content management, security, etc. User can only access information and do not have administrative rights. User can login by their login id and password provided by Bank and can also download Bank prospectus and old questions. We have added some new facilities from which Bank will be benefitted in future.

Software Development Life Cycle Management

The TIGTA Application Development Team follows a standard Software Development Life Cycle (SDLC) for the development of all TIGTA software applications. The SDLC is composed of seven phases:

Requirements Phase; Analysis Phase; Design Phase; Coding/Development Phase; Testing Phase; Deployment Phase; Maintenance Phase.

Requirements Phase
During the Requirements Phase, automation needs of the business functions are collected and quantified. The requirements include business rules that govern the work of the user,

definition of specific business functions or processes, and levels of security needed to protect the business information. During this phase, a Change Control Board (CCB) is established. This Board is comprised of business function and OIT representatives. The CCB receives all

proposed changes to the requirements, decides if the proposed change should be applied to the system and if accepted, places a priority on the incorporation of the change to the system.

Analysis Phase
In the analysis phase the requirements gathered in the requirements phase, are used to create report definitions and layouts, screen definitions and layouts, data element definitions, workflow diagrams, and security matrices. logical model of the application. This phase culminates in the creation of a

Design Phase.
In the design phase the logical model developed in the analysis phase, is used to develop a physical model of the application. The physical model contains business object logic, database schemas identifying relationships, web object design and layout, report calculations and processing, and the security object definition.

Coding/Development Phase.
In the coding/development phase the individual objects or components of the application are coded from the physical model. Once the system objects have been developed, they are gathered and connected together (integrated) to create a working application. The integrated application is placed on a staging server for testing.

Testing Phase.
The testing phase encompasses three testing stages; component testing, requirements testing, and acceptance testing. During component testing, all objects are tested to ensure they work together as specified by the physical design. Once the components are tested and the system operates as designed, the application is tested against the requirements gathered in the requirements phase of development. Once the requirements testing stage is completed, the system is presented to the business function for acceptance testing. In all testing stages, defects are identified and returned to the development/coding phase for correction.

Deployment Phase.
The deployment phase contains two stages, a three- to six-month pilot followed by a national deployment. At the conclusion of the pilot, the finished application is placed on a production server. Users are trained, user guides are delivered, and the system is distributed nationally. The application is then maintained by the TIGTA Central Support Facility (TCSF).

Maintenance Phase.
In the maintenance phase the deployed application is maintained through scheduled backups. Any changes to the application are presented to the Change Control Board for approval. If a change or enhancement has been approved by the CCB, it is presented to the Requirements Team and the software development life cycle begins again.

Life cycle model

A software life cycle model (also called process model) is a descriptive and diagrammatic representation of the software life cycle. A life cycle model represents all the activities required to make a software product transit through its life cycle phases. It also captures the order in which these activities are to be undertaken. In other words, a life cycle model maps the different activities performed on a software product from its inception to retirement. Different lifecycle models may map the basic development activities to phases in different ways. Thus, no matter which life cycle model is followed, the basic activities are included in all life cycle models though the activities may be carried out indifferent orders in different life cycle models. During any life cycle phase, more than one activity may also be carried out. For example, the design phase might consist of the structured analysis activity followed by the structured design activity.

The need for a software life cycle model

The development team must identify a suitable life cycle model for the particular project and then adhere to it. Without using of a particular life cycle model the development of a software product would not be in a systematic and disciplined manner. When a software product is being developed by a team there must be a clear understanding among team members about when and what to do. Otherwise it would lead to chaos and project failure. This problem can

be illustrated by using an example. Suppose a software development problem is divided into several parts and the parts are assigned to the team members. From then on, suppose the team members are allowed the freedom to develop the parts assigned to them in whatever way they like. It is possible that one member might start writing the code for his part, another might decide to prepare the test documents first, and some other engineer might begin with the design phase of the parts assigned to him. This would be one of the perfect recipes for project failure.

A software life cycle model defines entry and exit criteria for every phase. A phase can start only if its phase-entry criteria have been satisfied. So without software life cycle model the entry and exit criteria for a phase cannot be recognized. Without software life cycle models (such as classical waterfall model, iterative waterfall model, prototyping model, evolutionary model, spiral model etc.) it becomes difficult for software project managers to monitor the progress of the project.

Different software life cycle models

Many life cycle models have been proposed so far. Each of them has some advantages as well as some disadvantages. A few important and commonly used life cycle models are as follows: Classical Waterfall Model Iterative Waterfall Model Prototyping Model Evolutionary Model Spiral Model

Fig: Classical Waterfall Model

Feasibility Study
The main aim of feasibility study is to determine whether it would be financially and technically feasible to develop the product. At first project managers or team leaders try to have a rough understanding of what is required to be done by visiting the client side. They study different input data to the system and output data to be produced by the system. They study what kind of processing is needed to be done on these data and they look at the various Constraints on the behaviour of the system. After they have an overall understanding of the problem they investigate the different solutions that are possible. Then they examine each of the solutions in terms of what kind of resources required, what would be the cost of development and what would be the development time for each solution. Based on this analysis they pick the best solution and determine whether the solution is feasible financially and technically. They check whether the customer budget would

meet the cost of the product and whether they have sufficient technical expertise in the area of development.

Requirements analysis and specification

The aim of the requirements analysis and specification phase is to understand the exact requirements of the customer and to document them properly. This phase consists of two distinct activities, namely Requirements gathering and analysis, and Requirements specification

The goal of the requirements gathering activity is to collect all relevant information from the customer regarding the product to be developed. This is done to clearly understand the customer requirements so that in completeness and inconsistencies are removed. The requirements analysis activity is begun by collecting all relevant data regarding the product to be developed from the users of the product and from the customer through interviews and discussions. For example, to perform the requirements analysis of a business accounting software required by an organization, the analyst might interview all the accountants of the organization to ascertain their requirements. The data collected from such a group of users usually contain several contradictions and ambiguities, since each user typically has only a partial and incomplete view of the system. Therefore it is necessary to identify all ambiguities and contradictions in the requirements and resolve them through further discussions with the customer. After all ambiguities, inconsistencies, and incompleteness have been resolved and all the requirements properly understood, the requirements specification activity can start. During this activity, the user requirements are systematically organized into a Software Requirements Specification (SRS) document. The customer requirements identified during the requirements gathering and analysis activity are organized into a SRS document. The important components of this document are functional requirements, the non functional requirements, and the goals of implementation.

Design
The goal of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language. In

10

technical terms, during the design phase the software architecture is derived from the SRS document. Two distinctly different approaches are available: the traditional design approach and the object-oriented design approach. Traditional design approach Traditional design consists of two different activities; first a structured analysis of the requirements specification is carried out where the detailed structure of the problem is examined. This is followed by structured design activity. During structured design, the results of structured analysis are transformed into the software design. Object-oriented design approach In this technique, various objects that occur in the problem domain and the solution domain are first identified, and the different relationship that exist among these objects are identified. The object structure is further refined to obtain the detailed design.

Coding and unit testing

The purpose of the coding and unit testing phase (sometimes called the implementation phase) of software development is to translate the software design into source code. Each component of the design is implemented as a program module. The end-product of this phase is a set of program modules that have been individually tested. During this phase, each module is unit tested to determine the correct working of all the individual modules. It involves testing each module in isolation as this is the most efficient way to debug the errors identified at this stage.

Integration and system testing

Integration of different modules is undertaken once they have been coded and unit tested. During the integration and system testing phase, the modules are integrated in a planned manner. The different modules making up a software product are almost never integrated in one shot. Integration is normally carried out incrementally over a number of steps. During each integration step, the partially integrated system is tested and a set of previously planned modules are added to it. Finally, when all the modules have been successfully integrated and

11

tested, system testing is carried out. The goal of system testing is to ensure that the developed system conforms to its requirements laid out in the SRS document. System testing usually consists of three different kinds of testing activities: testing: It is the system testing performed by the development team. testing: It is the system testing performed by a friendly set of customers. Acceptance testing: It is the system testing performed by the customer himself after the product delivery to determine whether to accept or reject the delivered product. System testing is normally carried out in a planned manner according to the system test plan document. The system test plan identifies all testing related an activity that must be performed, specifies the schedule of testing, and allocates resources. It also lists all the test cases and the expected outputs for each test case.

Maintenance Phase
Maintenance of a typical software product requires much more than the effort necessary to develop the product itself. Many studies carried out in the past confirm this and indicate that the relative effort of development of a typical software product to its maintenance effort is roughly in the40:60 ratio. Maintenance involves performing any one or more of the following three kinds of activities: Correcting errors that were not discovered during the product development phase. This is called corrective maintenance. Improving the implementation of the system, and enhancing the functionalities of the system according to the customers requirements. This is called perfective maintenance. Porting the software to work in a new environment. For example, porting may be required to get the software to work on a new computer platform or with a new operating system. This is called adaptive maintenance.

Verification and Validation

Verification: Are we building the product right?

12

The software should conform to its specification. The process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase and form formal proof of program correctness.

Validation: Are we building the right product? The software should do what the user really requires. The process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements.

System decommissioning
System decommissioning means taking the system out of service after the end of its useful operational lifetime. For hardware system this may involve disassembling and recycling materials or dealing with toxic substances. Software has no physical decommissioning problem, but some software may be incorporated in a system to assist with the decommissioning process. For eg: software may be used to monitor the state of hardware components when the system is decommissioned component that are not worn can therefore be identify and reuse in other systems. If the data in the system that is being decommissioned is still valuable to our organization, you may have to convert it for use by some other system. This can often involve significant cost as the data structure may be implicitly defined in the software itself. You have to analyse the software to discover how the data is structured and then write a program to reorganize the data into the required structure for the new system.

List of figures
Gantt chart
A Gantt chart is a horizontal bar chart developed as a production control tool in 1917 by Henry L. Gantt, an American engineer and social scientist. Frequently used in project

13

management, a Gantt chart provides a graphical illustration of a schedule that helps to plan, coordinate, and track specific tasks in a project.

Fig: Gantt chart

User Interface
The user interface is built to interact the system in the initial phase.

14

Login interface
Login interface is use to login in in the bank system

15

Activity flowchart of ATM

Fig: flow chart of ATM

16

Interface for billing

17

Conclusion
In this way, we have proposed a system for NCCS information system on the basis of its feasibility, requirements etc. We have proposed a automatic information system based on web technology. Any person or user can access our interface using internet and can get information desired. We have given administration facilities to the Bank administration such as content management, security, etc. User can only access information and do not have administrative rights. User can login by their login id and password provided by Bank and can also download Bank catalogue. We have added some new facilities from which Bank will be benefitted in future.

18

Bibliography
Albrecht, A. J. (1979). Measuring application development productivity. Alexander, C. S. (1977). a pattern language. oxford university press. Beginning php5,Apache,MySql web development. (2005). Database concept. Mcgraw Hill. R, A. (1983). Program design by informal english description. Comm.ACM. Sommervile. (2006). Software engineering. Pearson Education.

(Beginning php5,Apache,MySql web development, 2005) (Database concept)

Websites www.google.com www.bing.com www.agilemodeling.com www.patton-patton.com www.ehow.com en.wikipedia.org

19

Abbreviation
TU Tribhuvan University

BIM
IT NCCSCS

Bachelor in Information Management

Information technology NCCS Computer System

CIS ERD DFD

UML SWOT PHP HTML SQL SDLC MIS

College Information System Entity Relation Diagram Data Flow Diagram

Unified Modeling Language
Strength Weakness Opportunity and Threat Hypertext Preprocessor Hyper Text Mark up Language Structure Query Language System Development Life Cycle Management Information System

RAD

Rapid Application Development

20