Document defect tracking for improving product quality and productivity
Software Engineering for Self-Adaptive and Self-Managing Systems
1. Software Engineering for Adaptive
And Self Managing System
Muhammad Akram Abbasi, Prof.Naeem Janjua
Student of MS SE, Szabist Karachi
90 Clifton
asslam_alikum2002@yahoo.com
nujanjua@yahoo.com
Computer Science department Szabist Karachi 90 Clifton, Pakistan
ABSTRACT. Software engineering has
established innovative skills on behalf of
managing the ever growing density of assembling
recent day software structures, it becomes
deceptive that there is an equally persistent need
for mechanisms that systematize and simplify the
adaptation and modification of software Systems.
The purpose of this Research is to obtain
concentration in the area of software engineering
of the people on self configuring, self managing,
self optimizing, self healing, self adaptive and
autonomic in requirement elicitation techniques.
Keywords: Self-Adaptive, Self-Managing, Self-
Healing, Requirement Elicitation
1- Introduction
Main branch is software engineering which deals
with sub branches although there are many
branches but I will solely target to software
requirement engineering and requirement
engineering of problems and constraints and
what are self adaptive and self managing
systems how those can be embedded with
requirement engineering of branch for
requirement elicitation purpose either to achieve
target or can be beneficial for software industries.
When any vendor going to make the software
applications it needs certain human interaction
along with human resources, those which can
detect and manage all of the context of
significant information during first step of
elicitation process, that can be internal or
external of stockholders, such significant
interaction leads to more resources, budget,
supervision, contiguous innovative approaches
for best consequences, time taking and achieving
the desired or expected regulation during
gathering requirements and certain times it gets
preliminary problem or causing to fail the actual
requirements due to lack of knowledge of
requirement engineer(s), fail to remember
problem of humanity and mining the actual need
of customer.
Accordingly there is high need to require a
System/Framework that can troubleshoot,
reconfigure, detect significant complexity
reduction, robustness, can manage autonomic,
self-optimize, self-heal, self-adaptive and should
have ability to change itself at run time and keep
complexity hidden form the end user desire
quality requirement which can document
requirement that can record the actual gather
grained, imperative, cohesive and intensive data
and also audio/video chat discussion should be
recorded for future traceability of the meetings,
so all these properties how can we achieve and
that is big question that there can have some
idea for self adapting, managing automations
2. monitoring itself context, detect changes and
properties of stockholder need.
This paper will cover, Survey of requirements
problem regarding historical survey, requirements
concerns how will cope adaption, context
changing behavior will show option list, mapping
to Architecture with totally new requirements,
language concerns regarding multi lingual
support, security concerns to obtain verification
and validation.
2- Survey of requirements problem
An inspection/survey more than 800 projects,
under taken by 350 US business companies and
related that 1/3 (one third) projects, never
completed, major cost overrun and significant
delays, When most cause of problem and failure
asked, answers were “poor requirement” along
with following statistics [9].
Description percent
Involvement of user in
sufficient
13%
Requirement incomplete 12%
Requirement(s)
Changing(s)
11%
Unrealistic Expectations 6%
Objectives Unclear 5%
2.1 Requirement Elicitation
Requirement Elicitation is first and most critical
step during a project management most of the
errors come during first step of gathering data
from user stockholders such typical errors most
of those are including omission, use of incorrect
facts, misunderstanding, inconsistency and
ambiguity, overlapping, conflicting requirements,
Un-realistic, missing data, unclear data.
2.2 Requirements concerns
Classically used methods are for gathering data
through interview, meetings, domain documents
and both parties using natural languages to
classify requirements, despite that adaptive
system will ask such queries, Why user wants
this? Why in this way? What the system should
do? How well it should do? Where and, When it
need to be accomplished? And system has to
now solely define functional and non-functional
along with monitoring specification and will take
variability in operational context evolution criteria
will be take on at the run time, by the system and
auto will motivate with explanations along with
the list of options for different plans to
stockholders.
One of the big challenge is considering yet by
researchers, if new design or prototype which is
not exist yet, how self adaptive system will
possess because system can’t assume the
unknown requirements in advance accordingly
system will cope with entire possible set of
environment to their perspective of adaption for
specification.
2.3 Context Changing Behavior
Traditional Requirement Engineering:
- “This system shall do this….”
Adaptive level Requirement Engineering:
- “The system might do this……”
- “But it may do this …… as long as it
does this….”
- “The system ought to do this……..but if
it can’t, it shall eventually do this…” [4].
Therefore ought and might or assumed priority of
stockholder requirement like if customer accepts
“may” it will prioritize as “low” scale, if customer
uses “ought” that will be consider as “average”
task scale and same as if it is used “might” that
will be considered as “High” priority level of task
3. 2.4 Mapping to Architecture
If any technology requirement is used explicitly of
language system will handles uncertainty.
Requirement with similar domain for reusable will
be provided for adoption and Variety of technical
terminology will be exist for adapting context but
certain invariants will not be changed, it will be
dependent upon degree of flexibility from custom
need.
2.5 Language concerns
Current systems are not suitable for dealing with
suited for natural languages so system should
have multilingual capability to make out easily to
stockholders and also for verification and
validation to test and confirmation of context will
be automatically detect and suggest promptly
during adaptation mechanism.
2.6 Security concerns
Regarding non-functional requirement, this
system considers application level security rather
than hardware-level, distributed network-level or
operating system security level mechanisms
because of system cannot assume cyber-attacks
which are unknown yet.
Security will be considered authorization level,
authentication and tolerance level.
3- Requirement Engineering
Requirement engineering defines statement of
ideas about the proposed system(s) on which all
stockholders agree upon it and under which
constraints system is required to operate.
It is well to be said a process by which we
determine need of user (stockholders) is called
Requirement Engineering.
Figure 1 - RE Process
3.1 Requirement Engineering Components
Requirement
Development
Requirement
Management
Elicitation Volatility
Analysis Traceability
Specification
Validation
3.2 Requirement prioritization
There are three types of requirement prioritization
such as following.
High prioritization is determined during the
analysis, design and implementation of the
schedule of time.
High priority based task and it is also same time
can be difficult for product management to
determine which task is need to be high priority
based that priority need to be implemented first
from the schedule.
Medium prioritization is determined during the
analysis, design the schedule of time.
Low prioritization is determined during the
analysis schedule of time.
4. Functional & non functional requirements
prioritization
Functional deals with specific or functional
behavior like implementing the design of the
system if we broadly refer functional requirement
is for “what the system is to do”
Non-functional is such type of requirement which
deals the operation of systems like as detailed
architected of the system and defines how
systems supposed to be and also divides in to
two categories.
• Execution: like as usability, security
observed at running time of the system.
Evolution: as such, scalability
extensibility, manageability, testability of
embodied systems.
3.2.1 Requirement prioritization Qualitative
Methods
General Types
- Observations
- Interviews
- Focus Group
- Non – statistical (Method vary)
Specific types
- Observation Documentation
- Ethnography
- Use cases
- Analysis existing system
During the gathering of Requirement existing
methods are also familiar in software community
such as
Requirement Prototyping
o Throw Away prototyping
o Evolutionary prototyping
4- Self-Adaptive
Having an ability to change to suit different
conditions.
Having an ability to change into different
environment either condition or in having to direct
control as such adaptive based systems
consistently monitor the changing but it is clearly
said to be adaptive based cannot monitor over all
the things of changing in system like as if any
environmental catastrophic come at run time then
adaption can’t be able to build the system healthy
again.
4.1 Self-Managing
One of most applied ways is to human
administration to describe and add policies for
optimization problems most system uses like as
cloud computing, autonomic computing, web
services, communication network and distributed
system but rather than that,
Managing to direct or control the use of or
handle, such systems which configure and
reconfigure to it selves and optimize itself recover
and protect against over all catastrophic failure
and changing environment as B.HC cheng
showing control loop. Such as
Figure 2 Control Loop on changing
environment [4]
4.2 Self-Healing
It is the process of making or becoming sound or
healthy/well again and monitoring automatically,
one of the e.g.
5. Traffic monitoring camera(s) it is the efficient
transportation multi-agent system for monitor the
traffic in each node of agent is comprise the
single camera by which software system to
communicate to each other and the camera
agent is monitoring and detects traffic James on
roads and to avoid bottlenecks of central system.
4.3 Autonomic Systems
Autonomic computing a vision of by IBM in 2001
became most central area of practitioner and
researcher over last decades
Autonomic system manage several things like as
operating system OS X mange certain thing
themselves as such blood pressure and heart
rate etc.
5- Results
Requirement Engineering has set of group
activates and initial step is to gathering
requirements to overcome on failure of projects
requirement elicitation faces mostly vendors
common problems poor requirement along with
limited time and limited budget these constraints
keep in mind and purpose plan for elicitation
through system which will mitigate the all
classical behavior like through interviews,
checklists, scenario, story board ,ethnography
which will be covered by system self-adaptive
based rather than outside.
In area of adaptive systems there are many
suggestions from researcher and practitioner
along with requirement specification problems,
alternative methodologies constraints,
preferences and assumptions are, but there is
need to evaluate such system who can elicit
requirements by the adaptive although I got
literature survey there were certain
methodologies and alternative to cope with that
and modeling techniques but were very limited. In
this paper I investigate variability of modeling
techniques, representation and variants of
system behavior those which can monitor, adapt
alternate regarding context and ontologism are
variable among a domain on the literature or
internet, furthermore it required to work to
consolidate specially to mitigate the risk and cope
actual need of stockholders.
5.1 Proposed plan of requirement elicitation
When vendors are going to elicit of requirement
through adaptive system, thus keep in mind the
constraints of time and budget before plan for
elicitation.
6- Conclusion & Future work
Despite unstructured interviews get structured
interview to mitigate ambiguous, incomplete,
inadequate requirement for getting right and
accurate requirements for inklings data. The
critical process of elicitation of data in
requirement engineering have to high quality of
goal based and is to centralize elicited
requirements, for draft statement of
requirements, requirements analysis,
requirement problems with negotiation and
exploration elaboration of alternative of
boundaries and reuse through automated self-
managing, self-adapting and self-promising and
capturing accurately requirements.
I know it does not comply the rigorous full
adaptive approaches like as missing requirement
prototyping I plan to improve in future also.
For self adaptive and self managing based
system regarding Requirement Engineering
area still there are big challenges how to ?
Modeling and analysis for adaptive system e.g.,
- Runtime models
- Cost benefits
- Reuse support for self adaptive systems
e.g.,( patterns, designs, code)
- Design Architectural support
![monitoring itself context, detect changes and
properties of stockholder need.
This paper will cover, Survey of requirements
problem regarding historical survey, requirements
concerns how will cope adaption, context
changing behavior will show option list, mapping
to Architecture with totally new requirements,
language concerns regarding multi lingual
support, security concerns to obtain verification
and validation.
2- Survey of requirements problem
An inspection/survey more than 800 projects,
under taken by 350 US business companies and
related that 1/3 (one third) projects, never
completed, major cost overrun and significant
delays, When most cause of problem and failure
asked, answers were “poor requirement” along
with following statistics [9].
Description percent
Involvement of user in
sufficient
13%
Requirement incomplete 12%
Requirement(s)
Changing(s)
11%
Unrealistic Expectations 6%
Objectives Unclear 5%
2.1 Requirement Elicitation
Requirement Elicitation is first and most critical
step during a project management most of the
errors come during first step of gathering data
from user stockholders such typical errors most
of those are including omission, use of incorrect
facts, misunderstanding, inconsistency and
ambiguity, overlapping, conflicting requirements,
Un-realistic, missing data, unclear data.
2.2 Requirements concerns
Classically used methods are for gathering data
through interview, meetings, domain documents
and both parties using natural languages to
classify requirements, despite that adaptive
system will ask such queries, Why user wants
this? Why in this way? What the system should
do? How well it should do? Where and, When it
need to be accomplished? And system has to
now solely define functional and non-functional
along with monitoring specification and will take
variability in operational context evolution criteria
will be take on at the run time, by the system and
auto will motivate with explanations along with
the list of options for different plans to
stockholders.
One of the big challenge is considering yet by
researchers, if new design or prototype which is
not exist yet, how self adaptive system will
possess because system can’t assume the
unknown requirements in advance accordingly
system will cope with entire possible set of
environment to their perspective of adaption for
specification.
2.3 Context Changing Behavior
Traditional Requirement Engineering:
- “This system shall do this….”
Adaptive level Requirement Engineering:
- “The system might do this……”
- “But it may do this …… as long as it
does this….”
- “The system ought to do this……..but if
it can’t, it shall eventually do this…” [4].
Therefore ought and might or assumed priority of
stockholder requirement like if customer accepts
“may” it will prioritize as “low” scale, if customer
uses “ought” that will be consider as “average”
task scale and same as if it is used “might” that
will be considered as “High” priority level of task](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)