Selling packaged software: an ethical analysis

Within the IS literature there is little discussion on selling software products in general and especially from the ethical point of view. Similarly, within computer ethics, although there is much interest in professionalism and professional codes, in terms of accountability and responsibility, the spotlight tends to play on safety-critical or life-critical systems, rather than on software oriented towards the more mundane aspects of work organisation and society. With this research gap in mind, we offer a preliminary ethical investigation of packaged software selling. Through an analysis of the features of competition in the market, the global nature of the packaged software market and the nature of product development we conclude that professionalism, as usually conceived in computer ethics, does not apply particularly well to software vendors. Thus, we call for a broader definition of professionalism to include software vendors, not just software developers. Moreover, we acknowledge that with intermediaries, such as implementation consultants, involved in software selling, and the packaged software industry more generally, there are even more “hands” involved. Therefore, we contend that this is an area worthy of further study, which is likely to yield more on the question of accountability

A systematic review of software development cost estimation studies

This paper aims to provide a basis for the improvement of software estimation research through a systematic review of previous work. The review identifies 304 software cost estimation papers in 76 journals and classifies the papers according to research topic, estimation approach, research approach, study context and data set. A web-based library of these cost estimation papers is provided to ease the identification of relevant estimation research results. The review results combined with other knowledge provide support for recommendations for future software cost estimation research, including: 1) Increase the breadth of the search for relevant studies, 2) Search manually for relevant papers within a carefully selected set of journals when completeness is essential, 3) Conduct more studies on estimation methods commonly used by the software industry, and, 4) Increase the awareness of how properties of the data sets impact the results when evaluating estimation methods

Function Point: A Quality Loom for the Effort Assessment of Software Systems

Summary Accurate estimation of software development effort is critical in software engineering. Underestimates lead to time pressures that may compromise full functional development and thorough testing of software. In the existing systems, the effort and cost estimation are more concentrated only on the development of software systems alone and not on the quality coverage. Hence the quality assurance for the effort estimation is proposed in this paper. To assure this quality, the ISO 9126 quality factors are used. For weighing the factors, the function point metric is used as an estimation approach. The classification of software system for which the effort estimation is to be calculated based on the COCOMO model classes. An exhaustive literature survey reveals that attention is not paid to the following for estimating the effort: 1. Function point, 2. COCOMO classes of systems, and 3. ISO9126 quality factors. Thus by combining all the three parts, a new effort estimation method is developed as a research approach

The Scalable Startup : Customer, Business and Software

A software startup building a business upon the introspective vision of an entrepreneur is subject to many risks. Customers may reject the product. The business model may prove infeasible. Software production may fail because a product needs to be quickly implemented with scarce resources. This work examines how open-ended interviews with potential customers influence introspective hypotheses on important customer problems and planned software features. A research method based on the Customer Development methodology and the Business Model Ontology is applied to a real business idea. Results indicate that for the business idea case studied, early customer interviews reduced all three aforementioned risks. Risk of customer rejection was reduced by the exposure of problem hypotheses to real customer feedback. As a result some hypotheses were shown to be flawed, while also new previously unknown important customer problems were discovered. Customer risk was further reduced by the entrepreneur gaining knowledge on the domain of the customer. Business risk was reduced by concretely identifying and describing the whole business model of the business idea. By constructing a business model a technology-minded entrepreneur was forced to hypothesize on important business considerations that could have otherwise posed risks for the future of the enterprise. Software risk was reduced by the early identification of software features with negligible customer value. The interview data indicated that some planned features would be unimportant for customers. The feedback gathered provided directions for a more appropriate feature set for the planned software product. In the context of market-driven software engineering Customer Development can be applied as a sales-oriented requirements elicitation method to develop minimal products that can effectively sold to a large number of customers

An interpretive field study of packaged software selection processes

Packaged software is pre-built with the intention of licensing it to users in domestic settings and work organisations. This thesis focuses upon the work organisation where packaged software has been characterised as one of the latest ‘solutions’ to the problems of information systems. The study investigates the packaged software selection process that has, to date, been largely viewed as objective and rational. In contrast, this interpretive study is based on a 2½ year long field study of organisational experiences with packaged software selection at T.Co, a consultancy organisation based in the United Kingdom. Emerging from the iterative process of case study and action research is an alternative theory of packaged software selection. The research argues that packaged software selection is far from the rationalistic and linear process that previous studies suggest. Instead, the study finds that aspects of the traditional process of selection incorporating the activities of gathering requirements, evaluation and selection based on ‘best fit’ may or may not take place. Furthermore, even where these aspects occur they may not have equal weight or impact upon implementation and usage as may be expected. This is due to the influence of those multiple realities which originate from the organisational and market environments within which packages are created, selected and used, the lack of homogeneity in organisational contexts and the variously interpreted characteristics of the package in question

An Empirical investigation of software project schedule behavior.

Two intensive, longitudinal case studies were conducted at IBM Hursley Park. There were several objectives to these case studies: first, to investigate the actual behaviour of the two projects in depth; second, to develop conceptual structures relating the lower-level processes of each project to the higher-level processes; third, to relate the lower-level and higher-level processes to project duration; fourth, to test a conjecture forwarded by Bradac et al i. e. that waiting is more prevalent during the end of a project than during the middle of a project. A large volume of qualitative and quantitative evidence was collected and analysed for each project. This evidence included minutes of status meetings, interviews, project schedules, and information from feedback workshops (which were conducted several months after the completion of the projects). The analysis generated three models and numerous insights into software project behaviour. The models concerned software project schedule behaviour, capability and an integration of schedule behaviour and capability. The insights concerned characteristics of a project (i. e. the actual progress of phases and milestones, the amount of workload on the project, the degree of capability of the project, tactics of management, and the sociotechnical aspects of a project) and characteristics of process areas within a project (i. e. waiting, poor progress and outstanding work). Support for the models and the insights was sought, with some success, from previous research. Despite the approach taken in this investigation (i. e. the collection of a large volume of evidence and the analyses of a wide variety of factors using a very broad perspective), this investigation has been unable to pinpoint definite causes to explain why a project will or will not complete according to its original plan. One `hint' of an explanation are the differences between the socio-technical contexts of the two projects and, related to this, the fact that tactics of management may be constrained by a project's socio-technical context. Furthermore, while the concept of a project as a distinct entity seems reasonable, the actual boundaries of a project in an organisation's `space-time' are ambiguous and very difficult to properly define. Therefore, it may be that those things that make a project difficult to distinguish from its surrounding organisation are interwoven with the socio-technical contexts of a project, and may be precisely those things that explain the progress of that project. Recommendations, based on the models, the insights and the conclusions, are provided for industry and research