iREM AND AGILE IMPLEMENTATION

iREM is an iterative approach of SaaS RE for the agile implementation. It facilitates the discovery of services by mapping business process to services for the agile implementation in small iterations:

A business process (BP) is identified as an input (e.g. marked in bold and red color in Figure 2) from a pool or repository of business processes that need to be implemented in terms of software services in the agile iteration X (depending on situational circumstances, a large business process may span multiple iterations or a small number of business processes may fit in one iteration).

The identified business process (BP) is linked or mapped to a single or set of business use cases (BUC), which are identified and stored in the business use case backlog for the iteration X.

Each identified business use case (BUC) is linked or mapped to a single or set of system use cases (SUC), which are identified and stored in the system use case backlog for the iteration X.

Each identified system use case (SUC) is linked or mapped to a single or set of test cases (TC), which are identified and stored in the test case backlog for the iteration X. At this stage, the system use case backlog integrated with the test case backlog is released for the iteration X implementation by using agile practices.

Each identified system use case (SUC) is linked or mapped to a single or set of agile practices (within their overall generic process lifecycle), which is called integrated system requirement or system use case (please see Section above for details).

Each integrated system use case is linked or mapped to a software service (integrated SaaS requirements, which are stored in the product service backlog (e.g. marked in bold and green color in Figure 2) for the iteration X.

The business analyst and quality analyst start the next iteration X + 1 for identifying the BP and attached BUC, SUC and TC. The development team starts working on the implementation of services listed in the product service backlog for the iteration X as per their priority. If the requirements are changed during the iteration X implementation then those changes (if minor) can be considered in the current iteration X or next iteration X+n (where n= 1, 2, 3…). In the end of an iteration X, the iteration X retrospective is conducted to review the agile process (e.g. which services have been implemented by using which agile practices), and identify any issues (e.g. missed requirements, less than 50% unit test coverage) and their root-causes (e.g. continuous integration was not performed for SUC of service 1, code view review and user viewing sessions were not conducted) and then finally, the iteration X is released for further integration and user acceptance testing. Here, at this stage, the system use case backlog integrated with test case backlog for the next iteration X+1 may be released to development team by the business and quality analysts for implementation. The development team starts a work on the Iteration X+1 and also provides support for fixing any defects in the previous iteration X.

Here, we may observe how iREM supports the iterative discovery of SaaS requirements and their agile implementation. It can also be observed that there can be one or more active iterations at a given point of time (business and quality analyst working on the iteration X+1 while the development team is working on iteration X).