Continuous Schemes for Program Evolution

Understanding microarray data through applying competent program evolution

Proceedings of the 9th annual conference on Genetic and evolutionary computation - GECCO '07 ◽

10.1145/1276958.1277050 ◽

2007 ◽

Author(s):

Moshe Looks ◽

Ben Goertzel ◽

Lucio de Souza Coelho ◽

Mauricio Mudado ◽

Cassio Pennachin

Keyword(s):

Microarray Data ◽

Program Evolution

Download Full-text

The nuclear electromagnetic pulse program: Evolution and impact on technology

10.1109/aps.1982.1148894 ◽

2005 ◽

Author(s):

J. Castillo

Keyword(s):

Electromagnetic Pulse ◽

Program Evolution

Download Full-text

On the Relationship between Program Evolution and Fault-Proneness: An Empirical Study

2013 17th European Conference on Software Maintenance and Reengineering ◽

10.1109/csmr.2013.12 ◽

2013 ◽

Cited By ~ 2

Author(s):

F. Jaafar ◽

S. Hassaine ◽

Y. Gueheneuc ◽

S. Hamel ◽

B. Adams

Keyword(s):

Empirical Study ◽

Program Evolution ◽

The Relationship ◽

Fault Proneness

Download Full-text

Self-Verification Program in bp: Success Story of Major Accident Risk Management via Bowtie Barrier Model

SPE Drilling & Completion ◽

10.2118/204132-pa ◽

2021 ◽

pp. 1-13

Author(s):

Roman Bulgachev ◽

Michael Cromarty ◽

Lee Milburn ◽

Kevan Davies

Keyword(s):

Risk Management ◽

Risk Function ◽

Lessons Learned ◽

Management Tool ◽

Accident Risk ◽

Component Level ◽

Holistic View ◽

Operational Risks ◽

Program Evolution ◽

Major Accident

Summary bp’s (“the company’s”) wells organization manages its operational risks through what is known as the “three lines of defense” model. This is a three-tiered approach; the first line of defense is self-verification, which wells assets apply to prevent or mitigate operational risks. The second line of defense is conducted by the safety and operational risk function using deep technical expertise. The third line of defense is provided by group audit. In this paper, we discuss the wells self-verification program evolution from its first implementation and share case studies, results, impact, lessons learned, and further steps planned as part of the continuous improvement cycle. The company’s wells organization identified nine major accident risks that have the potential to result in significant health, safety, and environment (HSE) impacts. Examples include loss of well control (LoWC), offshore vessel collision, and dropped objects. The central risk team developed bowties for these risks, with prevention barriers on cause legs and mitigation barriers on consequence legs. Detailed risk bowties are fundamental to wells self-verification, adding technical depth to allow more focused verification to be performed when compared with the original bowties, because verification is now conducted using checklists targeting barriers at their component level, defined as critical tasks and equipment. Barriers are underpinned by barrier enablers (underlying supporting systems and processes) such as control of work, safe operating limits, inspection and maintenance, etc. Checklists are standardized and are available through a single, global digital application. This permits the verifiers, typically wellsite leaders, to conduct meaningful verification conversations, record the resulting actions, track them to closure within the application, and gain a better understanding of any cumulative impacts, ineffective barriers, and areas to focus on. Self-verification results are reviewed at rig, region, wells, and upstream levels. Rigs and regions analyze barrier effectiveness and gaps and implement corrective actions with contractors at the rig or region level. Global insights are collated monthly and presented centrally to wells leadership. Common themes and valuable learnings are then addressed at the functional level, shared across the organization, or escalated by the leadership. The self-verification program at the barrier component level proved to be an effective risk management tool for the company’s wells organization. It helps to continuously identify risks, address gaps, and learn from them. Recorded assessments not only provide the wells organization with barrier performance data but also highlight opportunities to improve. Leadership uses the results from barrier verification to gain a holistic view of how major accident risks are managed. Program evolution has also eliminated duplicate reviews, improved clarity of barrier components, and improved sustainability through applying a systematic approach, standardization, digitization, and procedural discipline.

Download Full-text

Software Modernization of Legacy Systems for Web Services Interoperability

Encyclopedia of Internet Technologies and Applications ◽

10.4018/978-1-59140-993-9.ch078 ◽

2008 ◽

pp. 551-557 ◽

Cited By ~ 1

Author(s):

Chia-Chu Chiang

Keyword(s):

Web Services ◽

Operating Systems ◽

Software Maintenance ◽

Legacy Systems ◽

Doing Business ◽

Program Evolution ◽

Software Modernization ◽

Business Requirements

Software maintenance is an inevitable process due to program evolution (Lehman & Belady, 1985). Adaptive maintenance (Schenidewind, 1987) is an activity used to adapt software to new environments or new requirements due to the evolving needs of new platforms, new operating systems, new software, and evolving business requirements. For example, companies have been adapting their legacy systems to Web-enabling environments of doing business that could not have been imagined even a decade ago (Khosrow-Pour & Herman, 2001; Werthner & Ricci, 2004).

Download Full-text