Abstract

Office Converter Jignesh Solanki Nikunj Yadav

Purpose:The purpose of this project was to convert all office files as well as pictures as per end user wants. Procedure:There were 14 converters developed such as pdf, doc, txt, html, xml, rtf, jpg, bmp, png etc. So user can convert their same files and pictures instead of searching on web. Observation:The converted file wasnt fully reliable because of their type like txt to xls, word to xls, pdf to xls etc. Conclusion:The data was analyzed and conclusion was drawn that its a standalone application, so it is used by only one user At a time. People can download it by a website.

Project summary
All Office Converter is an easy-to-use and professional document conversion tool. It can support batch converting documents, web and images with high good quality for business and individual to improve the work efficiency. With this powerful converter, you can create PDF file from versatile formats and convert PDF file to other versatile formats with super output quality and effectively. More, you can convert between different office document formats, web, images. It can support comprehensive formats: Word(doc, docm, docx), Excel(xls.xlsx.xlsm),PowerPoint(ppt,pptc,pptm),PDF,XLS,RTF,TX T,HTM/HTML,Website,JPG,BMP,GIF,TIF,WMF,EMF,TGA, RLE,PNG etc.

System Requirement
500 Mhz Pentium ll CPU or higher; 512 MB RAM Memory or higher; 200 MB free hard drive space Windows/98/ME/NT/2000/XP/2003 Server/Vista/win7 MS-office2000 version, or higher Adobereader 7 or above, or highter,if you control about pdf file IE 6.0 or above;

Advance Features
It can simultaneously convert different formats to one certain format once. It can convert the webpage on the website or your computer. Easy to use. Convert with one click. More setting options to let you control the output file more accurately. Save the imported file list.. Create PDF and Image with high good quality. Open *.HTM or URL as the following framework to convert.

Support Formats
Batch Convert Word(doc,docm,docx), Excel(xls.xlsx.xlsm), PowerPoint(ppt,pptc,pptm),RTF,TXT, HTM,HTML,Website,JPG, BMP,GIF,TIF,WMF,EMF to PDF(as default format, as image format, as text format). Batch Convert PDF to DOC,RTF,XLS,HTM,TXT, JPG, BMP, GIF, TIF, TGA, RLE, PNG, EMF, WMF. Batch Convert Word(doc,docm,docx) to PDF (as default format, as image format, as text format),XLS,TXT,HTM,JPG,BMP,GIF,TIF,TGA,RLE,PNG,EMF,WMF . Batch Convert PDF, Excel(xls.xlsx.xlsm),TXT,HTM,HTML,JPG, BMP, GIF, TIF, EMF, WMF to DOC. Batch Convert PowerPoint(ppt,pptc,pptm) to JPG, BMP,GIF,TIF,TGA,RLE,PNG,EMF,WMF,DOC, XLS,RTF,TXT,PDF(as default format,as image format, as text format). Batch Convert HTM,HTML,Website to DOC,PDF(as default format, as image format, as text format),TXT,RTF,XLS,JPG,BMP,GIF,TIF,TGA,RLE,PNG,EMF,WMF.

Risk management
Risk management is the identification, assessment, and prioritization of risks (defined in ISO 31000 as the effect of uncertainty on objectives, whether positive or negative) followed by coordinated and economical application of resources to minimize, monitor, and control the probability and/or impact of unfortunate events[1] or to maximize the realization of opportunities. Risks can come from uncertainty in financial markets, project failures (at any phase in development, production, or sustainment life-cycles), legal liabilities, credit risk, accidents, natural causes and disasters as well as deliberate attack from an adversary or events of uncertain root-cause. Several risk management standards have been developed including the Project Management Institute, the National Institute of Science and Technology, actuarial societies, and ISO standards.[2][3] Methods, definitions and goals vary widely according to whether the risk management method is in the context of project management, security, engineering, industrial processes, financial portfolios, actuarial assessments, or public health and safety. The strategies to manage risk include transferring the risk to another party, avoiding the risk, reducing the negative effect or probability of the risk, or even accepting some or all of the consequences of a particular risk. Certain aspects of many of the risk management standards have come under criticism for having no measurable improvement on

risk, whether the confidence in estimates and decisions seem to increase Introduction This section provides an introduction to the principles of risk management. The vocabulary of risk management is defined in ISO Guide 73, "Risk management. Vocabulary."[2] In ideal risk management, a prioritization process is followed whereby the risks with the greatest loss and the greatest probability of occurring are handled first, and risks with lower probability of occurrence and lower loss are handled in descending order. In practice the process can be very difficult, and balancing between risks with a high probability of occurrence but lower loss versus a risk with high loss but lower probability of occurrence can often be mishandled. Intangible risk management identifies a new type of a risk that has a 100% probability of occurring but is ignored by the organization due to a lack of identification ability. For example, when deficient knowledge is applied to a situation, a knowledge risk materializes. Relationship risk appears when ineffective collaboration occurs. Process-engagement risk may be an issue when ineffective operational procedures are applied. These risks directly reduce the productivity of knowledge workers, decrease cost effectiveness, profitability, service, quality, reputation, brand value, and earnings quality. Intangible risk management allows risk management to create immediate value from the identification and reduction of risks that reduce productivity.

Risk management also faces difficulties in allocating resources. This is the idea of opportunity cost. Resources spent on risk management could have been spent on more profitable activities. Again, ideal risk management minimizes spending and minimizes the negative effects of risks. Method For the most part, these methods consist of the following elements, performed, more or less, in the following order. 1. identify, characterize, and assess threats 2. assess the vulnerability of critical assets to specific threats 3. determine the risk (i.e. the expected consequences of specific types of attacks on specific assets) 4. identify ways to reduce those risks 5. prioritize risk reduction measures based on a strategy

Project Risk
Since December 8, 2009 at the earliest ATLAS.ti users on Windows XP have experienced problems when trying to load Word documents or other types of files that make use of the Microsoft Office converters. (What a date to choose for "killing" the converters ...) Before pointing to solutions here are some facts about using

converters: The MS office converters are also used in ATLAS.ti (and other software) for converting such files into "Richt Text Format (RTF)". Let aside how "rich" these conversions are, this on-thefly conversion at least eliminated the neccessity to create an extra RTF file and then assign this to the project. However with a few drawbacks: 1. Such files are blocked from editing. 2. Each time they are loaded into ATLAS.ti (for display, autocoding, searching, crawling) the are converted anew (however, only once for each session and file). This can be quite a performance (time and memory) issue when large documents with tables and images are affected. 3. When opening a project on another computer there is a chance that another converter is used creating different RTF (maybe only a few added spaces) and so yielding misaligned quotation boundaries (quotations are "stand-off" markup that relies on the documents content identity). 4. As happened now, a feature that is 3rd party - in this case Microsoft - may cease to exist or be restricted without further notice, resulting in the converter errors experienced now. In version 6.2 we will offer Smart PDs that - among other features - will hide this extra step from you, so you can then continue assigning DOC files. Until then, we recommend to

make the explicit extra step and convert DOC files into RTF explicitly (using Word) and then assign the resulting RTF files instead as primary documents. Another option is to convert a DOC file to PDF when layout is crucial.

Feasibility study
Feasibility studies aim to objectively and rationally uncover the strengths and weaknesses of the existing business or proposed venture, opportunities and threats as presented by the environment, the resources required to carry through, and ultimately the prospects for success.[1][2] In its simplest term, the two criteria to judge feasibility are cost required and value to be attained.[3] As such, a well-designed feasibility study should provide a historical background of the business or project, description of the product or service, accounting statements, details of the operations and management, marketing research and policies, financial data, legal requirements and tax obligations.[1] Generally, feasibility studies precede technical development and project implementation.

Five common factors (TELOS) Technology and system feasibility

The assessment is based on an outline design of system requirements in terms of Input, Processes, Output, Fields, Programs, and Procedures. This can be quantified in terms of

volumes of data, trends, frequency of updating, etc. in order to estimate whether the new system will perform adequately or not. Technological feasibility is carried out to determine whether the company has the capability, in terms of software, hardware, personnel and expertise, to handle the completion of the project. When writing a feasibility report the following should be taken to consideration:

* A brief description of the business * The part of the business being examined * The human and economic factor * The possible solutions to the problems

At this level, the concern is whether the proposal is both technically and legally feasible (assuming moderate cost). Economic feasibility

Economic analysis is the most frequently used method for evaluating the effectiveness of a new system. More commonly known as cost/benefit analysis, the procedure is to determine the benefits and savings that are expected from a candidate

system and compare them with costs. If benefits outweigh costs, then the decision is made to design and implement the system. An entrepreneur must accurately weigh the cost versus benefits before taking an action.

Cost-based study: It is important to identify cost and benefit factors, which can be categorized as follows: 1. Development costs; and 2. Operating costs. This is an analysis of the costs to be incurred in the system and the benefits derivable out of the system.

Time-based study: This is an analysis of the time required to achieve a return on investments. The future value of a project is also a factor. Legal feasibility

Determines whether the proposed system conflicts with legal requirements, e.g. a data processing system must comply with the local Data Protection Acts. Operational feasibility

Operational feasibility is a measure of how well a proposed system solves the problems, and takes advantage of the opportunities identified during scope definition and how it satisfies the requirements identified in the requirements analysis phase of system development.[4] Schedule feasibility

A project will fail if it takes too long to be completed before it is useful. Typically this means estimating how long the system will take to develop, and if it can be completed in a given time period using some methods like payback period. Schedule feasibility is a measure of how reasonable the project timetable is. Given our technical expertise, are the project deadlines reasonable? Some projects are initiated with specific deadlines. You need to determine whether the deadlines are mandatory or desirable. Other feasibility factors Market and real estate feasibility

Market Feasibility Study typically involves testing geographic locations for a real estate development project, and usually involves parcels of real estate land. Developers often conduct market studies to determine the best location within a

jurisdiction, and to test alternative land uses for given parcels. Jurisdictions often require developers to complete feasibility studies before they will approve a permit application for retail, commercial, industrial, manufacturing, housing, office or mixed-use project. Market Feasibility takes into account the importance of the business in the selected area. Resource feasibility

This involves questions such as how much time is available to build the new system, when it can be built, whether it interferes with normal business operations, type and amount of resources required, dependencies, Cultural feasibility

In this stage, the project's alternatives are evaluated for their impact on the local and general culture. For example, environmental factors need to be considered and these factors are to be well known. Further an enterprise's own culture can clash with the results of the project. Financial feasibility

In case of a new project,financial viability can be judged on the following parameters:

* Total estimated cost of the project * Financing of the project in terms of its capital structure, debt equity ratio and promoter's share of total cost * Existing investment by the promoter in any other business * Projected cash flow and profitability

User and System Requirements for Successful Software Development

The Importance of Software Requirements The software development life cycle

Defining and differentiating between requirement types Locating requirement sources Development approaches

Presenting software requirements

Structuring the requirements document Requirements components: text, diagrams, data

Structuring Your Project Tuning your methodology to your project size

Matching the process to small, medium and complex systems Differentiating agile from standard techniques

Analyzing stakeholder input

Identifying and prioritizing stakeholders Eliciting initial requirements from input documents Iterating requirements collaboratively

Applying the requirements process

Elicitation Analysis Specification

Validation IEEE SWEBOK The Unified Process

Capturing and Refining Use Cases Writing user stories

Scripting user stories and brief versions of use cases Iteration and progressive elaboration of use cases

Creating structured use cases

Use cases as behavioral requirements Identifying stakeholders and actors Naming and scoping use cases Writing scenarios: main and alternatives Adding preconditions and guarantees

Iterating use cases

Refining use cases with stakeholders Factoring common steps Discovering extension scenarios Verifying use case completeness

Organizing use cases

Diagramming scenarios with UML Choosing between free text and formal use case notation

Generating Interface Requirements

Integrating interface requirements

Supporting use cases with user interface mock-ups Comparing types of interface

Producing interface models

Storyboarding and prototyping Modeling interfaces with UML state diagrams and navigation maps

Data Requirements Analyzing data requirements

Exploring the use cases and the interface Determining data business rules

Creating a requirements data model

Representing data models with UML class diagrams Entities Attributes Associations Adding associations' multiplicity Maintaining the glossary

Nonfunctional Requirements Gathering nonfunctional requirements

Obtaining volumetrics Classifying nonfunctional requirements using FURPS

Documenting nonfunctional requirements

System reliability: Availability, Accuracy and Failures Addressing the "-ilities"

Validating Requirements and Producing Test Scenarios Performing requirements validation

Achieving well-formed requirements through validation Reviewing requirements with walkthroughs Verifying requirements with inspections

Generating use case tests from requirements

Ensuring testability of requirements Extrapolating test scripts and test scenarios from requirements Relating requirements to system and UA testing

Managing Changing Requirements

Developing a process for managing requirements Negotiating changes using a Change Control Board (CCB) Confirming requirements through a traceability matrix