Why is selecting a systems development approach

This feels like a natural fit to me. Also, business analysts are used to challenging 'great ideas' and conventional wisdom, putting forward views that are independent and focus on the business needs. They are concerned with taking a holistic view of the solution and don't have a vested interest in which approach is used to actually deliver the software. In many cases organisational change is initiated when an internal stakeholder raises a problem or concern which is perceived to be urgent.

Systems development approaches - selecting the best way forward. Blog date: 31 May Identifying and describing existing processes, understanding the process costs and process duration bring to the next step of decision how to improve these processes and can involve different layers of organization and even multiple companies if they are part of the shared processes.

Some have said that the best way to reduce system development costs is to use application software packages. Do you agree? Why or why not? If the organization doesn't have internal resources and have pretty standard business processes that can easily be set up in the application software package, it is a good way to go in case of right choice of the best vendor solution. Some vendors are specialize in industry preset solutions for their systems.

If organization has an unique requirements, then customizing the packages can be very costly and create a hassle for the future software upgrade and maintenance. Depends upon early identification and specification of requirements, yet users may not be able to clearly define what they need early in the project.

Requirements 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. Difficult to respond to changes. Changes that occur later in the life cycle are more costly and are thus discouraged. Produces excessive documentation and keeping it updated as the project progresses is time-consuming.

Written specifications are often difficult for users to read and thoroughly appreciate. Promotes the gap between users and developers with clear division of responsibility. Situations where most appropriate: 1. Project is for development of a mainframe-based or transaction-oriented batch system. Project is large, expensive, and complicated. Project has clear objectives and solution. Pressure does not exist for immediate implementation. Project requirements can be stated unambiguously and comprehensively.

Project requirements are stable or unchanging during the system development life cycle. User community is fully knowledgeable in the business and application. Team members may be inexperienced. Team composition is unstable and expected to fluctuate. Project manager may not be fully experienced. Resources need to be conserved. Strict requirement exists for formal approvals at designated milestones.

Situations where least appropriate: 1. Large projects where the requirements are not well understood or are changing for any reasons such as external changes, changing expectations, budget changes or rapidly changing technology. Real-time systems. Event-driven systems. Leading-edge applications. Prototyping Requirements Definition Coding, testing, Not a standalone, complete development methodology, but rather an approach to handling selected portions of a larger, more traditional development methodology i.

Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process. User is involved throughout the process, which increases the likelihood of user acceptance of the final implementation. While most prototypes are developed with the expectation that they will be discarded, it is possible in some cases to evolve from prototype to working system.

A basic understanding of the fundamental business problem is necessary to avoid solving the wrong problem. Improves both user participation in system development and communication among project stakeholders. 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. Helps to easily identify confusing or difficult functions and missing functionality. May generate specifications for a production application. Encourages innovation and flexible designs. Provides quick implementation of an incomplete, but functional, application. Approval process and control is 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 up-front user needs analysis, resulting in an inflexible design with narrow focus that limits future system potential. Designers may neglect documentation, resulting in insufficient justification for the final product and inadequate records for the future.

Can lead to poorly designed systems. Iterations add to project budgets and schedules, thus the added costs must be weighed against the potential benefits. Very small projects may not be able to justify the added time and money, while only the high-risk portions of very large, complex projects may gain benefit from prototyping. Prototype may not have sufficient checks and balances incorporated. Project is for development of an online system requiring extensive user dialog, or for a less well-defined expert and decision support system.

Project is large with many users, interrelationships, and functions, where project risk relating to requirements definition needs to be reduced. Project objectives are unclear.

Pressure exists for immediate implementation of something. Functional requirements may change frequently and significantly. User is not fully knowledgeable. Team members are experienced particularly if the prototype is not a throw-away.

Team composition is stable. Project manager is experienced. No need exists to absolutely minimize resource consumption. No strict requirement exists for approvals at designated milestones. Innovative, flexible designs that will accommodate future changes are not critical. Mainframe-based or transaction-oriented batch systems. Web-enabled e-business systems.