Question

1. Discuss the following system development methods (600 words approx.) – Structured development – Object oriented development – Agile development – Rapid Application Development

2. What is project creep? Which system development methods are more prone to project creep? What could be a strategy to avoid it? (400 words approx.)

Answer 1

Structured Methodology

Structured Methodology is a set of standards for systems analysis and application design. It uses a formal methodical approach to the analysis and design of information systems. The structured methodology is an open methodology based on the waterfall model. It has been used by many commercial businesses, consultants, educational establishments and CASE tool developers. One of the main features of structured methodology is the intensive user involvement in the requirements analysis stage. The users are made to sign off each stage as they are completed assuring that requirements are met. The users are provided with clear, easily understandable documentation consisting of various diagrammatic representations of the system. Structured methodology breaks up a development project into stages, modules, steps and tasks. The first and foremost model developed in structured methodology is the data model. It is a part of requirements gathering and consists of well defined stages, steps and products. The stages of structured methodology include:

• Determining feasibility
• Investigating the current environment
• Determining business systems options
• Defining requirements
• Determining technical system options
• Creating the logical design
• Creating the physical design

Object Oriented Development

Object Oriented Development (OOD) has been touted as the next great advance in software engineering. It promises to reduce development time, reduce the time and resources required to maintain existing applications, increase code reuse, and provide a competitive advantage to organizations that use it. While the potential benefits and advantages of OOD are real, excessive hype has lead to unrealistic expectations among executives and managers. Even software developers often miss the subtle but profound differences between OOD and classic software development.

A software development methodology is an organized process of fundamental activities of specification, development, validation and evolution and represents them as separate process phases such as requirements specification, software analysis and design, implementation, testing and so on. The general process for an object-oriented design has a number of stages:

• Understand and define the context and the modes of use of the system.
• Design the system architecture.
• Identify the principal objects in the system.
• Develop design models.
• Specify object interfaces.

Although these activities look separate stages the object-oriented design is not a simple, well-structured process. All of the above activities are interleaved and so influence each other. Objects are identified and the interfaces fully or partially specified as the architecture of the system is defined. As object models are produced, these individual object definitions may be refined, which leads to changes to the system architecture.

Agile Methodology

AGILE methodology is a practice that promotes continuous iteration of development and testing throughout the software development lifecycle of the project. Both development and testing activities are concurrent unlike the Waterfall model. There are various methods present in agile :

Scrum

SCRUM is an agile development method which concentrates specifically on how to manage tasks within a team-based development environment. Basically, Scrum is derived from activity that occurs during a rugby match. Scrum believes in empowering the development team and advocates working in small teams (say- 7 to 9 members). It consists of three roles, and their responsibilities are explained as follows:

• Scrum Master
  • Master is responsible for setting up the team, sprint meeting and removes obstacles to progress
• Product owner
  • The Product Owner creates product backlog, prioritizes the backlog and is responsible for the delivery of the functionality at each iteration
• Scrum Team
  • Team manages its own work and organizes the work to complete the sprint or cycle

eXtreme Programming (XP)

Extreme Programming technique is very helpful when there is constantly changing demands or requirements from the customers or when they are not sure about the functionality of the system. It advocates frequent "releases" of the product in short development cycles, which inherently improves the productivity of the system and also introduces a checkpoint where any customer requirements can be easily implemented. The XP develops software keeping customer in the target. There are 6 phases available in Agile XP method : Planning, Analysis, Design, Execution, Wrapping , Closure.

Rapid Development

Rapid application development is a form of Agile software development methodology. Unlike Waterfall methods, RAD emphasizes working software and user feedback over strict planning and requirements recording.

In other words, RAD is less talk, more action. Oh, and testing. Lots and lots of testing.

While RAD de-emphasizes strict planning, there are still a handful of steps or phases each development project goes through when using the rapid application development methodology,

1. Figure out the requirements

Every piece of software or app is built for a reason. RAD starts with figuring out what your project is supposed to accomplish.Get your users, developers, and designers into a room (or on a conference call) to discuss the purpose of the system you’re about to build and test.

2. Build prototypes, on the double!

RAD stands for rapid application development, so it shouldn’t be surprising that your team will start working on building functional models right away.

3. Get user feedback

With RAD, your users should already be familiar with most, if not all, parts of your finished product before you announce your project’s completion

4. Do it again!

You’ll repeat steps two and three until you feel like your project is done or until you have all working parts assembled together to meet a client’s requirements.

5. Test

You’re not ready to pronounce a project complete until you’ve made sure that it works the way it’s supposed to.

Project Creep

Project creep is also know as focus creep, feature creep, function creep, and requirement creep. Project creep in project management refers to uncontrolled changes or added objectives in a project. This phenomenon can occur when the scope of a project is not properly documented, defined, or controlled. It is generally considered a negative occurrence, and thus, should be avoided.

Additional requirements needed to achieve the new objectives can overwhelm the capacity of the resources allocated to the project resulting in the project missing deadlines, budgets or complete failure.

Agile Projects Are NOT Immune To Project Creep!

Agile practices provide this flexibility by fixing other key constraints such as cost or time, and allow for scope change by allowing the project's customer to modify the content and priority of items in the work backlog at regular intervals.

Strategies to avoid it:

• Ensure that high-level iteration planning includes a determination of how many iterations are required to meet the customer's minimal must-have requirements. Focus the team and customer on achieving this target, and then use remaining iterations as an opportunity to refactor and refine.
• Work with the customer to develop a performance incentive plan for the team that balances completing work on time and on budget with meeting all of the customer's requirements.
• Track iteration velocity and if it drops or is well below expected levels, dedicate sufficient time during the retrospective session at the end of each iteration to help the customer and team members identify likely causes. These reviews could include looking at what was expected to be completed during the past iteration and comparing that to the work items that were actually worked on by team members, and how many of those were redone or significantly modified.