Question

Consider the following case study:

Darwin College Darwin College is a liberal arts college located in Northern Territory. You are the systems analyst assigned from the college IT department to conduct the systems analysis phase of the development of a new listing system for the school’s housing office.

Based on your earlier recommendations, the housing office decided to continue the systems development process for a new listing system.

Now, at the end of the systems analysis phase, you are ready to prepare a system requirements document and give a presentation to the housing office. You must examine tangible costs and benefits to determine the economic feasibility of several alternatives. If the housing office decides to go ahead with the development process, the system can either be developed in-house or purchased as a vertical package and configured to meet the needs of the office.

Currently, housing listings are created by an employee at the housing office. While the demands on her time vary throughout the year, based on previous work logs kept by employees in the office you determine that the time spent maintaining the manual system (creating listing sheets for the various binders, copying, and filing listings in binders) by this employee works out to an average of 30 hours of overtime per month. The overtime cost of this employee is $25 per hour, including overhead.

Housing listings are pulled throughout the month, and all listings are reviewed once a month to delete those more than two months old. Currently, the once a month reviews are done by a student worker who spends 25 hours a month going through the 15 binders at the housing office and pulling all old listings for review by a housing office staff member. This student is paid $12.50 per hour, including overhead. A new system would conduct this review automatically, and generate a list for review.

Your estimates indicate that the housing office can expect to have staff spend 4 hours a week performing maintenance, file backups, and updating of the new system, at $25 per hour.

The university has lost revenue on some of its rental properties, having them lie idle for a month because of listings pulled either erroneously by staff, or deliberately by people using the housing listing service. Estimates put the amount of lost revenue due to listing problems such as these at two per cent of anticipated yearly rental receipts. In the current year, the anticipated rental receipts total $680,000. Annual rent increases vary from year to year depending on market rates but the average increase is three per cent per year.

Based on your research, you originally estimated that an in-house development project could be completed in about three weeks. This time estimate is based on 55 hours a week split between you and another analyst from the IT department. The IT department uses a chargeback rate of $40 per hour for work for other university departments. Three training sessions of four hours each will be required to train all staff in the new system. The charge-back cost of a training specialist from the IT department is $25 per hour. Training and support for the first year for the vertical software package are included in the initial price.

As an alternative to in-house development, a vertical software package is available for about $6,000, including an on-site day of training and support for the first year. If the department buys the package, it would take you about two weeks to install, configure, and test it, working full-time. The vendor provides free support during the first year of operation, but then the housing office must sign a support agreement at an annual cost of $750.

For both the in-house development and the vertical software package, the necessary hardware will cost about $3,500. Network upgrading, necessary for either option, has been estimated at $4,000 by the network operations team.

In your view, the useful life of the system will be about five years, including the year in which the system becomes operational.

Answer the following questions:

You scheduled a presentation to the housing office next week and you must submit a system requirements document during the presentation. Prepare both the written documentation and the presentation. Your oral and written presentation must include the following tasks:

a. What options for a development strategy does Darwin College have for developing a new system? Provide a brief explanation of specific alternatives that should be considered if development continues including in-house development and other strategies that would be a good fit. Justify your suggestions by analysing the advantages and disadvantages of the chosen methods.

b. You have been asked to prepare a system requirements document and deliver a presentation to the housing office management. What should be the main elements of the system requirements document?

c. What financial analysis tools are available to calculate the total cost of ownership for the system? What are the advantages (and possible disadvantages) of each tool?

Answer 1

Answer to point a)

options for a Inhouse development strategy , their advantages and disadvantages.

Option 1 : Water Fall Model

The waterfall approach is a traditional development approach in which each phase is carried in sequence or linear fashion. These phases include requirements analysis, specifications and design requirements, coding, final testing, and release. In this traditional approach of system development, activities are performed in sequence as shown below. When the traditional approach is applied, an activity is undertaken only when the prior step is fully completed.

The characterizing features of this model have influenced the development community in big way. Some of the key characteristics are the following:

• Project is divided into sequential phases, with some overlap and splash back acceptable between phases.
• Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire system at one time.
• Tight control is maintained over the life of the project through the use of extensive written documentation, as well as through formal reviews and approval/signoff by the user and information technology management occurring at the end of most phases before beginning the next phase

(a) Strengths: The fundamental strength of the waterfall model has made it quite popular and handy among the fraternity. Major strengths are given as follows:

• It is ideal for supporting less experienced project teams and project managers or project teams, whose composition fluctuates.

• The orderly sequence of development steps and design reviews help to ensure the quality, reliability, adequacy and maintainability of the developed software.

• Progress of system development is measurable.

• It enables to conserve resources.

(b) Weaknesses: Though it is highly useful model, it suffers from various weaknesses too. Experts and practitioners identify a number of weaknesses including the following:

• It is criticized to be inflexible, slow, costly, and cumbersome due to significant structure and tight controls.

• Project progresses forward, with only slight movement backward.

• There is a little to iterate, which may be essential i n situations.

• It depends upon early identification and specification of requirements, even if the users may not be able to clearly define 'what they need early in the project'.

• Requirement inconsistencies,    missing system components     and unexpected development needs are often discovered during design and coding.

• Problems are often not discovered until system testing.

• System performance cannot be tested until the system is almost fully coded, and under capacity may be difficult to correct.

• It is difficult to respond to changes, which may occur later in the life cycle, and if undertaken it proves costly and are thus discouraged.

• It leads to excessive documentation, whose updation to assure integrity is an uphill task and often time-consuming.

• Written specifications are often difficult for users to read and thoroughly appreciate.

• It promotes the gap between users and developers with clear vision of responsibility.

Option 2: The Prototyping Model

The traditional approach sometimes may take years to analyze, design and implement a system. More so, many a times we know a little about the system until and unless we go through its working phases, which are not available. In order to avoid such bottlenecks and overcome the issues, organizations are increasingly using prototyping techniques to develop smaller systems such as DSS, MIS and Expert systems. The goal of prototyping approach is to develop a small or pilot version called a prototype of part or all of a system. A prototype is a usable system or system component that is built quickly and at a lesser cost, and with the intention of modifying/replicating/expanding or even replacing it by a full -scale and fully operational system. As users work with the prototype, they learn about the system cri ticalities and make suggestions about the ways to manage it. These suggestions are then incorporated to improve the prototype, which is also used and evaluated. Finally, when a prototype is developed that satisfies all user requirements, either it is refined and turned into the final system or it is scrapped. If it is scrapped, the knowledge gained from building the prototype is used to develop the real system.

Prototyping can be viewed as a series of four steps, symbolically depicted in Fig. 5.4.2 wherein Implementation and Maintenance phases followed by full-blown developments take place once the prototype model is tested and found to be meet uses' requirements. The generic phases of this model are explained as follows:

• Identify Information System Requirements: In traditional approach, the system requirements are to be identified before the development process starts. However, under prototype approach, the design team needs only fundamental system requirements to build the initial prototype, the process of determining them can be less formal and time­ consuming than when performing traditional systems analysis.

• Develop the Initial Prototype: The designers create an initial base model and give little or no consideration to internal controls, but instead emphasize system characteristics such as simplicity, flexibility, and ease of use. These characteristics enable users to interact with tentative versions of data entry display screens, menus, input prompts, and source documents. The users also need to be able to respond to system prompts, make inquiries of the information system, judge response times of the system, and issue commands.

• Test and Revise: After finishing the initial prototype, the designers first demonstrate the model to users and then give it to them to experiment and ask users to record their likes and dislikes about the system and recommend changes. Using this feedback, the design team modifies the prototype as necessary and then resubmits the revised model to system users for reevaluation. Thus iterative process of modification and reevaluation continues until the users are satisfied.

• Obtain User Signoff of the Approved Prototype: Users formally approve the final version of the prototype, which commits them to the current design and establishes a contractual obligation about what the system will, and will not, do or provide. Prototyping is not commonly used for developing traditional applications such as accounts receivable, accounts payable, payroll, or inventory management, where the inputs, processing, and outputs are well known and clearly defined.

(a) Strengths: Some of its strengths identified by the experts and practitioners include the following:

• It improves both user participation in system development and communication among project stakeholders.

• It is especially useful for resolving unclear objectives; developing and validating user requirements; experimenting with or comparing various design solutions, or investigating both performance and the human computer interface.

• Potential exists for exploiting knowledge gained in an early iteration as later iterations are developed.

• It helps to easily identify, confusing or difficult functions and missing functionality.

• It enables to generate specifications for a production application.

• It encourages innovation and flexible designs.

• It provides for quick implementation of an incomplete, but functional, application.

• It typically results in a better definition of these users' needs and requirements than does the traditional systems development approach.

• A very short time period is normally required to develop and start experimenting with a prototype. This short time period allows system users to immediately evaluate proposed system changes.

• Since system users experiment with each version of the prototype through an interactive process, errors are hopefully detected and eliminated early in the developmental process. As a result, the information system ultimately implemented should be more reliable and less costly to develop than when the traditional systems development approach is employed.

(b) Weaknesses: Some of the weaknesses identified by the experts and practitioners include the following:

• Approval process and control are not strict.

• Incomplete or inadequate problem analysis may occur whereby only the most obvious and superficial needs will be addressed, resulting in current inefficient practices being easily built into the new system.

• Requirements may frequently change significantly.

• Identification of non-functional elements is difficult to document

• Designers may prototype too quickly, without sufficient upfront user needs analysis, resulting in an inflexible design with narrow focus that limits future system potential.

• Prototype may not have sufficient checks and balances incorporated.

• Prototyping can only be successful if the system users are willing to devote significant time in experimenting with the prototype and provide the system developers with change suggestions. The users may not be able or willing to spend the amount of time required under the prototyping approach.

• The interactive process of prototyping causes the prototype to be experimented with quite extensively. Because of this, the system developers are frequently tempted to minimize the testing and documentation process of the ultimately approved information system. Inadequate testing can make the approved system error-prone, and inadequate documentation makes this system difficult to maintain.

• Prototyping may cause behavioral problems with system users. These problems include dissatisfaction by users if system developers are unable to meet all user demands for improvements as well as dissatisfaction and impatience by users when they have to go through too many interactions of the prototype.

In spite of above listed weaknesses, to some extent, systems analysis and development has been greatly improved by the introduction of prototyping. Prototyping enables the user to take an active part in the systems design, with the analyst acting in an advisory role. Prototyping makes use of the expertise of both the user and the analyst, thus ensuring better anal ysis and design, and prototyping is a crucial tool in that process.

Option 3 : Incremental model

The Incremental model is a method of software development where the model is designed, implemented and tested incrementally (a little more is added each time) until the product is finished. The product is defined as finished when it satisfies all of its requirements. This model combines the elements of the waterfall model with the iterative philosophy of prototyping

The product is decomposed into a number of components, each of which are designed and built separately (termed as builds). Each component is delivered to the client when it is complete. This allows partial utilization of product and avoids a long development time. It also creates a large initial capital outlay with the subsequent long wait avoided. This model of development also helps to ease the traumatic effect of introducing completely new system all at once. A few pertinent features are listed as follows:

• A series of mini-waterfalls are performed, where all phases of the waterfall development model are completed for a small part of the system, before proceeding to the next increment.

• Overall requirements are defined before proceeding to evolutionary, mini - Waterfall development of individual increments of the system.

• The initial software concept, requirement analysis, and design of architecture and system core are defined using the Waterfall approach, followed by iterative Prototyping, which culminates in installation of the final prototype (i.e. Working system).

(a) Strengths: Some of its strengths identified by the experts and practitioners include the following:

• Potential exists for exploiting knowledge gained in an early increment as later increments are developed.

• Moderate control is maintained over the life of the project through the use of written documentation and the formal review and approval/signoff by the user and information technology management at designated major milestones.

• Stakeholders can be given concrete evidence of project status throughout the life cycle.

• It is more flexible and less costly to change scope and requirements.

• It helps to mitigate integration and architectural risks earlier in the project.

• It allows the delivery of a series of implementations that are gradually more complete and can go into production more quickly as incremental releases.

• Gradual implementation provides the ability to monitor the effect of incremental changes, isolated issues and make adjustments before the organization is negatively impacted.

(a) Weaknesses: Some of the weaknesses identified by the experts and practitioners include the following:

• When utilizing a series of mini-waterfalls for a small part of the system before moving onto the next increment, there is usually a lack of overall consideration of the business problem and technical requirements for the overall system.

• Each phase of an iteration is rigid and do not overlap each other.

• Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle.

• Since some modules will be completed much earlier than others, well -defined interfaces are required.

• It is difficult to demonstrate early success to management.

Option 4 - Spiral Model

The Spiral model is a software development process combining elements of both design and prototyping-in-stages. It tries to combine advantages of top-down and bottom-up concepts. It combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects. Game development is a main area where the spiral model is used and needed, that is because of the size and the constantly shifting goals of those large projects. A list of pertinent characterizing features includes the following:

• The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.

• A preliminary design is created for the new system. This phase is the most important part of "Spiral Model" in which all possible alternatives that can help in developing a cost effective project are analyzed and strategies are decided to use them. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements.

• A first prototype of the new system in constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.

• A second prototype is evolved by a fourfold procedure by evaluating the first prototype in terms of its strengths, weaknesses, and risks; defining the requirements of the second prototype; planning and designing the second prototype; and constructing and testing the second prototype.

(a) Strengths: Some of its strengths identified by the experts and practitioners include the following:

• It enhances the risk avoidance.

• It is useful in helping for optimal development of a given software iteration based on project risk.

• It can incorporate Waterfall, Prototyping, and Incremental methodologies as special cases in the framework, and provide guidance as to which combination of these models best fits a given software iteration, based upon the type of project risk. For example, a project with low risk of not meeting user requirements but high risk of missing budget or schedule targets would essentially follow a linear Waterfall approach for a given software iteration. Conversely, if the risk factors were reversed, the Spiral methodology could yield an iterative prototyping approach.

(a) Weaknesses: Some of the weaknesses identified by the experts and practitioners include the following:

• It is challenging to determine the exact composition of development methodologies to use for each iteration around the Spiral.

• It may prove highly customized to each project, and thus is quite complex and limits reusability.

• A skilled and experienced project manager is required to determine how to apply it to any given project.

• No established controls exist for moving from one cycle to another cycle. Without controls, each cycle may generate more work for the next cycle.

There are no firm deadlines, cycles continue with no clear termination condition leading to, inherent risk of not meeting budget or schedule.

Option 5 - Rapid Application Development

Rapid Application Development (RAD) refers to a type of software development methodology; which uses minimal planning in favor of rapid prototyping. The planning of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements. Key features include the following:

• Key objective is fast development and delivery of a high quality system at a relatively low investment cost,

• Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process.

• Aims to produce high quality systems quickly, primarily through the use of iterative Prototyping (at any stage of development), active user involvement, and computerized development tools. Graphical User Interface (GUI) builders, Computer Aided Software Engineering (CASE) tools, Database Management Systems (DBMS), Fourth generation programming languages, Code generators and object-oriented techniques etc.

• Key emphasis is on fulfilling the business need while technological or engineering excellence is of lesser importance.

• Project control involves prioritizing development and defining delivery deadlines or "timeboxes." If the project starts to slip, emphasis is on reducing requirements to fit the timebox, not in increasing the deadline.

• Generally includes Joint Application Development (JAD), where users are intensely involved in system design, either through consensus building in structured workshops, or through electronically facilitated interaction.

• Active user involvement is imperative.

• Iteratively produces production software, as opposed to a throwaway prototype.

• Produces documentation necessary to facilitate future development and maintenance.

• Standard systems analysis and design techniques can be fitted into this framework.

(a) Strengths: Some of the strengths identified by the experts and practitioners include the following:

• The operational version of an application is available much earlier than with Waterfall, Incremental, or Spiral frameworks.

• Because RAD produces systems more quickly and to a business focus, this approach tends to produce systems at lower cost.

• Quick initial reviews are possible.

• Constant integration isolates problems and encourages customer feedback.

• It holds a great level of commitment from stakeholders, both business and technical, than Waterfall, Incremental, or spiral frameworks. Users are seen as gaining more of a sense of ownership of a system, while developer are seen as gaining more satisfaction from producing successful systems quickly.

• It concentrates on essential system elements from user viewpoint.

• It provides for the ability to rapidly change system design as demanded by users.

• It leads to a tighter fit between user requirements and system specifications.

(a) Weaknesses: Some of the weaknesses identified by the experts and practitioners include the following:

• Fast speed and lower cost may affect adversely the system quality.

• The project may end up with more requirements than needed (gold-plating).

• Potential for feature creep where more and more features are added to the system over the course of development.

• It may lead to inconsistent designs within and across systems.

• It may call for violation of programming standards related to inconsistent naming conventions and inconsistent documentation,

• It may call for lack of attention to later system administration needs built into system.

• Formal reviews and audits are more difficult to implement than for a complete system.

• Tendency for difficult problems to be pushed to the future to demonstrate early success to management.

• Since some modules will be completed much earlier than others, well -defined interfaces are required.

Option 6 - Agile Model

This is an organized set of software development methodologies based on the iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery; time boxed iterative approach and encourages rapid and flexibl e response to change. It is a conceptual framework that promotes foreseen interactions throughout the development life cycle. Agile Manifesto is based on following 12 features:

• Customer satisfaction by rapid delivery of useful software;

• Welcome changing requirements, even late in development;

• Working software is delivered frequently (weeks rather than months);

• Working software is the principal measure of progress;

• Sustainable development, able to maintain a constant pace;

• Close, daily co-operation between business people and developers;

• Face-to-face conversation is the best form of communication (co-location);

• Projects are built around motivated individuals, who should be trusted;

• Continuous attention to technical excellence and good design;

• Simplicity;

• Self-organizing teams; and

• Regular adaptation to changing circumstances.

(a) Strengths: Some of the strengths identified by the experts and practitioners include the following:

• Agile methodology has the concept of an adaptive team, which enables to respond to the changing requirements.

• The team does not have to invest time and efforts and finally find that by the time they delivered the product, the requirement of the customer has changed.

• Face to face communication and continuous inputs from customer representative leaves a little space for guesswork.

• The documentation is crisp and to the point to save time.

• The end result is generally the high quality software in least possible time duration and satisfied customer.

(a) Weaknesses: Some of the weaknesses identified by the experts and practitioners include the following:

• In case of some software deliverables, especially the large ones, it is difficult to assess the efforts required at the beginning of the software development life cycle.

• There is lack of emphasis on necessary designing and documentation.

• Agile increases potential threats to business continuity and knowledge transfer. By nature, Agile projects are extremely light on documentation because the team focuses on verbal communication with the customer rather than on documents or manuals.

• Agile requires more re-work and due to the lack of long-term planning and the lightweight approach to architecture, re-work is often required on Agile projects when the various components of the software are combined and forced to interact.

• The project can easily get taken off track if the customer representative is not clear about the final outcome.

• Agile lacks the attention to outside integration.

Answer to point b)

Main Elements of Systems requirements documet are

1) Functional Requirements

2) Performance Requirements

3) Interface Requirements

4) Operational Requirements

5) Resources Requirements

6) Design and Implementation Constraints

7) Software Configuration and Delivery Requirements

8) Adaptation and Installation Requirements

9) Verification, Validation and Acceptance Requirements

Answer to C)

Fiancial Analysis Tools to calculate cost of ownerhip for the system are

1) Return on Investment

(i) Return on Investment (referred as ROI): This defines the return, an entity shall earn on a particular investment i.e. capital expenditure. This financial data is a prime consideration for any capital expenditure entity decides to incur. The important data required for this analysis being the cost of project, the expected revenue/benefit for a given pe riod. The analysis ideally needs to be done before the start of the development efforts for better decision making by management. For this analysis following data needs to be generated.

(a) Cost: This includes estimates for typical costs involved in the development, which are given as follows:

• Development Costs: Development Costs for a computer based information system include costs of the system development process, like salaries of developer s.

• Operating Costs: Operating Costs of a computer based information system including hardware/software rental or depreciation charges; sal aries of computer operators and other data processing personnel, who will operate the new system.

• Intangible Costs: Intangible Cost that cannot be easily measured. For exampl e, the development of a new system may disrupt the activities of an organization and cause a loss of employee productivity or morale.

(a) Benefits: The benefits, which result from developing new or improved information systems that can be subdivided into tangible and intangible benefits. A post implementation analysis is also done to see how the system development effort has benefitted an organization. For example: A large oil company in public sector, few years back implemented an ERP system at a total cost of 100 crores. The calculated benefits from the project were 40 crores per annum. Above data gives an actual ROI of 40%, which is tremendous for any business. Same also tells the payback period is around 2.5 years.

2) Computing Cost of IT Implementation and Cost Benefit Analysis:

Cost and Benefit Categories

In performing Cost benefit analysis (CBA) it is important to identify cost and benefit factors. Cost and benefits can be categorized into the following categories.

There are several cost factors/elements. These are hardware, personnel, facility, operating, and supply costs.

In a broad sense the costs can be divided into two types

1. Development costs-

Development costs that are incurred during the development of the system are one time investment.

• Wages

• Equipment

2. Operating costs,

e.g. , Wages
Supplies
Overheads

Another classification of the costs can be:

Hardware/software costs:

It includes the cost of purchasing or leasing of computers and it's peripherals. Software costs involves required software costs.

Personnel costs:

It is the money, spent on the people involved in the development of the system. These expenditures include salaries, other benefits such as health insurance, conveyance allowance, etc.

Facility costs:

Expenses incurred during the preparation of the physical site where the system will be operational. These can be wiring, flooring, acoustics, lighting, and air conditioning.

Operating costs:

Operating costs are the expenses required for the day to day running of the system. This includes the maintenance of the system. That can be in the form of maintaining the hardware or application programs or money paid to professionals responsible for running or maintaining the system.

Supply costs:

These are variable costs that vary proportionately with the amount of use of paper, ribbons, disks, and the like. These should be estimated and included in the overall cost ofthe system.

Benefits

We can define benefit as
Profit or Benefit = Income - Costs

Benefits can be accrued by :

- Increasing income, or
- Decreasing costs, or
- both

The system will provide some benefits also. Benefits can be tangible or intangible, direct or indirect. In cost benefit analysis, the first task is to identify each benefit and assign a monetary value to it.

The two main benefits are improved performance and minimized processing costs.

Further costs and benefits can be categorized as

Tangible or Intangible Costs and Benefits

Tangible cost and benefits can be measured. Hardware costs, salaries for professionals, software cost are all tangible costs. They are identified and measured.. The purchase of hardware or software, personnel training, and employee salaries are example of tangible costs. Costs whose value cannot be measured are referred as intangible costs. The cost of breakdown of an online system during banking hours will cause the bank lose deposits.

Benefits are also tangible or intangible. For example, more customer satisfaction, improved company status, etc are all intangible benefits. Whereas improved response time, producing error free output such as producing reports are all tangible benefits. Both tangible and intangible costs and benefits should be considered in the evaluation process.

Direct or Indirect Costs and Benefits

From the cost accounting point of view, the costs are treated as either direct or indirect. Direct costs are having rupee value associated with it. Direct benefits are also attributable to a given project. For example, if the proposed system that can handle more transactions say 25% more than the present system then it is direct benefit.

Indirect costs result from the operations that are not directly associated with the system. Insurance, maintenance, heat, light, air conditioning are all indirect costs.

Fixed or Variable Costs and Benefits

Some costs and benefits are fixed. Fixed costs don't change. Depreciation of hardware, Insurance, etc are all fixed costs. Variable costs are incurred on regular basis. Recurring period may be weekly or monthly depending upon the system. They are proportional to the work volume and continue as long as system is in operation.

Fixed benefits don't change. Variable benefits are realized on a regular basis.