A methodolgy for information systems development refers to the framework chosen to govern the structure, plan, and control the process involved in developing an information system. There are a number of frameworks that
have developed over the years. Each methodolgy has its own strengths and weaknesses. It is imortant to note that one system development methodology is not necessarily suitable for use by all projects – although some will receive more attention than others. Each of these established methodologies are best suited to specific kinds of projects, some are based on different technical, organisational, project and team considerations.
There are a number of methodologies that I will look at in this post. They are:
- Rapid Application Development
Agile software development is better understood as a group of development methodologies that is based on an iterative development. This is where the requirements and solutions evolve throughout the collaboration between self-organising and cross-functional teams.
Agile methods or Agile processes will usually promote a disciplined project management process that encourages frequent inspection, adaptation and reflection. This philosophy espouses a leadership style that encourages teamwork, self-organisation and accountability.
Agile methodologies are a set of best practices that intended to allow for quick delivery of high-quality software. As a business approach it will align itself with the development of customer needs and company goals.
Agile development refers to any development process that is also aligned with the ideas found in the Agile Manifesto. The Manifesto was developed by a group fourteen leading figures in the software industry, and it reflects their experience of what approaches do and do not work for software development.
PRINCE2 is a process-based approach that focuses on the organisation and control over the entire project, from beginning to end. This means that projects will be thoroughly planned before commencement and each stage of the process is clearly signposted, and any loose ends are all completed after the project ends. The PRINCE2 method is built on 7 main principles:
1. Projects must have a business justification.
2. Teams should learn from each stage of the project.
3. Roles and responsibilities are clearly defined.
4. Work is planned in stages. .
5. Project boards ‘manage by exception.’
6. Teams keep their focus on constant quality.
7. The approach is tailored for each project.
The Waterfall model is the earliest SDLC approach that was used for software development.
The waterfall Model shows the linear nature of the software development process in a linear sequential flow. This means that any stage in the development process begins only if the previous phase has been completed according to specified requirements. In this waterfall model, the phases do not overlap.
The sequential phases in Waterfall model are −
- Requirement Gathering and analysis
- System Design
- Integration and Testing
- Deployment of system
Rapid Application Development
The Rapid Application Development (RAD) methodology describes a method of software development that heavily emphasises rapid prototyping and iterative delivery. The RAD model is, therefore, an acute alternative to the typical waterfall development methodology. It will often focus on planning and sequential design practices.
Getting started with rapid application development generally follows a cyclical process that includes the following basic steps:
- Planning Requirements
- (Rapid) Prototype Cycle: Refine/Develop/Demonstrate
- Final Testing
The Advantages and Disadvantages of Each Methodology
- Customer satisfaction by rapid, continuous delivery of useful software.
- People and interactions are emphasized rather than process and tools. Customers, developers and testers constantly interact with each other.
- Working software is delivered frequently (weeks rather than months).
- Face-to-face conversation is the best form of communication.
- Close, daily cooperation between business people and developers.
- Continuous attention to technical excellence and good design.
- Regular adaptation to changing circumstances.
- Even late changes in requirements are welcomed
- In case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle.
- There is lack of emphasis on necessary designing and documentation.
- The project can easily get taken off track if the customer representative is not clear what final outcome that they want.
- Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources.
- 1. Prince2 is predictale
2. This methodology utilises best practice
3. There is standardised approach as every aspect to ensure that there is no chance of miscommunication or misdirection.
4. The methodology is effective in terms of time and is cost effective. Less time is spent identifying risks as they will have been identified at the beginning of the project.
5. The methodology is tried and tested and ensures it does not stray from the lessons learned by those directing the project.
- Slow to react to change.
- The process is quite cumbersome when the documentation requires changing.
- The methodology is not flexible
- Ideal for supporting less experienced project teams and project managers, or project teams whose composition fluctuates.
- The orderly sequence of development steps and strict controls for ensuring the adequacy of documentation and design reviews helps ensure the quality, reliability, and maintainability of the developed software.
- Progress of system development is measurable.
- Conserves resources.
- Inflexible, slow, costly and cumbersome due to significant structure and tight controls.
- Project progresses forward, with only slight movement backward.
- Little room for use of iteration, which can reduce manageability if used.
- 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 undercapacity 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
- The operational version of an application is avaible much earlier than with other frameworks.
- RAD produces systems with greater speed and with a business focus, which tends to produce systems at a lower cost.
- It fosters a greater level of commitment from stakeholders – both technical and business – than other frameworks. Users are seen as gaining more of a sense of ownership of a system, while developers are seen as gaining more satisfaction from producing successful systems with greater speed.
- It concentrates on the essential systems from a users viewpoint.
- It provides the ability to rapidly change system design as required by the users.
- It produces a tighter fit between the user requirements and the system specifications.
- It generally produces a dramatic saving in time, money and human effort.
- More speed and lower cost may lead to lower overall sysem quality.
- Danger of misalignment of developed system with the business due to missing information.
- Project may end up with more requirements than are needed.