Rational Unified Process

The most well-known OO approach to software development

Currently owned by IBM, the Rational Unified Process® (RUP) is a commercially available development process. The process includes descriptions of team roles, tasks, and deliverables. It is a customizable approach and recommends iterative and incremental development and deployment. Its popularity has made the acronym RUP almost equivalent to an industry term.

Agile Development Approaches

Focus on small, co-located teams Decreased focus on formal requirements

Every new software development approach grows out of experience with previous approaches, both good and bad. Most new approaches share one goal—faster development of useful business software to the business users. The word agile means being able to move quickly and easily and is used to describe an approach to software development that is fast, flexible, and effective. The agile style utilizes both the iterative and incremental characteristics.

Agile projects are gaining popularity and have been very successful in many organizations. Initially, some agile experts downplayed the need for a BA on the agile team. Instead, they utilized a developer to elicit requirements directly from the business stake-holders. An experienced BA will add significant value to the team. When a business analysis professional is not available, developers are expected to perform analysis and communicate directly with business stakeholders. Developers effectively wear two hats: that of the BA and that of the developer.

Characteristics of an agile project include:

• Short iterations (two to four weeks) with scope based on highest business value

• Small dedicated project team working closely together (ideally, the team is working in the same physical location)

• Full-time business stakeholder(s) assigned to the team

• JAD/facilitation sessions to quickly elicit requirements

• Daily “stand-up” meetings to keep the project on track (10 to 15 minutes)

• “Design as you go” approach to the software design

• “Demo as you go” approach to user requirements

• “Test as you go” approach to the software

• Requirements are communicated very informally

• Teams become self-managed

There are some really great things about using an agile approach:

1. Business value is delivered to business stakeholders very quickly.

2. Daily “stand-ups” and constant reviews keep all team members’ work on track and focused.

3. Because iterations typically run between 10 and 30 days, there is no formal change control process required during an iteration. Once the iteration scope is agreed upon, no changes are allowed (unless the scope is not feasible). Changes to requirements are considered for a subsequent iteration.

4. No voluminous requirements documents are written. BAs don’t have to spend hours fine-tuning every word in the requirements package in long document review sessions. Requirements are confirmed during demos of the product as it is developed or on white boards in the team workroom.

5. Working prototypes evolve from design artifacts to the production software so business users can see their requested changes and developers can easily make the changes to improve usability as the project moves along.

6. Dedicated team involvement including a full-time business stakeholder means everyone stays focused on achieving the objectives within the specified time frame.

These benefits are only achieved by a very high-performing team that understands the agile approach and commits to the process. Including a high-performing business analysis professional on the team increases the likelihood that the resulting product will meet true business needs and fit in well with the current business environment. If an experienced BA is not available, at least one team member must have extensive business analysis training and experience (Carkenord, 2007).