Essay Development Process Example For Students

Essay Development Process This week’s assignment focus on the processes of system development and risk involved. For someone like me who never was part of the full design phase of the development process, I never knew the full concept of how the projects or applications were built from initiation. This assignment will allow me to have a high level understanding of the processes involved in system development, thereby allowing me to get a full grip of Project Management involved in the entire system development lifecycle. The 1st part of the assignment will allow me to identify and differentiate the 3 different development processes; waterfall, iterative and agile. I am hoping that after completing this part, I will somehow be able to identify the appropriate process for a particular application development. Among the 3 types of development approaches, the only one that I am familiar of is the waterfall approach. The 2nd part of the assignment will allow me to group the risk involved with the scenario presented. As I go through this part of the assignment, my aim would be to be able to group the risk accordingly for my future project so that I can address them accordingly. Scenario Suppose that your organization, a mall management company, wants to leverage the very large amount of unstructured data that it has stored purchases by registered customers, in particular. The product, MallKiosk will make purchase suggestions at member stores. For example: â€Å"Shoes at Macy’s: 20% discount for 3 or more† based on the last time this customer bought items. The following characteristics apply: * It is anticipated that MallKiosk features will change as often as every month after its release. * For example, new applications will be added and others removed. This may be reflected in their positions on menus. * For this reason, its functionality should be as easy as possible to modify by IT * MallKiosk may be extended in the future to interface with customer-service communication, including chat and telephone. * It has not yet been determined if MallKiosk will be served by several internally managed servers or if it will be cloud hosted. * A website is to be established that describes MallKiosk and its usage. * Your team has only four programmers experienced with programming of this type of system: ten are needed. * A third of the development team will be co-located; a third will reside in a second domestic location; another third in another offshore location. * Initial delivery is to be in six months. Part I. Selection of a Suitable Development Process Waterfall Approach For the past years, waterfall process had been used by small and big companies as an approach to development process. This approach looks like a waterfall where it shows a steady downwards flow. This approach of development is the most mature and disciplined. The waterfall development model originated in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development (Bennington, 1983). The origin of the waterfall process from the manufacturing and construction industries entailed that the process should always have a pre-requisite be completed or almost be complete before the next can be started. This approach also deals with the entire process involved in the system development and breaks down the steps sequentially. In relation to the scenario, there are only a few characteristics of the MallKiosk that match up with the waterfall approach. Because of the waterfall’s disciplined approach for development, it will be an advantage for the delivery requirement of six months. The approach will also fit on the scattered location of the developer resources requirement because of the need to do hand-over. However because of the changing features of MallKiosk, this may not be the single best approach for the project. Iterative Approach Iterative process is the smaller version waterfall process and is identified as the essential part of the modern waterfall model. However, in comparison with the traditional waterfall approach, this development process makes use of the waterfall process in smaller scale and in repeating cycle. This is advantageous for development projects that needs constant addition of features or modules. The Iterative process provides a good approach for some of the characteristics of the MallKiosk development. A few of the characteristics of the project that can fit for the iterative process is the plan to constantly change or add functionality of the application. This process makes sure that a completion on each iteration is completed therefore ensuring a working product while on another modified design. Agile Approach The Agile development process is what the modern developers prefer over the more mature and disciplined processes and I understand why it attracts the new blood of developers and project management. This is because â€Å"Agile development is a systems development strategy wherein the system developers are given the flexibility to select from a variety of appropriate tools and techniques to be accomplish the tasks at hand. Agile development is believed to strike optimal balance between productivity and quality for systems development† (Whitten, 2007). This type of approach best fits most of the characteristics of the MallKiosk project like the need to have a fast turn-around or delivery of the project, the co-location The MallKiosk can also take advantage of the Agile development process that takes pride of the Agile manifesto which is based on twelve principles (refer to Appendix 3 for 12 principles) that focuses on the need to deliver a working software or application while keeping up with the changing features and requirements. Development Process for MallKiosk Development For the MallKiosk development, the best approach to deal with the entire system development is through agile process with iteration (iterative approach). Most of the MallKiosk characteristics and requirements involved in the whole application match each stated phrase in the Agile Manifesto. The following table will show why this development process was chosen over the Waterfall and Iterative processes: Characteristics | Agile | Iterative | Waterfall | It is anticipated that MallKiosk features will change as often as every month after its release. | One the advantage of this process is the regular adaptation to the changing processes. This means that with this process, if a requirement changes overnight, it can be implemented as soon as the requirement is verified | With this process it is possible to deliver the new or updates but because iterative is a modified waterfall process, it still follows strict guidelines on implementing new features in a working environment | The strict guideline and requirement specification made using this process will allow very small room to change or update the application on the fly. | MallKiosk may be extended in the future to interface with customer-service communication, including chat and telephone. | This is the same as the first characteristic to where an addition or change in the module can be implemented as soon as possible. | This may be considered a new module therefore creating a different iteration for each. Implementation of this is possible although the requirements should be defined properly. | Requirements are drawn on the first phase of the development and to be able to put these characteristics in the future, it should have been stated in the requirement document. | A website is to be established that describes MallKiosk and its usage. | A fast delivery is required of this, so someone with the expertise can go ahead and design the website while the application is still being developed. | Requirement gathering for this particular iteration will still be pre-requisite before development starts. Comparing The Writing Styles, Data Collection And Analysis ProcessThe 2nd risk can be avoided by creating a clear and resounding rule of transition from each member of the 3 scattered team. This risk can also be avoided by clearly detailing the responsibility and accountability of each member of the team by utilizing the RACI chart as presented in the Information Technology Infrastructure Library (ITIL). The 3rd and 4th risk both present technical risk because the decision to either host the server internally or host it in cloud should be determined not only based on the cost allocation but also on the technical skill of the human resources, the location capability to host internal server, and uptime requirement of the MallKiosk, all of which deals with the technical aspects. While the MallKiosk is at the development phase, the server/hardware requirements should already be scoped out. During the design and forecasting phase, our strategy will be risk conquest because we know that in as much as we scope out the hardware/server requirements, the load and transaction testing is the true determination if the existing server requirement meets all the application requirements. The 3rd risk however can be avoided by making sure that the hosting company provides the uptime or service lever agreement as per specified on the application requirements. Because the servers will be hosted remotely, the building network infrastructure should also be scoped out properly based on the requirements. The strategy for the 4th risk is conquest because when it is decided that the servers will be hosted internally, it should be made sure that a subject matter expert and team that will administer and maintain the servers are well informed of the application uptime or transaction requirements. Internet and Network connectivity should also be fully tested together with the server specifications. By properly identifying the specific risk and analyzing the impact we can help develop an effective risk management plan. As stated by Edmead in his article that was published online in 2007, â€Å"The end result of the risk assessment is to determine the extent of the potential threat and its associated risk, which is defined as the likelihood that a given threat can exploit or take advantage of a particular vulnerability.†   This statement encapsulated the whole reason why risk assessment is important for our current MallKiosk project. Appendices Appendix 1: Waterfall Approach The first known presentation describing use of similar phases in software engineering was held by Herbert D. Benington at Symposium on advanced programming methods for digital computers on 29 June 1956 (Navy Mathematical Computing Advisory).  This presentation was about the development of software for  SAGE. In 1983 the paper was republished   with a foreword by Benington pointing out that the process was not in fact performed in a strict top-down fashion, but depended on a prototype. The central idea behind the Big Design Up Front and the waterfall model: time spent early on making sure requirements and design are correct saves much time and effort later. Thus, the thinking of those who follow the waterfall process goes, make sure each phase is 100% complete and absolutely correct before proceeding to the next phase. Program requirements should be set in stone before design begins (otherwise work put into a design based on incorrect requirements is wasted). The programs design should be perfect before people begin to implement the design (otherwise they implement the wrong design and their work is wasted), etc. (Waterfall model, 2008). Appendix 2: Agile Approach As stated in the Agile Manifesto: â€Å"Through this work we have come to value: Individuals and interactions over processes and tools; Working software over comprehensive documentation; Customer collaboration over contract negotiation; Responding to change over following a plan; That is, while there is value in the items on the right, we value the items on the left more (Beck, 2001). The agile manifesto is based on the 12 principles as shown below: 1. Customer satisfaction by rapid delivery of useful software 2. Welcome changing requirements, even late in development 3. Working software is delivered frequently (weeks rather than months) 4. Working software is the principal measure of progress 5. Sustainable development, able to maintain a constant pace 6. Close, daily cooperation between business people and developers 7. Face-to-face conversation is the best form of communication (co-location) 8. Projects are built around motivated individuals, who should be trusted 9. Continuous attention to technical excellence and good design 10. Simplicity the art of maximizing the amount of work not done is essential 11. Self-organizing teams 12. Regular adaptation to changing circumstances Appendix 3: Risk Management In the example of risks, there were only 2 types of risk identified. However in totality, there are more categories as identified by Edmead in his article online in 2007. As stated, the risk assessment process begins with the identification of risk categories. An organization most likely will have several risk categories to analyze and identify risks that are specific to the organization. Examples of risk categories include: * Technical or IT risks. * Project management risks. * Organizational risks. * Financial risks. * External risks. * Compliance risks. For instance, technical risks are associated with the operation of applications or programs including computers or perimeter security devices (e.g., a computer that connects directly to the Internet could be at risk if it does not have antivirus software). An example of a project management risk could be the inadequacy of the project manager to complete and deliver a project, causing the company to delay the release of a product to the marketplace. Organizational risks deal with how the companys infrastructure relates to business operations and the protection of its assets (e.g., the company does not have clear segregation of duties between its production and development environments), while financial risks encompass events that will have a financial impact on the organization (e.g., investing the companys cash reserves in a highly speculative investment scheme). External risks are those events that impact the organization but occur outside of its control (e.g., natural disasters suc h as earthquakes and floods). Finally, a compliance risk occurs when a company does not comply with mandated federal regulations, which often results in fines or legal sanctions. References 1. Benington, Herbert D. (1 October 1983).  Production of Large Computer Programs.  IEEE Annals of the History of Computing  (IEEE Educational Activities Department)  Retrieved 2011-03-21. 2. Whitten, J. L. Bentley, L. D. (2007). Systems Analysis and Design Methods (7th ed.). McGraw-Hill/Irwin. 3. Waterfall model. (2008, September). Retrieved from http://en.wikipedia.org/wiki/Waterfall_model 4. Agile software development. (2012, April). Retrieved from http://en.wikipedia.org/wiki/Agile_software_development 5. Beck, K., et.al (2001).  Manifesto for agile software development. Retrieved from http://agilemanifesto.org/ 6. Beck, Kent; et al. (2001).  Principles behind the Agile Manifesto. Agile Alliance.  Archived  from the original on 14 June 2010. Retrieved 6 June 2010. 7. Edmead, M. (2007, May).  Understanding the risk management process. Retrieved from http://www.theiia.org/intAuditor/itaudit/archives/2007/may/understanding-the-risk-management-process/ 8. Knapp, D. (2010). ITSM Process design Guide. Ross Publishing, Incorporated, J