Decision support systems, group decision support systems,expert systems-manag...clincy cleetus
concept of decision making,decision making process-intelligence phase-design phase-choice phase,types of decisions,meaning and definition of decision support systems(dss),evolution of dss,characteristics of dss,decision support and repetitiveness of decisions,objectives and importance of dss,classification of dss,components of dss,functions of dss,development of dss,support for different phases of decision making,benefits and risk of dss,group decision support systems, gdss software, gdss benefits and risks,expert systems,difference between dss and es, comparison between dss and es
Continuity planners follow a methodology which elicits recovery requirements (RTO, RPO) from stakeholders and seeks to build capacity to meet those requirements. However, all disasters are not created equal and the reality is that most businesses, while able to meet those requirements for some scenarios, simply cannot meet them for more disruptive scenarios. Scenario-based Recovery Metrics give continuity planners a method to measure their ability to recover for a range of scenarios, from simpler to more complex. This facilitates measurement of deficits relative to the stakeholder's requirements for a range of scenarios. Furthermore, this method gives opportunity for continuity planners to dialogue with stakeholders and explain that 'we can meet your requirements for this set of simpler scenarios, however with our current recovery capacity we are unable to meet them for these more disruptive scenarios’. This dialogue 1.) Prevents unrealistic expectations and 2.) Lays the groundwork for making the case for budgets and projects for remediation of these deficits. These scenarios also provide a basis for the development of exercises to test recovery capability.
Rod Davis, CRISC, CBCP
Ever since the pocket calculator replaced the adding machine and the slide rule, accountants have been debating whether today’s accountant is less skilled than those that went before. The increasing reliance upon legislative compliance and ‘best practice frameworks’ has ensured that the modern professional must rely on the computer to carry out their tasks.
This session presents preliminary results from Micheal’s research into whether the sophisticated use of computers (‘intelligent decision aids’) to assist with accounting and audit reduces the professional’s judgment capability – their ‘know-how’. Micheal’s research draws upon interviews with 59 public sector auditors to identify whether this ‘deskilling’ is occurring.
The session identifies the driving forces behind this ‘deskilling effect’ (‘technology dominance), outlines recent research into the phenomenon (and in fact whether it exists or not), and identifies risk factors that may be at play in deskilling yourself and your staff if you rely on computers too much. Potential strategies to reduce this deskilling effect are also outlined and discussed.
This session should be of interest to any professional that relies upon a computer to help them with their professional tasks.
Decision support systems, group decision support systems,expert systems-manag...clincy cleetus
concept of decision making,decision making process-intelligence phase-design phase-choice phase,types of decisions,meaning and definition of decision support systems(dss),evolution of dss,characteristics of dss,decision support and repetitiveness of decisions,objectives and importance of dss,classification of dss,components of dss,functions of dss,development of dss,support for different phases of decision making,benefits and risk of dss,group decision support systems, gdss software, gdss benefits and risks,expert systems,difference between dss and es, comparison between dss and es
Continuity planners follow a methodology which elicits recovery requirements (RTO, RPO) from stakeholders and seeks to build capacity to meet those requirements. However, all disasters are not created equal and the reality is that most businesses, while able to meet those requirements for some scenarios, simply cannot meet them for more disruptive scenarios. Scenario-based Recovery Metrics give continuity planners a method to measure their ability to recover for a range of scenarios, from simpler to more complex. This facilitates measurement of deficits relative to the stakeholder's requirements for a range of scenarios. Furthermore, this method gives opportunity for continuity planners to dialogue with stakeholders and explain that 'we can meet your requirements for this set of simpler scenarios, however with our current recovery capacity we are unable to meet them for these more disruptive scenarios’. This dialogue 1.) Prevents unrealistic expectations and 2.) Lays the groundwork for making the case for budgets and projects for remediation of these deficits. These scenarios also provide a basis for the development of exercises to test recovery capability.
Rod Davis, CRISC, CBCP
Ever since the pocket calculator replaced the adding machine and the slide rule, accountants have been debating whether today’s accountant is less skilled than those that went before. The increasing reliance upon legislative compliance and ‘best practice frameworks’ has ensured that the modern professional must rely on the computer to carry out their tasks.
This session presents preliminary results from Micheal’s research into whether the sophisticated use of computers (‘intelligent decision aids’) to assist with accounting and audit reduces the professional’s judgment capability – their ‘know-how’. Micheal’s research draws upon interviews with 59 public sector auditors to identify whether this ‘deskilling’ is occurring.
The session identifies the driving forces behind this ‘deskilling effect’ (‘technology dominance), outlines recent research into the phenomenon (and in fact whether it exists or not), and identifies risk factors that may be at play in deskilling yourself and your staff if you rely on computers too much. Potential strategies to reduce this deskilling effect are also outlined and discussed.
This session should be of interest to any professional that relies upon a computer to help them with their professional tasks.
This lecture provide a review of requirement engineering process. The slides have been prepared after reading Ian Summerville and Roger Pressman work. This lecture is helpful to understand user, and user requirements.
History about software engineering . Tell about what is software engineering requirements model and also tell about the description and definitely about software engineering products protocol
BA and Beyond 19 Sponsor spotlight - Namahn - Beating complexity with complexityBA and Beyond
It’s a complex world full of complex problems- organisational change, the income inequality gap and digital transformation just to name a few.
The conventional way of combatting complexity to solve problems no longer works.
The great minds of Systemic Design have come together to create a unique and innovative toolkit designed to embrace complexity and change the way that we design solutions.
The first of its kind, the toolkit is based on academic research and human-centred design expertise. It is also the first to be endorsed by the Systemic Design Association and is truly changing the way that solutions are designed.
We invite you to come and discover how the Systemic Design Toolkit is driving a democratisation and transformation of the solutions design process for all stakeholders involved.
Discusses sociotechnical issues that arose in the design of a national digital learning system intended for use by more than a million students and their teachers
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
2. Design for Recovery,York EngD Programme, 2010
Slide 2
Objectives
• To discuss the notion of ‘failure’ in software systems
• To explain why this conventional notion of ‘failure’ is not
appropriate for many LSCITS
• To propose an approach to failure management in LSCITS
based on recoverability rather than failure avoidance
3. Design for Recovery,York EngD Programme, 2010
Slide 3
Complex IT systems
• Organisational systems that support different functions
within an organisation
• Can usually be considered as systems of systems, ie
different parts are systems in their own right
• Usually distributed and normally constructed by
integrating existing systems/components/services
• Not subject to limitations derived from the laws of
physics (so, no natural constraints on their size)
• Data intensive, with very long lifetime data
• An integral part of wider socio-technical systems
4. Design for Recovery,York EngD Programme, 2010
Slide 4
What is failure?
• From a reductionist perspective, a failure can be
considered to be ‘a deviation from a specification’.
• An oracle can examine a specification and observe a
system’s behaviour and detect failures.
• Failure is an absolute - the system has either failed or it
hasn’t
• Of course, some failures are more serious than others; it
is widely accepted that failures with minor consequences
are to be expected and tolerated
5. Design for Recovery,York EngD Programme, 2010
Slide 5
A question to the audience
• A hospital system is designed to maintain information about available
beds for incoming patients and to provide information about the
number of beds to the admissions unit.
• It is assumed that the hospital has a number of empty beds and this
changes over time. The variable B reflects the number of empty beds
known to the system.
• Sometimes the system reports that the number of empty beds is the
actual number available; sometimes the system reports that fewer
than the actual number are available .
• In circumstances where the system reports that an incorrect number
of beds are available, is this a failure?
6. Design for Recovery,York EngD Programme, 2010
Slide 6
Bed management system
• The percentage of system users who considered the
system’s incorrect reporting of the number of available
beds to be a failure was 0%.
• Mostly, the number did not matter so long as it was
greater than 1. What mattered was whether or not
patients could be admitted to the hospital.
• When the hospital was very busy (available beds = 0),
then people understood that it was practically impossible
for the system to be accurate.
• They used other methods to find out whether or not a
bed was available for an incoming patient.
7. Design for Recovery,York EngD Programme, 2010
Slide 7
Failure is a judgement
• Specifications are a simplification of reality.
• Users don’t read and don’t care about specifications
• Whether or not system behaviour should be considered to
be a failure, depends on the judgement of an observer of that
behaviour
• This judgement depends on:
• The observer’s expectations
• The observer’s knowledge and experience
• The observer’s role
• The observer’s context or situation
• The observer’s authority
8. Design for Recovery,York EngD Programme, 2010
Slide 8
System failure
• ‘Failures’ are not just catastrophic events but normal,
everyday system behaviour that disrupts normal work and
that mean that people have to spend more time on a task
than necessary
• A system failure occurs when a direct or indirect user of
a system has to carry out extra work, over and above
that normally required to carry out some task, in
response to some inappropriate system behaviour
• This extra work constitutes the cost of recovery from
system failure
9. Design for Recovery,York EngD Programme, 2010
Slide 9
Failures are inevitable
• Technical reasons
• When systems are composed of opaque and uncontrolled components,
the behaviour of these components cannot be completely understood
• Failures often can be considered to be failures in data rather than failures
in behaviour
• Socio-technical reasons
• Changing contexts of use mean that the judgement on what constitutes a
failure changes as the effectiveness of the system in supporting work
changes
• Different stakeholders will interpret the same behaviour in different
ways because of different interpretations of ‘the problem’
10. Design for Recovery,York EngD Programme, 2010
Slide 10
Conflict inevitability
• Impossible to establish a set of requirements where
stakeholder conflicts are all resolved
• Therefore, successful operation of a system for one set of
stakeholders will inevitably mean ‘failure’ for another set
of stakeholders
• Groups of stakeholders in organisations are often in
perennial conflict (e.g. managers and clinicians in a
hospital). The support delivered by a system depends on
the power held at some time by a stakeholder group.
11. Design for Recovery,York EngD Programme, 2010
Slide 11
Where are we?
• Large-scale information systems are inevitably complex
systems
• Such systems cannot be created using a reductionist
approach
• Failures are a judgement and this may change over time
• Failures are inevitable and cannot be engineered out of a
system
12. Design for Recovery,York EngD Programme, 2010
Slide 12
The way forward
• Software design has to be seen as part of a wider process
of LSCITS engineering
• We need to accept that technical system failures will
always occur and examine how we can design these
systems to allow the broader socio-technical systems, in
which these technical systems are used, to recognise,
diagnose and recover from these failures
13. Design for Recovery,York EngD Programme, 2010
Slide 13
Software dependability
• A reductionist approach to software dependability takes the view that
software failures are a consequence of software faults
• Techniques to improve dependability include
• Fault avoidance
• Fault detection
• Fault tolerance
• These approaches have taken us quite a long way in improving
software dependability. However, further progress is unlikely to be
achieved by further improvement of these techniques as they rely on
a reductionist view of failure.
14. Design for Recovery,York EngD Programme, 2010
Slide 14
Failure recovery
• Recognition
• Recognise that inappropriate behaviour has occurred
• Hypothesis
• Formulate an explanation for the unexpected behaviour
• Recovery
• Take steps to compensate for the problem that has arisen
15. Design for Recovery,York EngD Programme, 2010
Slide 15
Coping with failure
• Socio-technical systems are remarkably robust because
people are good at coping with unexpected situations
when things go wrong.
• We have the unique ability to apply previous experience from
different areas to unseen problems.
• Individuals can take the initiative, adopt responsibilities and,
where necessary, break the rules or step outside the normal
process of doing things.
• People can prioritise and focus on the essence of a problem
16. Design for Recovery,York EngD Programme, 2010
Slide 16
Recovering from failure
• Local knowledge
• Who to call; who knows what; where things are
• Process reconfiguration
• Doing things in a different way from that defined in the ‘standard’ process
• Work-arounds, breaking the rules (safe violations)
• Redundancy and diversity
• Maintaining copies of information in different forms from that maintained
in a software system
• Informal information annotation
• Using multiple communication channels
• Trust
• Relying on others to cope
17. Design for Recovery,York EngD Programme, 2010
Slide 17
Design for recovery
• The aim of a strategy of design for recovery is to:
• Ensure that system design decisions do not increase the amount of
recovery work required
• Make system design decisions that make it easier to recover from
problems (i.e. reduce extra work required)
• Earlier recognition of problems
• Visibility to make hypotheses easier to formulate
• Flexibility to support recovery actions
• Designing for recovery is an holistic approach to system design and not
(just) the identification of ‘recovery requirements’
• Should support the natural ability of people and organisations to cope with
problems
18. Design for Recovery,York EngD Programme, 2010
Slide 18
Problems
• Security and recoverability
• Automation hiding
• Process tyranny
• Multi-organisational systems
19. Design for Recovery,York EngD Programme, 2010
Slide 19
Security and recoverability
• There is an inherent tension between security and
recoverability
• Recoverability
• Relies on trusting operators of the system not to abuse privileges
that they may have been granted to help recover from problems
• Security
• Relies on mistrusting users and restricting access to information
on a ‘need to know’ basis
20. Design for Recovery,York EngD Programme, 2010
Slide 20
Automation hiding
• A problem with automation is that information becomes subject to
organizational policies that restrict access to that information.
• Even when access is not restricted, we don’t have any shared culture
in how to organise a large information store
• Generally, authorisation models maintained by the system are based
on normal rather than exceptional operation.
• When problems arise and/or when people are unavailable, breaking
the rules to solve these problems is made more difficult.
21. Design for Recovery,York EngD Programme, 2010
Slide 21
Process tyranny
• Increasingly, there is a notion that ‘standard’ business
processes can be defined and embedded in systems that
support these processes
• Implicitly or explicitly, the system enforces the use of the
‘standard’ process
• But this assumes three things:
• The standard process is always appropriate
• The standard process has anticipated all possible failures
• The system can be respond in a timely way to process changes
22. Design for Recovery,York EngD Programme, 2010
Slide 22
Multi-organisational systems
• Many rules enforced in different ways by different systems.
• No single manager or owner of the system . Who do you call when
failures occur?
• Information is distributed - users may not be aware of where
information is located, who owns information, etc.
• Processes involve remote actors so process reconfiguration is more
difficult
• Restricted information channels (e.g. help unavailable outside normal
business hours; no phone numbers published, etc.)
• Lack of trust. Owners of components will blame other components
for system failure. Learning is inhibited and trust compromised.
23. Design for Recovery,York EngD Programme, 2010
Slide 23
Design guidelines
• Local knowledge
• Process reconfiguration
• Redundancy and diversity
24. Design for Recovery,York EngD Programme, 2010
Slide 24
Local knowledge
• Local knowledge includes knowledge of who does what,
how authority structures can be bypassed, what rules can
be broken, etc.
• Impossible to replicate entirely in distributed systems but
some steps can be taken
• Maintain information about the provenance of data
• Who provided the data, where the data came from, when it
was created, edited, etc.
• Maintain organisational models
• Who is responsible for what, contact details
25. Design for Recovery,York EngD Programme, 2010
Slide 25
Process reconfiguration
• Make workflows explicit rather than embedding them in the software
• Not just ‘continue’ buttons! Users should know where they are and
where they are supposed to go
• Support workflow navigation/interruption/restart
• Design systems with an ‘emergency mode’ where the the system
changes from enforcing policies to auditing actions
• This would allow the rules to be broken but the system would maintain a
log of what has been done and why so that subsequent investigations
could trace what happened
• Support ‘Help, I’m in trouble!’ as well as ‘Help, I need information?’
26. Design for Recovery,York EngD Programme, 2010
Slide 26
Redundancy and diversity
• Maintaining a single ‘golden copy’ of data may be efficient but it may
not be effective or desirable
• Encourage the creation of ‘shadow systems’ and provide import
and export from these systems
• Allow schemas to be extended
• Schemas for data are rarely designed for problem solving. Always
allow informal extension (a free text box) so that annotations,
explanations and additional information can be provided
• Maintain organisational models
• To allow for multi-channel communications when things go wrong
27. Design for Recovery,York EngD Programme, 2010
Slide 27
Summary
• A reductionist approach to software engineering is no longer viable.
on its own, for complex systems engineering
• Improving existing software engineering methods will help but will
not deal with the problems of complexity that are inherent in
distributed systems of systems
• We must learn to live with normal, everyday failures
• Design for recovery involves designing so that the work required to
recover from a failure is minimised
• Recovery strategies include supporting information redundancy and
annotation and maintaining organisational models