Fuzzy Logic Based Computational Technique for Analyzing Software Bug Repository

Cybersecurity risks are increasing in frequency and complexity, but many organizations struggle to plan and implement adequate protections at all stages of the software development life cycle (SDLC). Security is frequently added at the end of development (afterthought), and making effective use of safeguard space is difficult for IT leaders. The purpose of this study is to produce an all‐encompassing framework to adopt and ensure security throughout each phase of the SDLC, from planning through maintenance. The aim is to minimize vulnerabilities and improve the resilience of software by making “security by design” a structure that not only adopts security elegantly as a living document but also is built to be part of the development process. This study adopted a mixed‐methods approach. The initial stage of inquiry involved a systematic literature review (SLR) to identify common cybersecurity issues associated with each SDLC phase. The SLR was followed by an empirical survey of 71 software professionals from a variety of organizations. The survey was designed to gather perceived threats, current practices, and challenges associated with software development for survey participants' organizations. The data collected were analyzed and reviewed statistically, through chi‐square tests and ANOVA, to profile the variance relative to the size of the organization, geographic region, and experience level of the practitioner. The results noted several high‐risk challenges across the SDLC: underfunded security controls, imprecise requirements, insecure architecture, software bugs (i.e., injection vulnerabilities), inadequate testing, misconfigured production environments, and unreliable maintenance. The proposed framework provides cybersecurity mitigation techniques for each stage of the SDLC, such as leveraging security‐oriented design patterns, secure coding policies (i.e., input validation and authentication protocols), robust testing (i.e., penetration testing and code review), and continuous monitoring after deployment. The implementation of these measures leads to a significant risk reduction in the overall organizational security posture. The framework is a formalized end‐to‐end approach to secure software development by embedding security throughout the cycle. Embedding security as a part of the process versus an afterthought at every stage of the cycle creates a risk reduction impact. This integrated approach also provides organizations with the opportunity to foresee and mitigate events earlier in the cycle, along with general compliance mandates (i.e., GDPR, HIPAA, and PCI‐DSS), to provide more resilient, trustworthy software systems.

Tracing known security vulnerabilities in software repositories – A Semantic Web enabled modeling approach

MARVEL is a kernel for software development environments that enacts a processing modeling notation, called the MARVEL Strategy Language (MSL). The software process is defined in MSL as a collection of modular strategies, where different (sets of these) strategies are appropriate for different tool suites, user roles, phases of the lifecycle, management policies, etc. Each strategy specifies a partial object-oriented data model and a partial rule-based process model. The strategies are supplemented by a collection of envelopes, each of which describes how to apply one or more of the external tools used during software development activities; this includes the mapping from the inputs/outputs of these tools and the MARVEL objectbase and the command lines to invoke these tools. Multiple MSL strategies are merged to obtain the full data and process models for enaction by the MARVEL kernel.Each software development activity is described in MSL by a rule specifying the precondition and multiple postconditions of the activity. Both preconditions and postconditions are written in a subset of the first order predicate logic, stylized to incorporate directives for efficient queries and updates. A precondition is a logical statement that must be true before the activity is initiated; a postcondition is a logical statement asserted to be true when the activity completes. Multiple mutually exclusive postconditions reflect the multiple possible results of many activities. An activity is typically a particular combination of software development tool, options specific to that tool, and typed arguments. The notion of activity could be extended to include loading a new set of strategies to take over at this point in the process, to support both nesting of hierarchical activities and successive activity phases.Enaction of an MSL process model is implemented by what we call opportunistic processing, consisting primarily of forward and backward chaining among the rules. When a user initiates an activity, MARVEL applies backward chaining to attempt to satisfy its precondition. If this is not possible, MARVEL could use the rules in the style of an expert system to explain the problem. Once an activity has completed, MARVEL asserts one of its postconditions and uses forward chaining to automatically carry out other activities whose results are presumed to be needed in the near future.We have designed two facilities for controlling this processing, to prevent runaway automation. Hints are additional MSL preconditions that affect automatic but not user-initiated invocation of tools. Implicit queries represent a reflective capacity to keep tabs on estimated costs of automatic behavior and request user confirmation when certain user-selected thresholds are reached.MARVEL version 2.10 was recently completed, an upgrade over the version 2.01 that was demonstrated at the 3rd PSDE conference in November 1988. This latest version of MARVEL adds an X11 windows graphical user interface and new subsystems called Marvelizer and Organ. Marvelizer is a tool for immigrating existing software systems from the Unix file system or (a restricted class of) existing software development environment into a MARVEL objectbase. Organ is a set of commands for reorganizing MARVEL objectbases as the project and/or system structure evolves. Marvelizer has been used to immigrate Marvel itself, including about 35,000 lines of C code, into a C/Marvel objectbase. We would like to use the C/Marvel set of MSL strategies, which support activities using the user's favorite editor, lint, cc, ar, ranlib, less (and soon rcs, dbx and mail), for our own further development of MARVEL. Both MARVEL and C/Marvel were in use during the Spring 1989 semester by students in my E6123y Programming Environments and Software Tools course (admittedly a captive audience).We have discovered several difficulties with the MARVEL paradigm that seem likely to apply at least partially to enaction of other notations for software process modeling. First, constructing and debugging a process model is hard. We have run into many unanticipated interactions among rules, particularly among those defined in different strategies that happen to be loaded into the MARVEL kernel at the same time. We are working on debugging facilities that will uncover all direct and transitive dependencies by constructing a graphical dataflow graph of the currently loaded rules. It is feasible for a user to enable and disable individual rules, both during debugging to see how that affects the dataflow among rules and also during operation because certain behavior is not currently desired. This would be dangerous, however, if done by a naive user: if rules were turned off and on at arbitrary points, it would be possible for MARVEL to get into what is an inconsistent state with respect to the full set of rules in such a way that automatic recovery is impossible.Similar difficulties seem likely to arise for any enactable process modeling paradigm. The following questions need to be answered: How does an implementor go about writing, testing and debugging a process model? For non-trivial processes, the model is likely to be very large and hence should be modularized. What is the appropriate style of interface among process model modules and how is it enforced? Is the process model visible to the users and, if so, how is it presented? If the users can modify the process model during enaction, how does this affect continuing the process? Should (can) consistency be enforced or should (can) inconsistencies be detected and repaired?Second, constructing envelopes is even harder. We currently use the Shell languages (e.g., CShell) as notations for defining envelopes. Writing the Shell scripts requires an intimate knowledge of both the tool and the mapping of the MARVEL objectbase onto the file system. Although there is no way to avoid the former, we hope to minimize the latter by developing a higher level envelope language that understands the MARVEL objectbase implementation so the envelope writer doesn't have to. However, this is currently a relatively low priority due to lack of manpower.Again, similar difficulties seem inevitable for other enaction mechanisms intended to work with external tools. The questions: Is it possible (or desirable) to support existing tools, particularly tools where retrofitting is impractical? If only new tools are supported, can a relatively simple standard interface be developed and published so these tools can be developed separately by vendors? Would such an interface pre-empt too many design decisions, or would it be feasible for vendors to upgrade their current products?Third, supporting multiple users is hardest of all. The current MARVEL kernel does not provide any facilities for concurrency control. It would be easy to add locking of the entire objectbase, but a more flexible transaction model is needed. We are working on a number of alternative models that we think are promising for incorporation into the MARVEL kernel. Commit-serializability introduces two new transaction operations, split-transaction and join-transaction, that manipulate in-progress transactions to support coordination among multiple users. Participant transactions (AKA participation domains) distinguishes participants in group software development tasks from observers, and relaxes serializability as viewed by participants to permit cooperation.It is essential for enactable process models to support coordination and cooperation among the members of software development teams. There are two sets of questions: First, what are appropriate processes for programming-in-the-many? This is itself an active area of research, and there is certainly no consensus. One opinion, voiced at the previous workshop, is that the community should not be enacting process models until we understand the processes we are modeling. An opposing opinion is that enaction gives the community the capability to experiment with different processes without prematurely making a full scale commitment to a particular process. Assuming agreement with the second view, what process modeling notations and enaction mechanisms can support a reasonable range of cooperative work facilities?The database and operating system communities have agreed on atomic and serializable transactions, which can be implemented using a wide variety of technologies, as the basis for data consistency, failure recovery and concurrency control across their traditional application areas. Can the software engineering community develop an equally all-encompassing “transaction” model? Or is there some characteristic of the software development process such that coordination and cooperation policies will always require special support on a case-by-case basis? If so, what does this say about enaction of process models in general?In summary, MARVEL is implemented and in limited use, it works in some cases, it doesn't work in others, it raises a lot of questions, and both we the MARVEL group and we the software engineering community have a lot more work to do.

The design of accounting information systems for non-profit entities to improve accountability in presenting the mosque's financial statements. Non-profit entity accounting information system using Enterprise Resources Planning (ERP) is odoo accounting. Approach to ERP methodology using ASAP (Accelerated SAP) methodology, software development stage using Software Development Life Cycle (SDLC), in design using DFD and system flowchart. Keywords: Accountability; Non-Profit Entity; Enterprise Resources Planning; Financial statements; Odoo Accounting; Accounting Information System Design.

A fuzzy logic based approach for phase-wise software defects prediction using software metrics

AOSD (Aspect Oriented Software Development) is an emerging discipline in Software Engineering. It focuses on the separation of concerns of the ’70s, aiming at improving modularity, to ensure maintainability in the sense of extensibility, changeability and reuse, towards an evolutionary software product responding to a more dynamic environment. The AOP (Aspect Oriented Programming) paradigm of the ’90s focuses on the separation of the crosscutting concerns, which are in general non functional requirements (quality requirements). It is now of general agreement that the entanglement and scattering of concerns must be handled early in the software life cycle. However, these aspects are inherent to all the stages of software development, from requirements elicitation to code implementation. Many concepts and mechanisms have been proposed to handle properly these issues; however terms are in general semantically slightly dierent in each discipline where they have been formulated and used, causing misunderstanding and confusion. This paper presents an AOSD UML core for early aspects (requirements, analysis and design disciplines), constructed gathering dierent modelling elements found in the literature, focusing particularly on the AOSD ontolgy document of the Common Foundation for AOSD of the European Community, and dierent

The quality of software is enormously affected by the faults associated with it. Detection of faults at a proper stage in software development is a challenging task and plays a vital role in the quality of the software. Machine learning is, now a days, a commonly used technique for fault detection and prediction. However, the effectiveness of the fault detection mechanism is impacted by the number of attributes in the publicly available datasets. Feature selection is the process of selecting a subset of all the features that are most influential to the classification and it is a challenging task. This paper thoroughly investigates the effect of various feature selection techniques on software fault classification by using NASA’s some benchmark publicly available datasets. Various metrics are used to analyze the performance of the feature selection techniques. The experiment discovers that the most important and relevant features can be selected by the adopted feature selection techniques without sacrificing the performance of fault detection.

Despite the extensive adoption of crowdsourcing for the timely, cost-effective, and high-quality completion of software development tasks, a large number of crowdsourced challenges are not able to acquire a winning solution, on time, and within the desired cost and quality thresholds. A possible reason for this is that we currently lack a systematic approach that would aid software managers during the process of designing software development tasks that will be crowdsourced. This paper attempts to extend the current knowledge on designing crowdsourced software development tasks, by empirically answering the following management questions: (a) what type of projects should be crowdsourced; (b) why should one crowdsource-in terms of acquired benefits; (c) where should one crowdsource-in terms of application domain; (d) when to crowdsource-referring to the time period of the year; (e) who will win or participate in the contest; and (f) how to crowdsource (define contest duration, prize, type of contest etc.) to acquire the maximum benefits-depending on the goal of crowdsourcing. To answer the aforementioned questions, we have performed a case study on 2,209 software development tasks crowdsourced through TopCoder platform. The results suggest that there are significant differences in the level to which crowdsourcing goals are reached, across different software development activities. Based on this observation we suggest that software managers should prioritize the goals of crowdsourcing, decide carefully upon the activity to be crowdsourced and then define the settings of the task.

In Software Development Life Cycle, fixing defect bugs is one of the essential activities of the software maintenance phase. Bug severity indicates how major or minor the bug impacts on the execution of the system and how rapidly the developer should fix it. Triaging a vast amount of new bugs submitted to the software bug repositories is a cumbersome and time-consuming process. Manual triage might lead to a mistake in assigning the appropriate severity level for each bug. As a consequence, a delay for fixing severe software bugs will take place. However, the whole process of assigning the severity level for bug reports should be automated. In this paper, we aim to build prediction models that will be utilized to determine the class of the severity (severe or non-severe) of the reported bug. To validate our approach, we have constructed a dataset from historical bug reports stored in JIRA bug tracking system. These bug reports are related to different closed-source projects developed by INTIX Company located in Amman, Jordan. We compare eight popular machine learning algorithms, namely Naive Bayes, Naive Bayes Multinomial, Support Vector Machine, Decision Tree (J48), Random Forest, Logistic Model Trees, Decision Rules (JRip) and K-Nearest Neighbor in terms of accuracy, F-measure and Area Under the Curve (AUC). According to the experimental results, a Decision Tree algorithm called Logistic Model Trees achieved better performance compared to other machine learning algorithms in terms of Accuracy, AUC and F-measure with values of 86.31, 0.90 and 0.91, respectively.

The software development process model or what is commonly called SDLC (Software Development Life Cycle) is one of the Software Engineering (RPL) course materials in the Information Engineering Education (PTI) undergraduate study program where one of the competencies is understanding and knowing the concepts of device engineering software that can be applied in the software development life cycle which is summarized in the material for the SDLC software development process model. This material is the initial material that must be mastered by students to develop quality software. The use of interactive and interesting computer assisted learning media is expected to help the stages of the student learning process properly. This requires an interactive learning multimedia application. The purpose of this research is to develop interactive learning media as an alternative to independent learning tools to assist students in mastering the Software Development Process Model (SDLC) material for students and to find out the feasibility of multimedia application products for learning the Software Development Process Model (SDLC). The research and development methodology used in this research is Research and Development (R&D) with Borg and Gall's development steps which include: (1) Research and data collection; (2) Planning; (3) Development of product drafts; (4) Initial field trials; (5) Revision of trial results (6) Field trials; (7) Product improvement; (8) Field implementation test; (9) Completion of the final product; and (10) Dissemination of implementation. This methodology covers all matters relating to development to produce quality interactive learning media software. Based on the trials, the results obtained were 90.63 percent from media experts, 98.08 percent from material experts, 85.46 percent from initial field trials, 84.56 percent from field trials, and 86.27 percent from field implementation trials. The average value obtained is 89 percent based on the results of the overall data analysis. The conclusion of this research is that the development of multimedia applications for learning the Software Development Process Model (SDLC) is feasible as an independent learning medium. The product produced in this development research is a multimedia application for learning flash-based software development process (SDLC) models.

This history column article provides a tour of the main software development life cycle (SDLC) models. (A lifecycle covers all the stages of software from its inception with requirements definition through to fielding and maintenance.) System development lifecycle models have drawn heavily on software and so the two terms can be used interchangeably in terms of SDLC, especially since software development in this respect encompasses software systems development. Because the merits of selecting and using an SDLC vary according to the environment in which software is developed as well as its application, I discuss three broad categories for consideration when analyzing the relative merits of SDLC models. I consider the waterfall model before the other models because it has had a profound effect on software development, and has additionally influenced many SDLC models prevalent today. Thereafter, I consider some of the mainstream models and finish with a discussion of what the future could hold for SDLC models.

Despite the fact that a number of approaches have been proposed for effective and accurate prediction of software defects, yet most of these have not found widespread applicability. Our objective in this communication is to provide a framework which is expected to be more effective and acceptable for predicting the defects in multiple phases across software development lifecycle. The proposed framework is based on the use of neural networks for predicting defects in software development life cycle. Further, in order to facilitate the easy use of the framework by project managers, a software graphical user interface has been developed that allows input data (including effort and defect) to be fed easily for predicting defects. The proposed framework provides a probabilistic defect prediction approach where instead of a definite number, a defect range (minimum, maximum, and mean) is predicted. The claim of efficacy and superiority of proposed framework is established through results of a comparative study, involving the proposed frame-work and some well-known models for software defect prediction.

Crowd sourcing, citizen journalism and social networks are Information and Communications Technologies (ICT) that have ushered in civil society's participation in the ICT equation. However, the participation of civil society has been limited to creating content and, to some extent, capturing data about events around the community. An area that has been neglected is the inclusion of these new players in the software development life cycle. Democratizing software development by including civil society in the software development life cycle will increase the variety of software applications and generate more buy-in of applications that improve livelihoods. Such an approach will lead to the emergence of Inclusive Information and Communication Technologies (IICT). The challenges that arise when developing IICTs include, inter alia, ownership of IICT, computer illiteracy of beneficiary communities, balkanized nature of communities in place and the well-known challenge of the communication gap between software developers and user communities. My approach to addressing these challenges was to develop the Integrated Development Spatial Planning Framework (IDSPF), a systems development methodology that seeks to demystify software development for grassroots communities by using participatory techniques that are familiar to stakeholders who implement socio economic development projects.

The personality traits of software developers can be exploited to co-relate their intellectual capabilities with work tasks in accordance with their job descriptions in industry. A software engineer may be required to have different levels and types of soft/hard skills during the different stages of software development activities. It would be more beneficial to select most appropriate software development personalities as team developers by considering their personality traits. Personality traits may play a vital role in selecting the right people for right jobs and hence may contribute in improvement of quality of software development process and its outcomes. This article presents a systematic mapping of MBTI personality traits of software developers with their assigned job cards/roles to allocate them with more appropriately associated software development tasks during different stages of software lifecycle. In this way, the article contributes in the improvement of overall software development process by finding most appropriate workers for each stage of software development activities. The article is assumed to serve as an asset for software development companies to predict most effective software development teams for their projects.

Software defect detection is particularly important for modern society, as it is a crucial step in ensuring the quality and reliability of software systems. With the emergence of artificial intelligence (AI), research in software defect detection has evolved from traditional methods to more complex approaches that utilize deep learning and large language models (LLMs). The advent of LLMs has fundamentally changed the paradigm of software development and defect detection, bringing new challenges and confusion to the field of software defect prediction research. To address these issues, we compare software defect detection methods based on traditional techniques, deep learning approaches, and LLMs through a literature review. We analyze the changes brought about by the introduction of LLMs to software development and propose new insights. Additionally, we examine the progress and trends in software defect prediction to provide inspiration for subsequent research.