Methodology of Information System Development

The rigid methods employed by the Waterfall approach makes it easy to manage because the team cannot move onto the next stage if all of the

One commonly-used business process methodology is that of the Systems Development Lifecycle (SDL). The steps of the method involve: defining the components of the proposed system; determining its requirements (interviewing users, determining existing processes); designing the system components (determining specifications and job definitions); implementing the system (building, testing, and/or converting the existing system) and then maintaining the system (by fixing failures and quality monitoring) (Noe 2010: 18).

SC will compare traditional and various iterative implementations of the SDLC. For example, Braude and Bernstein (2011) state that the popular and mature waterfall process model promotes simple comprehension, project management, and resource distribution of small project development lifecycles. The serial nature of the traditional SDLC leans toward the gathering of all requirements at the beginning of the project whereas the majority of testing occurs at the end of the lifecycle. The waterfall model’s linear design creates disastrous risks for large projects if the project team does not understand the core requirements during the initial phase of the project or the detection of major problems occurs toward the end of the project. On the other hand, a spiral model significantly reduces risks for large projects whereas complexity causes overkill for smaller projects. The project’s physical scope, timeline, budget, and resource determine which the most optimal process model for a project. Table 1.1 displays a comparison chart that SC uses to weigh advantages and disadvantages of traditional SDLC and Agile development methodologies. SC will utilize this chart to determine which development methodology is utilized based on the primary amount of questions answered positively weighed with the clients business case requirements. “Agile software development is a

This models most common if you compared with network and relational database because can be manage by huge amounts of data for difficult projects.

This models most common if you compared with network and relational database because can be manage by huge amounts of data for difficult projects.

Since the method was developed for manufacturing and construction projects, it made sense in these industries that a portion of the project was fixed and unchangeable after a phase completed. Imagine the construction of a road, you prep and lay down a foundation then eventually lay down the final asphalt or concrete layer. It wouldn’t make sense to build in the ability to go back and change the foundation after the top layer was set. Obviously, software engineering is very different and therefore requires a much different approach to development. Besides slow turnaround, there were many other criticisms of the waterfall method. Some included redesign, rework, and retesting due to lack of knowledge about requirements when a project began. Also, due to the extremely long lead and delivery times, requirements changed or projects were dropped altogether leaving a company with a half-built loss on the balance sheet. An industry average put the estimated time for any software project using the Waterfall approach at 3 years. This was the environment that enabled a few forward-thinking developers to meet and design a new and better approach.

The traditional development method requires the definition and documentation of a stable set of requirements at the beginning of the project. It was inherited by other projects mainly related to construction which focused on the completion of one phase of production before moving on to the next phase, for example, laying the foundations of a building first and then proceeding with the further stages (Bowes 2014). Similarly, in Waterfall, the requirement gathering and designing work is done upfront before any coding takes place. The basic notion behind the traditional development approaches is that the projects are comparatively less complex, linear and predictable with clearly defined system boundaries which makes it simple to plan and follow without having any room for changes (Spundak 2014). Moreover, traditional development method depicts the requirements document as he key piece of documentation. The gathering of all the requirements, getting a sign off from the customer and then starting with the development of the project gives the project a limit of

A new system development cycle brings a process of building a good system with quality. A single incorrect step could create a huge mistake in the development process. Steps of developing a system begin with requirement gathering and analysis; basically brainstorm to check ideas to put into action for development. This could be assembled independently through personal documentation, but a lot of them could be acquired with the user participation through interviews of open-ended questions or a structured questionnaire. Next task is the system analysis to improve decision making in order to define in detail. This is broken down into smaller parts to help make it more manageable to develop, design, and test. A system design gathers

The waterfall model should be used in certain situations. For instance, waterfall models should only be applied when the requirements are clearly known and properly fixed (Tutorials Point, n.d.). They can also be used when there is a stable definition of the product, a distinct understanding of the technology, or when ambiguous requirements are

can stand alone as the sole development strategy. Verner and Cerpa (1997) observed a relationship between the size of a department and the preference to utilize a prototype. They also discovered many of the aspects of a waterfall approach that made it widely used still hold true. Developer communication and project control have long been seen as positive characteristics of the waterfall approach. The increased control is the result of the rigid, phased structure that defines a waterfall development plan. A drawback to this development strategy is the lack of feedback that we see in the scrum or agile method. This lack of feedback makes having a complete requirements essential, the lack of which can mean an unsuccessful or scrapped project.

Looking at each methodology from a different perspective, the management perspective, unveils additional benefits and setbacks. The rigidity of the Waterfall method for software development can be cumbersome when dealing with changing expectations, but it makes it easier for management to manage the project’s progression. Having clear goals makes it easy for managers to track the development process. It is more difficult to track a project where requirements are constantly evolving. Most of the projects (not involving software development) in our department are tracked through their process. As goals are achieved, completion nears 100%.

Waterfall method is one of the traditional software developing method that has been implementing for decades. Usually, clients have requests, then software developers create an initial paln; after client approves the plan, developers follow through the plan; at the end, developers test and finish the task. Upon clients’ additional requests or tests, developers add up the extra features, but in most of the case, it would be too late or too hard to change. The entire process is not very communicative or translucent since clients and developers generally meet just once or twice throughout the project. In the article Why Making Software is so Difficult the author mentioned that software production is very

Waterfall does have its issues: the process is generally “uni-directional” meaning that once the project hits a certain stage, there’s no mechanism to go back to a previous stage. This prohibits this method from being responsive to changing environments and/or requirements. The extensive documentation required at each stage (requirements, specification, design documentation, test plans and status) requires a great deal of time to complete. Additionally if it is discovered that there was a major issue with a missing requirement or the coding (and it’s uncovered in time) it is extremely expensive to make an adjustment.

“The waterfall model is a sequential design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction,

The waterfall method is a linear, sequential, non-iterative process for software development first mentioned by Herbert Benington in 1956. The software development life cycle (SDLC) is defined by Ruparelia as “a conceptual framework or process that considers the structure of the stages in-volved in the development of an application from its initial feasibility study through to its deploy-ment in the field and maintenance (Ruparelia, 2010, p. 8).’’ This method is so named “waterfall’’ because the stages of the SDLC cascade down through the stages of product consideration, re-quirements, analysis, design, development, testing, implementation and review/maintenance.