PM PRoject

Download as pdf or txt
Download as pdf or txt
You are on page 1of 92

ISO 9001:2000 CERTIFIED INSTITUTION No.

123,Ist Main Road,Kengeri Satellite Town,Bangalore-560 060 Ph:080-2848 5569,Mobile:98800 94725 Centre Code No: 2787 A STUDY ON Sales & Inventory Management by Using Project Management Techniques GOODRICH AEROSPACE INDIA, BANGALORE By

Mr. RAVI HUNGUND


Reg. No: 520947465 Under the guidance of

Prof. SUKANYA HEGDE M.B.A., M.Com


A project report submitted in partial fulfillment of the requirements for Master of Business Administration In Project Management

Sikkim - Manipal University Distance Education wing Syndicate house Manipal 576119 2009

ISO 9001:2000 CERTIFIED INSTITUTION No.123,Ist Main Road,Kengeri Satellite Town,Bangalore-560 060 Ph: 080- 2848 5569, Mobile: 98800 94725

CERTIFICATE
This is to Certify that the dissertation titled A STUDY ON SALES & INVENTORY MANAGEMENT BY USING PROJECT MANAGEMENT

TECHNIQUES GOODRICH AEROSPACE INDIA PVT LTD, BANGAORE Is based on original project study conducted by Mr. RAVI HUNGUND under the Guidance of Prof. SUKANYA HEGDE M.B.A. M.Com.,

This dissertation is original and has formed the basis for the award of any other degree/ diploma by Sikkim Manipal University or any other university.
Date:

Prof. : SUKANYA HEGDE M.B.A. M.Com.,

(Director)

GOODRICH AEROSPACE INDIA PVT LTD.,


TO WHOM SOEVER IT MAY BE CONCERN This is certify that his by Mr. RAVI HUNGUND MBA Student of

National Institute of Management Studies Bangalore has successfully completed his project on A STUDY ON SALES & INVENTORY MANAGEMENT BY USING PROJECT MANAGEMENT TECHNIQUES GOODRICH AEROSPACE INDIA PVT LTD., Us from May 1st 2011 to 29th May 2011 under the Guidance

For GOODRICH AEROSPACE INDIA PVT LTD.

MR. ANANDA KUMAR (Senior Technical Manager)

BONAFIDE CERTIFICATE
Certified that this project report titled A STUDY ON SALES & INVENTORY
MANAGEMENT BY USING PROJECT MANAGEMENT TECHNIQUES is the

bonafide work of RAVI HUNGUND who carried out the project work under my supervision.

SIGNATURE HEAD OF THE DEPARTMENT

SIGNATURE FACULTY IN CHARGE

Examiners Certification
The project report of

Mr. RAVI HUNGUND


A STUDY ON

SALES & INVENTORY MANAGEMENT BY USING PROJECT MANAGEMENT TECHNIQUES ON GOODRICH AEROSPACE INDIA PVT LTD. Is approved and is acceptable in quality and form

Internal Examiner

External Examiners

Student Declaration
I here by declare that the project report entitled A STUDY ON SALES & INVENTORY MANAGEMENT BY USING PROJECT MANAGEMENT TECHNIQUES ON GOODRICH AEROSPACE INDIA PVT LTD. By

Mr. RAVI HUNGUND


Reg. No: 520947465 Submitted in partial fulfillment of the requirements for the degree of Master of business Administration To Sikkim-Manipal University, India, is my original work and not submitted for the award of any other degree, diploma, fellowship, or any other similar title or prizes

Place: BANGALORE

Mr. RAVI HUNGUND

Date: 01/06/2011

Reg. No: 520947465

ACKNOWLEDGEMENTS
I have an immense pleasure in expressing my deepest gratitude to our beloved and highly esteemed institution NATIONAL INSTITUTE OF MANAGEMENT STUDIES MBA student. for giving me an opportunity to become an

I express my profound gratitude to my guide Mrs. Prof. Sukanya

Hedge lecturer and Director of NIMS , Bangalore Sikkim-Manipal


University for her invaluable and tireless guidance and incisive comments, suggestions, without her constant encouragement and help, it would never have been possible for me to complete my project work.

I express my deep sense of gratitude to my external guide Mr Ananda Kumar , Senior Technical Manager, GOODRICH AEROSPACE INDIA PVT LTD. for his timely and convenient guidance for the completion of this project. I thank my friend who helps me to complete this work.

Sales & Inventory Management by Using Project Management Techniques


A Project Report

SMU Roll No. 520947465

CONTENTS
SYNOPSIS . PROBLEMS IN THE EXISTING SYSTEM ...... SCOPE OF PROPOSED PROJECT . USER REQUIREMENTS FEASIBILITY STUDY ....

Page 3 6 11 12 13 17 22 30 34 46 52 59 61 65 67 71 72 75 81 84

......

PROPOSED SYSTEM . ESTIMATION & SCHEDULING ANALYSIS & DESIGN .. INPUT SCREENS .. TABLE SPECIFICATIONS ... TEST PROCEDURES AND IMPLEMENTATION .. MENU TREE ....... USER MANUAL ...... MAINTENANCE ...

PROPOSED ENHANCEMENTS .... CONCLUSION ........ TEST CASES ...... REPORTS ....... GLOSSARY ...... BIBLIOGRAPHY ..

SMU Roll No. 520947465

SYNOPSIS

SMU Roll No. 520947465

SYNOPSIS
Project management concepts, tools & techniques have been studied & applied as appropriate in finding a solution to the operations problem faced by organizations..

Research conducted over the past ten years by the Software Engineering Institute has shown that by improving their software development process, organisations can typically improve software quality by a factor of 4, and software productivity by 25%. In some cases, the actual improvements achieved have been much higher than this.

Schedule estimation is very difficult. When a project is still at the conceptual stage, estimates are likely to be wrong by a factor of four. As the project progresses, the accuracy of estimates generally improves. The amount of work required to complete a project is an exponential function of the size of the job. This is a strong argument for keeping projects as small and simple as possible.

The COCOMO estimation model helps estimate the amount of work required to complete a project based on the size of the job and 16 other factors. Validation of COCOMO on actual projects in the US defense industry has shown that, 80% of the time, it can produce estimates that are accurate within a tolerance of 20%. It would be wise to assume that other estimation techniques are less accurate than this, unless proven otherwise.

In making schedule estimates, one has to assume that the project will be well managed by both the customer and the developer. Poorly-managed projects can consume as much time and money that you can throw into them.

Studies have shown that the quality of physical environment provided for programmers (telephones, freedom from distraction, etc.) significantly influences programmer productivity. It also pays to choose programming staff very carefully, since good

SMU Roll No. 520947465

programmers are typically at least ten times more productive than poor programmers. For similar reasons, its very costly to keep poor performers on the team.

This software is developed using best project management tools and techniques a software for sales and inventory management processes with robust functionality for managing logistics facilities. Support for inventory management helps record and track materials on the basis of both quantity and value. Warehouse inventory management functions cover internal warehouse movements and storage.

Using this software we can reduce cost of warehousing, transportation, order fulfillment, and material handling while improving customer service. Significant improvement can be done in inventory turns, optimize the flow of goods, and shorten routes within warehouse or distribution center. Additional benefits of inventory management include improved cash flow, visibility, and decision making.

This software is user friendly and hence easy to use. Employees can plan, enter, and document warehouse and internal stock movements by managing goods receipts, goods issues, storage, picking, physical stock transfers, and transfer postings.

SMU Roll No. 520947465

Problems in the Existing System

As we know manual system are quite tedious, time consuming and less efficient and accurate in comparison to the computerized system. So following are some disadvantages of the old system:

1. Time consuming

2. Less accurate

3. Less efficient

4. Lot of paper work

5. Slow data processing

6. Not user friendly environment

7. Difficult to keep old records

SMU Roll No. 520947465

Introduction
Modern business relies on computers for the development of new products and services, and also for a continuous improvement in underlying costs. According to a principle known as Moores Law, the microprocessor doubles in power every 18 months. So, while hardware costs were originally the main economic constraint on what could be achieved with computers, software is increasingly the factor that determines the effectiveness of an organisations IT initiatives.

It is widely recognised that over 50% of large software projects fail, where failure means cancellation, large budget overruns, or substantial under-delivery of business functionality. It stands to reason that the management of software projects is therefore a vital ingredient in a companys overall success. Whether a company chooses to develop software in-house or to outsource, it is important to be aware of the main factors that make software projects succeed or fail. As pointed out in the quote at the top of this page, poor management is the main driver behind excessive software development costs.

SMU Roll No. 520947465

Key Elements of a Project


Figure depicts the central theme used in this document. From the project management perspective, the main factors to be managed on a software project (in descending order of criticality) are people, process, and products. Each of these topics is discussed in a separate section of this document. The Software Development Process Much of the recent work on software quality improvement has centred on software process improvement. Broadly speaking, the term software process refers to the pattern of management and technical activities that an organisation uses for developing and maintaining software. For example, some organisations insist that a written specification be produced before programmers start developing a program. Other organizations never use written specifications. One of the key responsibilities of a project manager is to develop a sound development process within the organisation, and then to continuously improve this process. Experience has shown that the most effective way for organisations to improve productivity and quality is by improving their software process. For example, by rigorously implementing a quality plan, Leeds and Northrop reduced software failures by 95% while simultaneously improving productivity by over 300%1. The SEI reports that typical benefits from software process improvement are a 25% productivity increase and a four-fold reduction in software defects2. Where a sound development process is not in place, the success of projects depends entirely on the Herculean efforts of highly talented and hardworking individuals. Software process improvement does not mean that it becomes unimportant for organisations to select and retain talented and well-trained staff; on the contrary, these responsibilities will be carried out in a well-defined, consistent, and documented way when the organisation has a sound development process. However, in the absence of an effective software process, the outcome of software projects is highly variable, and can be drastically harmed by the departure of only one key programmer.

SMU Roll No. 520947465

Project Phases

The distribution of effort (and therefore costs) over different project phases is at variance with common assumptions. Most people (including computer programmers) think that programming is the chief activity on a software development project. None of the literature based on analysing successful projects bears this out. For example, Sommerville8 suggests that in business applications, a typical cost breakdown is:

Requirements and Design: 44% Implementation: 28% Testing: 28%

These figures classify detailed design under requirements and design, rather than under implementation. Arguably, it is equally valid to regard detailed design as an activity that should take place during implementation. In this case, the phase distribution of costs shifts significantly. In Schedules on page 16, we look at a schedule estimation model called COCOMO. This model treats detailed design as part of the implementation phase.
SMU Roll No. 520947465

It also adopts slightly different definitions than Sommerville uses. For this reason, the numbers it uses do not reconcile clearly with those presented by Sommerville.

Requirements
A requirements statement has two audiences: 1. the prospective system users who want to understand the business objectives of the system, and the way it will mesh in with their job responsibilities; and 2. the development team who want large quantities of detailed information about exactly what the system should do. For the requirements statement to be of practical use, it must anticipate the most important technical constraints, and describe the principles that will be of greatest importance in resolving the technical tradeoffs that are likely to arise. In practice, it is not possible to do justice to both audiences at once. The first audience looks for a clear vision of what the system will provide in business terms. The second audience looks for a statement in technology terms that defines the system functionality. The tension between these objectives is best resolved by developing two parallel documents, which could be called:

1. a concept of operation (which states the requirements in business terms); and 2. a requirements specification (which states the requirements more precisely and with more emphasis on technical detail). While each of these documents will be more intelligible to its own intended audience, it is essential for both documents to be totally consistent with one another. This can only be achieved if senior business and technology staff both make the effort to fully understand each of the documents. The concept of operation describes the business rationale for the system, and the ways in which the system will meet business objectives. It can normally be a fairly concise document, crisply setting out how the system functionality will add value to the business.

10

SMU Roll No. 520947465

Scope of Proposed Project


The scope of this project is to provide user efficient working environment and more output can be generated through this. This system provides user friendly interface resulting in knowing each and every usability features of the system.

This system helps in tracking records so that past records can be verified through them and one can make decisions based on the past records. This system completes the work in a very less time resulting in less time consumption and high level of efficiency.

This system is developed in such a way that even a nave user can also operate the system easily. The calculations are made very quickly and the records are directly saved into databases and the databases can be maintained for a longer period of time. Each record can be retrieved and can be verified for the future transactions.

Also this system provides high level of security for data leaking as only admin people can access the database no changes can be made in it until it verifies the user login id and password.

We also have operator login through which operator can take orders but cant make changes in the database. Limited access is available to the operator.

11

SMU Roll No. 520947465

User Requirements

Requirements Specification
The requirements specification will normally be more detailed. The following structure is suitable: Introduction This describes the need for the system and explains how the system meets that need. It should describe how the system fits into the overall business and strategic objectives of the organisation commissioning the software. The system model This identifies and describes the major components in the system. Also, the relationships between these components are described by using suitable diagrams. Functional requirements This section describes the services that the system will provide for its users. Hardware This section describes the kinds of computers, printers, and other devices that the system must support. Database requirements This includes the logical organisation of the data and how it will be obtained. Non-functional requirements These are various constraints under which the system must operate, for example required operating system platforms, development tools, etc. Maintenance information This section should describe anticipated directions in which the system may evolve due to new hardware, changing user requirements, etc. Glossary This helps non-technical users to understand the document, and it also makes the document more precise for technical readers.

12

SMU Roll No. 520947465

Feasibility Study
As we know each and every project needs to have a feasibility study for the complete understandability of the project. We will consider 3 types of feasibility study they are technical feasibility, operational feasibility and economical feasibility.

Technical Feasibility: This new system requires 6 fully trained people to run the system perfectly. 1 admin person to maintain database and other 5 to handle the system interface and order making things. As our existing system is purely manual, so we need a onetime investment of Rs 4 Lacs for the purchase of 6 computers, 5 invoice printers, a laser printer, AC and networking etc. It requires apprx. 10 Lacks PA as operating cost. With the above details our system is technically feasible as after investing 14 Lacs in a year, the company is still saving Rs 15 Lacs PA.

Operational Feasibility: The new solution is feasible in all sense but operationally it is not. The new system demands the expulsion of at least 15 people from the company. It creates an environment of joblessness and fear among the employees. It can lead to an indefinite strike in the company also. So the management must take corrective actions prior in advance in order to start the further proceedings.

Economic Feasibility: With the manual system the operating cost of the system is about 60 Lacks P.A. This cost comprises salary of 25 people, stationary, building rent, electricity, water, telephone etc. But with the new system this reoccurring cost comes out to be about 20 Lacks P.A. Hence the new system is economically feasible.

13

SMU Roll No. 520947465

Operating Environment Hardware and Software

HARDWARE REQUIREMENTS

Processor: Pentium 4 or more for optimum performance RAM: Recommended 256MB Hard Disk: Minimum 20GB

SOFTWARE REQUIREMENTS

Operating System - Certified Distribution of WINDOWS Visual Basic 2005 Express Edition Database(Backend) - MS Access 2003

14

SMU Roll No. 520947465

User Requirements

Functional Requirements

A. INPUT/OUTPUT 1. System shall have a form to accept the customer details. 2. System shall have a form to accept the Plant details. 3. System shall display transaction details. 4. System shall provide search facility on customer name, Order Placed, date of order, date of order dispatch, date of transaction, transaction amount, credit card no etc. 5. System should provide facility for change in address/name. 6. System should maintain the details about placing order/dispatch or order i.e, order status

B. PROCESSING 1. System should automatically generate the bill. 2. System should inform the pending order and make changes if the order is dispatched.

C. ERROR HANDLING 1. Should report any errors on duplicate primary keys. 2. Should report any Out of Range values on numeric fields 3. Should report any data type mismatches any field on the forms. 4. Should report on any Invalid dates 5. Should report any violation of authorization of rights 6. Should report any Invalid Login errors

15

SMU Roll No. 520947465

NON-FUNCTIONAL REQUIREMENTS
1. All user manuals should be provided in the necessary format 2. Application should support 5 simultaneous users. 3. Transaction should be completed within 1/5th of second 4. There will be backup procedure to maintain records.

16

SMU Roll No. 520947465

Proposed System

17

SMU Roll No. 520947465

Objectives
The main objective of this system is to keep records of the complete inventory.

It support for inventory management helps you record and track materials on the basis of both quantity and value.

It improves cash flow, visibility, and decision making.

For warehouse management, you can track quantity and value of all your materials, perform physical inventory, and optimize your warehouse resources

The Waterfall Model and the Incremental Model When commercial software development first began, the approach to project management left much to be desired. Projects were often managed according to the intuition of people who had learnt to program by solving small problems in an academic context. It quickly became apparent that the management methods required for a 500 line programming exercise did not scale-up well for use on a 500,000 line project costing millions of dollars. Since many of the largest software projects were for military purposes, it was natural that the earliest efforts at improving software project management were influenced by military engineering. So, the Waterfall model was inspired by the engineering management methods used by the US Air Force in developing new technologies. The waterfall model is still the basis for most approaches to managing software projects. It is characterised by an orderly progression from initial planning stages through to implementation and then maintenance. Each step should be completed and verified before the next stage starts. Also, as Figure illustrates, shortcomings in the preceding phase should be corrected immediately. So, for example, the project begins with System Feasibility, and the outputs from this phase are the basis for work in the Plans and Requirements phase. During Plans and Requirements, and

18

SMU Roll No. 520947465

shortcomings in the System Feasibility work should be identified and corrected. It is not permissible to skip forward over any intermediate steps, or to skip backward (say) from Integration to Product Design. Apart from reverting to the immediately preceding phase if it is found to be lacking, progress in the Waterfall model is strictly sequential. The Waterfall model has many advantages over unplanned chaos. It enforces a discipline of planning, and rightly emphasises verification and validation as a method for ensuring that the project does not run amok. However, the Waterfall method is not always an ideal approach. When you want to be innovative, a bit of practical experimentation sometimes delivers more value that any amount of pencil-and-paper planning could. Sometimes the easiest way to test a hunch is by implementing it.

19

SMU Roll No. 520947465

Which Method Is Best


There is no simple answer as to whether the Waterfall model or incremental model is best. In most cases, the best outcome is probably achieved by wisely combining both approaches. On the one hand, a strictly Waterfall approach is likely to be less innovative since it doesnt incorporate experimentation. It also runs a great risk of not being very responsive to user feedback. On the other hand, extreme versions of the incremental model degenerate into chaos, especially when there are more than two people on the project. In most cases, elements of both approaches will be desirable. Some organisations staff projects initially with analysts who do not have programming skills. Such people are useful, but when there are few programming skills in the early team members, it is just not possible to develop any prototypes or deliver incrementally. A balanced team will combine strong business skills and strong technical skills at every stage of the project.

How Does Each Model Influence Schedules?


In theory, a perfect project conducted using the Waterfall model would finish before a perfect project using the incremental model. However, this does not mean that the Waterfall model is superior, for the following reasons:

1. No project in the real world conforms with theoretically perfect models. Mistakes always happen. Because the incremental model focuses on exposing risk as early as possible, and because it provides tangible and unmistakable evidence of progress through the delivery of incremental functionality, the incremental model is more robust than the Waterfall model. When a project delivers its functionality incrementally to the users, the possibility of major unpleasant surprises is greatly diminished. 2. Under the Waterfall model, the users get nothing but promises and status reports until the project completes. However, the incremental model attempts to deliver the most valuable functionality as early as possible. Sometimes, the requirement is all or

20

SMU Roll No. 520947465

nothing, and incremental deliveries are only useful for testing. However, at other times the incrementally delivered functionality can be very useful, as in Gilbs example of the Swedish mapping project. To use a financial analogy, the Waterfall method is like a deep discount security where the interest is paid only on maturity, while the incremental method is like a bond with regular coupon payments. The present value of the cashflows from the bond might be greater than that of the interest from the deep discount security, even if it matures later. (In this analogy, cashflows from the securities represent the delivery of valuable functionality).

21

SMU Roll No. 520947465

Estimation & Scheduling


Schedules Schedule estimation and tracking is part of the software development process. However, it is such an important and difficult area that it deserves a section of its own. The first step that most organisations can make in improving their software development process is to institute documented schedule estimation and tracking as a management practice. The reason for this is that, by comparing outcomes with estimates, a feedback loop is established, enabling the organisation to learn about its performance and become better at prediction. As a first approximation, you can plan schedules based on the industry averages that are discussed in the next few pages. By quantitatively tracking your progress against these schedules, you can then recalibrate your estimation model to better reflect your own situation. The data that you obtain from this discipline will also assist you in pinpointing productivity bottlenecks.

22

SMU Roll No. 520947465

Limits to the Accuracy of Schedule Estimation

Typical range of uncertainty in schedule/cost estimation

It is a fallacy to believe that schedules and costs can be estimated with complete accuracy. Inevitably, as the idea for a system progresses towards implementation, people learn more about what is really required. Figure above shows how the funnel of doubt surrounding the cost of a system narrows during the course of development. For example, at the feasibility stage, estimates are likely to be out by a factor of 4. Hence, the actual cost may be 75% lower or 300% higher than the guesstimate made at this early stage. Even at the stage of requirements specification, there is a wide band of uncertainty. This uncertainty is inevitable, since until all of the details have been examined, there is just no certain way of knowing exactly how much work needs to be done. The most widely respected technique for schedule estimation is Barry Boehms COCOMO model. When dealing with a kind of project against which it has been calibrated, this model produces

23

SMU Roll No. 520947465

an estimate that is within 20% of actual expenditure 80% of the time. To reliably produce estimates that are this good, you need a clear written statement of requirements, and a clear plan for how the project will be implemented (personnel, hardware, etc.) Depending on the size of the project, gathering this much knowledge can take a reasonably high amount of resources. For example, the initial stage of project planning and requirements definition normally consumes about 6% of project resources and at least 10% of elapsed time. At the end of this stage, it is possible to make a rough schedule estimate. Creating a design for the product takes another 16% of resources and 19% of the elapsed time.

Estimating Project Size


Before estimating the resources needed to complete a project, one first has to gain a good estimate of the project size. This is much more difficult than it sounds. Generating a formula for sizing software has a good many of the aspects of generating a formula for sizing a novel. Both deal with a product capable of virtually unlimited levels of elaboration, and it is difficult to characterise these levels of elaboration in any way related to sizing. Just consider the problem of estimating the number of pages in a novel with four characters who influence each others lives profoundly 20 more or less incidental characters three different locations two years time span five detailed flashbacks and you begin to get a better appreciation of the software sizing problem.16 In the COCOMO method, project size is estimated in units called KDSI, which means thousands of delivered source instructions. This refers to the number of lines of source code (excluding comments and blank lines) in the software that is finally delivered as the product. This unit of measurement is very unintuitive to people who are not programmers, but for programmers it is a natural way of measuring the size of a software product. The effort required to build a software product is a function of the number of

24

SMU Roll No. 520947465

lines of code. Therefore, powerful programming languages that permit more work to be done in less lines of code tend to be more conducive to productivity than verbose programming languages. The nominal effort estimate (21 person months for example) is not suitable for immediate use. It has to be adjusted to account for 16 important factors that have been found to influence productivity. Table 1 shows the values of these factors.

Effort Multipliers for the COCOMO Model

Phase Distribution of Effort and Elapsed Time COCOMO also includes guidelines on the amount of person months (effort) and elapsed time that will be required for each phase of the project. Table shows the distribution of effort over project phases. The 6% allocated to Plans and Requirements is preparation time before the program begins in earnest, and does not count toward the 100% total for implementation time.
SMU Roll No. 520947465

25

Distribution of effort (work months) over project phases

Distribution of elapsed time over project phases

Budgeting for Hardware

Developing a software system usually requires greater hardware capacity than the system will use once it is implemented. In particular, software development tools tend to require lots of memory and a fast processor. By analysing the projects in the COCOMO database, Boehm quantified the benefits to be gained from using powerful hardware on a software project. His main findings were:

1. Overall system cost is generally minimised by procuring computer hardware with 30 to 50% more capacity than is absolutely necessary. 2. The more the ratio of software-to-hardware cost increases, the more excess capacity one should procure. 26
SMU Roll No. 520947465

3. It is far more risky to err by procuring too little hardware capacity than by procuring too much. This is especially important, given the tendencies discussed elsewhere for sizing estimates to be low and for software products to expand during development and maintenance.

The ratio of software-to-hardware costs is much higher. This would indicate that more than 50% hardware over-capacity is economically optimal. Practical experience bears this out. Good software developers are hard to find, and expensive to keep. Good hardware is easy to find, and a powerful machine now only costs a few weeks salary for the programmer who will be using it. By spending a bit extra on hardware, you can significantly enhance productivity. This leads to a lower total project cost.

The 90% Complete Syndrome In most cases, progress against schedule is estimated by a subjective gut feel, or by a quantitative method that fails to account for the realities of software development. This typically leads to the 90% complete syndrome, as illustrated in Figure below. This graph shows a programmers estimate of the percent completion of a software module that he had been assigned to write. After five weeks, the programmer told his manager that the module was 90% complete. Because of this, the manager allowed one more week in the schedule for completion of the module, and scheduled the programmer to begin another task in the following week. However, over the course of the week, the programmer kept finding unexpected bugs in the module. In his attempts to fix the bugs, he introduced others. After a while, he discovered that he had misunderstood part of the specification, and that a portion of the module needed to be rewritten. It actually took twelve weeks for the module to be completed.

27

SMU Roll No. 520947465

This pattern is typical of what happens when completion is estimated by gut feel. It happens at both the micro level (such as in this example) where a few weeks of work are at stake, but more damagingly it also happens at the macro level, where a three-year project will typically be estimated as 90% complete after two years and nine months, but still only 95% complete a year later when it is cancelled because it has overrun its budget. Two measures are necessary to avoid the 90% complete syndrome:

1. Tasks must be broken up into subtasks that can be verified for completeness. Each subtask is given a weighting. Then the completeness of the task is estimated only by summing the weightings of the subtasks that have been verified to be complete. For

28

SMU Roll No. 520947465

example, in this particular case the task of writing the module may have been divided into firstly writing the code, then unittesting it to eliminate the bugs. In accordance with good practice, the criterion for considering the code written would be that the code has been formally inspected by a group of peers, and the rework emerging from the inspection has been completed. At that point the module would be considered 60% complete. Before that, no verifiable checkpoint had been reached, so the module was 0% complete for scheduling purposes. Then, when the module had passed all its unit tests, it would be considered 100% complete. It is not permissible to give partial credit until a verifiable checkpoint is reached.

2. The breakdown of tasks into subtasks must be done according to well established guidelines taken from the software engineering literature. In this example, the programmer considered the module 90% complete because he had written the code. Completing the module was merely a matter of running a few tests. Implicitly, the programmer had assumed that writing the code is 90% of the job, and unit-testing it is another 10%. However, the literature does not support this assumption. If inspections are not used, unit testing would be expected to take as long as writing the code. With inspections, we would expect 60% for writing the code and 40% for unit testing. A common error in estimation is to assume that once the code is written the job is almost finished.

29

SMU Roll No. 520947465

ANALYSIS & DESIGN

30

SMU Roll No. 520947465

Use case Diagram for Supplier

LoginIdandPwd

ChecksInventories <<include>> TracksOrder

Supplier

Dispatchorderontime Customer

SendsInvoice

UpdatesRecords

31

SMU Roll No. 520947465

Use Case Diagram for Customer

Studies Requirements

Make List of Requirements Places the Order Makes Payment Send GRN

Customer

Clerk

32

SMU Roll No.520947465

Input Screens
Splash Screen

Login Form

34

SMU Roll No. 520947465

Main Form

35

SMU Roll No. 520947465

Transaction screen

36

SMU Roll No. 520947465

Order Enquiry

37

SMU Roll No. 520947465

Material Details

38

SMU Roll No. 520947465

Plant Details

About

39

SMU Roll No. 520947465

State Details

Order Details

40

SMU Roll No. 520947465

Customer Details

41

SMU Roll No. 520947465

Order Status

Add Plant

42

SMU Roll No. 520947465

Add Customer

Search Customer

43

SMU Roll No. 520947465

Update Customer

Add Material

44

SMU Roll No. 520947465

Edit Material

45

SMU Roll No. 520947465

Table Specifications

46

SMU Roll No. 520947465

UID_PASS (Login Table) Column Name Data Type USER_NAME PASSWORD Text Text 50 50 User name of the ADMIN/OPERATOR Password of the ADMIN/OPERATOR Size Description

customer_master (Customer Details Table) Column Name cust_slno (PK) cust_name cust_add1 cust_add2 Cust_add3 cust_pincode cust_city contact_person _name contact_person _number State_code (FK) Char 2 Initials of the state derived from state details table Num 10 Phone number for the person who made the order Data Type Size Num Text Char Char Char Num Char Char 6 50 40 40 40 6 15 30 Description Customer identification Name of the customer Address line one of the customer Address line two of the customer Address line three of the customer Pin code of the customer address City of the customer Name of the person responsible for order making

47

SMU Roll No. 520947465

state_master (State Details table) Column Name state_code Data Type Size char 2 50 Description Code Of the state eg. MH -maharashtra Description of the code.

state_descriptio char n

material_master (Material Detail Table) Column Name cust_slno (PK) material_code material_descri ption shipping_plant Char 4 It gives detail of shipping plant n is linked with plant master table material_price Num 10 Price of the material Data Type Size Num char Char 6 10 20 Description Customer identification Code of the material Describing the material specification

Values Like : COMP001 Computer Pentium IV PMP1 Pune Plant Unit I PMP2 Pune Plant Unit II PMP3 Pune Plant - Unit III Material_price - 5000

48

SMU Roll No. 520947465

plant_master (Plant Details Table) Column Name plant_code plant_name material_descri ption shipping_plant Char 4 It gives detail of shipping plant n is linked with plant master table material_price Plant_add Plant_city Plant_code(pk) Num Char Char Char 10 40 15 15 Price of the material Address of plant City of plant Code of plant Data Type Size Num char Char 6 10 20 Code of the material Describing the material specification Description

status_master (Order Status Master) Column Name order_status description Data Type Size char char 4 50 Description Status of order in short Description of the plant.

Order Status Code & Values OED OCHKD CLRD SCHD SHIPDIS INVG MACI PYMR Order Entry done Order checked Order cleared Order scheduled Order Shipped by dispatch section Invoice generated by accounts department Machine installed by installation group Payment Received from customer

49

SMU Roll No. 520947465

Transactional Tables To Be Created


ORDER_HEADER(ORDER Header Information Table Column Name Data Type order_no (pk) order_creation_date Num Date 8 Number of order Date of the order placement Size Description

order_status customer_ref_no customer_ref_date

char char date

4 20 -

Status of order Reference number of the customer date on which customer referred

Order_value

Num

11

Value of each order Date on which customer needs the delivery

material_required_d Date ate customer_slno (FK) Num 6 8

Customer identification number Delivery challan number Date on which material dispatched

delivery_challan_no num shipment_date invoice_number invoice_date transporter_name plant_code (FK) machine_installed_ by cheque_no bank_name num char Date num date char char char

8 40 4 40

Number of invoice Date of invoice Name of the transporter Code of the plant Name of the person who installed the machine

20 15

Number of cheque Name of the bank

50

SMU Roll No. 520947465

ORDER_DETAIL(Order Detail Information Table line item wise )

Column Name order_no(FK) material_code (FK) item_qty item_value

Data Type Size Num Num 8 8

Description Number of order Code of material

num Num

6 11

Quantity of the item Value of item

stock_master (Item Stock Master Table) Column Name material_code (FK) plant_code(FK ) stock_qty Num 6 Stock of item quantity char 4 Code of plant Data Type Size Num 8 Description Code of material

order_tracking (Order_status_tracking Table) Column Name order_no (FK) order_status creation_date char date 4 Description of item status Date on which order was created Data Type Size Num 8 Description Number of order

51

SMU Roll No. 520947465

Test Procedures and Implementation

52

SMU Roll No. 520947465

Introduction

Testing presents an interesting anomaly for the software engineer. During earlier software engineering activities, the engineer attempts to build software from an abstract concept to a tangible product. Now comes testing. The engineer creates a series of test cases that are intended to demolish the software that has been built. In fact, testing is the one step in the software process that could be viewed (psychologically, at least) as destructive rather than constructive.

Software engineers are by their nature constructive people. Testing requires that the developer discard preconceived notions of the correctness of software just developed and overcome a conflict of interest that occurs when errors are uncovered.

If testing is conducted successfully (according to the objectives stated previously), it will uncover errors in the software. As a secondary benefit, testing demonstrates that software functions appear to be working according to specification, that behavioral and performance requirements appear to have been met. In addition, data collected as testing is conducted provide a good indication of software reliability and some indication of software quality as a whole. But testing cannot show the absence of errors and defects, it can show

Only that software errors and defects are present. It is important to keep this (rather gloomy) statement in mind as testing is being conducted.

Testing Principles Before applying methods to design effective test cases, a software engineer must understand the basic principle that guide software testing: All tests should be traceable to customer requirements Tests should be planned long before testing begins.

53

SMU Roll No. 520947465

80 percent of all errors uncovered during testing will likely be traceable to 20 percent of all program components. The problem, of course, is to isolate these suspect components and to thoroughly test them.

Testing should being in the small and progress toward testing in the large. Exhaustive testing is not possible To be most effective an independent third party should conduct testing A rich variety of test case design methods have evolved for software. These methods provide the developer with a systematic approach to testing. More important, methods provide a mechanism that can help to ensure the completeness of tests and provide the highest likelihood for uncovering errors in software.

Any engineered product (and most other things) can be tested in one of two ways: Knowing the specified function that a product has been designed to perform, tests can be conducted that demonstrate each function is fully operational. While at the same time searching for errors in each function; (2) knowing the internal

Working of a product, tests can be conducted to ensure that all gears mesh, that is, internal operations are performed according to specifications and all internal components have been adequately exercised. The first test approach is called black box testing and the second, white-box testing. Testing performed were: UNIT TESTING INTEGRATION TESTING DATABASE TESTING RECOVERY TESTING FUNCTIONALITY TESTING SMOKE TEST

54

SMU Roll No. 520947465

SANITY TEST

COMPATIBILITY TESTING LOAD TESTING SYSTEM TESTING PERFORMANCE TESTING USER ACCEPTANCE TESTING

55

SMU Roll No. 520947465

White Box Testing

Sometimes called glass-box testing is a test case design method that uses the control structure of the procedural design to derive test cases. Using white-box testing methods, the software engineer can derive test cases that (1) guarantee that all independent paths within a module have been exercised at least once, (2) exercise all logical decisions on their true and false sides, (3) execute all loops at their boundaries and within their operational bounds, and (4) exercise internal data structures to ensure their validity.

White-box testing of software is predicated on close examination of procedural detail. Providing test cases that exercise specific sets of conditions and/or loops tests logical paths through the software. The status of the program may be examined at various points to determine if the expected or asserted status corresponds to the actual status. Basis path testing is a white-box testing technique first proposed by Tom McCabe. The basis path method enables the test case designer to derive a logical complexity measure of a procedural design and use this measure as a guide for defining a basis set of execution paths. Test cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one time during testing.

In this system, the system was tested for the calculation matters were the data provided for giving the right output or not. If wrong data was provided then what it is throwing error or accepting.

Black Box Testing

Also called behavioral testing, focuses on the functional requirements of the software. That is, black box testing enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program. Black box testing is not an alternative to white-box techniques. Rather, it is a complementary approach that is

56

SMU Roll No. 520947465

likely to uncover a different class of error than white-box methods. When computer software is considered, black box testing alludes to tests that are conducted at the software interface. Although they are designed to uncover errors, black-box tests are used to demonstrate that software functions are operational, that input is

Properly accepted and output is correctly produced and that the integrity of external information is maintained. A black-box test examines some fundamental aspect of a system with a little regard for the internal logical structure of the software. Black-box testing attempts to find errors in the following categories:

1. 2. 3. 4. 5.

Incorrect or missing functions, Interface errors, Errors in data structures or external database access, Behavior or performance errors, and Initialization and termination errors. By applying back-box techniques, we derive a set of test cases that satisfy the following criteria:

a. Test cases that reduce, by a count that is greater than one, the number of additional test cases that must be designed to achieve reasonable testing and b. Test cases that tell us something about the presence or absence of classes of errors, rather than an error associated only with the specific test at hand.

White-box testing should not, however, be dismissed as impractical. A limited number of important logical paths can be selected and exercised. Important data structures can be probed for validity. The attributes of both black and white box testing can be combined to provide an approach that validates the software interface and selectively ensures that the internal workings of the software are correct. Black box testing for this system was done to check the internal testing i.e, the system is working properly in each case or no. What kind of errors are there in database design.

57

SMU Roll No. 520947465

Testing Process The testing process can be shown as:

Levels of testing

Test Plan

Test Procedures

Test Case Specification

Yes

Test Case Execution Is Error Uncovered? Test Case Analysis

No

Test Report

58

SMU Roll No. 520947465

Menu Tree

59

SMU Roll No. 520947465

USER MANUAL

61

SMU Roll No. 520947465

Menu Explanation
Start Up screen 1. The first menu item of the System screen is transaction screen this screen is the main screen it has all the menu items which help to take order and maintain it in database. The 1st tab is order entry this screen will be disabled initially to make an order operator has to click on order entry button at the right hand side of the screen

Order Entry 2. Once that button is clicked the screen is activated and orderno.,oder creation date and order status are auto generated search cust_code by clicking search button and retrieve rest of the customer details. If the customer is new then administrator has to add new customer into database which is only accessed by admin person operator are not given those rights.

3. Once customer details are retrieved click calculate order value button this this will take to the order detail screen where order no is auto generated material code is selected and item qty is to be filled and by clicking on calculate the total is calculated n thus the order is placed

4. To add all details in transaction screen refresh button should be clicked

5. Customer ref number is also have to be filled by operator/admin n then to go on the next screen click on verified

Shipment Details 6. The shipment details are already auto filled by the system operator has to provide the transporter name only

62

SMU Roll No. 520947465

Accounts Department 7. Accounts dept is also auto filled admin has to verify all the details and make order date according to convenience

Machine Installation 8. Next screen is machine installation here the engineer who gonna install the machine is to be given.

Commercial Group 9. In commercial group screen all the payment details are to be filled accordingly once customer makes the payment

10. Thus the records has been created.

Order Enquiry 11. In the next tab we can see the order status.

63

SMU Roll No. 520947465

Admin Authority

1. Handling databases is in the power of the admin person only

2. So all customer databases and material database and all master tables are to be handled by the admin person only.

3. These screens are detailed screens so no specific description is needed for the same.

64

SMU Roll No. 520947465

Maintenance

65

SMU Roll No. 520947465

Once a program has gone into use, subsequent modifications to it are generally referred to as maintenance. This term is very misleading, since software does not wear out or require lubrication: in fact software does not require maintenance in the sense that machinery does. Software maintenance is really just software development that happens after the software has been implemented. Therefore, planning for maintenance generally involves exactly the same considerations as planning for any other development. A survey on software maintenance has found that only 17% of maintenance was aimed at fixing bugs or performance problems in the software. 18% of maintenance was due to changes in the program environment, such as the introduction of new kinds of computers or printers. However, the overwhelming majority of maintenance work (65%) was to implement refinements to program functionality. The estimation techniques that are described later in this document are also applicable to software maintenance. Estimating maintenance effort is very much like estimating the effort required to originally develop a program. For example, if 15% of the code in a program will change each year due to maintenance, then (other things being equal) the amount of resources required for maintenance will be approximately 15% of the resources required for the original development. It is important to achieve balance in managing a contractual relationship with a software vendor. It is usually not a successful strategy to seek a good result by imposing onerous contractual conditions. Rather, it is a good idea to use only vendors who have a sound software process. After jointly defining the requirements, it is best not to try monitoring the implementation too closely. On large projects it can be a good idea to engage a third-party with software expertise to audit the project on your behalf.

66

SMU Roll No. 520947465

Proposed Enhancements

67

SMU Roll No. 520947465

Future Scope
The scope of the project includes that what all future enhancements can be done in this system to make it more feasible to use

Databases for different products range and storage can be provided.

Multilingual support can be provided so that it can be understandable by the person of any language.

More graphics can be added to make it more user-friendly and understandable.

Manage & backup versions of documents online.

68

SMU Roll No. 520947465

Benefits
Manages Track sales

Manages contacts

Manages accounts

Manages opportunities

Track product issues

Manage issue priority

Track product features

Manage product life cycle

69

SMU Roll No. 520947465

Drawbacks & Limitations

1. The system is not capable of handling more than 6 users at a time.

2. Some keywords in system are difficult to understand so the admin n operator person should understand them thoroughly to use the system accurately.

3. Graphs could have been added in order to get the records more clearly.

70

SMU Roll No. 520947465

CONCLUSION

While developing the system a conscious effort has been made to create and develop a software package, making use of available tools, techniques and resources that would generate a proper System

While making the system, an eye has been kept on making it as user-friendly, as costeffective and as flexible as possible. As such one may hope that the system will be acceptable to any user and will adequately meet his/her needs.

As in case of any system development processes where there are a number of shortcomings, there have been some shortcomings in the development of this system also. The project is still under modification.

71

SMU Roll No. 520947465

Test Cases

72

SMU Roll No. 520947465

Test Cases Case no. 1 Login A User forgets enter Scenario Sr.no Action Expected Output Message to window the saying Please enter Actual Output Message window saying Please the enter the PASS Result

username/ password

username/ password B User enters Message wrong username/ password window saying Wrong username/ password C

username/ password Message window saying Wrong username/ password PASS

User enters Takes user Takes user PASS correct username/ password to Homepage to Homepage

73

SMU Roll No. 520947465

Case no. 2

Scenario

Sr.no

Action

Expected Output

Actual Output Message window saying Customer not

Result

Placing Order

User enters Message wrong customer code window saying Customer Does exist

PASS

not Does exist

User not Some

does Message enters window saying

Message window saying Name

PASS

record e.g Name name

Should Not Should Not be null be null Message window saying Invalid code PASS

User Enters Message wrong plant code window saying Invalid code

74

SMU Roll No. 520947465

REPORTS

75

SMU Roll No. 520947465

Order Pending/Booking/Billing

76

SMU Roll No. 520947465

Order analysis in terms of dates

77

SMU Roll No. 520947465

Balance Payment Report

78

SMU Roll No. 520947465

State Transition Diagram for Supplier

Initiate

LogIn Validate User_id and Pwd


Invalid userid /pwd
Tracks Order

Order Order Details


Check For the transport

Shipment Shipment availabilit y


Dispatch order

Invoice Invoice details

Payment Details

Records Update Records

79

SMU Roll No. 520947465

Activity Diagram for System


Customer Supplier Shipment

Request Material Get Materials

Ship Order Tracks Order

Receive Order

Bill Customer

Pay Bill

Send GRN

Close Order

80

SMU Roll No. 520947465

Glossary

81

SMU Roll No. 520947465

Glossary
Term CIO CMM Meaning Chief Information Officer The Capability Maturity Model, a system for classifying and improving the effectiveness of software processes, Effort In the context of scheduling, effort refers to the number of work months involved in doing a task. Evolutionary model Incremental model Synonym for the incremental model. A model of the software development process in which subsets of the specified functionality are implemented and delivered to users over the course of the project. Inspection A low-technology formalised technique for peer review of work in any phase of a software development project. Inspections are cheaper and more effective than testing as a way of finding software defects. Iterative model KDSI Synonym for the incremental model. Thousands of Delivered Source Instructions: a unit of measure for the amount of source code that is developed in a project (excludes source code that is not included in the delivered product). PM In the COCOMO model, PM represents the expected number of person months required to complete the project. SEI Statistical Control The Software Engineering Institute at Carnegie Mellon University. A quality management term, used by authorities such as Deming and Juran. Refers to a production process where product variation is controlled within prescribed limits. TDEV In the COCOMO model, TDEV represents the expected elapsed development time (in months) for the project. Validation Checking that the software is suitable for its intended business purpose.

82

SMU Roll No. 520947465

Informally, Are we building the right software? Verification Checking that software is being developed in accordance with agreed plans and procedures. Informally, Are we building the software right? Waterfall model A model of the software development process in which all of the specified functionality is developed at once. Nothing is delivered until the project reaches completion.

83

SMU Roll No. 520947465

BIBLIOGRAPHY

84

SMU Roll No. 520947465

BOOKS:

Arthur, L.J. Improving Software Quality: An Insiders Guide to TQM New York: John Wiley & Sons, 1993.

Boehm. B.W. Some Steps Towards Formal and Automated Aids to Software Requirements and Design IFIP 74 Amsterdam: New Holland, 1974.

Boehm, B.W. Software Engineering Economics New Jersey: Prentice-Hall, 1981.

De Marco, T. and T. Lister Programmer Performance and the Effects of the Workplace Proceedings of the 8th International Conference on Software Engineering

Gilb, Tom Principles of Software Engineering Management Massachusetts: Addison-Wesley, 1988.

Introduction To Programming with Visual Basic .NET - by Gary J. Bronson

WEB LINK

http://www.dreamincode.net

http://www.a1vbcode.com

85

SMU Roll No. 520947465

Thank You

86

SMU Roll No. 520947465

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy