INTERIM REPORT
The values in the manifesto such as “Individuals and interaction over processes and tools” and “Responding to change over following a plan” were never considered positive within the traditional linear context of SD; it was a strictly planned and regimented process. Problems with the tayloristic approaches, for instance using the waterfall model required many iterative processes during the development, due to the structure of the model, in order to meet the customers specification. The spiral model by Barry Boehm aimed to change the negatives of the waterfall model but was still not to efficient as it incurred high costs and high risk taking as the development changed due circumstances. Agile methods aimed to address these concerns and promote SD processes which were people orientated. Despite the positives, there are some negative aspects of agile such as the social and psychological effects of team working, the concern for safety critical software due to the unpredictability of ASD and working effectively in large teams/oragnisations.
On the contrary, the methods are flexible enough for almost any SD team to implement if the team has focus. Large or small development teams have potential with ASD to become successful, yet not all projects achieve a positive end result. The literature review will assess how ASD can be used in a project and what benefits or costs to SD it embodies. Collectively, these results will form the conclusion to my paper.
4.0.3 SOFTWARE DEVELOPMENT AND THE INTRODUCTION OF AGILE Software development began in the 1960’s. The processes involved in creating software were basic due to the quality of computers that programmers were using to create the software and their procedural and basic approach to development. The development would consist of making the programming code and then fixing errors if they were present then moving onto the next piece of software. This approach was named the “code and fix model”. This caused many problems, such as high costs of fixing the errors or if the design had to be changed when the customer received the software. The customers’ requirements were not sufficiently well defined to create acceptable software. Moreover, the maintenance of the programing code with the model was inefficient and could not be reused in other projects. Specific stages were implemented in order to resolve these difficulties which incurred high financial risk to software development companies.
The transformation of software development therefore began in the 1970’s, when the waterfall model was introduced. This model was a heavy weight approach to software development: the structure of the development was focused on rigorous processes - Analysis, Design, Implementation, Testing, Documentation, Evaluation, Maintenance -which eliminated the issues with the code and fix it model. The waterfall model presented linear procedures for creating software. According to Boehm (1988) the waterfall proved useful in maintaining a projects deliverables as each stage was done in iterative stages which standardised software development. Yet the model was unable to be flexible enough to adapt to changes during development and cost companies money to fix.
Page 13 of 42