Spelling suggestions: "subject:"documentative"" "subject:"documentive""
1 |
Design of Document-Driven Decision Support SystemsLiu, Yu-liang 10 February 2006 (has links)
Documents are records of activities and related knowledge generated from organizational operations. With the trend of more and more documents being stored in the digital form, how to manage this knowledge has become an important issue. The first step is to manage knowledge is to activate the content of knowledge. These documents stored in an organization can not only be retrieved for future reference but also be analyzed to assist managers in making the right decision. Therefore, it is important for a organization to develop document-driven DSS that can discover useful knowledge from a large amount of documents in an organization.
Most previous research on document management are focused on the indexing, retrieval and mining of documents, few applications have investigate how this technology can be used to construct knowledge for decision support. The purpose of this research is to propose an approach for developing document-driven DSS. In particular, the research proposes a methodology that combines ontology, indexing, and information retrieval technology to develop event scheme that can be used as a basis for the document-driven DSS. A prototype system has been designed to analyze documents collected from a journal ranking exercise to demonstrate the feasibility of the proposed approach.
|
2 |
Case Studies in Document Driven Design of Scientific Computing SoftwareJegatheesan, Thulasi January 2016 (has links)
The use and development of Scientific Computing Software (SCS) has become commonplace
in many fields. It is used to motivate decisions and support scientific research.
Software Engineering (SE) practices have been shown to improve software quality in other
domains, but these practices are not commonly used in Scientific Computing (SC). Previous
studies have attributed the infrequent use of SE practices to the incompatibility of
traditional SE with SC development. In this research, the SE development process, Document
Driven Design (DDD), and SE tools were applied to SCS using case studies.
Five SCS projects were redeveloped using DDD and SE best practices. Interviews with
the code owners were conducted to assess the impact of the redevelopment. The interviews
revealed that development practices and the use of SE varied between the code owners.
After redevelopment, the code owners agreed that a systematic development process can
be beneficial, and they had a positive or neutral response to the software artifacts produced
during redevelopment. The code owners, however, felt that the documentation produced by
the redevelopment process requires too great a time commitment. To promote the use of SE
in SCS development, SE practices must integrate well with current development practices
of SC developers and not disrupt their regular workflow. Further research in this field
should encourage practices that are easy to adopt by SC developers and should minimize
the effort required to produce documentation. / Thesis / Master of Science (MSc)
|
3 |
INVESTIGATING COMMON PERCEPTIONS OF SOFTWARE ENGINEERING METHODS APPLIED TO SCIENTIFIC COMPUTING SOFTWARESrinivasan, Malavika January 2018 (has links)
Scientific Computing (SC) software has significant societal impact due to its application
in safety related domains, such as nuclear, aerospace, military, and medicine.
Unfortunately, recent research has shown that SC software does not always achieve
the desired software qualities, like maintainability, reusability, and reproducibility.
Software Engineering (SE) practices have been shown to improve software qualities,
but SC developers, who are often the scientists themselves, often fail to adopt SE
practices because of the time commitment.
To promote the application of SE in SC, we conducted a case study in which we
developed new SC software. The software, we developed will be used in predicting
the nature of solidification in a casting process to facilitate the reduction of expensive
defects in parts. During the development process, we adopted SE practices and
involved the scientists from the beginning. We interviewed the scientists before and
after software development, to assess their attitude towards SE for SC.
The interviews revealed a positive response towards SE for SC. In the post development
interview, scientists had a change in their attitudes towards SE for SC
and were willing to adopt all the SE approaches that we followed. However, when it
comes to producing software artifacts, they felt overburdened and wanted more tools
to reduce the time commitment and to reduce complexity.
While contrasting our experience with the currently held perceptions of scientific
software development, we had the following observations: a) Observations that
agree with the existing literature: i) working on something that the scientists
are interested in is not enough to promote SE practices, ii) maintainability is a secondary
consideration for scientific partners, iii) scientists are hesitant to learn SE
practices, iv) verification and validation are challenging in SC, v) scientists naturally
follow agile methodologies, vi) common ground for communication has always been
a problem, vii) an interdisciplinary team is essential, viii) scientists tend to choose
programming language based on their familiarity, ix) scientists prefer to use plots to
visualize, verify and understand their science, x) early identification of test cases is
advantageous, xi) scientists have a positive attitude toward issue trackers, xii) SC
software should be designed for change, xiii) faking a rational design process for documentation
is advisable for SC, xiv) Scientists prefer informal, collegial knowledge
transfer, to reading documentation, b) Observations that disagree with the existing
literature: i) When unexpected results were obtained, our scientists chose
to change the numerical algorithms, rather than question their scientific theories,
ii) Documentation of up-front requirements is feasible for SC
We present the requirement specification and design documentation for our software
as an evidence that with proper abstraction and application of “faked rational
design process”, it is possible to document up-front requirements and improve quality. / Thesis / Master of Science (MSc)
|
Page generated in 0.0719 seconds