Systems Development of Waterfall Approach - Coursework Example

Systems Development and Procurement Prepared by Presented by: On Date Table of Contents Waterfall Methodology verses Agile Methodology 4 Waterfall methodology verses RAD methodology 7 ERP and CRM Application 9 Part 2 10 IT adoption process 11 How Organizations can Effectively and Efficiently Manage its Project Procurement 12 Organizational and Environmental Differences Affect the IT/IS procurement process 13 Why ERP and CRM implementations are especially prone to failure 14 References 14 Waterfall approach to Information Systems Development The waterfall software development methodology is a well-known type of software development lifecycle model for software engineering. Basically, it is recognized as a classic software development approach to the software development methodology, the waterfall development methodology refers to a development technique that is linear and sequential. Additionally, the waterfall software development model has separate objectives for every stage of software development. In this development model when a development stage is completed, then the preceding development stages proceed to the subsequent stage and there is no turning back in this overall software development structure (Rouse, 2007; Whitten et al., 2000). Figure 1 Waterfall Model http://www.buzzle.com/editorials/1-5-2005-63768.asp In addition, the waterfall development methodology is simple and easy to manage and use. It is also simple to deal with because of the inflexibility of this model. In this model every development stage involves precise deliverables as well as a review procedure. On the other hand, in waterfall approach, once we reached to the testing phase, it is extremely hard to go back as well as modify something that was not effectively developed or designed in the concept phase. Additionally, the waterfall approach for system development does not offer any working software till the end of the overall lifecycle. Moreover, this development approach also presents a great deal of risk and uncertainty (ISTQB Guide, 2012; Sommerville, 2004). In my opinion, in case of using waterfall methodology, we need plenty of time for the overall system development lifecycle. Here we can not afford projects with small time line. For example for over development project we will prefer for evolutionary development methodology because waterfall is so much rigid and hard to manage. Waterfall Methodology verses Agile Methodology Agile software development methodology is a development framework that can be effectively executed and it is able to make sure team synchronization. Through these development framework software development products is more and more target to client requirements, and keep a development project financial plan on target. Additionally, it involves smaller software delivery sets. In addition, the software development deliverable sets are task/feature prioritization, and daily collaborative scrum meetings. In fact, simply scrum meetings in agile development are frequently fewer that 15 minutes, as well as are immediately a status check to observe where everyone is, and if there is anybody who has some issues where others are able to resolve it. For example we are dealing with a dynamic business that requires repeatedly developing and adapting changes, in this situation agile development will be very effective in offering all these support services (Reich, 2012; Aggarwal, 2005). Figure 2 Agile Method: http://www.commonplaces.com/inspiring-conversation/team-posts/agile-vs-waterfall-how-approach-your-web-development-project Through agile development we can have backward scalability that offers us a great deal of capability to effectively manage software development by incorporating on-going changes. Through waterfall software development methodology, we are not able to alter the decisions and implementations that we had formulated through the earlier phases. If we desire to alter under waterfall development methodology, we will have to complete the entire project from the scratch again (Reich, 2012; Amwicker, 2012; Phatak, 2012; Nayab & McDonough, 2012). Additionally, the elasticity to error check through some component of the development phase formulates agile development methodology more effectively, bug free and less mistaken as compared to the waterfall software development methodology. This is able to simply test bugs at the end of the software development module (Reich, 2012; Amwicker, 2012; Phatak, 2012; Nayab & McDonough, 2012). In view of the fact that the agile software development methodology offers flexibility to make changes according to clients’ needs it is more inclined towards more effective customer approval. This is an actual setback for the waterfall software development model that does not permit some changes once the software module that has been completed (Reich, 2012; Amwicker, 2012; Phatak, 2012; Nayab & McDonough, 2012). In addition, the agile software development modular partitioning of the software can be efficiently performed as compared to its counterpart. However, both of them offer alternatives for separation but the afterward lacks the changes in the accomplishment phase. Additionally, policies are established previous to the beginning of the project therefore it delays additional breakdown of the logical system development module. On the other hand, the agile software development process is able to offer a great deal of support under similar circumstances as well as is able to permit immediate development of diverse modules at the same time as stated by time bound need. If we want the project to be additional separating agile development process appears as a pain release intended for developers (Reich, 2012; Amwicker, 2012; Phatak, 2012; Nayab & McDonough, 2012). For our group project I have used the agile methodology. This methodology is more and more communication oriented. For this purpose, we have communicated more and more for taking information and details about system development and tasks management. Though, my personal viewpoints are in favor of the agile software development because in agile software development we can develop a software application according to customer’s expectations quickly. However, in our educational setting we normally use waterfall approach. For instance, when we have to work on a project or assignment we follow the steps sequentially. First of all we set objectives, and then we plan and then actually perform tasks and everything we document. Waterfall methodology verses RAD methodology Rapid Application Development (RAD) software development methodology is the arrangement as well as the technique in that software development is applied to tackle client requirements without widespread prototyping and planning. In addition, it is tremendously practical in circumstances where time can be significant in encompassing a practical application prepared as well as further improved and enhancements can be made later (Custom Application Development Portal, 2010). In addition, the major benefit of RAD development over waterfall model is that it splits the project work into lesser parts those can be assessed more regularly. As the project cannot obtain as far off track previous to issues are checked, fewer time as well as effort is wasted on task that turns out to be incorrect. Instead of wasting more time attempting to obtain needs right as well as however still having them transformed, wait for the transformation as well as then develop systems in reaction to the altered needs consequently task does not have to be redone as a result. Functionality improves progressively as extra small parts of operational code are checked, developed and applied. Additionally, minimizing wasted attempts and offering working code faster surely is creditable (Rooney, 2008; Goldsmith, 2009). Moreover, the RAD model is a faster application development methodology. Additionally, the RAD model also offers a great deal of improved quality through fast system delivery and less resource application (Novulo, 2012). I will prefer RAD methodology, when we have shortage of time. While using such development methodology we need to assess some of the major areas of system and utilize available time more and more effectively. This will offer us a great deal of opportunity for the enhanced system development and management. ERP and CRM Application The implementation of systems like ERP or CRM at any corporate offers a great deal of support for the business management. In addition, the new technology of ERP and CRM systems are offering more and more support to any corporate for the sake of business resource handling and resource management. For example ERP systems offer better support and automated management of the business tasks and resources. In addition, it will reduce a great deal of need for the human intervention for potential resource handling and management. The CRM system offers more effective handling and management of the client needs according to their buying behavior. I have often seen, a number of CRM systems online. These systems are more and more user oriented. For example, DELL web based CRM system. It is a perfect example of CRM system. Here customer is able to have a number of ways for the services and operations. Part 2 Having IS/IT products and services through some contract with the external purchasers or retailers have turned out to be an extremely significant aspect to numerous business. Additionally, the cause is that it minimizes both recurrent and fixed costs, permitting client business to pay attention on its fundamental businesses are able to achieve access to precise technologies and skills, offering elasticity where additional staff members would be offered during periods of high workload, and growing accountability for the reason that contracts are officially binding. To be flourishing in IT/IS project procurement administration there are 4 major procedures for businesses to follow. They are conducting procurements, planning procurements, closing procurements and administering procurements (Dunn, 2012; Whitten et al., 2000). In addition, in case of technology procurement like that for IS/IT procurement procedure is much more about acquiring telecommunications, technology goods and services. Additionally, the procedure comprises a number of tasks and activities from planning, processing of a demand, preparation of needs, solicitation, assessment, reward and contract configuration, to receiving and receiving payment, delivery, produces and services disposition, whether the technology service or product necessary is managed by the agency with the support of its assigned authority (Virginia, 2008; Laudon & Laudon, 1999). IT adoption process In case of new technology based IS/IT system procurement we need to adopt an enhanced method and solution for the better management of all possible areas of the procurement process. Given below is a generalized list of procurement processes for IS and IT products and services acquisition: (Virginia, 2008; Turban et al., 2005) IS/IT products or services specifications IS/IT products or services Standard specifications New technology base design specifications IS/IT products or services performance specifications Necessary characteristics specifications Stating functional requirements Stating Technical requirements Acquisition Testing Quality Assurance Performance Assessment How Organizations can Effectively and Efficiently Manage its Project Procurement IT/IS project procurement management comprises the procedures needed to obtain products and services from outside the business. Additionally, the procurement planning is the procedure of recognizing which project requirements can be best attained by procuring goods/services outside the project company. It entails reorganization of whether to acquire, how much to acquire, what to acquire, how to acquire plus when to acquire it (Project Management Institute, 1996; Kerzner, 2006). In addition, when the IT/IS procurement project does not get products as well as services from external working organization, the process of solicitation planning would not be carried out. This frequently happens on research as well as development based technology based IS /IT projects when the performing business is unenthusiastic to share for project technology and on numerous smaller, in house IS/IT projects when the price of discovering and handling an outside resource can rise to the possible savings (Project Management Institute, 1996; Kerzner, 2006). For the sake of IS system procurement we need to manage and handle number of aspects. For my personal experience, one of initial aspect we need to take care is our already available technology. We need to be careful to regarding application of new technology based system with more and compatibility with our previously available technology. Organizational and Environmental Differences Affect the IT/IS procurement process The procurement processes of IT and IS systems and services for a business can be expensive, complex, susceptible and time consuming process. A corporate procurement management system is one of the major market interactions by other business and dealing parties. As for some other procedure in a technology based IS/IT lifecycle or product supply chain, a procurement procedure is able to offer some significant service improvements and cost savings to facilitate the whole business productivity as well as marketplace share. The buying of IT and IS products and services in an organizations entails a broad variety of areas plus practices where environmental and organizational factors are important. It is consequently very important that present procurement systems turn out to be more ground-breaking as well as environmentally friendly (International Telecommunication Union, 2012). Some of the organizational and environmental factors those can influence the IS and IT products and services acquisition are: (Sigalaa, 2010) Working Structure Supply chain strategy Supply chain member Organizational size Transactional climate a Polecat Environment uncertainty Why ERP and CRM implementations are especially prone to failure At the present, the ERP and CRM technology based system application at any corporate is mist prone to failure. The main reason behind this failure is the lack of effective planning for enhanced and improved acquiring of these technologies based products. The new technology based procurement project needs to be well managed and handled in order to offer better services and operational support. In addition, the lack of management of such projects can lead to overall failure of project. Here we also need to deal with some of the issues regarding risk management. In case of less effective risk management of corporate tasks and operations there can be some issues regarding project effective application. These risks can be about cost management, time management and particularly political aspects management. According to my personal opinion, these technology based system are more prone to failure because of the less effective technology based management of application process. Here these project are managed through less technical ways, those leads to overall failure of project. References Aggarwal, K., 2005. Software engineering. New York. Amwicker, 2012. Waterfall vs Agile Models in Software Development. [Online] Available at: http://www.myglobalit.com/waterfall-vs-agile-models-in-software-development/ [Accessed 30 September 2012]. Custom Application Development Portal, 2010. Benefits of Rapid Application Development. [Online] Available at: http://www.customapplicationdevelopment.org/rapid-application-development/benefits-of-rapid-application-development.html [Accessed 01 October 2012]. Dunn, S., 2012. Project Procurement Management in Information Systems Projects. [Online] Available at: http://www.termpaperwarehouse.com/essay-on/Project-Procurement-Management-In-Information-Systems/39723 [Accessed 01 October 2012]. Goldsmith, R.F., 2009. Waterfall versus iterative development misconceptions. [Online] Available at: http://searchsoftwarequality.techtarget.com/answer/Waterfall-versus-iterative-development-misconceptions [Accessed 03 October 2012]. International Telecommunication Union, 2012. Guidance on green ICT procurement. [Online] Available at: https://itunews.itu.int/En/2855-Guidance-on-green-ICT-procurement.note.aspx [Accessed 01 October 2012]. ISTQB Guide, 2012. What is Waterfall model- advantages, disadvantages and when to use it? [Online] Available at: http://istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/ [Accessed 29 September 2012]. Kerzner, H., 2006. Project management: A systems approach to planning, scheduling, and controlling. 10th ed. New Jersey: John Wiley & Sons. Laudon, K.C. & Laudon, J.P., 1999. Management Information Systems, Sixth Edition. 6th ed. New Jersey: Prentice Hall. Nayab, N. & McDonough, M., 2012. Agile vs. Waterfall - Is There a Real Winner? [Online] Available at: http://www.brighthubpm.com/agile/50473-agile-vs-waterfall-is-there-a-real-winner/ [Accessed 01 October 2012]. Novulo, 2012. RAD (Rapid Application Development). [Online] Available at: http://www.novulo.com/Rad.aspx [Accessed 02 October 2012]. Phatak, O., 2012. Waterfall Vs. Agile Model. [Online] Available at: http://www.buzzle.com/articles/waterfall-model-vs-agile.html [Accessed 02 October 2012]. Project Management Institute, 1996. PROJECT PROCUREMENT MANAGEMENT. [Online] Available at: http://www.softwareresearch.net/fileadmin/src/docs/teaching/SS05/PM/PMBOK12.PDF [Accessed 02 October 2012]. Reich, M., 2012. Agile vs. Waterfall: How to Approach your Web Development Project. [Online] Available at: http://www.commonplaces.com/inspiring-conversation/team-posts/agile-vs-waterfall-how-approach-your-web-development-project [Accessed 30 September 2012]. Rooney, D., 2008. Waterfall vs. RAD vs. RUP vs. Agile (Scrum, XP, etc.). [Online] Available at: http://practicalagility.blogspot.com/2008/11/waterfall-vs-rad-vs-rup-vs-agile-scrum.html [Accessed 02 October 2012]. Rouse, M., 2007. waterfall model. [Online] Available at: http://searchsoftwarequality.techtarget.com/definition/waterfall-model [Accessed 29 September 2012]. Sigalaa, M., 2010. e-Procurement Use and Adoption Barriers: Evidence from the Greek Foodservice Sector. [Online] Available at: http://www.ifitt.org/admin/public/uploads/SigalaEB.pdf [Accessed 29 September 2012]. Sommerville, I., 2004. Software Engineering, 7th Edition. New York: Pearson Education (Addison Wesley). Turban, E., Leidner, D., McLean, E. & Wetherbe, J., 2005. Information Technology for Management: Transforming Organizations in the Digital Economy. New York: Wiley. Virginia, 2008. Chapter 8 – Describing the Need: Specifications and Requirements. [Online] Available at: http://www.vita.virginia.gov/uploadedfiles/VITA_Main_Public/unmanaged/scm/procurement_manual/chapter_08_-_ng_partnership/SCM_Chapter08.pdf [Accessed 01 October 2012]. Whitten, J.L., Bentley, L.D. & Dittman, K.C., 2000. Systems Analysis and Design Methods 5th Edition. New York: Irwin/McGraw-Hill. Read More

Additionally, the elasticity to error check through some component of the development phase formulates agile development methodology more effectively, bug free and less mistaken as compared to the waterfall software development methodology. This is able to simply test bugs at the end of the software development module (Reich, 2012; Amwicker, 2012; Phatak, 2012; Nayab & McDonough, 2012). In view of the fact that the agile software development methodology offers flexibility to make changes according to clients’ needs it is more inclined towards more effective customer approval.

This is an actual setback for the waterfall software development model that does not permit some changes once the software module that has been completed (Reich, 2012; Amwicker, 2012; Phatak, 2012; Nayab & McDonough, 2012). In addition, the agile software development modular partitioning of the software can be efficiently performed as compared to its counterpart. However, both of them offer alternatives for separation but the afterward lacks the changes in the accomplishment phase. Additionally, policies are established previous to the beginning of the project therefore it delays additional breakdown of the logical system development module.

On the other hand, the agile software development process is able to offer a great deal of support under similar circumstances as well as is able to permit immediate development of diverse modules at the same time as stated by time bound need. If we want the project to be additional separating agile development process appears as a pain release intended for developers (Reich, 2012; Amwicker, 2012; Phatak, 2012; Nayab & McDonough, 2012). For our group project I have used the agile methodology.

This methodology is more and more communication oriented. For this purpose, we have communicated more and more for taking information and details about system development and tasks management. Though, my personal viewpoints are in favor of the agile software development because in agile software development we can develop a software application according to customer’s expectations quickly. However, in our educational setting we normally use waterfall approach. For instance, when we have to work on a project or assignment we follow the steps sequentially.

First of all we set objectives, and then we plan and then actually perform tasks and everything we document. Waterfall methodology verses RAD methodology Rapid Application Development (RAD) software development methodology is the arrangement as well as the technique in that software development is applied to tackle client requirements without widespread prototyping and planning. In addition, it is tremendously practical in circumstances where time can be significant in encompassing a practical application prepared as well as further improved and enhancements can be made later (Custom Application Development Portal, 2010).

In addition, the major benefit of RAD development over waterfall model is that it splits the project work into lesser parts those can be assessed more regularly. As the project cannot obtain as far off track previous to issues are checked, fewer time as well as effort is wasted on task that turns out to be incorrect. Instead of wasting more time attempting to obtain needs right as well as however still having them transformed, wait for the transformation as well as then develop systems in reaction to the altered needs consequently task does not have to be redone as a result.

Functionality improves progressively as extra small parts of operational code are checked, developed and applied. Additionally, minimizing wasted attempts and offering working code faster surely is creditable (Rooney, 2008; Goldsmith, 2009). Moreover, the RAD model is a faster application development methodology. Additionally, the RAD model also offers a great deal of improved quality through fast system delivery and less resource application (Novulo, 2012). I will prefer RAD methodology, when we have shortage of time.

Read More