Spelling suggestions: "subject:"computer softwaredevelopment"" "subject:"computer softwareevelopment""
51 |
SSDE : structured software development environmentNorman, Michael John January 1990 (has links)
Bibliography: pages 219-230. / Software engineers have identified many problem areas regarding the development of software. There is a need for improving system and program quality at design level, ensuring that design costs remain within the budget, and increasing the productivity of designers. Structured Software Development Environment (SSDE) provides the system designer with an interactive menu-driven environment, and a framework within which he can conveniently express and manipulate his proposed solution. This representation is in terms of both a conceptual model and a detailed software logic definition. Thus SSDE provides tools for both high-level (or logical) and low-level (or physical) design. It allows a user to follow his own preferred methodology rather than restricting him to one specific strategy. SSDE builds and maintains databases that record all design decisions. It provides the system designer with a mechanism whereby systems can easily be modified and new systems can evolve from similar existing systems. There are several auxiliary facilities as productivity aids. SSDE generates PASCAL code for low-level design constructs, ·full documentation of both the high- and low-level designs for inclusion in the project file, as well as a skeleton manual. The system was evaluated by a number of independent users. This exercise clearly demonstrated its success as an aid in expressing, understanding, manipulating and solving software development problems.
|
52 |
Quality management challenges in iterative software product development of a selected software development organisation in Cape Town, South AfricaChipunza, Enciliah January 2018 (has links)
Thesis (MTech (Business Information Systems))--Cape Peninsula University of Technology, 2018. / Many software organisations using iterative software development approach use practices that relate to quality management. However, the quality management process has been inadequate. Despite many research studies conducted on quality management in iterative software product development none have adequately addressed the challenges and mitigation techniques to have an adequate process that leads to a quality software product. The objective of this study was to determine factors that affect the quality management process in iterative software development. The research followed a qualitative approach, a case of software organisation SasTech in Cape Town, South Africa. 22 interviews were conducted on three roles actively involved in the software product development process. These are product management, quality assurance and software developers. Themes were drawn from results and were tabulated. The duality of technology theory was used as a theoretical lens to data analysis.
Several factors were identified to influence the software quality management process. These include planning, documentation, process ownership, technologies, testing, timelines and management support.
Through the general proposed framework, facilities (human resources and technologies), interpretive schemes (architecture) and norms (practices) of software quality management can be institutionalised leading to adequate and effective quality management in iterative development for SasTech as well as other organisations in the same industry.
|
53 |
Moops: A web implementation of the Personal Software Process reporting systemGigler, Thomas Russell, III. 01 January 2008 (has links)
The purpose of Moops is to bridge the gap between PSP Scriber, geared very specifically to the CSCI655 class, and other available PSP implications which are so general they are difficult to use immediately without valuable time spent learning the software. Moops is a PHP/MySQL based web application designed to provide the students taking the CSCI655 graduate software engineering course at CSUSB with an intuitive, easy to use tool to implement the Personal Software Process (PSP). Moops eliminates the possibility of errors in calculations by completing all calculations for the user.
|
54 |
Risk management in software developmentLabuschagne, Mariet 01 1900 (has links)
This dissertation discusses risk management in the context of software development.
It commences by investigating why so many software development projects fail. It
then focuses on approaches to software development that emerged as attempts to
improve the success rate. A common shortcoming to these approaches is identified,
namely that they only cater for the tasks that need to be done, ignoring possible
unexpected problems. After having motivated the need for risk management, the
framework for a risk management methodology is discussed, outlining the steps in
the risk management process. Decision-making guidelines and best practices follow,
as well as a discussion about the way they should be implemented as part of the risk
management effort. Guidelines are provided for the implementation of risk
management as part of software development. Finally, the risks that may cause the
failure of the implementation of risk management are identified and guidelines
provided to address them. / Computing / M. Sc. (Information Systems)
|
55 |
The Knowledge Integration Tool : a knowledge based system development environmentNewcomb, Philip H. January 1988 (has links)
The current generation of conventional software productivity tools is likely to achieve at most a factor of two reduction in life-cycle costs by the early 1990s. With projected order of magnitude increases in system complexity and size, a far greater improvement (factor of 10 or higher) is needed. Significant cost reductions and qualitative improvements for many kinds of applications can be demonstrated by means of a knowledge-based integrated tool environment that both adheres to the software development standards of the software development organization and promotes rapid development of high quality knowledge-based systems and their integration within highly specialized application environmentsThis investigation has led to the construction of the (K)nowledge (I)ntegration (T)ool, an operational testbed and architectural framework for the rapid development of highly extensible artificial intelligence systems and environments that both support the conventional life-cycle paradigm and facilitate the evolution of a knowledge-based life-cycle paradigm. A knowledge-based system is a programming system characterized by the ease with which objects, the relationships between them, and higher-level concepts composed of such objects and relationships, are manipulated and presented graphically and textually. The KIT consists of: knowledge-based integrated tool environments, integrated assemblages of knowledge-based systems that possess a man-machine interface that adjusts to the needs of individual users by means of user-profile and application-specific information; and a knowledge-based based system development environment, a knowledge-based system that supports the construction and maintenance of software systems, and acts as a mechanism to improve the reliability of the software development process. This thesis describes the synthesis of these system types in the KIT.Following the KIT's successful prototyping and demonstration, it is being scaled up and incrementally developed to provide life-cycle automation capabilities for a roboticized factory of a major aerospace company. In this thesis the historical and theoretical foundations, capabilities, current and planned uses of the KIT are described.Key Words: Artificial Intelligence, Knowledge Base, Life-cycle Automation, Knowledge-Based Environment, Knowledge-Based Systems, Knowledge-Based Project Management, Knowledge-Based Configuration Management, Knowledge-Based System Development, Knowledge-Based Software Engineering. / Department of Computer Science
|
56 |
Quantifying Design Principles in Reusable Software ComponentsMoore, Freeman Leroy 12 1900 (has links)
Software reuse can occur in various places during the software development cycle. Reuse of existing source code is the most commonly practiced form of software reuse. One of the key requirements for software reuse is readability, thus the interest in the use of data abstraction, inheritance, modularity, and aspects of the visible portion of module specifications. This research analyzed the contents of software reuse libraries to answer the basic question of what makes a good reusable software component. The approach taken was to measure and analyze various software metrics as mapped to design characteristics. A related research question investigated the change in the design principles over time. This was measured by comparing sets of Ada reuse libraries categorized into two time periods. It was discovered that recently developed Ada reuse components scored better on readability than earlier developed components. A benefit of this research has been the development of a set of "design for reuse" guidelines. These guidelines address coding practices as well as design principles for an Ada implementation. C++ software reuse libraries were also analyzed to determine if design principles can be applied in a language independent fashion. This research used cyclomatic complexity metrics, software science metrics, and traditional static code metrics to measure design features. This research provides at least three original contributions. First it collects empirical data about existing reuse libraries. Second, it develops a readability measure for software libraries which can aid in comparing libraries. And third, this research developed a set of coding and design guidelines for developers of reusable software. Future research can investigate how design principles for C++ change over time. Another topic for research is the investigation of systems employing reused components to determine which libraries are more successfully used than others.
|
57 |
Fuzzy logic, estimated null values and their application in relational databasesPowell, Susan E. January 1986 (has links)
Call number: LD2668 .T4 1986 P68 / Master of Science / Computing and Information Sciences
|
58 |
Design of a seismic data acquisition system and automatic triggering softwareCole, Robert, Sidney John January 1991 (has links)
A dissertation submitted to the Faculty of Science, University of the Witwatersrand, Johannesburg, for the degree Master of Science / The recording of seismic signals in remote areas requires a portable, low
power recording system that can be left in the field for a few weeks at a time.
Three components of ground motion are generally measured, and some form
of event recording, rather than continuous recording should be available. [Abbreviated abstract. Open document to view full version] / AC2017
|
59 |
A Decision Support System for Sprint Planning in Scrum PracticeUnknown Date (has links)
Scrum is one of the Agile software development processes broadly adopted in industry. Scrum promotes frequent customer involvements and incremental short release. Sprint planning is a critical step in Scrum that sets up next release goals and lays out plans to achieve those goals. This thesis presents a Sprint Planning dEcision Support System (SPESS) which is a tool to assist the managers for Sprint planning. Among considering other Sprint planning factors, SPESS takes into consideration developer competency, developer seniority and task dependency. The results are that the assignments of the tasks of each Sprint to developers guarantee that each team member contributes to their fullest potential, and project planning is optimized for the shortest possible time. Keywords—Scrum, Sprint planning, planning poker, competence, task dependence, Hungarian algorithm, Essence. / Includes bibliography. / Thesis (M.S.)--Florida Atlantic University, 2018. / FAU Electronic Theses and Dissertations Collection
|
60 |
Rapid prototyping of software specifications in Z.January 1993 (has links)
by Wu Chun Pong. / Thesis (M.Phil.)--Chinese University of Hong Kong, 1993. / Includes bibliographical references (leaves 86-[91]). / Chapter 1 --- Introduction --- p.1 / Chapter 1.1 --- Formal Specification Methods --- p.1 / Chapter 1.2 --- The Z notation --- p.2 / Chapter 1.3 --- Overview of Thesis --- p.3 / Chapter 2 --- The Specification Language Z --- p.5 / Chapter 2.1 --- Background --- p.5 / Chapter 2.2 --- Structure and Characteristics --- p.6 / Chapter 2.3 --- Object Orientation in Z --- p.10 / Chapter 2.3.1 --- Hall's style --- p.11 / Chapter 2.3.2 --- Schuman and Pitt's variant --- p.11 / Chapter 2.3.3 --- Object-Z --- p.12 / Chapter 2.4 --- Execution in Z --- p.13 / Chapter 2.5 --- Animation of Z Specifications --- p.15 / Chapter 2.5.1 --- Prolog --- p.15 / Chapter 2.5.2 --- Translation Z into Prolog --- p.18 / Chapter 2.5.3 --- Related Works --- p.19 / Chapter 3 --- Incorporating Real Numbers in Z --- p.22 / Chapter 3.1 --- Dedekind Cut --- p.23 / Chapter 3.2 --- Cantor's definition --- p.23 / Chapter 3.3 --- Practical approach --- p.24 / Chapter 4 --- Constraint Logic Programming and CLP(R) --- p.26 / Chapter 4.1 --- Constraint Logic Programming --- p.26 / Chapter 4.2 --- CLP(R) --- p.27 / Chapter 4.3 --- Example of CLP(R) --- p.29 / Chapter 5 --- The ZCLP(R) Animation System --- p.31 / Chapter 5.1 --- Design Philosophy --- p.31 / Chapter 5.2 --- Implementation Strategy --- p.34 / Chapter 5.3 --- Z editor (ZEDIT) --- p.36 / Chapter 5.4 --- Prolog Library for set operation (ZCLIB) --- p.37 / Chapter 5.4.1 --- Basic needs for the Library --- p.37 / Chapter 5.4.2 --- Rules for the library --- p.38 / Chapter 5.4.3 --- Limitation of the Library --- p.43 / Chapter 5.5 --- Z to CLP(R) Translator (ZCGEN) --- p.44 / Chapter 5.5.1 --- Procedure for translation --- p.45 / Chapter 5.5.2 --- Demonstration --- p.47 / Chapter 5.5.3 --- Rules for translation --- p.48 / Chapter 5.5.4 --- Limitations of the Translator --- p.50 / Chapter 5.6 --- Z to LATEX translator (ZLATEX) --- p.52 / Chapter 6 --- Examples --- p.54 / Chapter 6.1 --- A Simple Banking System --- p.54 / Chapter 6.1.1 --- Bags --- p.54 / Chapter 6.1.2 --- Specifications --- p.56 / Chapter 6.2 --- A Graphics Example --- p.61 / Chapter 6.2.1 --- Defining a Rectangle --- p.62 / Chapter 6.2.2 --- Drawing a Rectangle --- p.63 / Chapter 6.2.3 --- Defining a Circle --- p.63 / Chapter 6.2.4 --- Specifications --- p.64 / Chapter 6.3 --- Specifications Writing Experience --- p.76 / Chapter 7 --- Conclusion --- p.79 / Chapter 7.1 --- Contributions --- p.79 / Chapter 7.2 --- Difficulties --- p.83 / Chapter 7.3 --- Further Works --- p.84 / Bibliography --- p.86
|
Page generated in 0.079 seconds