Magazine article Mortgage Banking

Revisiting Proven Development Processes

Magazine article Mortgage Banking

Revisiting Proven Development Processes

Article excerpt

Software development has a way of reinventing itself over the years, tt is true that there is constant innovation and new technologies being released, but those of us who have been around see patterns and repetition not too unlike business-perfection tools and strategies (Total Quality Management anyone?).

There are many software development life cycle (SDLC) methodologies out there. Lately, agile software development has been all the rage.

Years ago, the waterfall development methodology was used. Whereas waterfall is traditional and detailed, requiring painstaking amounts of documentation and signoffs through each part of the development life cycle (business analysis, development, quality assurance, etc.), agile foregoes the documentation but adds many new facets to the development model that confuse people and are difficult to initially adapt in most shops.

One approach that has been there since the beginning is iterative (where academically it can be argued that agile is a variant). Sometimes this approach is called incremental.

The model was initially developed simply to address perceived inefficiencies in the waterfall model--specifically where written requirements were identified late in the life cycle incorrectly, which typically have a tremendous cost associated with fixing or remediating, depending on how late they are identified.

In a traditional waterfall model, development is closely watched and follows a very well-defined set of documentation (business analysis creates requirements, which begets design documentation from development and test plans from quality assurance), and the model runs for the most part sequentially. In an iterative model, many more cycles of the whole model are run in smaller increments of time.

The iterative model is very circular, and is designed to feed off itself. You constantly go through the phases of the SDLC while using lessons learned in the previous iteration in the one that follows and so on. In doing more iterations of the whole model, the developer and end user are exposed to the product sooner and thus can provide better feedback as to its function and as to whether requirements are being met. If requirements are not being met, because people can see the system, alternative suggestions are usually easier to come up with and it is possible to create a better product. The product is constantly massaged into its final form.

Think if you were implementing a new loan origination system (LOS). Rather than documenting everything you want in the LOS upfront, then waiting six months or a year before ever seeing it--only to find out that it was not built correctly or the vendor didn't understand everything properly--you would instead see an early iteration or build of the LOS every two to four weeks and you would see it come together over time. By the time 12 months went by, you would have seen the system six to 10 times and had the ability to provide valuable feedback at each iteration. Many companies use this technique when they are configuring an existing product.

Another way to look at it is that you are constantly updating and massaging the final deliverable or system. The stakeholders understand they will not get exactly what they want alt the time, but because the system itself is constantly iterating, they are more accepting of this.

Features and new functionalities are broken down into smaller functional pieces, which in turn are fed to the stakeholders over the course of multiple versions over time. …

Search by... Author
Show... All Results Primary Sources Peer-reviewed


An unknown error has occurred. Please click the button below to reload the page. If the problem persists, please try again in a little while.