Topic: Systems/Software engineering

You are looking at all articles with the topic "Systems/Software engineering". We found 4 matches.

Hint: To view all topics, click here. Too see the most popular topics, click here instead.

🔗 Fourth-Generation Programming Language

🔗 Technology 🔗 Computing 🔗 Computer science 🔗 Systems 🔗 Business 🔗 Computing/Software 🔗 Systems/Software engineering

A fourth-generation programming language (4GL) is any computer programming language that belongs to a class of languages envisioned as an advancement upon third-generation programming languages (3GL). Each of the programming language generations aims to provide a higher level of abstraction of the internal computer hardware details, making the language more programmer-friendly, powerful, and versatile. While the definition of 4GL has changed over time, it can be typified by operating more with large collections of information at once rather than focusing on just bits and bytes. Languages claimed to be 4GL may include support for database management, report generation, mathematical optimization, GUI development, or web development. Some researchers state that 4GLs are a subset of domain-specific languages.

The concept of 4GL was developed from the 1970s through the 1990s, overlapping most of the development of 3GL, with 4GLs identified as "non-procedural" or "program-generating" languages, contrasted with 3GLs being algorithmic or procedural languages. While 3GLs like C, C++, C#, Java, and JavaScript remain popular for a wide variety of uses, 4GLs as originally defined found uses focused on databases, reports, and websites. Some advanced 3GLs like Python, Ruby, and Perl combine some 4GL abilities within a general-purpose 3GL environment, and libraries with 4GL-like features have been developed as add-ons for most popular 3GLs, producing languages that are a mix of 3GL and 4GL, blurring the distinction.

In the 1980s and 1990s, there were efforts to develop fifth-generation programming languages (5GL).

Discussed on

🔗 Capability Immaturity Model

🔗 Computing 🔗 Systems 🔗 Computing/Software 🔗 Systems/Software engineering

Capability Immaturity Model (CIMM) in software engineering is a parody acronym, a semi-serious effort to provide a contrast to the Capability Maturity Model (CMM). The Capability Maturity Model is a five point scale of capability in an organization, ranging from random processes at level 1 to fully defined, managed and optimized processes at level 5. The ability of an organization to carry out its mission on time and within budget is claimed to improve as the CMM level increases.

The "Capability Im-Maturity Model" asserts that organizations can and do occupy levels below CMM level 1. An original article by Capt. Tom Schorsch USAF as part of a graduate project at the Air Force Institute of Technology provides the definitions for CIMM. He cites Prof. Anthony Finkelstein's ACM paper as an inspiration. The article describes situations that arise in dysfunctional organizations. Such situations are reportedly common in organizations of all kinds undertaking software development, i.e. they are really characterizations of the management of specific projects, since they can occur even in organizations with positive CMM levels.

Kik Piney, citing the original authors, later adapted the model to a somewhat satirical version that attracted a number of followers who felt that it was quite true to their experience.

Discussed on

🔗 History of software engineering

🔗 Computing 🔗 Systems 🔗 Computing/Software 🔗 Systems/Software engineering

From its beginnings in the 1960s, writing software has evolved into a profession concerned with how best to maximize the quality of software and of how to create it. Quality can refer to how maintainable software is, to its stability, speed, usability, testability, readability, size, cost, security, and number of flaws or "bugs", as well as to less measurable qualities like elegance, conciseness, and customer satisfaction, among many other attributes. How best to create high quality software is a separate and controversial problem covering software design principles, so-called "best practices" for writing code, as well as broader management issues such as optimal team size, process, how best to deliver software on time and as quickly as possible, work-place "culture", hiring practices, and so forth. All this falls under the broad rubric of software engineering.

Discussed on

🔗 Extreme Programming

🔗 Computing 🔗 Systems 🔗 Systems/Software engineering 🔗 Method engineering

Extreme programming (XP) is a software development methodology intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent releases in short development cycles, intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

Other elements of extreme programming include programming in pairs or doing extensive code review, unit testing of all code, not programming features until they are actually needed, a flat management structure, code simplicity and clarity, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers. The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels. As an example, code reviews are considered a beneficial practice; taken to the extreme, code can be reviewed continuously (i.e. the practice of pair programming).