• Refine Query
  • Source
  • Publication year
  • to
  • Language
  • 120
  • 104
  • 29
  • 12
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 1
  • 1
  • 1
  • Tagged with
  • 341
  • 341
  • 341
  • 112
  • 105
  • 87
  • 78
  • 60
  • 56
  • 47
  • 46
  • 46
  • 40
  • 40
  • 39
  • About
  • The Global ETD Search service is a free service for researchers to find electronic theses and dissertations. This service is provided by the Networked Digital Library of Theses and Dissertations.
    Our metadata is collected from universities around the world. If you manage a university/consortium/country archive and want to be added, details can be found on the NDLTD website.
31

Pitfalls and guide lines in the transition to object oriented software design methodologies

Jansen van Rensburg, Miranda January 1998 (has links)
A research report submitted to the Faculty of Engineering, University of the Witwatersrand, Johannesburg, in partial fulfilment of the requirements for the degree of Master of Science in Engineering. / Due to the dynamic nature of the software engineering industry there is a constant move towards new strategies for solving design problems. More specifically there is a move towards Object Oriented (OO) methodologies, presumably because of the various advantages offered in terms of maintainability, and reuse of code produced this way. As with various other aspects of the software industry there are however also problems encountered in this transition and lessons to be learned from the experience of companies who have already performed this change. This research report investigates possible guidelines for companies who are currently contemplating a change to the OO software design methodologies, by covering a collection of issues one should know about prior to this change. It also summarises the problems faced in the transition so far, the reasons for these problems and suggests possible solutions. Lastly it also investigates new trends in the OO arena. The emphasis is on South African companies and projects. The results obtained are compared with results obtained overseas to find out what the differences and similarities are. Areas of concern are also identified, where theoreticians' views have been ignored, and both South African and overeeas companies have not implemented any of the suggestions made. / Andrew Chakane 2018
32

A generalized software environment for developing decision support systems.

January 1988 (has links)
by Liu Shu Cheung, Jimmy. / Thesis (M.Ph.)--Chinese University of Hong Kong, 1988. / Bibliography: leaves 61-64.
33

Quality prediction for component-based software development: techniques and a generic environment.

January 2002 (has links)
Cai Xia. / Thesis (M.Phil.)--Chinese University of Hong Kong, 2002. / Includes bibliographical references (leaves 105-110). / Abstracts in English and Chinese. / Chapter 1 --- Introduction --- p.1 / Chapter 1.1 --- Component-Based Software Development and Quality Assurance Issues --- p.1 / Chapter 1.2 --- Our Main Contributions --- p.5 / Chapter 1.3 --- Outline of This Thesis --- p.6 / Chapter 2 --- Technical Background and Related Work --- p.8 / Chapter 2.1 --- Development Framework for Component-based Software --- p.8 / Chapter 2.1.1 --- Common Object Request Broker Architecture (CORBA) --- p.9 / Chapter 2.1.2 --- Component Object Model (COM) and Distributed COM (DCOM) --- p.12 / Chapter 2.1.3 --- Sun Microsystems's JavaBeans and Enterprise JavaBeans --- p.14 / Chapter 2.1.4 --- Comparison among Different Frameworks --- p.17 / Chapter 2.2 --- Quality Assurance for Component-Based Systems --- p.199 / Chapter 2.2.1 --- Traditional Quality Assurance Issues --- p.199 / Chapter 2.2.2 --- The Life Cycle of Component-based Software Systems --- p.255 / Chapter 2.2.3 --- Differences between components and objects --- p.266 / Chapter 2.2.4 --- Quality Characteristics of Components --- p.27 / Chapter 2.3 --- Quality Prediction Techniques --- p.32 / Chapter 2.3.1 --- ARMOR: A Software Risk Analysis Tool --- p.333 / Chapter 3 --- A Quality Assurance Model for CBSD --- p.35 / Chapter 3.1 --- Component Requirement Analysis --- p.38 / Chapter 3.2 --- Component Development --- p.39 / Chapter 3.3 --- Component Certification --- p.40 / Chapter 3.4 --- Component Customization --- p.42 / Chapter 3.5 --- System Architecture Design --- p.43 / Chapter 3.6 --- System Integration --- p.44 / Chapter 3.7 --- System Testing --- p.45 / Chapter 3.8 --- System Maintenance --- p.46 / Chapter 4 --- A Generic Quality Assessment Environment: ComPARE --- p.48 / Chapter 4.1 --- Objective --- p.50 / Chapter 4.2 --- Metrics Used in ComPARE --- p.53 / Chapter 4.2.1 --- Metamata Metrics --- p.55 / Chapter 4.2.2 --- JProbe Metrics --- p.57 / Chapter 4.2.3 --- Application of Metamata and Jprobe Metrics --- p.58 / Chapter 4.3 --- Models Definition --- p.61 / Chapter 4.3.1 --- Summation Model --- p.61 / Chapter 4.3.2 --- Product Model --- p.62 / Chapter 4.3.3 --- Classification Tree Model --- p.62 / Chapter 4.3.4 --- Case-Based Reasoning Model --- p.64 / Chapter 4.3.5 --- Bayesian Network Model --- p.65 / Chapter 4.4 --- Operations in ComPARE --- p.66 / Chapter 4.5 --- ComPARE Prototype --- p.68 / Chapter 5 --- Experiments and Discussions --- p.70 / Chapter 5.1 --- Data Description --- p.71 / Chapter 5.2 --- Experiment Procedures --- p.73 / Chapter 5.3 --- Modeling Methodology --- p.75 / Chapter 5.3.1 --- Classification Tree Modeling --- p.75 / Chapter 5.3.2 --- Bayesian Belief Network Modeling --- p.80 / Chapter 5.4 --- Experiment Results --- p.83 / Chapter 5.3.1 --- Classification Tree Results Using CART --- p.83 / Chapter 5.3.2 --- BBN Results Using Hugin --- p.86 / Chapter 5.5 --- Comparison and Discussion --- p.90 / Chapter 6 --- Conclusion --- p.92 / Chapter A --- Classification Tree Report of CART --- p.95 / Chapter B --- Publication List --- p.104 / Bibliography --- p.105
34

Software composition with extended entity-relationship diagrams

Muenchaisri, Pornsiri 14 November 1997 (has links)
I introduce a compositional approach to application software development. In this approach, an extended entity-relationship diagram (EERD), which represents the component types and the relationship types within an application domain, is used as a template of executable programs in that application domain. As we use structural active objects as the components of a program, we can obtain an executable program if those components are instantiated and interconnected as dictated by an EERD. Furthermore, the graphical editor in the proposed software development environment, entity-relationship software development environment (ERSDE), uses EERDs as menus in constructing application software. An EERD used as a menu can enforce legitimate patterns of relationships among components, in addition to providing an intuitive view of available components and possible relationships among them. Two experiments were conducted in order to compare the effectiveness between EERDs and class diagrams of Object Modeling Technique (OMT) and between the ERSDE and the menu-based Structural-Active Object System (SAOS) graphical editors. From these experiments, we obtained the following results. 1. A significant proportion of the subjects who used EERDs to compose certain applications did so correctly, while only a small proportion of the students who used the OMT class diagrams composed these applications correctly. 2. Most of the subjects preferred EERDs to OMT class diagrams as design documents. 3. Although the proportion of the students who composed applications correctly with the ERSDE application editor was larger than the proportion of the students who did so with the menu-based SAOS graphical editors, this difference was statistically not significant. 4. The subjects took significantly longer time to compose applications with the menu-based SAOS editors than with the ERSDE editor. 5. All the subjects preferred the ERSDE application editor to the menu-based SAOS graphical editors as a software development environment. / Graduation date: 1998
35

Integration of model checking into software development processes

Xie, Fei 28 August 2008 (has links)
Not available / text
36

Mining and tracking in evolving software

Breu, Silvia January 2013 (has links)
No description available.
37

Usability and viability of the dynamic help toolkit

Robertson, Susan Reinhard 08 1900 (has links)
No description available.
38

Goal identification and refinement in the specification of software-based information systems

Anton, Ana I. January 1997 (has links)
No description available.
39

Model-based analogy in innovative device design

Bhatta, Sambasiva R. January 1996 (has links)
No description available.
40

Creating an Ada module description tool

Rice, Richard M. January 1988 (has links)
The purpose of this project was to develop, using Object Oriented Development (OOD), a software tool identified as the Ada Module Description Tool (AMDT). The AMDT provides an automated way to get a module level description of Ada code. A module level description will identify packages, subprograms, objects and type declarations and relationships. This software tool also has the ability to compare Ada source code with a module level description. The comparison shall identify any object, type, subprogram, or package declared in the module level description that does not match the provided source code.The AMDT is made up of two executable programs that run on a VAX/VMS system. The Module Description Generator (MDG) generates a module level description from a set of Ada source code files. The Module Description Checker (MDC) compares a module level description to the Ada source code. Ada is the required High Order Language for the Department Of Defense. The development methodology used was basically Object Oriented Development as described in the book Software Engineerinq With-AAA by Grady Booch and the Software Standards and Procedure Manual for Object Oriented Development (SSPM-M02.04 Draft).Booch's book is a description of Object Oriented Development methodology, while the SSPM is a set of instructions and standard format to implement the methodology. The total design of the AMDT is documented in five segments. The SSPM defines a segment as the code and documentation resulting from a pass through the OOD process. From a Software Quality Engineer's point of view the AMDT would save time in not having to check module descriptions by hand. From the Software Engineer's point of view, when the code is updated a new module description can be generated easily to keep the documentation current with the code. The AMDT tool as written does not find object declarations in the code. Fortunately the effect is minor because the module descriptions needs to be edited anyway. The module description generated by the MDG may have too much information in it. The designer wants only the types, objects, and operations that aid in the understandability of the design and how it is implemented. The only checks the MDC makes are to see if an identifier on the module description is in the code. It does not check to see if there are extra items in the code that should be required in the module description. / Department of Computer Science

Page generated in 0.0673 seconds