Промышленный лизинг Промышленный лизинг  Методички 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 [ 32 ] 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101

References



Beedle, M., M. Devos, Y. Sharon, K. Schwaber, and J. Sutherland. SCRUMA: An Extension Pattern Language for Hyperproductive Software Development. In Pattern Languages of Program Design, edited by N. Harrison, B. Foote, and H. Rohnert, Reading, MA: Addison-Wesley, 2000.

Buzan, T. The Mind Map Book Radiant Thinking, London: BBC Books, 1995. p. 29. Cockburn, Alistair. Methodology per Project (October 1999): TR 99.04.

Khosla, Vinod. GigaTrends, Wired. Available from http: www.wired.com/wired/archive/9.04/optical pr.html.

Malik, Palencia. Synchronize and Stabilize versus Open Source, Computer Science report 95.314A. Ottawa, Ontario, Canada: Carleton University (December 6, 1999).

Musashi, Miyamoto. (T. Cleary, Translator). The Book of Five Rings. Boston: Shambhala Publications, 2000, April

2001.

Newman, P. OGC, PRINCE2. Available from www.ogc.gov.uk/prince/.

Royce, W. Managing the Development of Large Software Systems, Proceedings of IEEE WESCON, 1970. pp.

1 9.

Royce, W. The Rational Edge CMM versus CMMI, From Conventional to Modern Software Management,

February 2000.

Senge, Peter. The Fifth Discipline The Art and Practice of the Learning Organization. New York: Doubleday/Currency, 1990.

Using the Rational Unified Process for Small Projects; Expanding upon eXtrme Programming. Gary, Indiana: Gary Police, Rational Software.

van Onna, Mark M. Progress in Changing Environments with PRINCE2, THS Worldclass Guide, January 2000. Weaver, P., N. Lambrou, and M. Walkey. PracticalSSADM, Ver. 4, 2nd ed. Pitman Publishing, 1993.



Chapter 4: Development Methodology Selection and Utilization

Using Development Methodologies

In this chapter, we explore various development methodologies used on projects either alone or in conjunction with a bigger project framework. Most project work can be a chaotic activity, often characterized by the phrase fighting fires. The project is often started without much of an underlying plan, and the designs are often changed because of technology or error. Sometimes the project is simply cobbled together from multiple quick-paced decisions. This can be effective if the project is small, but as the project grows to be a medium- or super-sized project, it becomes increasingly difficult to add features to the system. The project managers coordination skills are tested to the fullest extent as the project gets larger. Furthermore, mistakes become increasingly prevalent and difficult to fix (i.e., change control, issue logs). For example, building a space vessel begins with a blueprint based on numerous aeronautical and mathematical calculations, including material specifications, variables, and tolerances. Any change to this blueprint, which must be followed at all times, can kill the project because changes are costly and schedules can be horribly affected. The tools and materials that were manufactured specifically for the space vessel project are very expensive and should not change during the construction phase. On such a project, everything needs to be predictable.

Alternatively, when we look at developing software, we see something very different. We obviously try to build new software solutions usually with new technologies therefore, the associated risks are very high. In comparison to building space vessels, developing software is not the same. One is predictable and the other is not. In this chapter, we look at predictable methodologies, then at nonpredictable ones.

1кШиШ=1 1иллл1М1Ы1Д



How Many Development Methodologies are There?

There are no one-size-fits-all development methodologies. Some companies have their own unique customized methodology for developing products or services; others simply use standard commercial off-the-shelf methodologies. With the incorrect methodology, discovering, designing, building, testing, and deploying projects can be chaotic. At least 20 different methodologies are competing to be the best methodology, and this list of methodologies keeps on growing (see Figure 4.1).

х 1 -.

* j

! ~

К --

К <-

у 1-

X 1 -

Figure 4.1: Assessing project development methodologies.

The project methodology that is chosen represents merely the framework for the real work to be done and indicates where creativity is needed. Many times, project managers simply select the available methodology and continue to develop their projects with that same methodology. When unpredictable results occur on a project, they raise issues and risks and try to manage reactively. Project managers often lack the controls to measure and respond to the unpredictable. Therefore, they must first determine that the methodology is the correct one.

Many project managers find it difficult to give up control as provided in traditional development. There is no guarantee that the team will deliver if you just follow a chosen methodology. Clients seldom complete requirement specifications because their requirements are constantly changing. The most logical solution is to simply evolve the product as the clients needs change along the project development process. This shows the need for a methodology more flexible than a formal waterfall approach. In fact, the trend is shifting to the more iterative or incremental style of methodologies.

Most project developments are wrongly approached with the assumption that the methodology used is well understood, and the project can be easily planned and estimated. When a project begins to fail, the development process is immediately provided with more resources and attention to get it back on track. Thus, cost and schedule overruns start occurring. These step-by-step approaches do not work because they do not cope with human and technical unpredictability. Rigid processes are often too constraining and fall short of delivering a project to operations or production.

Influence of New Product Development

In todays progressive marketplace, every moment counts. Companies developing new products, whether new bridge construction or a wireless mobile device, usually do so concurrently with existing product developments, often competing for similar resources and delivery dates. These projects must be developed in a synchronized approach with some differentiator toward the development of new stellar products. Hence, a competitive project methodology



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 [ 32 ] 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101