IEEE DIS 24748-2-2017 pdf download

IEEE DIS 24748-2-2017 pdf download.Systems and software engineering一Life cycle management一-Part 2: Guidelines to the application of ISO/IEC/IEEE 15288(System life cycle processes).
Bringing all the stakeholders together in this effort is critical: even one area left out that should have been in the planning can materially disrupt applying the new basis. One way of proceeding is for a small group to develop a checklist of things that must be considered in applying ISO/IEC/IEEE 15288:2015. This may include, and possibly will not be limited to:
a) documentation changes, including flow and nomenclature;
b) staff training needs;
c) responsibility changes, including need for new agreements;
d) impacts on tools and databases;
e) changes in the inputs required by and outputs from each process.
The initial checklist should be then be used by an immediately subsequent, larger, group of all stakeholders to work through what other items need to be added and what the specific changes are for each item on the checklist. Repeated reviews of checklist drafts should be held to find the final few surprises.
Once there is a detailed listing of the changes derived in this, or equivalent, manner, the time and cost impacts of each need to be assessed and adjusted for the risks of each change and various groupings of change. Then further analysis of the sequence of implementing the changes is necessary. The group should explore phasing in changes in a way that minimizes cost, project disruption and the potential for adverse human reactions. Readiness criteria should be developed for starting each step of a phase-in, as well as checks for successful completion after each step of phasing in the changes. Quantitative metrics should be developed and used.
Throughout, a core group should be maintained to oversee the change from one basis to another, with periodic meetings of the entire group of stakeholders.
When a project or organization is already in a steady state, i.e. where the processes have been established and institutionalized, then the implementation strategy could be shortened and would probably include the following:
a) plan the application;
b) adapt ISO/lEG/IEEE 15288:2015, it applicable (for the risk level of the work);
c) conduct the project(s).
5.2.2 Planning the application
Applying lSO/IEC/IEEE 15288:2015 should be considered as a specific project and planned as such. The following are examples of items to consider while planning the application project:
a) define the scope of the project. Possibilities include:
1) a single project either internal to an organization or as part of a two party contract;
2) concentration on some key processes or even a single process where there is expected to be some gain for an organization. This approach could be used where a weakness has been detected previously and could lead to a full application of ISO/IEC/IEEE 15288:2015 at some future point. Conversely, the approach could be of benefit where significant process refinements or additions have been made, so that in depth revisions of a single process will be necessary;
3) adoption of lSO/IEC/IEEE 15288:2015 across a range of projects with probably a staged introduction. Here the organization would probably have no or few defined processes and would be standardizing on ISOIIEC/IEEE 15288:2015;
4) adoption of ISO/lEG/IEEE 15288:2015 across all projects and within all parts of the organization. It is unlikely that any organization except a very small one would take this approach. It would be relevant though for a new subsidiary of an existing organization that has adopted ISO/IEC/IEEE 15288 into working practice previously.
b) identify the project goals and determine how they fit into the organization-wide business goals. If no obvious link is established between this project and the organization’s business focus, then lasting commitment to achieve the application project goals will be difficult if not impossible to maintain;
c) identify roles and responsibilities of the project team/organization, assigning a single point of responsibility for each process. In many cases, one individual or organization may be responsible for more than one process, particularly in small projects or organizations.