Framework for Online Software Evolution: FOSE Abstract Business Application Software BAS malfunctions often during early stages of development and deployment. They are inevitable and unavoidable. They are costly and time consuming to fix. There are two kinds of errors that cause BAS malfunction, (1) Errors in Business Policies, Rules, Information and Data (2) Software Errors of BAS. It is here proposed that some means of quick and safe correction and relaunching process be built into software design and operation. There are two separate proposals for (1) and (2). The second is discussed here. ASIS (current) Process Map shows BAS running on its platform with its actors. The software development system (CI/CD Server) with BAS Developers is NOT connected to BAS or actors of BAS. The proposed Framework for Online Software Evolution FOSE is added to interconnect BAS Developer, CI/CD Server, and Platform of BAS online (while running). Business Actor of BAS initiates Software Correction Request and online Business Authority (specially added actor of BAS) approves it for transmission to FOSE. Approved Software Correction Requests flow from BAS to FOSE and FOSE to BAS Developer. The BAS Developer then identifies the affected parts of BAS that need correction and works on the source code of BAS available in CI/CD Server. Then he or she corrects parts of BAS and tests them to generate a corrected trial version of BAS. The corrected trial version of BAS is available to the end users of BAS for evaluation of how their requests have been processed and met. The corrected and tested parts of BAS are then released to the Platform of BAS. The framework FOSE is notified of this for updating the status of approved software correction requests maintained in FOSE. Then FOSE allows launch of the new version of BAS. Making end users initiate “software correction requests”, approving them and passing them through FOSE to online BAS Developers in a closed loop, are the key factors for software evolution. Thus, the BAS together with FOSE, becomes robust BAS continually. Here the software itself is Agile---not the software development. Incomplete software can safely be launched and run without frequent crashes. Unspecified user requirements get systemically captured from the business actors and met. ---III--- See examples and explanation in a separate word document

1. Framework for Online
Software Evolution FOSE
Putcha V. Narasimham
putchavn@yahoo.com
New Version
04AUG2022
1
©2022 All rights are reserved by Putcha V Narasimham

2. Contents of this proposal
1. Pre-requisites:
A. The BizApp Software BAS needs to be upgraded for “Online
Error Capture and Correction” (see the PPT)
B. The Software Development System of BAS has to be interfaced
with the Platform of BAS and brought online
2. The proposed FOSE is the framework that satisfies 1B
3. This PPT describes 1 and 2
4. The Glossary defines the concepts and models
CONFIDENTIAL
2

3. Upgrading BAS and Interfacing with it with FOSE
 Business Application
software BAS or BizApp has
to be miodfied for Online
Error Capture & Correction
 BAS and Proposed FOSE
need to be interfaced online
 See the two new services of
FOSE
CONFIDENTIAL
3
See notes of every slide for
more explanation
Upgraded
BAS
BizApp
Platform
1
1 Approved
Sw Ch Req
2 New BAS Release
2
Proposed
Framework
for Online
Software
Evolution
FOSE

4. Existing Isolation and Proposed Online Integration
 At present, the 1)
Development and 2 )
Opeartion of BizApp
Software, are isolated
 The Business Authorities
are NOT ONLINE with
BAS
 The twin proposals
 Upgrading BAS and
 Using the framework FOSE
 Seek to bring all stakeholders
online
 That ensures true integration of:
 Software development and
 Operations
CONFIDENTIAL 4

5. Stand-Alone Software Development System
 Application software like BAS is
developed on special software DevSys
 DevSys puts out Trial BAS executable
object code for launching on Platform
for testing, acceptance, integration,
deployment etc.
CONFIDENTIAL
5
SW DevSys
Developers
Platform
BAS-Code
BAS parts
Trial BAS
Testers, QA, User Reps, Business Executives,
collectively called Stakeholders
Test
Results
Tests
Acceptance

6. Software Development & Deployment Frameworks
 New services and users are added to SW
DevSys
 Platform and Trial BAS are parts of it
 Often called CI/CD pipeline
 Testers, QA, User Reps, Business
Executives are the Stakeholders
 See notes for many architectures
6
BAS
Developer
CONFIDENTIAL
Software
Dev Sys
BAS Corrections
New BAS
Code
Platform
Stakeholders
Tests & trials
BAS

7. ASIS Process Map: BAS and BAS Releases
BAS
Business
Actor 1
Business
Authority
CONFIDENTIAL
7
Modify Trial CS
Release
BAS Code
Informal bugs reports & change requests???
Evaluate Trial BAS
Software
Dev Sys
BAS
Developer
Stakeholders
Includes Trial BAS
and Platform
Platform

8. TOBE Process Map with upgraded BAS & FOSE
Upgraded
BAS
Business
Actor 1
Business
Authority
CONFIDENTIAL
8
Modify Trial BAS
Release
BAS Code
Evaluate Trial BAS
Software
Dev Sys
BAS
Developer
Stakeholders
Platform
FOSE
Approved
Sw Cor Req
Approved Sw Cor Req
Launch
BAS
FOSE corrects
the problem

9. FOSE UseCase (Service Dialog) Diagram
9
 SD1:
 FOSE accepts Approved Software
Correction Requests
 SD2:
 FOSE acknowledges that new version
of BAS is ready
 FOSE updates internal data and allows
the launch of new BAS on the Platform
 SD3:
 FOSE passes Approved SW Corr Req
1
2
3
Approved
Sw Correct
Req
BAS
Developer
Platform
Approved
Sw Correct
Req
BAS
release
Launch
BAS
FOSE
Service
Dialog 1
Service
Dialog 2
Service
Dialog 3

10. Approved Software Correction Request
When a user presses De-Automate button,
BAS presents a Dialog Box
Typical Dialog Screen
Approved Software Correction Request
If you wish to proceed fill-in the following: If not
1: Difficulty faced Describe with examples
2: Software Correction Describe with examples &
reasons
3: UX Improvements Describe with examples &
reasons
Cancel
Send
Cancel
CONFIDENTIAL
10
De-Automate
Default button on
every or screen
Attachments

11. Conclusion:
 Perfect software cannot be directly generated
 But imperfections can be quickly and safely detected, corrected
while the software is in use
 The framework FOSE enables online flow of software change
requests and release of BAS modifications by bringing them
ONLINE
 The improvement of the software actually occurs in CI/CD Server
 But CI/CD Server cannot do it by itself
 Minimal essential incomplete software can now be launched
safely
 The user triggers all change requests and FOSE responds
GO
CONFIDENTIAL
10

12. Glossary and
Corrected Process & UseCase Modelling
CONFIDENTIAL 11

13. Glossary:
Framework, Online and Evolution
 framework: Support software
which hosts BizApp Software
(CS) to operate in a monitored
and controlled environment so
that it (BAS) is amenable for
evolution.
 Online Software: Software in
operation
 evolution: correction,
improvement,
enhancement,
additional functionality
and capability, higher
efficiency, higher
effectiveness,
simplification etc.
CONFIDENTIAL
12

14. New Process Element: Dialog or Conversation
 Dialog is a sequence of messages
between one entity and another
 It has a name and goal
 Dialog is an expressive element for
process modelling
 UML UseCase is actually a dialog; a
Service Dialog; this is not recognized
Entity X
Entity 2
CONFIDENTAL
13
N
Dialog
Entity 1
equivalent
Conversation
of BPMN 2.0

15. Erroneous UML UseCase Model
 UseCase model: Conceptually very
apt, effective, comprehensive and
useful
 However UML spec v 2.5 is too lax,
imprecise and misleading
 Fails to identify the exact nature of
UseCase
 So, it is corrected and used here
System under
Consideration
SuC
Business
Actor 1
Business
Actor N
UC 1
UC N
What is wrong and why? What is the correction?
See: https://www.slideshare.net/putchavn/errors-corrections-of-use-case-modeling
CONFIDENTIAL
14
Erroneous UseCase Model

16. What Exactly is UseCase?
 It is variously mistaken as
 a part of the system,
 a sub-system,
 an object,
 a process,
 a goal etc.,
 It is none of them
 Then, what is it?
 Where does it exist?
System under
Consideration
SuC
CONFIDENTIAL
15
UC
UC
UC
Business
Actor 1
Business
Actor N
What is the right
place of a UC?
Is it a path for data flow?
Or an association

17. UseCase is a Dialog or Conversation
 In 2008, it was identified as a “Dialog of
Messages” leading to a service
goal…Putcha V. Narasimham
 In 2011 BPMN discovered a need for new
element of a process: Conversation
 The UML specification has NOT accepted
UseCase to be a Dialog or Conversation
which it is exactly
System under
Consideration
SuC
Business
Actor 1
Business
Actor N
CONFIDENTIAL
16
1
2
N
Service Dialog

18. Goal of Dialog or Conversation
 A dialog or conversation must have
a goal
 The goal may have multiple
conditional end results
 A log-in conversation
 Enables authentic users to access the
system and
 Block others
System under
Consideration
SuC
Business
Actor 1
Business
Actor N
CONFIDENTIAL
17
1
2
N
Goal 1
Goal 2
Goal N

19. Service Goal, Service Dialog and Associations
 Each Service Dialog has specific Service
Goal
 The same actor can have two service
dialogs 1 and 2 with SuC for different
service goals
 Different actors may have the same
service dialog to reach the same goal (Eg.
login)
 X and Y don’t communicate directly
SuC
Business
Actor 1
Business
Actor Y
CONFIDENTIAL
18
1
N
Service Dialog
2
Business
Actor X

20. A Dialog can only be between TWO entities
 A third entity may listen to a
dialog but NOT participate in it
 A dialog is at times shown with
multiple entities
 A and B are equivalent
 In B it is implied X has the same
kind of dialog with SuC as Y has
with SuC; better avoided
SuC
Business
Actor Y
CONFIDENTIAL
19
1
GO
Business
Actor X
Business
Actor Y
Business
Actor X
1
1 SuC
Equivalent
A
B