Information Project Management Methodologies
Preface: The purpose of this publication is to receive feedback and collect criticism of the article from the IT community in anticipation of its publication in a periodical. The article will provide a brief description, in chronological order, of popular methodologies in the field of information project management.
In 1958, the consulting company Booz Allen Hamilton Inc. together with the Lockheed Martin Space Systems development center and the software development department of the special design center of the US Navy Department, they develop the Program Evaluation and Review Technique, code-named PERT, for the Polaris submarine weapons development project "[1] (ballistic missiles).
PERT was designed to save time when managing large projects in which time is a critical metric. The methodology involves the analysis of individual tasks in terms of their impact on the completion of the entire project, in particular, the time to complete each task is analyzed, as a result of which the minimum necessary time to complete all stages is determined. This technique can be used in conditions of uncertainty, when the details of each stage and the exact time to complete them are unknown, moreover, it is an event-oriented technique applied to projects where time is a more important factor than cost.
This methodology was used in preparation for the 1968 Winter Olympics in Grenoble [2], it was the first of its kind to revive the approach of the “Scientific organization of labor” [3] first described by Taylor Frederick Winslow in 1911, who tried to apply science to process engineering and management.
The basis of the described technique is the construction of a network diagram represented by events that are interconnected by activities, as shown in Figure 1.
Fig. 1. Network diagram of the PERT methodology
Events themselves do not have time and resources, they only mean the beginning of a new stage of activity, but for activities the necessary resources and characteristics of time are determined, such as: minimum, maximum, normal and expected time. The time of slippage or sagging is also calculated - the time difference in relation to other activities, showing how much this activity is ahead or behind the schedule, respectively.
Based on the network diagram, the most popular methodology of the PERT technique is built - the critical path method, the essence of which is to build the longest route from the first to the final event. Thus, any delays on the critical path will delay the onset of the final event. This method allows you to determine the most important tasks, and to optimize it, the “quick pass” method can be used, which may consist in parallelizing activities that lie on the critical path.
In 1970, Dr. Winston W. Royce published the publication “Managing the development of large software systems” [4] (managing the development of large software applications), in which he describes the development techniques, which will later be known as the “cascading development model” , also “waterflow” or “waterfall”. The original model assumes the following sequence of development steps:
Initially, a sequential transition from one stage to another was supposed, but here Winston considers the situation where, after moving to the next step, the shortcomings of the previous one can be revealed, and offers a model where you can return to the previous stage to finalize it. He further develops it to what will be known in the future as an “iterative development model” - it consists of the same stages as cascading, but involves a transition from the testing phase to the stage of determining software requirements.
In 1991, James Martin published the book Rapid Application Development (RAD), which describes the concept of rapid software development using prototyping with minimal planning. Among other things, this methodology is distinguished by prioritization: if the cascading model is repelled from the functional, then the focus is on on time and resources spent. Thus, if the development of a non-critical part of the functional does not meet the deadlines, RAD implies the rejection of this functionality. RAD includes the following development steps:
In 1993, Microsoft released the Microsoft Solutions Framework (MSF 1.0) as a set of models of disciplines, concepts and principles for creating information technology solutions. At MSF, emphasis is placed on the following values [5]:
The key elements of MSF are principles, ways of thinking, a team model, and a management model. The principles are presented by recommendations, here are some of them: encouraging communication; the most open project information within the team; empowerment of team members with authority, responsibility and accountability. Thinking patterns include: “take care of your teammates” or “lifelong learning”.
The MSF team model considers the steps that are described in the cascading development model from the perspective of their inherent goals and functional areas, in order to effectively distribute roles in the team. The management model is designed to provide the right guidance to the right people at the right time and recommends controlling resources and priorities at each stage of development. Among other things, in MSF there is such a thing as “control points”, the concept of which resembles events from the PERT network diagram, considered from the perspective of MSF core values.
In 1994, a consortium of 17 British companies created the Dynamic Systems Development Method (DSDM) software development framework based on the concept of rapid RAD application development. A framework is a set of principles, predefined role types, and the following techniques [6]:
The time-box technique is the main DSDM technique used to complete a project on time, meet budget and maintain quality. The timebox is an iteration, in which the project is divided into logical sections, spaced in time. Timeboxes are not divided into sub-events, and the functionality is not critical, as a result of which it can be partially excluded in order to save time, in the manner determined by the MoSCoW prioritization method. The MoSCoW prioritization method defines 4 priority levels:
The methodology for prototyping involves the development of functional, productive and other models at various stages of the project, which allows you to identify the difficulties that you will encounter, to evaluate the performance, usability of the interface and functionality, including from a commercial point of view.
DSDM pays special attention to participation in the user (consumer) development process, which is enshrined in the principles that are an integral part of the framework [7]:
As described above, the DSDM methodology defines a set of standard roles, each of which, in turn, corresponds to a certain area of responsibility, such as:
The latest version of the methodology, released in 2007 and called DSDM Atern, involves the following 7 stages of the project life cycle:
1. Pre-project. At the first stage of the project life cycle, the appropriateness of the project is determined and, among other things, the issuance of an act on project initiation is allowed.
2. Feasibility. At this stage, the technical and economic feasibility of the project is being determined, including the ability to effectively achieve business goals.
3. Definition of business processes - implies the definition of requirements, strategy, architecture, standards used and possible risks associated with the project implementation process.
4. Intelligence. At this stage, it is planned to build business prototypes and create a list of functional requirements.
5. Engineering. Design surveys aimed at solving non-functional requirements (for example, performance, security, support and maintenance capabilities). Including the implementation of all the requirements for the successful operation of the product.
6. Deployment - implies a cycle of work to provide the product to the final consumer, training and writing documentation. It also reveals whether the product meets all established business requirements.
7. Post project. At this stage, the results are summed up and the effectiveness of the decisions made is evaluated, it is recommended to do this after 3-6 months in order to have a lot of information about the results of the project.
In 1995, Dr. Jeff Sutherland and Ken Schwaber presented a methodology called “Scrum” at the annual Practical Conference “Object-Oriented Programming, Systems, Languages and Applications” (OOPSLA) hosted by the Computer Science Association [8]. The approach was first described by scientists Hirotaka Takeuchi and Ikujiro Nonaka in 1986, as a flexible, holistic, product development strategy, where the development team works as a whole to achieve a common goal, in contrast to the traditional, consistent approach [9].
In accordance with the latest guidance, Scrum is positioned as a framework within which it is possible to solve complex adaptive problems and at the same time productively and creatively develop products of the highest quality. As stated in the official documentation, it shows the relative effectiveness of product management and development practices [10]. The approach is represented by three categories:
The team consists of the owner of the product, which is responsible for setting goals, the development team and the Scrum wizard, which is designed to ensure compliance with the Scrum methodology. Artifacts are internal terminology, and events are used in Scrum to create regularity and minimize the need for meetings not specified by Scrum, their list is as follows:
In 1997, the article "MESSY, EXCITING, AND ANXIETY-RIDDEN: ADAPTIVE SOFTWARE DEVELOPMENT" [11] by Jim Higgsmith, in which he describes the adaptive methodology of software development (Adaptive software development, abbreviated ASD). A key feature of this methodology is a new look at the relationship to requirements and the project, it implies the possibility of constant change, which is what it wants to adapt to. The prevailing classical project life cycle: planning-design-construction is modified here and is represented by the sequence: speculate-collaborate-learn.
In 1999, the book Extreme Programming Explained: Embrace Change [12] was published, describing an extreme programming methodology authored by Kent Beck, Ward Cunningham, and Martin Fowler. Extreme programming, like ASD, focuses on constantly changing requirements and offers 12 techniques that contribute to an efficient development process in such conditions:
In 2001, in the USA, Utah, the Agile Manifesto agile software development methodology manifest was signed. Agile is a family of development methodologies that includes extreme programming, SCRUM, DSDM, ASD, a little-known methodology Crystal, FDD, Pragmatic Programming and others. Agile defines 12 principles that you should adhere to [13]:
1. The highest priority for us is to meet customer needs, provided through the regular and early delivery of valuable software.
2. Changing requirements is welcome, even in the later stages of development. Agile processes enable you to leverage change to provide your customer with a competitive edge.
3. A working product should be released as often as possible, with a frequency of from a couple of weeks to a couple of months.
4. Throughout the project, developers and business representatives must work together daily.
5. Motivated professionals should work on the project. For the work to be done, create conditions, provide support and fully trust them.
6. Direct communication is the most practical and effective way to exchange information both with the team itself and within the team.
7. A working product is a key indicator of progress.
8. Investors, developers and users should be able to maintain a constant rhythm indefinitely. Agile helps to set up such a sustainable development process.
9. Continuous attention to technical excellence and design quality enhances project flexibility.
10. Simplicity - the art of minimizing unnecessary work - is essential.
11. The best requirements, architectural and technical solutions are born of self-organizing teams.
12. The team should systematically analyze possible ways to improve efficiency and adjust their work style accordingly.
In the same year 2001, IBM developed a development methodology called the Rational Unified Process (RUP) that describes how to leverage commercially proven approaches to software development. RUP provides team members with the guidelines, templates, and instructive tools needed for the entire team to take full advantage of the following practices:
Fig. 2. RUP workflows
The core of the RUP are the following workflows, the intersection of which is shown in Figure 2. Among which are 6 engineering processes and 3 auxiliary processes:
The latest innovations in the field of software development methodologies include the 37signals book “Getting Real” [14], published in 2006, which describes the methodology of the same name, which is entirely aimed at minimizing any bureaucratic costs, such as compiling specifications or staffing. In this development approach, it is recommended to start development with an interface design, then move on to the interface itself and, at the end, to programming. Thus, it is implied that as soon as possible release the minimum version of the product and develop it, which is most suitable for web projects.
Getting Real is offered primarily for use in small companies and teams, where various organizational obligations are not a necessary condition for survival and only burden the team. In general, this methodology meets or contributes to most of the principles described in extreme programming and the manifesto of flexible methodologies. In addition, the methodology covers such areas of knowledge as:
The main methodologies used in the management of information projects are considered, the stages of the life cycle of projects inherent in some of them, the fundamental principles and inherent priorities, as well as the strengths and main differences from previous methodologies are established.
In the field of development of information project management methodologies, the earliest were studied, among which were presented such as PERT, which, however, is a universal project management methodology, where time is a critical indicator, and was also used to organize the 1968 Winter Olympics. The iterative model of the project life cycle presented by Winston W. Royce is considered, such popular project methodologies as RAD, MSF, DSDM, Scrum, ASD, Extreme Programming, RUP are described. An overview of Agile agile development manifest principles and features of the latest 37signals Getting Real development methodology is presented.
Throughout the development of methodologies, one can observe changes in the prioritization from time-functional to time-resources. Moreover, the latest versions of methodologies imply a constant change in functional requirements. The greatest formalization of methodologies and processes was observed by the end of the first half of the 90s, after which light versions began to gain popularity.
1. Fazar W., Program Evaluation and Review Technique // The American Statistician, Vol. 13 (No. 2), 1959, p. 10.
2. Official report of the International Olympic Committee on the results of the Winter Olympic Games in Grenoble, 1968, p. 49
3. Taylor FW, The Principles of Scientific Management, New York, NY, USA and London, UK: Harper & Brothers, - LCCN 11010339, OCLC 233134.
4. Royce WW, Managing The Development Of Large Software Systems // Reprinted from Proceedings, IEEE WESCON, August 1970, pages 1-9. Copyright © 1970 by The Institute of Electrical and Electronics Engineers, Inc. Originally published by TRW.
5. Overview of Microsoft Solutions Framework (MSF) [Internet resource] / Microsoft Developer Network - Access mode: msdn.microsoft.com/en-us/library/jj161047.aspx(Date of treatment: 11/03/2014).
6. DSDM Atern Handbook [Internet resource] / DSDM Consortium - Access mode: www.dsdm.org/dig-deeper/book/dsdm-atern-handbook (accessed: 03.11.2014).
7. Shopyrin DG, Project management of software development: Training manual on discipline "Flexible software development technologies", St. Petersburg: St. Petersburg State University ITMO, 2007. - 131 p.
8. Sutherland JV, Business object design and implementation / Sutherland JV Schwaber K. // OOPSLA '95 Workshop Proceedings, The University of Michigan, 1995, - 118 p.
9. Takeuchi H., New New Product Development Game [Internet source] / Takeuchi H., Nonaka I. // Harvard Business Review, 1986 - Access mode: hbr.org/1986/01/the-new-new-product- development-game / ar / 1(Date of treatment: 11/03/2014).
10. A comprehensive guide to Scrum: Game Rules [Internet Source] / Scrum.org - Access mode: www.scrum.org/scrum-guide (accessed: 03.11.2014).
11. Highsmith JM, Exciting, And Anxiety-Ridden: Adaptive Software Development // American Programmer, Volume X (No. 1), 1997 - Electronic resource: www.adaptivesd.com/articles/messy.htm (accessed: 03.11.2014 )
12. Beck K., Extreme Programming Explained: Embrace Change. US: Addison-Wesley Professional, 2005 .-- 224 c. - ISBN-10: 0201616416
13. Fundamental Principles of the Agile Manifesto [Internet source] / Beck K., Beedle M., Arie van Bennekum, Cockburn A., Cunningham W., Fowler M., Grenning J., Highsmith J., Hunt A., Jeffries R ., Kern J., Marick B., C. Martin RC, Mellor S., Schwaber K., Sutherland J., Thomas D. - Access mode: agilemanifesto.org/iso/en/principles.html (accessed: 03.11 .2014).
14. Getting Real [Internet source] / 37signals, 2014 - Access mode: gettingreal.37signals.com (accessed: 03.11.2014).
In 1958, the consulting company Booz Allen Hamilton Inc. together with the Lockheed Martin Space Systems development center and the software development department of the special design center of the US Navy Department, they develop the Program Evaluation and Review Technique, code-named PERT, for the Polaris submarine weapons development project "[1] (ballistic missiles).
PERT was designed to save time when managing large projects in which time is a critical metric. The methodology involves the analysis of individual tasks in terms of their impact on the completion of the entire project, in particular, the time to complete each task is analyzed, as a result of which the minimum necessary time to complete all stages is determined. This technique can be used in conditions of uncertainty, when the details of each stage and the exact time to complete them are unknown, moreover, it is an event-oriented technique applied to projects where time is a more important factor than cost.
This methodology was used in preparation for the 1968 Winter Olympics in Grenoble [2], it was the first of its kind to revive the approach of the “Scientific organization of labor” [3] first described by Taylor Frederick Winslow in 1911, who tried to apply science to process engineering and management.
The basis of the described technique is the construction of a network diagram represented by events that are interconnected by activities, as shown in Figure 1.
Fig. 1. Network diagram of the PERT methodology
Events themselves do not have time and resources, they only mean the beginning of a new stage of activity, but for activities the necessary resources and characteristics of time are determined, such as: minimum, maximum, normal and expected time. The time of slippage or sagging is also calculated - the time difference in relation to other activities, showing how much this activity is ahead or behind the schedule, respectively.
Based on the network diagram, the most popular methodology of the PERT technique is built - the critical path method, the essence of which is to build the longest route from the first to the final event. Thus, any delays on the critical path will delay the onset of the final event. This method allows you to determine the most important tasks, and to optimize it, the “quick pass” method can be used, which may consist in parallelizing activities that lie on the critical path.
In 1970, Dr. Winston W. Royce published the publication “Managing the development of large software systems” [4] (managing the development of large software applications), in which he describes the development techniques, which will later be known as the “cascading development model” , also “waterflow” or “waterfall”. The original model assumes the following sequence of development steps:
- definition of system requirements;
- definition of software requirements;
- analysis;
- design;
- development;
- testing;
- exploitation.
Initially, a sequential transition from one stage to another was supposed, but here Winston considers the situation where, after moving to the next step, the shortcomings of the previous one can be revealed, and offers a model where you can return to the previous stage to finalize it. He further develops it to what will be known in the future as an “iterative development model” - it consists of the same stages as cascading, but involves a transition from the testing phase to the stage of determining software requirements.
In 1991, James Martin published the book Rapid Application Development (RAD), which describes the concept of rapid software development using prototyping with minimal planning. Among other things, this methodology is distinguished by prioritization: if the cascading model is repelled from the functional, then the focus is on on time and resources spent. Thus, if the development of a non-critical part of the functional does not meet the deadlines, RAD implies the rejection of this functionality. RAD includes the following development steps:
- planning - requirements are defined;
- user design - definition of functionality;
- construction - development;
- switching - implementation;
In 1993, Microsoft released the Microsoft Solutions Framework (MSF 1.0) as a set of models of disciplines, concepts and principles for creating information technology solutions. At MSF, emphasis is placed on the following values [5]:
- compliance with technical and commercial goals;
- definition of clear goals, distribution of roles and responsibilities;
- the implementation of an iterative process, divided into stages or control points;
- proactive risk management;
- effective response to change.
The key elements of MSF are principles, ways of thinking, a team model, and a management model. The principles are presented by recommendations, here are some of them: encouraging communication; the most open project information within the team; empowerment of team members with authority, responsibility and accountability. Thinking patterns include: “take care of your teammates” or “lifelong learning”.
The MSF team model considers the steps that are described in the cascading development model from the perspective of their inherent goals and functional areas, in order to effectively distribute roles in the team. The management model is designed to provide the right guidance to the right people at the right time and recommends controlling resources and priorities at each stage of development. Among other things, in MSF there is such a thing as “control points”, the concept of which resembles events from the PERT network diagram, considered from the perspective of MSF core values.
In 1994, a consortium of 17 British companies created the Dynamic Systems Development Method (DSDM) software development framework based on the concept of rapid RAD application development. A framework is a set of principles, predefined role types, and the following techniques [6]:
- timebox
- MoSCoW prioritization principle,
- workshops
- prototyping.
The time-box technique is the main DSDM technique used to complete a project on time, meet budget and maintain quality. The timebox is an iteration, in which the project is divided into logical sections, spaced in time. Timeboxes are not divided into sub-events, and the functionality is not critical, as a result of which it can be partially excluded in order to save time, in the manner determined by the MoSCoW prioritization method. The MoSCoW prioritization method defines 4 priority levels:
- must have
- it should be
- need (could have) and
- you can (want have).
The methodology for prototyping involves the development of functional, productive and other models at various stages of the project, which allows you to identify the difficulties that you will encounter, to evaluate the performance, usability of the interface and functionality, including from a commercial point of view.
DSDM pays special attention to participation in the user (consumer) development process, which is enshrined in the principles that are an integral part of the framework [7]:
- Active user involvement in the development process;
- The development team can make decisions;
- Frequent delivery of results;
- The criterion for the acceptability of the results is their compliance with the business;
- Iterative and incremental development;
- Any actions may be undone;
- Stability of high-level requirements;
- Testing is performed continuously and continuously;
- Interaction and cooperation.
As described above, the DSDM methodology defines a set of standard roles, each of which, in turn, corresponds to a certain area of responsibility, such as:
- project manager - general management;
- seer - monitors compliance with commercial goals and objectives;
- project champion - resource management;
- team leader - leads the developers;
- Technical Coordinator - Architecture;
- developer - development;
- tester - testing;
- representative user - represents the interests of consumers;
- user consultant - advises on the use of the product;
- Secretary - is responsible for recording;
- intermediary - is responsible for the interaction between team members;
The latest version of the methodology, released in 2007 and called DSDM Atern, involves the following 7 stages of the project life cycle:
1. Pre-project. At the first stage of the project life cycle, the appropriateness of the project is determined and, among other things, the issuance of an act on project initiation is allowed.
2. Feasibility. At this stage, the technical and economic feasibility of the project is being determined, including the ability to effectively achieve business goals.
3. Definition of business processes - implies the definition of requirements, strategy, architecture, standards used and possible risks associated with the project implementation process.
4. Intelligence. At this stage, it is planned to build business prototypes and create a list of functional requirements.
5. Engineering. Design surveys aimed at solving non-functional requirements (for example, performance, security, support and maintenance capabilities). Including the implementation of all the requirements for the successful operation of the product.
6. Deployment - implies a cycle of work to provide the product to the final consumer, training and writing documentation. It also reveals whether the product meets all established business requirements.
7. Post project. At this stage, the results are summed up and the effectiveness of the decisions made is evaluated, it is recommended to do this after 3-6 months in order to have a lot of information about the results of the project.
In 1995, Dr. Jeff Sutherland and Ken Schwaber presented a methodology called “Scrum” at the annual Practical Conference “Object-Oriented Programming, Systems, Languages and Applications” (OOPSLA) hosted by the Computer Science Association [8]. The approach was first described by scientists Hirotaka Takeuchi and Ikujiro Nonaka in 1986, as a flexible, holistic, product development strategy, where the development team works as a whole to achieve a common goal, in contrast to the traditional, consistent approach [9].
In accordance with the latest guidance, Scrum is positioned as a framework within which it is possible to solve complex adaptive problems and at the same time productively and creatively develop products of the highest quality. As stated in the official documentation, it shows the relative effectiveness of product management and development practices [10]. The approach is represented by three categories:
- command;
- activity;
- artifacts.
The team consists of the owner of the product, which is responsible for setting goals, the development team and the Scrum wizard, which is designed to ensure compliance with the Scrum methodology. Artifacts are internal terminology, and events are used in Scrum to create regularity and minimize the need for meetings not specified by Scrum, their list is as follows:
- sprint - an analogue of the timebox, from the DSDM methodology;
- sprint planning;
- daily Scrum rally - quarter-hour meetings to plan tasks for the day and discuss the results of the previous working day;
- sprint review - a discussion of the results achieved during the iteration and setting new tasks;
- sprint retrospective - a discussion of the quality of development processes following an iteration.
In 1997, the article "MESSY, EXCITING, AND ANXIETY-RIDDEN: ADAPTIVE SOFTWARE DEVELOPMENT" [11] by Jim Higgsmith, in which he describes the adaptive methodology of software development (Adaptive software development, abbreviated ASD). A key feature of this methodology is a new look at the relationship to requirements and the project, it implies the possibility of constant change, which is what it wants to adapt to. The prevailing classical project life cycle: planning-design-construction is modified here and is represented by the sequence: speculate-collaborate-learn.
In 1999, the book Extreme Programming Explained: Embrace Change [12] was published, describing an extreme programming methodology authored by Kent Beck, Ward Cunningham, and Martin Fowler. Extreme programming, like ASD, focuses on constantly changing requirements and offers 12 techniques that contribute to an efficient development process in such conditions:
- The game of planning (planning game) - the rapid creation of an approximate work plan and its constant updating;
- Small releases - frequent release of small versions of a product;
- Metaphor (metaphor) - a brief description of the system;
- Simple design (simple design) - in relation to architecture;
- Testing (testing) - it is worth noting that this methodology later became a separate development methodology called “Test Driving Development” (TDD);
- Processing (refactoring);
- Pair programming (pair programming) - simultaneous participation in the work on the task of two developers;
- Collective ownership of code (collective ownership);
- Continuous integration (continuous integration) - the frequent implementation of development;
- 40-hour week (40-hour week);
- Customer at the development site (on-site customer);
- Coding standards
In 2001, in the USA, Utah, the Agile Manifesto agile software development methodology manifest was signed. Agile is a family of development methodologies that includes extreme programming, SCRUM, DSDM, ASD, a little-known methodology Crystal, FDD, Pragmatic Programming and others. Agile defines 12 principles that you should adhere to [13]:
1. The highest priority for us is to meet customer needs, provided through the regular and early delivery of valuable software.
2. Changing requirements is welcome, even in the later stages of development. Agile processes enable you to leverage change to provide your customer with a competitive edge.
3. A working product should be released as often as possible, with a frequency of from a couple of weeks to a couple of months.
4. Throughout the project, developers and business representatives must work together daily.
5. Motivated professionals should work on the project. For the work to be done, create conditions, provide support and fully trust them.
6. Direct communication is the most practical and effective way to exchange information both with the team itself and within the team.
7. A working product is a key indicator of progress.
8. Investors, developers and users should be able to maintain a constant rhythm indefinitely. Agile helps to set up such a sustainable development process.
9. Continuous attention to technical excellence and design quality enhances project flexibility.
10. Simplicity - the art of minimizing unnecessary work - is essential.
11. The best requirements, architectural and technical solutions are born of self-organizing teams.
12. The team should systematically analyze possible ways to improve efficiency and adjust their work style accordingly.
In the same year 2001, IBM developed a development methodology called the Rational Unified Process (RUP) that describes how to leverage commercially proven approaches to software development. RUP provides team members with the guidelines, templates, and instructive tools needed for the entire team to take full advantage of the following practices:
- Design software iteratively;
- Manage requirements;
- Use component architecture;
- Visualize the program model;
- Check the quality of the program;
- Monitor program changes.
Fig. 2. RUP workflows
The core of the RUP are the following workflows, the intersection of which is shown in Figure 2. Among which are 6 engineering processes and 3 auxiliary processes:
- Business Modeling;
- Requirements
- Analysis and Design (Analysis & Design);
- Implementation
- Testing (Test);
- Deployment
- Project Management
- Configuration & Change;
- Management
- Environment
The latest innovations in the field of software development methodologies include the 37signals book “Getting Real” [14], published in 2006, which describes the methodology of the same name, which is entirely aimed at minimizing any bureaucratic costs, such as compiling specifications or staffing. In this development approach, it is recommended to start development with an interface design, then move on to the interface itself and, at the end, to programming. Thus, it is implied that as soon as possible release the minimum version of the product and develop it, which is most suitable for web projects.
Getting Real is offered primarily for use in small companies and teams, where various organizational obligations are not a necessary condition for survival and only burden the team. In general, this methodology meets or contributes to most of the principles described in extreme programming and the manifesto of flexible methodologies. In addition, the methodology covers such areas of knowledge as:
- Priority management;
- Communications management;
- Personnel Management;
- Pricing management;
- Promotion
- Support.
Conclusion
The main methodologies used in the management of information projects are considered, the stages of the life cycle of projects inherent in some of them, the fundamental principles and inherent priorities, as well as the strengths and main differences from previous methodologies are established.
In the field of development of information project management methodologies, the earliest were studied, among which were presented such as PERT, which, however, is a universal project management methodology, where time is a critical indicator, and was also used to organize the 1968 Winter Olympics. The iterative model of the project life cycle presented by Winston W. Royce is considered, such popular project methodologies as RAD, MSF, DSDM, Scrum, ASD, Extreme Programming, RUP are described. An overview of Agile agile development manifest principles and features of the latest 37signals Getting Real development methodology is presented.
Throughout the development of methodologies, one can observe changes in the prioritization from time-functional to time-resources. Moreover, the latest versions of methodologies imply a constant change in functional requirements. The greatest formalization of methodologies and processes was observed by the end of the first half of the 90s, after which light versions began to gain popularity.
List of references
1. Fazar W., Program Evaluation and Review Technique // The American Statistician, Vol. 13 (No. 2), 1959, p. 10.
2. Official report of the International Olympic Committee on the results of the Winter Olympic Games in Grenoble, 1968, p. 49
3. Taylor FW, The Principles of Scientific Management, New York, NY, USA and London, UK: Harper & Brothers, - LCCN 11010339, OCLC 233134.
4. Royce WW, Managing The Development Of Large Software Systems // Reprinted from Proceedings, IEEE WESCON, August 1970, pages 1-9. Copyright © 1970 by The Institute of Electrical and Electronics Engineers, Inc. Originally published by TRW.
5. Overview of Microsoft Solutions Framework (MSF) [Internet resource] / Microsoft Developer Network - Access mode: msdn.microsoft.com/en-us/library/jj161047.aspx(Date of treatment: 11/03/2014).
6. DSDM Atern Handbook [Internet resource] / DSDM Consortium - Access mode: www.dsdm.org/dig-deeper/book/dsdm-atern-handbook (accessed: 03.11.2014).
7. Shopyrin DG, Project management of software development: Training manual on discipline "Flexible software development technologies", St. Petersburg: St. Petersburg State University ITMO, 2007. - 131 p.
8. Sutherland JV, Business object design and implementation / Sutherland JV Schwaber K. // OOPSLA '95 Workshop Proceedings, The University of Michigan, 1995, - 118 p.
9. Takeuchi H., New New Product Development Game [Internet source] / Takeuchi H., Nonaka I. // Harvard Business Review, 1986 - Access mode: hbr.org/1986/01/the-new-new-product- development-game / ar / 1(Date of treatment: 11/03/2014).
10. A comprehensive guide to Scrum: Game Rules [Internet Source] / Scrum.org - Access mode: www.scrum.org/scrum-guide (accessed: 03.11.2014).
11. Highsmith JM, Exciting, And Anxiety-Ridden: Adaptive Software Development // American Programmer, Volume X (No. 1), 1997 - Electronic resource: www.adaptivesd.com/articles/messy.htm (accessed: 03.11.2014 )
12. Beck K., Extreme Programming Explained: Embrace Change. US: Addison-Wesley Professional, 2005 .-- 224 c. - ISBN-10: 0201616416
13. Fundamental Principles of the Agile Manifesto [Internet source] / Beck K., Beedle M., Arie van Bennekum, Cockburn A., Cunningham W., Fowler M., Grenning J., Highsmith J., Hunt A., Jeffries R ., Kern J., Marick B., C. Martin RC, Mellor S., Schwaber K., Sutherland J., Thomas D. - Access mode: agilemanifesto.org/iso/en/principles.html (accessed: 03.11 .2014).
14. Getting Real [Internet source] / 37signals, 2014 - Access mode: gettingreal.37signals.com (accessed: 03.11.2014).