Page 162 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Principles of Software Engineering

Notes Where fan_in represents the number of modules that call this module and fan_out is the number
of modules this module calls. The main question that arises is how good these metrics are.
For “good,” we will have to define their purpose, or how we want to use them. Just having a
number signifying the complexity is, in itself, of little use, unless it can be used to make some
judgment about cost or quality. One way to use the information about complexity could be to
identify the complex modules, as these modules are likely to be more error prone and form
“hot spots” later, if they are left as is. Once these modules are identified, the design can be
evaluated to see if the complexity is inherent in the problem or if the design can be changed to
reduce the complexity. To identify modules that are “extra complex,” we will have to define
what complexity number is normal. Having a threshold complexity above which a module is
considered complex assumes the existence of a globally accepted threshold value. This may not
be possible, as designs in different problem domains produce different types of modules. Another
alternative is to consider a module against other modules in the current design only, instead of
comparing the modules against a prespecified standard. That is, evaluate the complexity of the
modules in the design and highlight modules that are, relatively speaking, and more complex. In
this approach, the criterion for marking a module complex is also determined from the current
design. One such method for highlighting the modules was suggested. Let avg _complexity be
the average complexity of the modules in the design being evaluated and let std_deviation be
the standard deviation in the design complexity of the modules of the system. The proposed
method classifies the modules in three categories: error-prone, complex, and normal. If D , is
c
the complexity of a module.
Validation metrics must be established during the validation requirement
phase of the conceptual model development and should include estimates of
the numerical and experimental error.

The NENE Code Project

he Defence Advanced Research Projects Agency (DARPA) High Productivity
Computing Systems (HPCS) Program is sponsoring a series of case studies to
Tidentify the life cycles, workflows, and technical challenges of computational science
and engineering code development that are representative of the program’s participants.
A secondary goal is to characterize how software development tools are used and what
enhancements would increase the productivity of scientific-application programmers.
These studies also seek to identify “lessons learned”? That can be transferred to the general
computational science and engineering community to improve the code development process.
The NENE code is the fifth science-based code project to be analyzed by the Existing Codes
sub team of the DARPA HPCS Productivity Team. The NENE code is an application code
for analyzing scientific phenomena and predicting the complex behaviour and interaction
of individual physical systems and individual particles in the systems. The core NENE
development team is expert, agile, and of moderate size, consisting of a professor and another
permanent staff member, five post docs, and 11 graduate students. NENE is an example of
a distributed development project; the core team is anchored at a university, but as many
as 250 individual researchers have made contributions from other locations.

Questions
1. What is the NENE Code Project?
2. What is the DARPA?

156 LOVELY PROFESSIONAL UNIVERSITY