See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/322816988

Customized project charter for computational scientific software products

Article  in  Journal of Computational Methods in Sciences and Engineering · January 2018

DOI: 10.3233/JCM-180778

CITATIONS READS

6 2,152

2 authors:

Shlomo Mark Yotam Lurie

SCE College of Engineering, Ashdod Israel Ben-Gurion University of the Negev
64 PUBLICATIONS   629 CITATIONS    30 PUBLICATIONS   282 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Learning outcomes in project oriented environments View project

Software Quality View project

All content following this page was uploaded by Yotam Lurie on 20 November 2019.

The user has requested enhancement of the downloaded file.

Journal of Computational Methods in Sciences and Engineering 18 (2018) 165–176 165
DOI 10.3233/JCM-180778
IOS Press

Customized project charter for computational

scientific software products

Shlomo Marka,∗ and Yotam Lurieb

Y
a Negev Monte Carlo Research Center and Department of Software Engineering, SCE – Shamoon
College of Engineering, Ashdod, Israel

OP
b Guilford Glazer Faculty of Business and Management, Ben-Gurion University of the Negev,

Beer-Sheva, Israel

Abstract. Different domains of software applications require that the project management’s development process be customized
to its specific conditions and needs. One of the most widely used operation research is the development of a scientific software
C
product. Numerous studies point to a wide gap among the various communities, processes, dynamics, etc., between the de-
velopment of general software products and the development of computational scientific software products. This wide gap
emphasizes the necessity for more suitable and more adjustable practices in project management and in the development of
scientific software products. One of the most significant challenges in the development of scientific software is expressed in the
OR

different attitudes and expectations held by various stakeholders, in terms of the scope, objectives, and goals they envision for
their software product. Although unique challenges in the development of scientific software arise at every stage of the process,
we maintain that, by addressing the varying perspectives gap at the very outset of the project management process, one can
reduce unwanted dynamics throughout the development process. A “project charter” is a critical formal statement that defines
the scope, objectives and participants in a project in order to officially authorize the project and to ensure that everyone involved
is aware of its purpose and objectives. Customization of the project charter can provide a response to the varying perspectives
TH

gap. This paper presents an approach to the generation of a customized project charter for scientific software products as an
initial and essential step for the achievement of quality. We will demonstrate the implementation of the approach in one of
our own scientific software development projects – a simulation software product used for the development of a fiber optic
evanescent wave spectroscopy (FEWS) simulator.

Keywords: Simulation, scientific software product, project management, project charter

AU

1. Introduction

Quality in engineering is a complex and highly context-dependent concept and has numerous defini-
tions and approaches as expressed in different areas of engineering. In fact, there is no single agreed-upon
definition for quality [1].
The engineering process for the development of a software product – software engineering – is meant
to systematically lead us from an initial conception of what the software is meant to do to an imple-
mentation that correctly meets the objectives assigned to it [2,3]. Different domains of software appli-
cations require that the development process be customized to its specific conditions and needs, while

∗
Corresponding author: Shlomo Mark, Negev Monte Carlo Research Center and Department of Software Engineering, SCE –
Shamoon College of Engineering, Ashdod, Israel. Tel.: +972 8 8519078; Fax: +972 8 8519062; E-mail: marks@sce.ac.il.

1472-7978/18/$35.00
c 2018 – IOS Press and the authors. All rights reserved
166 S. Mark and Y. Lurie / Customized project charter for computational scientific software products

the engineering development process entails the initiation, planning, execution, monitoring, control and
finalizing of those activities necessary to meet the project’s requirements [4].
According to IEEE [5], software quality is defined by the degree to which a system, component, or pro-
cess meets specified requirements as well as customer or user needs or expectations. Pressman [6] defines
it as conformance to explicitly stated functional and operational requirements, conformance to explicit
development standards, and conformance to professional needs. According to Gurla and Lin [7], soft-
ware quality is determined by three main factors: organizational, technological, and individual. McCall
et al. [8] categorize software quality factors into three sets: product operation (e.g., functionality), prod-
uct revision (e.g., testability), and product adaptability (e.g., reusability). Similarly, the metric structure
for the evaluation of quality varies and therefore cannot be a single acceptable measure of product qual-
ity. Essentially, there are two main concepts as to how to approach quality improvement: the “product

Y
base” approach and the “process base” approach [9]. In the “product base” approach, as it is commonly
perceived, “quality software” is software where all the characteristics comply with the requirements. In

OP
practice, the characteristics that are not related to the requirements are also important. Therefore, not
only the presence of certain characteristics is important; a lack of features will also affect the quality of
the product [9]. On the other hand, software quality is highly influenced by the development process,
as is argued by the proponents of the “process base” approach. Failures in the requirements definition
process, failures in developer-customer communication, failures in the design process and failures in the
C
quality assurance process are some of the most important factors affecting the quality of a software prod-
uct [10]. Clearly, a single operational definition of the key performance indicators for the measurement
of the quality of both the development process and software product quality is problematic, limited and
OR

almost impossible.
Given the absence of a single operational definition for the measurement of quality, one way of over-
coming this difficulty in the development process is to focus attention on the drivers that advance quality
value, i.e., QVD – quality value drivers. QVD is a managerial approach (practices, roles, ceremonies,
artifacts) that delivers quality value to the organization, process, and method. The Value “V” is what
TH

we want to achieve, e.g., the improvement of the team’s knowledge; the driver “D” is the managerial
approach (practices, roles, ceremonies, artifacts) that helps us to achieve the value; and the quality “Q”
is the metrics and the method that help us to measure the improvement that we achieved by adopting
the driver. By way of analogy, just as a scientist need not have an operational definition of truth in order
to seek truth – and instead might stress the importance of rigor, methodological and critical thinking
AU

among the familiar value drivers toward truth – similarly, the quest for quality value starts with a clear
understanding of those variables that actually create quality value in a significant way: i.e., the key qual-
ity value drivers. In the business world, managers seek business value drivers of different kinds, such
as financial value drivers, customer value drivers, operational value drivers and so forth. The identifi-
cation of the key quality value drivers needed for a given software product and which are relevant for
a fuller understanding of the goals and objectives of the development process, is a complex process. It
requires the prioritization of individuals and team interactions over formal processes and tools, of piece-
meal development of working products over comprehensive grand project documentation, of stakeholder
collaboration and involvement over contract negotiation, and of the ability to respond to change over a
reliance on comprehensive plans.
One of the most complex, most important and commonest domains of software products is the sci-
entific application. Computational science is a science that provides hardware and software solutions to
scientific problems [11], with the focus on efficiency, while the narrow realm of scientific programming
in computational science is concerned with the development of algorithms and codes to solve problems
 S. Mark and Y. Lurie / Customized project charter for computational scientific software products 167

in science and engineering. While, scientific computing can be defined as: “. . . the collection of tools,
techniques and theories required to solve on a computer mathematical models of problems in science and
engineering. . . In summary scientific computing draws on mathematics and computer science to develop
the best way to use computer systems to solve problems from science and engineering [12]. “ The sci-
entific programming development process generally begins with a code development process, in which
the scientist – in this case, the “computational scientist” – begins with the development of an in-house
computational code [13,14]. However, scientific systems tend to be complex, with unexpected relation-
ships and dependencies that often make the development of a scientific program (i.e., the creation of
executable sequences of instructions) an onerous and arduous task, requiring not only programing and
coding, but also the collecting and collating of computer instructions (e.g., database, library, framework,
OS, etc.). The complexity of the computing, as well as that of the research and coding, along with the

Y
need for high-performance computing applications [2], in many instances prompts the “computational
scientist” to require the intervention of a professional who specializes in proven approaches and tools –

OP
i.e., the “software engineer” – to develop a software product that will be efficient and will be capable
of dealing with a large computational component, while, at the same time, ensuring maintainability,
reusability and transparency for users and developers [11].
The development of scientific software products (SSP) is the unique feature of computational science
that is used for the construction of mathematical models and which involves the employment of quanti-
C
tative analysis techniques in order to assist scientists in analyzing, visualizing and simulating processes
and data [15]. These software products are geared toward scientific computations in which the SSP de-
velopment life cycle is focused on the design, analysis and development of algorithms and software with
OR

a computational component that can model phenomena, solve problems and provide data for decision
support [16] in science and engineering [17,18]. In the adoption of the “process base” approach to qual-
ity for the modification or adjustment of a suitable engineering development process for an SSP, one
must reveal and confront the unique difficulties as well as the gaps and the origin of the gaps that char-
acterize the development process for specific domains, where the origin in the case of an SSP can arise
TH

from technical complications as well as from behavioral complications (among stakeholders). From pre-
vious studies [2,13,15,17–19] and from the extensive research we have performed, we have come to the
conclusion that the development process of scientific software products has unique features with com-
plications that, in addition to the problems inherent in software development, include uncertainties and
constraints stemming from various scientific processes as well as from mathematical difficulties.
AU

Our group, the NMCRC (Negev Monte Carlo Research Center) brought together scientists from a va-
riety of fields in order to develop Monte Carlo simulations – “. . . a branch of experimental mathematics
in which one uses random numbers to conduct experiments [20] “ – for different scientific spheres, utiliz-
ing the requirements, rigors, and standards of software engineering. The goal of the Negev Monte Carlo
Research Center is to combine research in physical, environmental, biological, chemical, and medical
models with proven software capability, while ensuring software quality, software development, method-
ology, and advanced testing standards. Over the years, the scope of the NMCRC center expanded from
Monte Carlo simulation to the applied Computational Science, and Engineering Center, which exploits
the power of computation to provide scientific software products for a variety of scientific and engineer-
ing fields under proven principles, approaches, tools, and standards. In fact the suggested tool serves has
been adopted as proven QVD tool for a variety of projects and ensures success. In fact, unique challenges
in the development of an SSP exist at every stage of the development process. Notable constraints and
uncertainties stem from varying prespectives in attitudes and expectations that can easily be identified
and remedied with the use of a proper protocol. The addressing of the varying perspectives gap at the
168 S. Mark and Y. Lurie / Customized project charter for computational scientific software products

very outset of the development process will reduce unwanted dynamics throughout the development
process. There is thus a need for the customized implementation of development practices and methods
that will be suited to the specific conditions and needs in the development process of a given scientific
software product and which will thereby ensure its quality.

2. Discussion

As part of a larger study seeking to explore the quality enhancement factors in software engineering,
we conducted an online survey in January and February 2015 [21]. We used a questionnaire survey to
assess the opinions and concerns of software practitioners regarding the connection between “quality”

Y
and “process approach” factors in their working environments and practices. The online survey consisted
of three parts: a demographic questionnaire, professional questionnaires related to the profession of the
respondents, and the study, which presented statements that reflected the attitudes of the respondents

OP
about the factors required to make a “process base” approach an appropriate perception for the ensuring
of success in software development. The premise of the survey was that different domains of software
applications need a customization of the development process in accordance with their specific condi-
tions and needs; thus the survey considered only a generic “process approach”, focusing on a search
for the factors that can generate success. The method used in the formulation of the statements did not
C
disclose the subject matter of the survey, i.e., the premise and the hypothesis of the survey; therefore, the
survey does not mention two terms: “quality” and “process approach factors”. The sample comprised
130 participants, 86% of whom worked at the time of the survey in the software development industry
OR

and in the academic community. The participants were from different places around the world and from
a broad range of different organizations, and represented a wide variety of attributes and characteristics.
Over four fifths (87%) of the respondents had a university education while three-quarters of them were
academics whose subject area was computer science or software engineering.
The results of this survey revealed some noteworthy findings. The vast majority of the participants
TH

(77.09%) agreed with the statement that software engineering is a relatively young engineering field
characterized by the lack of an agreed-upon theoretical and quantitative basis on which one could estab-
lish proven and binding processes. Therefore personal experiences as well as modifications to method-
ologies and procedures play a crucial role in the success of software development projects. Over three
quarters of the respondents (78.46%) agreed with the statement that, in order to create a successful soft-
AU

ware development project, the software engineer must employ technical, engineering and professional
skills, as well as social skills, for example, in interpersonal communication. Overwhelming support
(76.17%) was expressed for the statement that familiarity with the ramifications of every action taken in
the development process is a necessary precondition for the process’s success, while a lack of awareness
of such ramifications is one of the factors that can harm the development process.
These survey results complement, support and reveal two previous significant findings. First, among
the many known factors for success, three generic “process approach” factors can be identified: ex-
perience (in the specific domain), awareness (of difficulties, factors and gaps), and modification (of
methodologies and procedures). Second, modification of the software development life cycle involves
three elements: the “human factor”, an appropriate working environment, and the detection of factors
that could positively influence the success of the project. The meaning of software quality, how we assess
it, and how we generate and improve it are important elements, as noted above. There is no agreed-upon
definition and there are no agreed-upon approaches for software quality, nor is there any single op-
erational definition of the key performance indicators for measuring the overall quality of a process or
 S. Mark and Y. Lurie / Customized project charter for computational scientific software products 169

product; therefore we will employ the concept “generation of quality”, which will mean the achievement
of quality is by enabling a set of local modified quality generators with an inevitably relative impact to
the entire quality. The modified generators are practices, artifacts roles and the like, that modified to the
specific domain and cause a local significant improvement.
The scientific software product (SSP) development process can be characterized as complex, confus-
ing, highly sensitive to parameter changes, expensive and dangerous and often exhibiting a wide gap
between developer and client. Much of the literature [2,13,19,22,23] deals with factors that affect scien-
tific software development, while many articles emphasize the presence of several wide chasms between
general software development and scientific software product development [13,15,24] throughout the
entire software development life cycle. Among the various difficulties, factors and gaps, one can quite
easily identify a “conceptual gap” between developer and client. The first hindrance arises when the two

Y
parties use terms and statements that, because of their extensive knowledge in the required scientific
field, are familiar to some participants, while others cannot grasp their exact meaning or the conclu-

OP
sions they generate. Quite often, one party is not thoroughly knowledgeable regarding the difficulties the
other party confronts (both scientific and technical). Therefore, in many cases, exaggerated and unreal-
istic expectations may arise. In other words, the software development process itself can involve many
discrepancies, differences and hindrances.
Previous works [15,16,24–26] have pointed to the absence of a uniform understanding of both the soft-
C
ware development process and the objectives of the various software development phases. For example,
there is a gap between developers and clients as to their understanding of the importance and objectives
of software verification and testing. Most scientists have a solid grasp of the goals of software verifica-
OR

tion and comprehend its importance [16,25]. On the other hand, it was found that many scientists do not
“have [a] sufficient understanding [of] testing concepts” [16,25]. Thus, from the scientist’s perspective,
the tool most commonly used to assess software quality is testing. In other words, scientists use software
testing as the main tool for the assessment of software in the light of known and trusted empirical and
experimental results and in comparison with other models and with similar software products. Software
TH

developers, by contrast, treat testing as an important element of the quality assessment process, but do
not necessarily see it as the most important one.
Complexity and hindrance can arise because of the place occupied by the SSP within the scope of the
entire research project. From the point of view of the client (the scientist), the creation of the software
AU

is not the end goal but is simply one element in the whole process, with the actual goal being the
particular scientific research study in its entirety. On the other hand, from the perspective of the software
developer, the software itself is the goal. Complexity stems from the place the software development
project occupies as part of the overall research project. Essentially, there are two distinct objectives in
the initiation stage of a software development project: the development process and the software product.
Thus, if the development process is seen as the objective, then the motivation of the client involved in
the underlying science (i.e., the scientist as the end-user) is to use the software development process as
part of the entire research project and to use the software development as an operations research tech-
nique in order to explore and better understand the mechanisms involved in the corresponding real-world
dynamics. Recent developments in operations research include the use of many different techniques that
including also computer simulation [27]. In such cases, the client usually understands what to expect
when the process will be completed, but generally only toward the end of the process; therefore the
specifications for the software and most of the requirements will be discovered in the course of the
project [26]. This fact creates problems with respect to the definition of the project’s boundaries, both
170 S. Mark and Y. Lurie / Customized project charter for computational scientific software products

inclusive and exclusive, and also makes it difficult, if not impossible, to ascertain whether those bound-
aries are respected at every point in the process [19]. This is a serious challenge to the development
process, which thus requires close cooperation and flexibility in the introduction of changes.
On the other hand, if the software product is perceived as the objective, then the scientist may have
some idea of what must be done and what achievements to expect, while not necessarily knowing the
precise results of the actions that will be undertaken in the course of the research project; thus, the
scientist will have to know in advance what results will be provided by the final software product itself.
For example, there might be a situation where the developer needs to develop a software product for the
comp design and simulation of a prosthetic limb for a specific individual. The scientist understands the
physical situation, knows that its description will require the application of multiple partial differential
equations, can assess the results, but will have trouble evaluating the interim results. Such an objective

Y
encourages a development process that emphasizes orderly, detailed requirements, design and testing.
Essentially, the success of the development project of a scientific software product will depend on the

OP
extent to which these conceptual gaps (between the developer and the client) can be bridged, while the
successful completion of the development project will be measured not only in terms of the fact that
the project has been completed, but also in terms of the product’s quality, i.e., the scientific value that
will be provided when the product has been completed and which will stem from any improvements
made in the organizational process, i.e., the quality driver. As we see it, helping the software engineer
C
recognize – as early as possible (that is, before the commencement of the development process) – the
problems that could arise from the gaps between the developer and the client with regards to both per-
ception and knowledge is the key element to the “generation of quality” in the development process of
OR

a scientific software product. The project management planning process aims to define and refine the
project’s objectives, as well as to organize, manage and plan tasks necessary for the achievement of
success – namely, the project’s successful completion [4].
One of the primary tools required for the initiation and authorization of software development projects
is the “project charter”. The project charter [4] is a formal statement concisely outlining what it is
TH

to be done and why, and what value the software product will provide when completed. The primary
purpose of the project charter is to provide official authorization for the project by presenting the scope,
objectives, vision, and responsibilities of the participants and stakeholders, and to align these factors
with the project’s purpose. In practice, through the modification of the “project charter” for different
domains, it can serve as the initial quality driver tool to identify and overcome constraints, uncertainties
AU

and gaps. The goal (the value) of the suggested project charter in the development of an SSP is to
generate quality through the early detection and definition of possible conceptual gaps, so that a rough
idea can be obtained of the scientific value that will be provided when the product has been completed
and so that these conceptual gaps can be bridged through the adoption of other practices, tools or methods
for the ensuring of success. We present below a framework for the modification of a project charter
document for a scientific software product – the driver. Since such a framework provides the guiding
principles [28,29] needed for the initial stage, the parties will be in a better position to evaluate their
ability to meet the demands of the software’s development. The proposed framework will generally
outline the basic components that characterize scientific software product development in general and
which must be acknowledged so that the conceptual gaps that could hinder the process can be bridged.
These components can be adopted as – is, modified, ignored, or supplemented with additional elements.
The purpose of the modified project charter for a scientific software product is to document the necessary
information required (goals, objectives, needed knowledge, the significance of the development process
as part of the overall research study, and the relationship between the stakeholders), to obtain the approval
 S. Mark and Y. Lurie / Customized project charter for computational scientific software products 171

of this scientific software product for the operations research and to ensure that all the stakeholders are
aware of the purpose and objectives of the SSP’s development. Although there are various approaches
and documents to the development of a Project Charter, the following approach has proven itself to be
specific enough to get the project on the right track and yet narrow enough so as not to be an unnecessary
hurdle for SSP development.
A generic modified framework for a project charter for an SSP project will comprise five parts:
A. Rules:
– The goal of the scientific software product
– Declaration of concepts: Testing verification and quality
B. Overview of the scientific software product in question (assessment of the SSP’s scientific value
upon its completion):

Y
C. Scope – the need for a clear understanding of exactly what is to be done:
1. Stakeholders

OP
2. Objectives (choose one)
– The development process as the objective
– The software product as the objective
– Other
C
3. Assumptions
4. Constraints
5. Boundaries
OR

D. Quality
1. Is there another alternative (i.e., the utilization or reuse of existing software)? Yes/No. If yes, please
specify:
2. Criteria for success
3. Verification (choose one method and add references)
TH

– Comparison with similar software

– Comparison with known empirical results
– Comparison with known experimental results
– Other:
AU

E. Glossary

3. Case study: Simulation software example – fiber evanescent wave spectroscopy (FEWS)

One of the most widely used forms of operation research is the development of a simulation software
product, whereby researchers can develop techniques for the use of computers to numerically evaluate
the operation of a variety of systems and to form a better understanding of corresponding real-world
dynamics. In this paper, we demonstrate how to specifically utilize and modify a project charter in the
development of a fiber optic evanescent wave spectroscopy (FEWS) simulator [30–32], an interactive
product used to simulate the optimal design of a device for the spectroscopic analysis of tissue. The soft-
ware product is based on FEWS technology and utilizes the Monte Carlo method as its basic computing
algorithm.
Evanescent wave spectroscopy has become a widely used technique for the examination of the proper-
ties of materials, mostly within the infrared range of the electromagnetic spectrum [33–36]. Its advantage
172 S. Mark and Y. Lurie / Customized project charter for computational scientific software products

derives from the phenomenon of attenuated total reflection. Fiber evanescent wave spectroscopy (FEWS)
has been extensively used in biomedical skin diagnoses and chemical sensors.
A medical physics research group specializing in the design and manufacture of fiber optics turned
to our research team with the request that we develop a computational simulation tool [32] that could
help them design the optimal optical fibers they needed for their research. The client – in this case, the
research group – required a computational tool for the assessment of the feasibility, design and develop-
ment of new types of optical fibers. Specifically, the client required scientific software that would enable
the exploration of new compounds, geometric structures, and spatial arrangements in the development
of optical fibers – for the purpose of achieving maximum measurement accuracy. The client planned to
use the simulation tool for conditions that cannot be applied today due to technological limitations and
wanted to employ the simulation tool to evaluate the feasibility of the development of certain optical

Y
fibers. The client was interested in using the results from the advanced simulation tool to design fibers
for medical purposes. The accurate and error-free performance of such fibers would be crucial because
they could serve as an essential component in a tool used for the forming of a clinical diagnostic picture

OP
of a patient. It was therefore vital that a suitable and effective criterion for accuracy be determined and
that a test procedure be formulated for it. In accordance with the client’s specifications, the end user
would be a physicist from the research group, a specialist in fibers made of crystalline silver halides for
use in middle-infrared (mid-IR) spectroscopy. The team also requested that the software product utilize
the Monte Carlo method for simulation purposes [37]. The client emphasized the fact that its members
C
did not possess the knowledge or ability to examine and test the computational tool and that the software
tools would be tested and evaluated only after the delivery of the final results of the simulations. Fur-
thermore, the research would be carried out against a well-known experimental benchmark – a complete
OR

three-dimensional geometry (shape and structure) of tapered optical fiber material demonstrating the
absorbance of the evanescent field of an infrared signal [32] in fibers made of crystalline silver halides.
These parameters created huge challenges for us, a research group comprised of computer scientists,
physicists, mathematicians, and one biologist, working in close collaboration with a development team
consisting of software engineers. While the members in the research group and the development team
TH

collectively possessed rich background knowledge allowing them to cope with the development require-
ments, they lacked experience in, and a deep understanding of, this specific field of research. Therefore,
the requirements presented many potential failure routes for the developers. For example, even if a sim-
ulation program is written in a precise and correct way, the result produced by the simulation program
may not conform to the prescribed experimental benchmark. In such an instance, it would be difficult for
AU

the developer team to identify which element of the simulation failed: whether the difference in results
was caused by inaccurate algorithms, coding errors, false constants or imprecision in the application
of the Monte Carlo technique, or whether the incongruity arose through the use of imprecise, incorrect
formulae or because of constants obtained from previous measurements. In summary, this could have
happened for a variety of reasons, including choice of initial conditions (The key aspects are italicized
and printed in bold for the reader’s convenience. To avoid excessive detail and for the sake of brevity
and clarity, we have whittled down the content to its bare essentials).

3.1. Modification framework for a simulation software product – project charter

A. Rules
1) The purpose: The purpose of the project charter modification for a simulation software product
is to document the necessary information required to obtain approval of the simulation software
product for operations research and to ensure that all stakeholders are aware of the purpose and
objectives of the product’s development.
 S. Mark and Y. Lurie / Customized project charter for computational scientific software products 173

Y
OP
Fig. 1. FEWS and ray propagates.

2) The goal of the simulation software product: To serve as a simulation tool to study and better
understand new or complex scientific problems and phenomena through the development of theory
and the conducting of experiments.
C
3) Testing verification and quality: Testing is meant to ascertain the satisfaction of certain require-
ments. Thus we must regard the simulation software product as the result of a series of prob-
lems and reformulations whose requirements and their satisfaction must be individually examined.
Therefore, we must determine requirements – not just what the client wants, but also what the
OR

software needs. Thus, testing is an important part, but not the only part, of the quality assurance
process. In practice, the quality assurance process influences the entire development life cycle and
completion is obtained only when the software meets each and every one of the specified quality
assessments. Therefore, the quality assessment planning process and the activities it involves are
vital to the success of the project.
TH

B. Overview of the simulation software product (i.e., assessment of scientific value attained upon
completion)
Development of a computational tool for checking the feasibility, design and development of new
optical fibers.
AU

C. Scope – the need for a clear understanding of exactly what is to be done

By using this tool, we seek to explore new compounds, the geometric structures, and the spatial ar-
rangement of the fiber evanescent wave spectroscopy (FEWS) in order to obtain maximum measurement
efficiency.
1) Stakeholders
– Client – A medical physics research group
– Developers – NMCRC – Negev Monte Carlo Research Center
– End user – A physicist from the research group, a specialist in fibers made of crystalline silver
halides for middle-infrared (mid-IR) spectroscopy
– Other
2) Objectives (choose one)
– The development process as the objective
– The software product as the objective
174 S. Mark and Y. Lurie / Customized project charter for computational scientific software products

3) Assumptions
The simulation tool will be used to evaluate the feasibility of the fiber development. It is therefore
of vital importance that a suitable and effective criterion for accuracy be selected and that a test
procedure be formulated.
4) Constraints
The simulation tool will be used to assess conditions that today, due to technological limitations,
cannot be applied.
5) Boundaries
The exploration of new compounds, the geometric structures, and the spatial arrangement of the
fiber in order to attain maximum measurement efficiency.
D. Quality

Y
1) Is there another alternative (i.e., the utilization or the reuse of existing software)? Yes/No. If yes,
please specify:

OP
2) Criteria for success
The results from the desired complementary advanced simulation tool will be used to design fibers
that will be an essential component of a medical tool used in forming a clinical diagnostic picture
for a patient; therefore, its accuracy and error-free performance are of prime importance.
3) Verification (choose one method and add references)
C
– Comparison with similar software
– Comparison with known empirical results
– Comparison with known experimental results
OR

Y. Raichlin and A. Katzir, Appl. Spectrosc. 62, 55A (2008).

E. Glossary
– Mid-IR – middle-infrared
– FEWS – fiber evanescent wave spectroscopy
TH

4. Conclusion

This paper presented an approach to the generation of a customized project charter for scientific soft-
ware products (SSP) as a response to the varying perspectives gap. Conceptually we argued that the
AU

customized project charter provides the guiding principles needed for the initial stage, putting the par-
ties in a better position to evaluate their ability to meet the demands of the software’s development. It
is offered as a generic approach to the development of SSP. The charter is a mean for overcoming the
conceptual gap between developer and client. Results of a survey conducted complete these findings.
This is an important step for the achievement of quality, since by addressing the varying perspectives
gap at the very outset of the project management process, one can reduce unwanted dynamics through-
out the development process. Given the absence of a single operational definition for the measurement
of quality, we have focused on the concrete drivers that can actually advance quality value, i.e., QVD -
quality value drivers. More specifically, the actual identification of the key quality value drivers needed
for a given software product requires the prioritization of individuals and team interactions over formal
processes and tools, of piecemeal development of working products over comprehensive grand project
documentation, of stakeholder collaboration and involvement over contract negotiation, and of the abil-
ity to respond to change over a reliance on comprehensive plans. In this paper, through the case study
of the development of simulation software for fiber evanescent wave spectroscopy (FEWS), we have
demonstrated what this modified project charter would look like.
 S. Mark and Y. Lurie / Customized project charter for computational scientific software products 175

References

[1] B. Kitchenham and S.L. Pfleege, Software quality: The elusive target, IEEE Software (1996), 12–21.
[2] J.C. Carver, R.P. Kendall, S.E. Squires and D.E. Post, Software development environments for scientific and engineering
software: A series of case studies, in: International Conference on Software Engineering (2007).
[3] I. Sommerville, Software engineering, New York: Wesley, 2004.
[4] A Guide to the Project – Management Body of Knowledge (PMBOK R
Guide), Fifth Edition, Pennsylvania USA: Project
Management Institute, Inc, 2013.
[5] IEEE Standard Glossary of Software Engineering Terminology (IEEE Std 610.12-1990), IEEE Computer Society (1990),
Los Alamitos, CA, 1990.
[6] R.S. Pressman, Software engineering: A practitioner’s approach, Palgrave Macmillan, 2005.
[7] N. Gorla and S.C. Lin, Determinants of software quality: A survey of information systems project managers, Information
and Software Technology 52(6) (2010), 602–610.

Y
[8] J.A. McCall, P.K. Richards and G.F. Walters, Factors in Software Quality, Volume-III, Preliminary Handbook on Soft-
ware Quality for an Acquisiton Manager, 1977.
[9] R. Petrasch, The definition of software quality: A practical approach, in: In Proceedings of the 10th International Sym-

OP
posium on Software Reliability Engineering November (1999).
[10] O. Korkmaz, I. Akman and S. Ostrovska, Assessing software quality using the markov decision processes, Human
Factors and Ergonomics in Manufacturing & Service Industries 24(1) (2014), 86–104.
[11] M. Diehl, B.D. Leineweber and A. Schäfer, Muscod-II users’ manual, preprint 2001-25, Interdisciplinary Center for
Scientific Computing, University of Heidelberg, 2001.
[12] G.G.A.J.M. Ortega, Scientific Computing and DIfferential Equations – An Introduction to Numerical Methods, San-
Diego, CA: Academic Press, 1992, 3–4.
C
[13] J. Segal, Some problems of professional end user developers, IEEE Visual Languages and Human-Centric Computing
(2007), 111–118.
[14] J. Segal, Models of scientific software development, 2008.
[15] E. Hannay, C. MacLeod, J. Singer, H.P. Langtangen, D. Pfahl and G. Wilson, How do scientists develop and use scientific
OR

software? Software Engineering for Computational Science and Engineering, ICSE Workshop (2009), 1–8.
[16] R. Sanders, The development and use of scientific software, Queen’s University, 2008.
[17] S. Mark and Y. Ronen, The Milne and Numorov methods as independent approaches for solving the Schroedinger
equation: Test case for the deuteron model for odd-odd N = Z nuclei, Physica Scripta 82(4) (2010), 1–8.
[18] C. Dubi, I. Yaar and S. Mark, Two independent approaches used for estimating 2d contamination distribution on the
ground level – based on air monitoring information, Mathematics in Engineering, Science and Aerospace 3(2) (2012),
151–158.
TH

[19] J. Segal and C. Morris, Developing scientific software, IEEE Software 25(4) (2008), 18–20.
[20] N.N. Madras, Lectures on monte carlo methods, Vol. 16, American Mathematical Soc, 2002.
[21] E. Amity, Agile and proffesional ethics, MSc Thesis in Software Engineering, SCE – Shamoon College of Engineering,
Ashdod, Israel, 2014.
[22] V.R. Basili, D. Cruzes, J.C. Carver, L.M. Hochstein, J.K. Hollingsworth and M.V. Zelkowitz, Understanding the high-
AU

performance computing community: A software engineer’s perspective, IEEE Software 25(4) (2008), 29–36.
[23] R. Sanders and D. Kelly, Dealing with risk in scientific software development, IEEE Software 25(4) (2008), 21–28.
[24] L. Nguyen-Hoan, S. Flint and R. Sankaranarayana, A survey of scientific software development, Proceedings of the 2010
ACM-IEEE International Symposium on Empirical Software Engineering and Measurement ACM (2010).
[25] K. Diane and R. Sanders, Assessing the quality of scientific software, in: First International Workshop on Software
Engineering for Computational Science and Engineering (2008).
[26] J.C. Carver et al., Software development environments for scientific and engineering software: A series of case studies,
in: 29th International Conference on Software Engineering (ICSE’07), IEEE (2007).
[27] J. Rajgopal, Principles and applications of operations research, in: Industrial Engineering Handbook, (2004), 11–27.
[28] E. Mnkandla, About software engineering frameworks and methodologies, in: AFRICON, 2009. AFRICON’09, 2009.
[29] W.F. Opdyke, Refactoring Object-Oriented Frameworks, PhD Thesis, University of Illinois, 1992.
[30] D. Khankin, S. Mark and S. Mordechai, Monte Carlo Simulation Tool of Evanescent Waves Spectroscopy Fiber – Optic
Probe for Medical Applications (FOPS 3D), in: Applications of Monte Carlo Methods in Biology Medicine and Other
Fields of Science, INTECH Open Access Publisher, 2011, 357–370.
[31] H. Cohen, D. Khankin, S. Mark and S. Mordechai, Resource management and optimization efficiency issues in a sim-
ulation software package, in: SIMUL 2015, The Seventh International Conference on Advances in System Simulation,
Barcelona, Spain (2016).
[32] M.P. Mann, S. Mark, Y. Raichlin, A. Katzir and S. Mordechai, Optimization of fiber-optic evanescent wave spectroscopy:
A Monte Carlo approach, Applied Spectroscopy 63(9) (2009), 1057–1061.
 176 S. Mark and Y. Lurie / Customized project charter for computational scientific software products

[33] P. Lucas, M.R. Riley, C. Boussard-Plédel and B. Bureau, Advances in chalcogenide fiber evanescent wave biochemical
sensing, Analytical Biochemistry 351(1) (2006), 1–10.
[34] E. Krioukov, D.J.W. Klunder, A. Driessen, J. Greve and C. Otto, Integrated optical microcavities for enhanced
evanescent-wave spectroscopy, Opt Lett 27(17) (2002), 1504–1506.
[35] M.A. Mackanos and C.H. Contag, Fiber-optic probes enable cancer detection with FTIR spectroscopy, Trends in Biotech-
nology 28(6) (2010), 317–323.
[36] C.R. Taitt, G.P. Anderson and F.S. Ligler, Evanescent wave fluorescence biosensors, Biosensors and Bioelectronics
20(12) (2005), 2470–2487.
[37] J.E. Gentle, Random Number Generation and Monte Carlo Methods, Springer, 2003.
[38] J.E. Hannay, C. MacLeod, J. Singer, How do scientists develop and use scientific software? in: SECSE ’09 Proceedings
of the 2009 ICSE Workshop on Software Engineering for Computational Science and Engineering (2009).

Y
C OP
OR
TH
AU

View publication stats