Reflections on WISDM:Reflections on the case

By -
12.4 Reflections on the case

In this section the differences between web-based IS development and traditional, pre-Internet development are considered, followed by reflections on the role of methodology in IS development. The outcome of this reflection is a revised WISDM framework for IS development in general. In chapter 3 Baskerville & Pries-Heje (2001) outlined ten characteristics of Internet development, which are used here to analyse the GDS case:

Time pressure: The users and senior management expected early and frequent delivery of prototypes.

Vague requirements: The high level aims of the project were clear (deliver research data to customers via the Internet) but the detailed requirements were unknown (e.g., how would the research data be packaged, priced, and presented to the user in graphical format?).

Prototyping: The detailed requirements were explored and developed through successive prototypes. Since a formal requirements dictionary was not kept the prototype became the detailed specification.

Release orientation: The release early and often approach of open source software was followed throughout, for internal prototypes and for the production system. This helped the development of the requirements specification and enabled new features to be delivered to customers on a regular basis in response to comments and feedback.

Parallel development: Analysis and design were conducted in parallel throughout the project, each informing the other.

Fixed architecture: A three-tier architecture was adopted at a later stage of the project to manage the complexity and to avoid being overwhelmed by the software maintenance task.

Coding your way out: Coding your way out was a fact of life. Emergency fixes and last minute requirements led to 'hacks' being made, with the documentation left to catch up later, 'when things are quieter'.

Quality is negotiable: The benchmark for quality is customer perceptions, rather than the internally focussed perspectives of the product and the software development process.

Dependence on good people: Given the timescale and the small project team, dependence on good people was an absolute requirement. An able Associate who is quick to learn was an essential prerequisite to the success of the project. However, it is particularly difficult to predict the learning ability and aptitude of a novice developer and to a rather worrying extent the project is largely dependent on the 'luck of the draw'. With larger projects there might be some resilience to developer variability – with Internet time projects with small numbers of specialized resources (e.g., graphic design, database design) getting the personnel resources wrong has catastrophic implications

Need for new structures of IS development: This may be the case where there is a traditional systems development department in existence, but in the case of the GDS project the team were working in a green field situation and created working structures and routines as the project unfolded.

Although the ten concepts capture the emergent WISDM and our experience on the GDS project well, as we pointed out in chapter 3, it is less clear that the concepts really capture the differences between web-based IS development and traditional IS development. However, there are differences between web-based projects and traditional IS development, but these differences are more to do with concrete content than with abstractions (table 12.1).

As Internet projects become broader in scope requiring greater integration with front office, back office, and legacy IT systems of all sorts, then Internet projects will become yet more difficult to distinguish from traditional IT projects. Traditional IS projects would also benefit from giving more attention to strategy, customers, and design aesthetics and therefore the distinctions in table 12.1 should, over time, become less pronounced and ultimately disappear altogether.

Comments

Post a Comment

Popular posts from this blog

The Conversion Cycle:The Traditional Manufacturing Environment

By -
Image
The Traditional Manufacturing Environment The conversion cycle consists of both physical and information activities related to manufacturing products for sale. The context-level data flow diagram (DFD) in Figure 7-1 illustrates the central role of the conversion cycle and its interactions with other business cycles. Production is triggered by customer orders from the revenue cycle and/or by sales forecasts from marketing. These inputs are used to set a production target and prepare a production plan, which drives production activities. Purchase requisitions for the raw materials needed to meet production objectives are sent to the purchases procedures (expenditure cycle), which prepares purchase orders for vendors. Labor used in production is transmitted to the payroll system (expenditure cycle) for payroll processing. Manufacturing costs associated with intermediate work-in-process and finished goods (FG) are sent to the general ledger (GL) and financial reporting system. Dependin
Read more

The Revenue Cycle:Manual Systems

By -
Image
Manual Systems The purpose of this section is to support the system concepts presented in the previous section with models depicting people, organizational units, and physical documents and files. This section should help you envision the segregation of duties and independent verifications, which are essential to effective internal control regardless of the technology in place. In addition, we highlight inefficiencies intrinsic to manual systems, which gave rise to modern systems using improved technologies. SALES ORDER PROCESSING The system flowchart in Figure 4-12 shows the procedures and the documents typical to a manual sales order system. In manual systems, maintaining physical files of source documents is critical to the audit trail. As we walk through the flowchart, notice that in each department, after completion of the assigned task, one or more documents are filed as evidence that the task was completed. Sales Department The sales process begins with a customer cont
Read more

HIPO (hierarchy plus input-process-output)

By -
Image
HIPO (hierarchy plus input-process-output) 64.1 Purpose The HIPO (Hierarchy plus Input-Process-Output) technique is a tool for planning and/or documenting a computer program. A HIPO model consists of a hierarchy chart that graphically represents the program’s control structure and a set of IPO (Input-Process-Output) charts that describe the inputs to, the outputs from, and the functions (or processes) performed by each module on the hierarchy chart. 64.2 Strengths, weaknesses, and limitations Using the HIPO technique, designers can evaluate and refine a program’s design, and correct flaws prior to implementation. Given the graphic nature of HIPO, users and managers can easily follow a program’s structure. The hierarchy chart serves as a useful planning and visualization document for managing the program development process. The IPO charts define for the programmer each module’s inputs, outputs, and algorithms. In theory, HIPO provides valuable long-term documentation. However
Read more