|
List Of Software Development Philosophies
This is a list of approaches, styles, methodologies, philosophies in software development and engineering. It also contains programming paradigms, software development methodologies, software development processes, and single practices, principles and laws. Some of the mentioned methods are more relevant to a specific field than another, such as automotive or aerospace. The trend towards agile methods in software engineering is noticeable, however the need for improved studies on the subject is also paramount. Also note that some of the methods listed might be newer ''or'' older ''or'' still in use ''or'' out-dated, and the research on software design methods is not new and on-going. Software development methodologies, guidelines, strategies Large-scale programming styles * Behavior-driven development * Design-driven development * Domain-driven design * Secure by design * Test-driven development ** Acceptance test-driven development ** Continuous test-driven development ** ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Programming Paradigm
Programming paradigms are a way to classify programming languages based on their features. Languages can be classified into multiple paradigms. Some paradigms are concerned mainly with implications for the execution model of the language, such as allowing side effects, or whether the sequence of operations is defined by the execution model. Other paradigms are concerned mainly with the way that code is organized, such as grouping a code into units along with the state that is modified by the code. Yet others are concerned mainly with the style of syntax and grammar. Common programming paradigms include: * imperative in which the programmer instructs the machine how to change its state, ** procedural which groups instructions into procedures, ** object-oriented which groups instructions with the part of the state they operate on, * declarative in which the programmer merely declares properties of the desired result, but not how to compute it ** functional in which the de ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Lean Software Development
Lean software development is a translation of lean manufacturing principles and practices to the software development domain. Adapted from the Toyota Production System, it is emerging with the support of a pro-lean subculture within the agile community. Lean offers a solid conceptual framework, values and principles, as well as good practices, derived from experience, that support agile organizations. Origin The term lean software development originated in a book by the same name, written by Mary Poppendieck and Tom Poppendieck in 2003. The book restates traditional lean principles, as well as a set of 22 ''tools'' and compares the tools to corresponding agile practices. The Poppendiecks' involvement in the agile software development community, including talks at several Agile conferences has resulted in such concepts being more widely accepted within the agile community. Lean principles Lean development can be summarized by seven principles, very close in concept to ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Code Reuse
In software development (and computer programming in general), code reuse, also called software reuse, is the use of existing software, or software knowledge, to build new software, following the reusability principles. Code reuse may be achieved by different ways depending on a complexity of a programming language chosen and range from a lower-level approaches like code copy-pasting (e.g. via snippets), simple functions ( procedures or subroutines) or a bunch of objects or functions organized into modules (e.g. libraries) or custom namespaces, and packages, frameworks or software suites in higher-levels. Code reuse implies dependencies which can make code maintanability harder. At least one study found that code reuse reduces technical debt. Overview Ad hoc code reuse has been practiced from the earliest days of programming. Programmers have always reused sections of code, templates, functions, and procedures. Software reuse as a recognized area of study in software eng ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Brooks's Law
Brooks' law is an observation about software project management according to which adding manpower to software project that is behind schedule delays it even longer.Frederick P. Brooks, Jr. ''The Mythical Man-Month''. 1995 975 Addison-Wesley. It was coined by Fred Brooks in his 1975 book ''The Mythical Man-Month''. According to Brooks, under certain conditions, an incremental person when added to a project makes it take more, not less time. Explanations According to Brooks himself, the law is an "outrageous oversimplification", but it captures the general rule. Brooks points to the main factors that explain why it works this way: # It takes some time for the people added to a project to become productive. Brooks calls this the "ramp up" time. Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them; this education requires diverting resources already working on the project, temporarily dim ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Big Ball Of Mud
An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. The term, coined in 1995 by computer programmer Andrew Koenig, was inspired by the book ''Design Patterns'' (which highlights a number of design patterns in software development that its authors considered to be highly reliable and effective) and first published in his article in the ''Journal of Object-Oriented Programming''. A further paper in 1996 presented by Michael Ackroyd at the Object World West Conference also documented anti-patterns. It was, however, the 1998 book ''AntiPatterns'' that both popularized the idea and extended its scope beyond the field of software design to include software architecture and project management. Other authors have extended it further since to encompass environmental/organizational/cultural anti-patterns. Definition According to the authors of '' ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Agile Unified Process
Agile Unified Process (AUP) is a simplified version of the Rational Unified Process (RUP) developed by Scott Ambler. It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. The AUP applies agile techniques including test-driven development (TDD), agile modeling (AM), agile change management, and database refactoring to improve productivity. In 2011 the AUP accounted for one percent of all the agile methodologies used. In 2012 the AUP was superseded by disciplined agile delivery (DAD). Since then work has ceased on evolving AUP. Discipline Unlike the RUP, the AUP has only seven disciplines : # Model. Understand the business of the organization, the problem domain being addressed by the project, and identify a viable solution to address the problem domain. # Implementation. Transform model(s) into executable code and perform a basic level of testing, in particular unit ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
OpenUP
The Open Unified Process (OpenUP) is a part of the Eclipse Process Framework (EPF), an open source process framework developed within the Eclipse Foundation. Its goals are to make it easy to adopt the core of the Rational Unified Process (RUP) / Unified Process. The OpenUP began with a donation to open source of process content known as the Basic Unified Process (BUP) by IBM. It was transitioned to the Eclipse Foundation in late 2005 and renamed OpenUP/Basic in early 2006. It is now known simply as OpenUP. Overview OpenUP preserves the essential characteristics of Rational Unified Process / Unified Process, which include iterative development, use cases and scenarios driving development, risk management, and architecture-centric approach. Most optional parts of RUP have been excluded, and many elements have been merged. The result is a much simpler process that is still true to RUP principles. OpenUP targets small and colocated teams interested in agile and iterative develop ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Rational Unified Process
The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process. History Rational Software originally developed the rational unified process as a software process product. The product includes a hyperlinked knowledge-base with sample artifacts and detailed descriptions for many different types of activities. RUP is included in the IBM Rational Method Composer (RMC) product which allows customization of the process. Philippe Kruchten, an experienced Rational technical representative was tasked with heading up the original RUP team. These initial versions combined t ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Unified Process
The Unified Software Development Process or Unified Process is an iterative and incremental software development process framework. The best-known and extensively documented refinement of the Unified Process is the Rational Unified Process (RUP). Other examples are OpenUP and Agile Unified Process. Overview The Unified Process is not simply a process, but rather an extensible framework which should be customized for specific organizations or projects. The ''Rational Unified Process'' is, similarly, a customizable framework. As a result, it is often impossible to say whether a refinement of the process was derived from UP or from RUP, and so the names tend to be used interchangeably. The name ''Unified Process'' as opposed to ''Rational Unified Process'' is generally used to describe the generic process, including those elements which are common to most refinements. The ''Unified Process'' name is also used to avoid potential issues of trademark infringement since ''Rat ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Kanban (development)
Kanban (Japanese: , meaning signboard or billboard) is a lean method to manage and improve work across human systems. This approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks. Work items are visualized to give participants a view of progress and process, from start to finish—usually via a kanban board. Work is pulled as capacity permits, rather than work being pushed into the process when requested. In knowledge work and in software development, the aim is to provide a visual process management system which aids decision-making about what, when, and how much to produce. The underlying kanban method originated in lean manufacturing, which was inspired by the Toyota Production System. It has its origin in the late 1940s when the Toyota automotive company implemented a production system called just-in-time; which had the objective of producing according to customer demand and identifying pos ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
ICONIX
ICONIX is a software development methodology which predates both the Rational Unified Process (RUP), Extreme Programming (XP) and Agile software development. Like RUP, the ICONIX process is UML Use Case driven but more lightweight than RUP. ICONIX provides more requirement and design documentation than XP, and aims to avoid analysis paralysis. The ICONIX Process uses only four UML based diagrams in a four-step process that turns use case text into working code. A principal distinction of ICONIX is its use of robustness analysis, a method for bridging the gap between analysis and design. Robustness analysis reduces the ambiguity in use case descriptions, by ensuring that they are written in the context of an accompanying domain model. This process makes the use cases much easier to design, test and estimate. The ICONIX Process is described in the book ''Use Case Driven Object Modeling with UML: Theory and Practice''. Essentially, the ICONIX Process describes the core "logical" anal ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
Feature-driven Development
Feature-driven development (FDD) is an iterative and incremental software development process. It is a lightweight or Agile method for developing software. FDD blends a number of industry-recognized best practices into a cohesive whole. These practices are driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner in accordance with the Principles behind the Agile Manifesto. History FDD was initially devised by Jeff De Luca to meet the specific needs of a 15-month, 50-person software development project at a large Singapore bank in 1997. This resulted in a set of five processes that covered the development of an overall model and the listing, planning, design, and building of features. The first process is heavily influenced by Peter Coad's approach to object modelling. The second process incorporates Coad's ideas of using a feature list to manage functional requirements and develop ... [...More Info...] [...Related Items...] OR: [Wikipedia] [Google] [Baidu] |
