Software Process Models for Ashwell and Ilminster Leisure Services - Essay Example

Software Process Models for AILS Table of Contents Introduction 3 2.Project Requirements 3 3.Software Process Models 4 3 Build and Fix Model 5 3.2.Waterfall Model 5 3.3. Spiral Model 6 3.4.Incremental Model 6 3.5.V Model 7 3.6.Evolutionary Prototyping 7 3.7.Staged Delivery Waterfall Model 8 3.8.Evolutionary Delivery Model 8 3.9.Design to Schedule 8 4.Conclusion 9 5.References 9 1. Introduction A software process model represents a simplified and generalized description of the actual software process with a particular viewpoint (James, 2009, pp. 38). This report aims to recommend software process models to be used on the Ashwell and Ilminster Leisure Services (AILS) Project. 2. Project Requirements For the development purposes, the project is divided into two parts; the administration system and the user interface where each part has a unique set of requirements. The requirements of the administrative system include: a) Developing existing data-handling functionalities (data input, storage, and security) and routine functions (e.g. booking facilities, class enrolment and management, membership management) using latest tools b) Developing a standard role based interface for reception, administrative and managerial staff c) In time delivery The requirements of the user interface include: a) Providing interfaces according to skill levels of a wide range of potential users b) Provide wide range of access to Interface (e.g. on site network, web, mobile, etc.). c) Satisfy customers/members with no previous interface experience d) Allow managers to extract monitoring and planning information by coordination with the administrative system e) Limit user views, local processing and data and interface options depending on the users f) Ensure flexibility to adjust changing requirements of users, technological changes g) No single deployment deadline From the above listed administrative system and user interface requirements, some generalized observations can be drawn regarding the two: a) The requirement capturing process for the administrative system is an extensive one time process. The requirements are based on system functionalities and roles and so would not undergo any change with time. b) The requirement capturing process for the user interface is an on-going process as a few of the requirements are subjected to change with availability of measures such as skill level of users, type of interface access methodologies, compliance with technological advancements, etc. Since separate teams handle the two parts independently of each other, separate software process models may be suitable for the development of each individual part. 3. Software Process Models This section presents a list of most commonly used process models (Pressman, 2010; Jalote, 2005, pp. 37) considering their application in the AILS project. 3.1. Build and Fix Model The model is generally used in small, simple throwaway projects with output as short lived demos, proof-of-concept or prototypes. No separate planning, risk assessment, designing, building, testing phases are required. The administrative system in AILS requires thorough gathering of requirements, understanding the working of existing processes and workflows and data accessing details for integration with the interface which the model fails to provide. For the user interface however, the model can be used the requirement of gaining user satisfaction. Interface can be made and tested; missing or ambiguous portions can be identified and fixed in the next build till a workable interface is achieved. 3.2. Waterfall Model The model comprises of well-defined requirements capturing, designing, coding, testing and maintenance phases. A finalized product is produced at the end. In the AILS administrative system, the requirements necessitate the need of completely capturing of fixed requirements and functionalities to produce a complete product as deliverable. Therefore, the model seems to be appropriate for the task. For the user interface, the requirements are subjected to change which is not supported by the model. Therefore, it cannot be applied. 3.3. Spiral Model Spiral model employs risk management approach, an essential requirement in the large mission-critical projects, where reusable, high quality versions of software are delivered before the requirements change again. For the administrative system, the requirements are fixed and do not undergo changes. So, the spiral model cannot be applied. For the user interface, applying the model would produce a workable solution but with an overhead of unnecessary risk analysis. User interface is not a critical task and therefore does not require extensive risk analysis. 3.4. Incremental Model The model helps identify a subset of requirements, design and build a product, assess risks and revise requirements and repeat process. In the administrative system, the requirements are straightforward and complete. The model cannot be applied because intermediate deliverables and risk evaluations are not needed. For the user interface, the model can be applied owing to the varying scope and requirements. An initial role based interface, accessing data may be developed and tested. The new requirements based on reviews can be embedded in the next iteration. The risk analysis feature can help in selecting technologies that would facilitate the access requirement in the long run. 3.5. V Model The model has fixed phases similar to the waterfall model. The model however offers higher success probability as the test cases are defined prior to the testing phase. In the administrative system, the model can be applied as the requirements are well-defined and the scope is limited and so no adjustments and prototypes are required. For the user interface, the model cannot be applied as the requirements are subjected to change while the model does not offer flexibility. 3.6. Evolutionary Prototyping Evolutionary prototyping employs multiple iterations of requirements capturing, designing and prototype development. The prototype is analyzed by customer, new requirements based on reviews defines the next iteration. For the administrative system, the model cannot be applied as the requirements are complete and prototyping is not needed. Furthermore, product has a critical delivery time, while the number of iterations is uncertain in the model. For the interface development, the model can be applied as requirements are expected to change. Since no deadline is specified for product delivery, the model is appropriate for the task. 3.7. Staged Delivery Waterfall Model The model is similar to waterfall except that at the delivery process is staged (Wysocki, 2010). The user can be given a useful functionality in entirety before complete delivery. In the administrative system, the model finds can be applied. The requirements for a functionally are complete. In the user interface, the model cannot be applied as the requirement of user satisfaction rules over all other fixed requirements. So functionalities such as data access cannot be isolated and delivered separately. 3.8. Evolutionary Delivery Model The model is a combination of evolutionary prototyping and staged delivery (Genuchten, 1992, pp. 65). Since prototyping is not applicable in administrative system, the model is not applicable. And since staged delivery is not applicable in user interface, the model is not applicable. 3.9. Design to Schedule The model is staged release model similar to stage delivery model except that the stages are not known and progress is driven by the delivery date. The model can be applied in the administrative system as the underlying model is waterfall. The model cannot be used for user interface due to changing requirements. 4. Conclusion The report discussed the strengths and weakness of applying various process models for the AILS project. The recommended model for the administrative system are the waterfall, V, staged-delivery and design-to-schedule models while for the user interface are build-and-fix, incremental, evolutionary prototyping and evolutionary delivery process models. 5. References James, K.L. (2009). Software Engineering. PHI Learning Pvt. Ltd. Pressman, R.S. (2010). Software engineering: a practitioners approach. McGraw-Hill Higher Education Wysocki, R.K. (2010). Effective Software Project Management. John Wiley and Sons. Genuchten, M.V. (1992). Towards a software factory. Springer Read More