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. ScenarioSuppose 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 ProcessWaterfall ApproachFor 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). [1]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 ApproachIterative 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 ApproachThe 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). [2]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 DevelopmentFor 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. A Requirement should be gathered as part of the complete documentation of the whole process |Your team has only four programmers experienced with programming of this type of system: ten are needed. | Co-location with the advantage of actual interaction with a developer. For the off shore and remote workers, there should be an instill discipline for each member of the team. | This process will not fit perfectly for this project characteristic because in as much as the project is subdivided into small groups, the developers have to work together and proper documentation is needed for transition or handover.
| Strict hand-over and transition is the key for this type of developer group to work. This process with the documentation will allow dispersed group of developers to properly complete their development task. 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. | Because developers dive as fast as possible to code the application, a working prototype or version may be available even after 1 to 2 months. | By the end of six months a prototype or intermediate working version is already available.
| IF requirements are drawn perfectly (which most often is not the case) this is possible. |Part II. Risk AnalysisIdentification of RiskThere are a lot of risks involved in MallKiosk project development but the following risks post most of the known impact to the whole system:* The lack of experienced programmer for the type of MallKiosk system development (assume that the technology used to build the system is C# in . Net Platform) may result to the non-delivery of the application on the required date. * If the MallKiosk application will be hosted by internally managed servers, the uptime may be compromised if there is no disaster recovery plan set in-place. * If the MallKiosk application will be hosted in the cloud, the latency may be compromised because of the dependency on the factors of internet and network connectivity at the MallKiosk location* By dividing the development group into 3, there is a big possibility of hand-over failure especially during bug troubleshooting.
* The extension of the MallKiosk interface with customer service in the future may affect a big change in the network and hardware infrastructure that will cost more because of the increased usage and transaction per minute handling. * The anticipated MallKiosk features done as often as every month will require a monthly downtime because of the release and if it not properly tested, it may cause a longer downtime. Risk AnalysisThe following table shows the risk prioritization with the impact and cost related with each risk. The table also show what type each risk belong the process of identifying the risk priority. Please refer to notes after the table for detailed explanation of each risk.
Rank | Risk | Risk Type | Likelihood of Occurrence | Estimated Impact | Estimated Management Cost | Priority Number |1 | The lack of experienced programmer for the type of MallKiosk system development (assume that the technology used to build the system is C# in . Net Platform) may result to the non-delivery of the application on the required date. | Organization and Technical | 8 | 9 | 9 | 54 |2 | By dividing the development group into 3, there is a big possibility of hand-over failure especially during bug troubleshooting. | Organization | 7 | 9 | 9 | 72 |3 | If the MallKiosk application will be hosted in the cloud, the latency may be compromised because of the dependency on the factors of internet and network connectivity at the MallKiosk location. | Technical | 6 | 9 | 8 | 80 |4 | If the MallKiosk application will be hosted by internally managed servers, the uptime may be compromised if there is no disaster recovery plan set in-place. | Technical | 4 | 9 | 8 | 112 |5 | The anticipated MallKiosk features done as often as every month will require a monthly downtime because of the release and if it not properly tested, it may cause a longer downtime.
| Organization | 1 | 9 | 6 | 120 |6 | The extension of the MallKiosk interface with customer service in the future may affect a big change in the network and hardware infrastructure that will cost more because of the increased usage and transaction per minute handling. | Technical | 2 | 9 | 9 | 162 |Risk ManagementThe first two top risks on this part is presented as one interrelated risk because both deals with developers involved in the development of the application. The first and second risk on the above table presents not just technical but also organizational risks. Assuming that the technology used is C# .
Net. The application requires 10 C# developers that should be all subject matter experts to be able to deliver the application on time. As indicated on the scenario and the detailed characteristics of the project, they only have 4 programmers who know the system. One of the characteristics of the application is also the division of the developers into 3 groups where one of the three groups is co-located, the other is located domestically working remotely and the other third is off-shore.
By looking at the two risks, the 1st risk was dealt with by the grouping the developers into 3 to deal with the impact of the 1st risk. The strategy to conquest the 1st risk however had introduced the 2nd risk because of the issue on hand-over or transition of developer tasks. The 2nd risk therefore can be dealt with by avoiding the risk. To deal with both the risk, the project manager should be able to scope the initial pre-requisite and determine each candidate’s strongest expertise on each module or feature of the application.
This will allow the proper distribution of task to every member of the developer team. The agile process will be very advantageous for this type of development group because of the need to have constant interaction between members. For the 1st risk, before the development starts for MallKiosk application, the subject matter experts in each group (3 groups) should be identified. If upon looking at the subject matter experts in each group, and it is determined that the total still lack the 10 requirements for the development team, the manager should speed up the training of the lower members of the team and validate the achievement of their development skill by earning the certification with a set deadline of when it should be earned or completed. The 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).
[8]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.
” [7] This statement encapsulated the whole reason why risk assessment is important for our current MallKiosk project. AppendicesAppendix 1: Waterfall ApproachThe 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 [1] 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 program’s 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). [3]Appendix 2: Agile ApproachAs 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: [6]1. Customer satisfaction by rapid delivery of useful software2. Welcome changing requirements, even late in development3. Working software is delivered frequently (weeks rather than months)4.
Working software is the principal measure of progress5. Sustainable development, able to maintain a constant pace6. Close, daily cooperation between business people and developers7. Face-to-face conversation is the best form of communication (co-location)8. Projects are built around motivated individuals, who should be trusted9. Continuous attention to technical excellence and good design10.
Simplicity – the art of maximizing the amount of work not done – is essential11. Self-organizing teams12. Regular adaptation to changing circumstancesAppendix 3: Risk ManagementIn 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 company’s 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 company’s 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 such 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. [7]References1. 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_model4. Agile software development. (2012, April). Retrieved from http://en.
wikipedia. org/wiki/Agile_software_development5. 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
