Group Project

Wednesday, November 01, 2006

System Development Methodology


Software development methodology or software development lifecycle (SDLC) is common methodology for deploying information systems in many organizations. Proper approach to software development results in fewer defects, reduced steps in the development, shorter delivery times and better quality of the final product.
There is a wide range of established development methodologies available from which to choose for this web development. I will discuss briefly the main attributes of each development methodology and conclude the section with an examination of which best suits the particular development.

1. Waterfall model


The waterfall model is the oldest software development model and consists of 5 consecutive stages. First the application requirements are gathered and a detailed requirement definition document is drawn up which is then used as input into next stage, Then a detailed system and software design document is drawn up to implement the requirements definition document. At this stage no changes can be made to the requirements definition. The next stage is code generation, followed by running against the test procedure, generated during the requirements definition stage. The testing may involve the development and testing of each unit of software separately and then, more testing integrating all units together. It is much easier to find an error in a single unit of software than in the complete system. The final stage is operation and maintenance as the system goes alive. No changes to the requirements or the design can be made until all these stages are complete and this then feeds back into earlier stages of the model. This method does not take account of the fact that, what a customer specifies is often not what is required, until the system is complete. The act of seeing the application helps the user specify and refine exactly what application functionality is required. The customer requirements initially specified are often not what customer requires when the application is completed.

2. Spiral model

This method is where the development is viewed as an iterative spiral development, where the application is under continual development. Each development cycle is divided into 4 stages:
1) Determine objectives
2) Evaluate alternative, identify and resolve risks involved in this cycle
3) Develop and identify next level of product
4) Plan next phase of process
This is repeated for each iteration of the cycle as the application is developed further. This allows for much more flexibility than in the waterfall model since the software application under development is seen as series of prototypes. The customer can see the final product and more easily refine the prototype as the development continues. The risk of failure due to complexity or misunderstanding if the customer’s requirements for development can be reassessed at each iteration of the spiral, saving time and money if the customer requirements are misunderstood at an early stage. The prototypes are used for gathering customer requirements and assessing risk which is the major feature of the spiral model and do not form part of the final application. A drawback with this method is that the customer may well see the final prototype as doing what is required and be tempted to accept that as a final application, and be reluctant to spend extra time on finishing the product.

3. Evolutionary development
This is more iterative process of specification, design and development, generating an initial version for demonstration only, on which the customer then comments and this then enables a new more accurate specification to be made. More intermediate versions are generated before a final version is delivered. There are essentially two types of evolutionary development, first exploratory development where development starts with parts of the system. The customer then specifies further extensions to be added to the initial system. The second is throw-away prototyping where initial prototypes of the system are developed to refine the application requirements, which are less understood.
The specification, development and validation are performed concurrently for each revision of software, resulting in rapid customer feedback, but there are several drawbacks to evolutionary development. Because earlier revisions of the software may be incorrect, building on these may lead to code that is poorly structured and difficult to maintain. The process is not visible to managers since there are not clear deliverables. Special software development tools may be required to develop the software, which are very application specific and few people may have skills to use these tools. Software tools are also often specific to a particular software problem such as process control applications and therefore the tool might not be suitable to assist with every type of application development, this may affect the choice of this methodology.
The waterfall model forces the customer to sign up for requirements at the start, which tends to lead to better, well structured and therefore maintainable code as opposed to the evolutionary method which may lead to less structured code, however the application may not do what is required by the customer.
  3.1 Rapid Application Development
RAD is a software development process that allows usable systems to be built in a very short timescale, but this involves compromises in the total application functionality.
  3.2 Extreme Programming
Extreme Programming or XP is one of agile development methodologies that can be described as a daily practices for developers and managers based on 4 core values aimed at reducing the cost of changes during project development:
1) Communication
The goal is to give all developers a shared view of the system which matches the view held by the users of the system.
2) Simplicity
Project starts with the simplest solution that can be easily understood by all members of the programming team. 
Design and coding for today's needs rather than for future requirements.
3) Feedback
Feedbcak relates to different system development dimensions: feedbcak from system by writing unit test, feedback from customers by performing acceptance 
tests, feedback from the team by giving the estimation of time needed for further implementation.
4) Courage
Courage enables developers to feel comfortable with refactoring their code when necessary. This means reviewing the existing system and modifying it so that future changes can be implemented more easily.

Main activities are likely to be the following: coding, testing, listening (to business side or/and customer needs), designing. If those activities are performed well, the result should always be a system that works. But in practice, this will not always work.

References
Kendall,J. and Kendall,K. (2004) System Analysis and Design, Prentice Hall, London.
Hoffer,J., George,J., Valacich,J. (2001) Modern System Analysis and Design, Prentice Hall, London.
Wikipedia: Extreme Programming



0 Comments:

Post a Comment

<< Home