Audit Process during Projects for Development of New Mobile IT Application

This paper presents characteristics of the computer audit process during software development life cycle focused on specific aspects of the mobile IT applications. There are highlighted specific features of the distributed informatics systems implemented in wireless environments as hardware components, wireless technologies, classes of wireless systems, specialized software for mobile IT applications, quality characteristics of the mobile IT applications, software development models and their specific stages and issues aspects of the computer audit during software development life cycle of the distributed informatics systems customized on mobile IT applications. In the computer audit process, tasks of the computer auditors and what controls they must implement are also presented.Audit Process, Mobile It Applications, Software Development Life Cycle, Project Management

Non-developmental item computer systems and the malicious software threat

The following subject areas are covered: a DOD development system - the Army Secure Operating System; non-development commercial computer systems; security, integrity, and assurance of service (SI and A); post delivery SI and A and malicious software; computer system unique attributes; positive feedback to commercial computer systems vendors; and NDI (Non-Development Item) computers and software safety

Proposed statement of position : software revenue recognition;Software revenue recognition; Exposure draft (American Institute of Certified Public Accountants), 1991, Jan. 16

This proposed statement of position (SOP) provides guidance on applying generally accepted accounting principles in recognizing revenue on software transactions. The basic principle is that revenue is recognized on delivery of software; some exceptions are discussed. The proposed SOP also discusses accounting for related services, accounting for transactions involving software that are primarily service transactions, the application of contract accounting to software transactions, and accounting for postcontract customer support. Briefly, the proposed SOP recommends the following: 1. Software licenses with no other vendor obligations—If collectibility is probable and the vendor has no obligations remaining under the sales or licensing agreement after delivering the software, revenue from the software licensing fees should be recognized on delivery of the software. 2. Software licenses with other insignificant vendor obiigations—If the vendor has insignificant obligations remaining under the sales or licensing agreement after delivering the software, revenue from the software licensing fees should be recognized on delivery of the software if collectibility is probable, and the remaining costs should be accrued or a pro rata portion of revenue should be deferred until completion of performance. 3. Software licenses with other significant vendor obligations—If, in addition to the obligation to deliver the software, the sales or licensing agreement includes other significant vendor obligations, the agreement should first be examined to determine whether it should be accounted for using contract accounting or as a service transaction. For agreements with significant vendor obligations beyond delivery of the software that are not accounted for using contract accounting or as service transactions, revenue should be deferred until all of the following conditions are met: a. Delivery has occurred. b. Other vendor obligations remaining are no longer significant. c. Collectibility is probable. 4. Significant uncertainties about customer acceptance—If, after delivery, there is significant uncertainty about customer acceptance of the software, license revenue should not be recognized until the uncertainty is removed. 5. Absence of a reasonable basis for estimating the degree of collectibility of receivables—Receivables associated with software transactions for which there is no reasonable basis of estimating the degree of collectibility should be accounted for using either the installment method or the cost recovery method of accounting. 6. Contract accounting—If a contract to deliver software or a software system, either alone or together with other products, requires significant production, modification, or customization of software, a system, or the other products, that contract should be accounted for in conformity with ARB 45, Long-Term Construction-Type Contracts, using the relevant guidance in SOP 81-1, Accounting for Performance of Construction-Type and Certain Production-Type Contracts. However, transactions that are normally accounted for as product sales should not be accounted for as long-term contracts merely to avoid the delivery requirements for revenue recognition normally 7. Service transactions—If, in addition to the obligation to deliver the software, the sales or licensing agreement includes obligations to perform services that (a) are not interdependent with the providing of a software product and (b) are separately stated and priced such that the total price of the agreement would be expected to vary as a result of the inclusion or exclusion of the services, the sales or licensing component and the services should be accounted for separately. If collectibility is probable, revenue from software services should generally be recognized as the services are performed or, if no pattern of performance is discernible, ratably over the period during which the services are performed. If significant uncertainty about customer acceptance of the services exists, revenue should not be recognized until the uncertainty is removed. 8. Postcontract customer support. If collectibility is probable, revenue from postcontract customer support (PCS), including revenue that is contractually bundled with initial licensing fees, should be recognized ratably over the term of the contract.https://egrove.olemiss.edu/aicpa_sop/1546/thumbnail.jp

Computer game development education at university

This paper articulates some of the challenges for computer game development courses at university level. A typical course development of this type is described. The need to include creative methods alongside more formal software development methodologies as core elements of computer game education is proposed and placed within the context of an industry specific framework. The evolutionary nature of the computer game industry requires that computer game development programmes at university should be equally evolutionary and adaptable to change

Development of a computer software for the monitoring of subsidence

A computer software has been developed at the Faculty of Geoinformation Science and Engineering, UTM for the purpose of detecting subsidence of ground surface or manmade structure by using Visual Basic 6.0 and FORTRAN computer languages. This software can be used for processing data from GPS and precise levelling methods. The software requires GPS baseline vectors (∆X, ∆Y, ∆Z). Relative ellipsoidal heights based on the WGS84 ellipsoidal surface must be derived from these baseline vectors. The derived relative ellipsoidal heights are then adjusted using least square estimation method. The adjusted heights will be used for further subsidence analysis. Stransformation is used to transform results from least square estimation using minimum constraints to a selected datum. This paper examines the method of subsidence using the iterative weighted transformation. In this method, the stability of reference points must be checked through a single point test. Stable points will then be adjusted again together with object points. Lastly, the stability of object points will be determined. User of this software requires little knowledge on deformation monitoring processing, as the user needs to follow the procedure of inputting data required by the software. The output from the software will give the stability of the all control points whether they have moved or otherwise

Measuring the impact of computer resource quality on the software development process and product

The availability and quality of computer resources during the software development process was speculated to have measurable, significant impact on the efficiency of the development process and the quality of the resulting product. Environment components such as the types of tools, machine responsiveness, and quantity of direct access storage may play a major role in the effort to produce the product and in its subsequent quality as measured by factors such as reliability and ease of maintenance. During the past six years, the NASA Goddard Space Flight Center has conducted experiments with software projects in an attempt to better understand the impact of software development methodologies, environments, and general technologies on the software process and product. Data was extracted and examined from nearly 50 software development projects. All were related to support of satellite flight dynamics ground-based computations. The relationship between computer resources and the software development process and product as exemplified by the subject NASA data was examined. Based upon the results, a number of computer resource-related implications are provided

Framework Programmable Platform for the Advanced Software Development Workstation (FPP/ASDW). Demonstration framework document. Volume 1: Concepts and activity descriptions

The Framework Programmable Software Development Platform (FPP) is a project aimed at effectively combining tool and data integration mechanisms with a model of the software development process to provide an intelligent integrated software development environment. Guided by the model, this system development framework will take advantage of an integrated operating environment to automate effectively the management of the software development process so that costly mistakes during the development phase can be eliminated. The Advanced Software Development Workstation (ASDW) program is conducting research into development of advanced technologies for Computer Aided Software Engineering (CASE)