Information Project Management Methodologies
Preface: The purpose of this publication is to get feedback and collect criticism of an 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 for managing information projects.
In 1958, consulting company Booz Allen Hamilton Inc., in conjunction with the development center of Lockheed Martin Space Systems and the software development division of the special design center of the US Navy, developed a program for evaluating and analyzing programs (projects) of the Program Evaluation and Review Technique under the code name PERT - for the Polaris submarine armament system development project [1] (ballistic missiles).
PERT was designed to save time when managing large projects, in which time is a critical indicator. The methodology involves the analysis of individual tasks in terms of their impact on the completion of the entire project, in particular, analyzes the time to complete each task, as a result of which the minimum required time to complete all stages is determined. This technique can be applied in conditions of uncertainty, when the details of each stage and the exact time for their execution 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 also the first of its kind reviving the “Scientific Labor Organization” approach [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 PERT Methodology
The events themselves do not have the time and resources, they only mean the beginning of a new stage of activity, but for the activities the necessary resources and characteristics of time are determined, such as: minimum, maximum, normal and expected time. It also calculates the time of slipping or sagging - the time difference in relation to other activities, showing how much this activity is ahead of or behind the execution 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 for its optimization the “fast pass” method can be applied, which may consist in parallelizing the activities that lie on the critical path.
In 1970, Dr. Winston W. Royce published Managing the Development of Large Software Systems [4] (managing the development of large software applications), in which he describes development techniques that will later be known as the “cascade development model” , also “waterflow” or “waterfall”. The original model assumes the following sequence of development stages:
Initially, a sequential transition from one stage to another was assumed, but here Winston considers the situation when, after the transition to the next step, the shortcomings of the previous one can be revealed, and proposes a model where you can return to the previous stage to refine it. Further, it develops it to the point that in the future it will be known as an “iterative model of development” - it consists of the same stages as the cascade one, but it assumes a transition from the testing stage to the stage of determining software requirements.
In 1991, James Martin's Rapid Application Development (RAD) is published, which describes the concept of rapid software development using prototyping with minimal planning. Among other things, this methodology is distinguished by prioritization: if the cascade model is repelled from the functional, then the emphasis is on on time and resources spent. Thus, if the development of a non-critical part of the functionality does not fit into the deadlines, RAD implies the rejection of this functionality. RAD includes the following development stages:
In 1993, Microsoft released the Microsoft Solutions Framework (MSF 1.0), as a set of discipline models, concepts and principles for creating information technology solutions. MSF focuses 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 recommendations, here are some of them: promotion of communications; maximum open information about the project within the team; empowering team members with authority, responsibility and accountability. The ways of thinking include the following: “take care of a team of supporters” or “continuous learning”.
The MSF team model considers the steps corresponding to the development model described in the cascade model from the perspective of their inherent goals and functional areas in order to effectively assign roles to the team. The management model is designed to provide the right landmarks to the right people at the right time and recommends controlling resources and priorities at each of the development stages. Among other things, in MSF there is such a thing as “control points”, the concept of which resembles events from the PERT network diagram, viewed from the perspective of MSF core values.
In 1994, a consortium of 17 British companies, based on the concept of rapid development of RAD applications, created a framework (from the English. "Framework" - framework) software development "Dynamic Systems Development Method" (DSDM). The framework is a set of principles, predefined role types and the following techniques [6]:
The timebox technique is the main DSDM technique used to complete the project on time, meet the budget and maintain quality. Timebox is an iteration in which the project is divided into logical sections, separated in time. Timeboxes are not divided into events, and the functionality is not critical, as a result of which it can be partially excluded in order to save time, in the order determined by the prioritization method “MoSCoW”. The prioritization method “MoSCoW” defines 4 levels of priorities:
Methods of building prototypes imply the development of functional, productive and other models at various stages of work on a project, which makes it possible to identify the difficulties that will be faced, to evaluate performance, user-friendly interface and functionality, including from a commercial point of view.
DSDM pays special attention to the participation in the development process of the user (consumer), which is enshrined in the principles that are an integral part of the framework [7]:
As stated 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 feasibility of the project is determined and, among other things, it is allowed to issue an act of initiating the project.
2. Feasibility. At this stage, the feasibility of the project, including the ability to effectively achieve business goals, is determined.
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 studies addressing non-functional requirements (for example, performance, security, support and maintenance capabilities). Including the implementation of all requirements for the successful operation of the product.
6. Deployment - involves a cycle of work to provide the product to the end user, training and writing documentation. It also identifies whether the product meets all established business requirements.
7. Post-project. At this stage, the results are summarized and the effectiveness of the decisions made is evaluated, it is recommended to do this after 3-6 months in order to have a large amount of information about the project's performance.
In 1995, at the annual practical conference "Object-Oriented Programming, Systems, Languages ​​and Applications" (OOPSLA) conducted by the "Association of Computing Techniques" Dr. Jeff Sutherland and Ken Schwaber presented a methodology called "Scrum" [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 one unit to achieve a common goal, as opposed to the traditional, consistent approach [9].
In accordance with the latest leadership, 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 presented in three categories:
The team consists of the owner of the product, who is responsible for setting the tasks, the development team and the Scrum Wizard, which is designed to ensure compliance with the Scrum methodology. Artifacts are internal terminology, and events in Scrum are used to create regularity and minimize the need for meetings not specified by Scrum, a list of which is as follows:
In 1997, the article “MESSY, EXCITING, AND ANXIETY-RIDDEN: ADAPTIVE SOFTWARE DEVELOPMENT” [11] Jim Higsmith, in which he describes the adaptive software development methodology (ASD), is published. A key feature of this methodology is a new look at attitudes to requirements and the project, implying the possibility of their constant change, to which it and to strive to adapt. The prevailing classic project life cycle: planning, design, and design are modified and represented here by the sequence: speculate-collaborate-learn.
In 1999 he published the book Extreme Programming Explained: Embrace Change [12], which describes the methodology of extreme programming, the authors of which are Kent Beck, Ward Cunningham and Martin Fowler. Extreme programming, like ASD, is focused on constantly changing requirements and offers 12 techniques that contribute to an effective development process in such conditions:
In 2001, in the USA, Utah, the Agile Manifesto software development methodology manifest was signed. Agile is a family of development methodologies that include: extreme programming, SCRUM, DSDM, ASD, little-known Crystal, FDD, Pragmatic methodology Programming and others. Agile defines 12 principles that should be followed [13]:
1. Our highest priority is customer satisfaction, provided through regular and early delivery of valuable software.
2. Changing requirements is welcome, even in the later stages of development. Agile processes allow changes to be used to provide a competitive advantage to a customer.
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 should work together every day.
5. Motivated professionals should work on the project. To get the job done, create the conditions, provide support and trust them completely.
6. Direct communication is the most practical and effective way to exchange information both with the team and within the team.
7. A working product is the main indicator of progress.
8. Investors, developers and users should be able to maintain a constant rhythm indefinitely. Agile helps to build such a sustainable development process.
9. Constant attention to technical excellence and design quality increases project flexibility.
10. Simplicity - the art of minimizing unnecessary work - is essential.
11. The best requirements, architectural and technical solutions are born from self-organizing teams.
12. The team should systematically analyze possible ways to improve efficiency and adjust the style of their work accordingly.
In the same year 2001, IBM developed a development methodology called the Rational Unified Process (RUP), which describes how to effectively use commercially proven approaches to software development. RUP provides team members with the guidelines, templates, and instrumental instructions needed for the entire team to take full advantage of the following practices:
Fig. 2. RUP Workflows
The RUP core consists of the following workflows, the intersection of which is shown in Figure 2., among which there 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 drawing up a specification or staffing table. In this approach to development, it is recommended to begin development with an interface design, then move on to the interface itself, and at the end to programming. Thus, it is assumed in the shortest possible time to 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 complies, or contributes to most of the principles described in extreme programming and manifest flexible methodologies. In addition, the methodology involves areas such 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 underlying principles and proper priorities, as well as the strengths and main differences from the previous methodologies are established.
In the field of development of information project management methodologies, the earliest were studied, among which are such as PERT, which, however, is a universal project management methodology, where time is a critical indicator, and was used, among other things, for the organization of the 1968 winter olympic games. The iterative model of the project life cycle presented by Winston W. Royce is considered, such popular methodologies as RAD, MSF, DSDM, Scram, ASD, Extreme Programming, RUP are described. An overview of Agile's agile development manifest principles and the features of the latest 37signals Getting Real design methodology is presented.
During the development of methodologies, one can observe changes in the prioritization from time-functional to time-resources. Moreover, the latest versions of the 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 the Microsoft Solutions Framework (MSF) [Internet resource] / Microsoft Developer Network - Access Mode: msdn.microsoft.com/ru-ru/library/jj161047.aspx (access date: 03.11.2014).
6. DSDM Atern Handbook [Internet resource] / DSDM Consortium - Access Mode: www.dsdm.org/dig-deeper/book/dsdm-atern-handbook (access date: 03.11.2014).
7. Shopyrin DG, Software Development Project Management: Teaching Tool for the Flexible Software Development Technologies discipline, St. Petersburg: ITMO St. Petersburg State University, 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 (appeal date: 11/03/2014).
10. Comprehensive guide to Scrum: Rules of the Game [Internet Source] / Scrum.org - Access mode: www.scrum.org/scrum-guide (access date: 03.11.2014).
11. Highsmith JM, Exciting, And Anxiety-Ridden: Adaptive Software Development // American Programmer, Volume X (# 1), 1997 - Electronic resource: www.adaptivesd.com/articles/messy.htm (appeal date: 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 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/ru/principles.html (access date: 03.11 .2014).
14. Getting Real [Internet source] / 37signals, 2014 - Access mode: gettingreal.37signals.com (appeal date: 03.11.2014).
In 1958, consulting company Booz Allen Hamilton Inc., in conjunction with the development center of Lockheed Martin Space Systems and the software development division of the special design center of the US Navy, developed a program for evaluating and analyzing programs (projects) of the Program Evaluation and Review Technique under the code name PERT - for the Polaris submarine armament system development project [1] (ballistic missiles).
PERT was designed to save time when managing large projects, in which time is a critical indicator. The methodology involves the analysis of individual tasks in terms of their impact on the completion of the entire project, in particular, analyzes the time to complete each task, as a result of which the minimum required time to complete all stages is determined. This technique can be applied in conditions of uncertainty, when the details of each stage and the exact time for their execution 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 also the first of its kind reviving the “Scientific Labor Organization” approach [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 PERT Methodology
The events themselves do not have the time and resources, they only mean the beginning of a new stage of activity, but for the activities the necessary resources and characteristics of time are determined, such as: minimum, maximum, normal and expected time. It also calculates the time of slipping or sagging - the time difference in relation to other activities, showing how much this activity is ahead of or behind the execution 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 for its optimization the “fast pass” method can be applied, which may consist in parallelizing the activities that lie on the critical path.
In 1970, Dr. Winston W. Royce published Managing the Development of Large Software Systems [4] (managing the development of large software applications), in which he describes development techniques that will later be known as the “cascade development model” , also “waterflow” or “waterfall”. The original model assumes the following sequence of development stages:
- definition of system requirements;
- definition of software requirements;
- analysis;
- design;
- development;
- testing;
- exploitation.
Initially, a sequential transition from one stage to another was assumed, but here Winston considers the situation when, after the transition to the next step, the shortcomings of the previous one can be revealed, and proposes a model where you can return to the previous stage to refine it. Further, it develops it to the point that in the future it will be known as an “iterative model of development” - it consists of the same stages as the cascade one, but it assumes a transition from the testing stage to the stage of determining software requirements.
In 1991, James Martin's Rapid Application Development (RAD) is published, which describes the concept of rapid software development using prototyping with minimal planning. Among other things, this methodology is distinguished by prioritization: if the cascade model is repelled from the functional, then the emphasis is on on time and resources spent. Thus, if the development of a non-critical part of the functionality does not fit into the deadlines, RAD implies the rejection of this functionality. RAD includes the following development stages:
- planning - requirements are determined;
- user design - the definition of the functional;
- design - development;
- switching - implementation;
In 1993, Microsoft released the Microsoft Solutions Framework (MSF 1.0), as a set of discipline models, concepts and principles for creating information technology solutions. MSF focuses on the following values ​​[5]:
- compliance with technical and commercial goals;
- setting clear goals, assigning roles and responsibilities;
- 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 recommendations, here are some of them: promotion of communications; maximum open information about the project within the team; empowering team members with authority, responsibility and accountability. The ways of thinking include the following: “take care of a team of supporters” or “continuous learning”.
The MSF team model considers the steps corresponding to the development model described in the cascade model from the perspective of their inherent goals and functional areas in order to effectively assign roles to the team. The management model is designed to provide the right landmarks to the right people at the right time and recommends controlling resources and priorities at each of the development stages. Among other things, in MSF there is such a thing as “control points”, the concept of which resembles events from the PERT network diagram, viewed from the perspective of MSF core values.
In 1994, a consortium of 17 British companies, based on the concept of rapid development of RAD applications, created a framework (from the English. "Framework" - framework) software development "Dynamic Systems Development Method" (DSDM). The framework is a set of principles, predefined role types and the following techniques [6]:
- timebox
- the principle of prioritization "MoSCoW",
- seminars,
- prototyping.
The timebox technique is the main DSDM technique used to complete the project on time, meet the budget and maintain quality. Timebox is an iteration in which the project is divided into logical sections, separated in time. Timeboxes are not divided into events, and the functionality is not critical, as a result of which it can be partially excluded in order to save time, in the order determined by the prioritization method “MoSCoW”. The prioritization method “MoSCoW” defines 4 levels of priorities:
- must have
- should be (should have)
- need (could have) and
- can (want have).
Methods of building prototypes imply the development of functional, productive and other models at various stages of work on a project, which makes it possible to identify the difficulties that will be faced, to evaluate performance, user-friendly interface and functionality, including from a commercial point of view.
DSDM pays special attention to the participation in the development process of the user (consumer), 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 stated 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 - responsible for recording;
- mediator - responsible for 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 feasibility of the project is determined and, among other things, it is allowed to issue an act of initiating the project.
2. Feasibility. At this stage, the feasibility of the project, including the ability to effectively achieve business goals, is determined.
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 studies addressing non-functional requirements (for example, performance, security, support and maintenance capabilities). Including the implementation of all requirements for the successful operation of the product.
6. Deployment - involves a cycle of work to provide the product to the end user, training and writing documentation. It also identifies whether the product meets all established business requirements.
7. Post-project. At this stage, the results are summarized and the effectiveness of the decisions made is evaluated, it is recommended to do this after 3-6 months in order to have a large amount of information about the project's performance.
In 1995, at the annual practical conference "Object-Oriented Programming, Systems, Languages ​​and Applications" (OOPSLA) conducted by the "Association of Computing Techniques" Dr. Jeff Sutherland and Ken Schwaber presented a methodology called "Scrum" [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 one unit to achieve a common goal, as opposed to the traditional, consistent approach [9].
In accordance with the latest leadership, 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 presented in three categories:
- team;
- activity;
- artifacts.
The team consists of the owner of the product, who is responsible for setting the tasks, the development team and the Scrum Wizard, which is designed to ensure compliance with the Scrum methodology. Artifacts are internal terminology, and events in Scrum are used to create regularity and minimize the need for meetings not specified by Scrum, a list of which is as follows:
- sprint - analogue of the timebox, from the DSDM methodology;
- sprint planning;
- Daily Scrum Rally - a quarter-hour meeting, with the goal of scheduling tasks for the day and discussing the results of the previous working day;
- Sprint review - discussion of the results achieved by the results of the iteration and setting new tasks;
- Sprint retrospective - a discussion of the quality of the development processes following the iteration.
In 1997, the article “MESSY, EXCITING, AND ANXIETY-RIDDEN: ADAPTIVE SOFTWARE DEVELOPMENT” [11] Jim Higsmith, in which he describes the adaptive software development methodology (ASD), is published. A key feature of this methodology is a new look at attitudes to requirements and the project, implying the possibility of their constant change, to which it and to strive to adapt. The prevailing classic project life cycle: planning, design, and design are modified and represented here by the sequence: speculate-collaborate-learn.
In 1999 he published the book Extreme Programming Explained: Embrace Change [12], which describes the methodology of extreme programming, the authors of which are Kent Beck, Ward Cunningham and Martin Fowler. Extreme programming, like ASD, is focused on constantly changing requirements and offers 12 techniques that contribute to an effective development process in such conditions:
- Planning game - quick creation of an approximate work plan and its constant updating;
- Small releases (small releases) - the frequent release of small versions of the product;
- Metaphor (metaphor) - a brief description of the system;
- Simple design (simple design) - applied to the architecture;
- Testing (testing) - it is worth noting that this technique was later singled out in a separate development methodology called “Test Driving Development” (TDD);
- Processing (refactoring);
- Pair programming - simultaneous participation in the work on the task of two developers;
- Collective ownership of the code (collective ownership);
- Continuous integration (continuous integration) - frequent implementation of development;
- 40-hour week (40-hour week);
- On-site customer;
- Coding standards.
In 2001, in the USA, Utah, the Agile Manifesto software development methodology manifest was signed. Agile is a family of development methodologies that include: extreme programming, SCRUM, DSDM, ASD, little-known Crystal, FDD, Pragmatic methodology Programming and others. Agile defines 12 principles that should be followed [13]:
1. Our highest priority is customer satisfaction, provided through regular and early delivery of valuable software.
2. Changing requirements is welcome, even in the later stages of development. Agile processes allow changes to be used to provide a competitive advantage to a customer.
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 should work together every day.
5. Motivated professionals should work on the project. To get the job done, create the conditions, provide support and trust them completely.
6. Direct communication is the most practical and effective way to exchange information both with the team and within the team.
7. A working product is the main indicator of progress.
8. Investors, developers and users should be able to maintain a constant rhythm indefinitely. Agile helps to build such a sustainable development process.
9. Constant attention to technical excellence and design quality increases project flexibility.
10. Simplicity - the art of minimizing unnecessary work - is essential.
11. The best requirements, architectural and technical solutions are born from self-organizing teams.
12. The team should systematically analyze possible ways to improve efficiency and adjust the style of their work accordingly.
In the same year 2001, IBM developed a development methodology called the Rational Unified Process (RUP), which describes how to effectively use commercially proven approaches to software development. RUP provides team members with the guidelines, templates, and instrumental instructions needed for the entire team to take full advantage of the following practices:
- Develop 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 RUP core consists of the following workflows, the intersection of which is shown in Figure 2., among which there are 6 engineering processes and 3 auxiliary processes:
- Business Modeling (Business Modeling);
- Requirements;
- Analysis and Design (Analysis & Design);
- Implementation;
- Testing;
- Deployment;
- Project Management;
- Configuration and Change (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 drawing up a specification or staffing table. In this approach to development, it is recommended to begin development with an interface design, then move on to the interface itself, and at the end to programming. Thus, it is assumed in the shortest possible time to 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 complies, or contributes to most of the principles described in extreme programming and manifest flexible methodologies. In addition, the methodology involves areas such 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 underlying principles and proper priorities, as well as the strengths and main differences from the previous methodologies are established.
In the field of development of information project management methodologies, the earliest were studied, among which are such as PERT, which, however, is a universal project management methodology, where time is a critical indicator, and was used, among other things, for the organization of the 1968 winter olympic games. The iterative model of the project life cycle presented by Winston W. Royce is considered, such popular methodologies as RAD, MSF, DSDM, Scram, ASD, Extreme Programming, RUP are described. An overview of Agile's agile development manifest principles and the features of the latest 37signals Getting Real design methodology is presented.
During the development of methodologies, one can observe changes in the prioritization from time-functional to time-resources. Moreover, the latest versions of the 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.
Bibliography
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 the Microsoft Solutions Framework (MSF) [Internet resource] / Microsoft Developer Network - Access Mode: msdn.microsoft.com/ru-ru/library/jj161047.aspx (access date: 03.11.2014).
6. DSDM Atern Handbook [Internet resource] / DSDM Consortium - Access Mode: www.dsdm.org/dig-deeper/book/dsdm-atern-handbook (access date: 03.11.2014).
7. Shopyrin DG, Software Development Project Management: Teaching Tool for the Flexible Software Development Technologies discipline, St. Petersburg: ITMO St. Petersburg State University, 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 (appeal date: 11/03/2014).
10. Comprehensive guide to Scrum: Rules of the Game [Internet Source] / Scrum.org - Access mode: www.scrum.org/scrum-guide (access date: 03.11.2014).
11. Highsmith JM, Exciting, And Anxiety-Ridden: Adaptive Software Development // American Programmer, Volume X (# 1), 1997 - Electronic resource: www.adaptivesd.com/articles/messy.htm (appeal date: 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 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/ru/principles.html (access date: 03.11 .2014).
14. Getting Real [Internet source] / 37signals, 2014 - Access mode: gettingreal.37signals.com (appeal date: 03.11.2014).
Source: https://habr.com/ru/post/244003/
All Articles