Software development process
In software engineering, a software development process is the process of dividing software development work into distinct phases to improve design, product management, project management. It is known as a software development life cycle; the methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application. Most modern development processes can be vaguely described as agile. Other methodologies include waterfall, prototyping and incremental development, spiral development, rapid application development, extreme programming; some people consider a life-cycle "model" a more general term for a category of methodologies and a software development "process" a more specific term to refer to a specific process chosen by a specific organization. For example, there are many specific software development processes that fit the spiral life-cycle model; the field is considered a subset of the systems development life cycle.
The software development methodology framework didn't emerge until the 1960s. According to Elliott the systems development life cycle can be considered to be the oldest formalized methodology framework for building information systems; the main idea of the SDLC has been "to pursue the development of information systems in a deliberate and methodical way, requiring each stage of the life cycle––from inception of the idea to delivery of the final system––to be carried out rigidly and sequentially" within the context of the framework being applied. The main target of this methodology framework in the 1960s was "to develop large scale functional business systems in an age of large scale business conglomerates. Information systems activities revolved around heavy data processing and number crunching routines". Methodologies and frameworks range from specific proscriptive steps that can be used directly by an organization in day-to-day work, to flexible frameworks that an organization uses to generate a custom set of steps tailored to the needs of a specific project or group.
In some cases a "sponsor" or "maintenance" organization distributes an official set of documents that describe the process. Specific examples include: 1970sStructured programming since 1969 Cap Gemini SDM from PANDATA, the first English translation was published in 1974. SDM stands for System Development Methodology1980sStructured systems analysis and design method from 1980 onwards Information Requirement Analysis/Soft systems methodology1990sObject-oriented programming developed in the early 1960s, became a dominant programming approach during the mid-1990s Rapid application development, since 1991 Dynamic systems development method, since 1994 Scrum, since 1995 Team software process, since 1998 Rational Unified Process, maintained by IBM since 1998 Extreme programming, since 19992000sAgile Unified Process maintained since 2005 by Scott Ambler Disciplined agile delivery Supersedes AUP2010s Scaled Agile Framework Large-Scale Scrum DevOpsIt is notable that since DSDM in 1994, all of the methodologies on the above list except RUP have been agile methodologies - yet many organisations governments, still use pre-agile processes.
Software process and software quality are interrelated. Among these another software development process has been established in open source; the adoption of these best practices known and established processes within the confines of a company is called inner source. Several software development approaches have been used since the origin of information technology, in two main categories. An approach or a combination of approaches is chosen by management or a development team. "Traditional" methodologies such as waterfall that have distinct phases are sometimes known as software development life cycle methodologies, though this term could be used more to refer to any methodology. A "life cycle" approach with distinct phases is in contrast to Agile approaches which define a process of iteration, but where design and deployment of different pieces can occur simultaneously. Continuous integration is the practice of merging all developer working copies to a shared mainline several times a day. Grady Booch first named and proposed CI in his 1991 method, although he did not advocate integrating several times a day.
Extreme programming adopted the concept of CI and did advocate integrating more than once per day – as many as tens of times per day. Software prototyping is about creating prototypes, i.e. incomplete versions of the software program being developed. The basic principles are: Prototyping is not a standalone, complete development methodology, but rather an approach to try out particular features in the context of a full methodology. Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process; the client is involved throughout the development process, which increases the likelihood of client acceptance of the final implementation. While some prototypes are developed with the expectation that they will be discarded, it is possible in some cases to evolve from prototype to working system. A basic understanding of the fundamental business problem is necessary to avoid solving the wrong problems, but this is true for all software methodologies.
Various methods are acceptable f
Root cause analysis
In science and engineering, root cause analysis is a method of problem solving used for identifying the root causes of faults or problems. It is used in IT operations, telecommunications, industrial process control, accident analysis, healthcare industry, etc. RCA can be decomposed into four steps: Identify and describe the fault/problem. Establish a timeline from normal situation until the fault/problem. Distinguish between the root cause and causal factors. Establish a causal graph between the root cause and the fault/problem. RCA serves as input to a remediation process whereby corrective actions are taken to prevent the fault/problem from reoccurring; the name of this process varies from one application domain to another. In science and engineering, there are two ways of repairing faults and solving problems. Reactive fault/problem management consists in reacting after the fault/problem occurs, by treating the symptoms; this type of management is implemented by reactive systems, self-adaptive systems, self-organized systems, complex adaptive systems.
The goal here is to react and alleviate the symptoms of the fault/problem as soon as possible. Proactive fault/problem management, consists in preventing problems from occurring. Many techniques can be used for this purpose, ranging from good practices in design to analyzing in detail problems that have occurred, taking actions to make sure they never reoccur. Speed is not as important here as the precision of the diagnosis; the focus is on addressing the real cause of the fault/problem rather than its symptoms. Root-cause analysis is used in proactive fault/problem management to identify the root cause of a fault/problem, that is, the factor, the main cause of that fault/problem, it is customary to refer to the root cause in singular form, but one or several factors may in fact constitute the root cause of the fault/problem under study. A factor is considered the root cause of a fault/problem if removing it prevents the fault/problem from recurring. A causal factor, conversely, is one, not the root cause.
Although removing a causal factor can benefit an outcome, it does not prevent its recurrence with certainty. Imagine an investigation into a machine that stopped because it overloaded and the fuse blew. Investigation shows that the machine overloaded because it had a bearing that wasn't being sufficiently lubricated; the investigation proceeds further and finds that the automatic lubrication mechanism had a pump, not pumping sufficiently, hence the lack of lubrication. Investigation of the pump shows. Investigation of why the shaft was worn discovers that there isn't an adequate mechanism to prevent metal scrap getting into the pump; this enabled scrap to get into the pump, damage it. The root cause of the problem is therefore. Fixing this problem ought to prevent the whole sequence of events recurring. Compare this with an investigation that does not find the root cause: replacing the fuse, the bearing, or the lubrication pump will allow the machine to go back into operation for a while, but there is a risk that the problem will recur, until the root cause is dealt with.
Root-cause analysis is used in many application domains. The example above illustrates. RCA is routinely used in industrial process control, e.g. to control the production of chemicals. RCA is used for failure analysis in engineering and maintenance. Root-cause analysis is used in IT and telecommunications to detect the root causes of serious problems. For example, in the ITIL service management framework, the goal of incident management is to resume a faulty IT service as soon as possible, whereas problem management deals with solving recurring problems for good by addressing their root causes. Another example is the computer security incident management process, where root-cause analysis is used to investigate security breaches. RCA is used in conjunction with business activity monitoring and complex event processing to analyze faults in business processes. In the domains of health and safety, RCA is used in medicine, environmental science, accident analysis, occupational safety and health. RCA is used in change management, risk management, systems analysis.
Despite the different approaches among the various schools of root cause analysis and the specifics of each application domain, RCA follows the same four steps. Effective problem statements and event descriptions are helpful and required to ensure the execution of appropriate root cause analyses. RCA should establish a sequence of events or timeline for understanding the relationships between contributory factors, the root cause, the fault/problem under investigation. By correlating this sequence of events with the nature, the magnitude, the location, the timing of the fault/problem, also with a library of analyzed faults/problems, RCA should enable the investigator to distinguish between the root cause, causal factors, non-causal factors. One way to trace down root causes consists in using hierarchical clustering and data-mining solutions. Another con
A software bug is an error, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. The process of finding and fixing bugs is termed "debugging" and uses formal techniques or tools to pinpoint bugs, since the 1950s, some computer systems have been designed to deter, detect or auto-correct various computer bugs during operations. Most bugs arise from mistakes and errors made in either a program's source code or its design, or in components and operating systems used by such programs. A few are caused by compilers producing incorrect code. A program that contains a large number of bugs, and/or bugs that interfere with its functionality, is said to be buggy. Bugs can trigger errors. Bugs may cause the program to crash or freeze the computer. Other bugs qualify as security bugs and might, for example, enable a malicious user to bypass access controls in order to obtain unauthorized privileges; some software bugs have been linked to disasters.
Bugs in code that controlled the Therac-25 radiation therapy machine were directly responsible for patient deaths in the 1980s. In 1996, the European Space Agency's US$1 billion prototype Ariane 5 rocket had to be destroyed less than a minute after launch due to a bug in the on-board guidance computer program. In June 1994, a Royal Air Force Chinook helicopter crashed into the Mull of Kintyre, killing 29; this was dismissed as pilot error, but an investigation by Computer Weekly convinced a House of Lords inquiry that it may have been caused by a software bug in the aircraft's engine-control computer. In 2002, a study commissioned by the US Department of Commerce's National Institute of Standards and Technology concluded that "software bugs, or errors, are so prevalent and so detrimental that they cost the US economy an estimated $59 billion annually, or about 0.6 percent of the gross domestic product". The term "bug" to describe defects has been a part of engineering jargon since the 1870s and predates electronic computers and computer software.
For instance, Thomas Edison wrote the following words in a letter to an associate in 1878: It has been just so in all of my inventions. The first step is an intuition, comes with a burst difficulties arise—this thing gives out and that "Bugs"—as such little faults and difficulties are called—show themselves and months of intense watching and labor are requisite before commercial success or failure is reached; the Middle English word bugge is the basis for the terms "bugbear" and "bugaboo" as terms used for a monster. Baffle Ball, the first mechanical pinball game, was advertised as being "free of bugs" in 1931. Problems with military gear during World War II were referred to as bugs. In a book published in 1942, Louise Dickinson Rich, speaking of a powered ice cutting machine, said, "Ice sawing was suspended until the creator could be brought in to take the bugs out of his darling."Isaac Asimov used the term "bug" to relate to issues with a robot in his short story "Catch That Rabbit", published in 1944.
The term "bug" was used in an account by computer pioneer Grace Hopper, who publicized the cause of a malfunction in an early electromechanical computer. A typical version of the story is: In 1946, when Hopper was released from active duty, she joined the Harvard Faculty at the Computation Laboratory where she continued her work on the Mark II and Mark III. Operators traced an error in the Mark II to a moth trapped in a relay; this bug was removed and taped to the log book. Stemming from the first bug, today we call errors or glitches in a program a bug. Hopper did not find the bug, as she acknowledged; the date in the log book was September 9, 1947. The operators who found it, including William "Bill" Burke of the Naval Weapons Laboratory, Virginia, were familiar with the engineering term and amusedly kept the insect with the notation "First actual case of bug being found." Hopper loved to recount the story. This log book, complete with attached moth, is part of the collection of the Smithsonian National Museum of American History.
The related term "debug" appears to predate its usage in computing: the Oxford English Dictionary's etymology of the word contains an attestation from 1945, in the context of aircraft engines. The concept that software might contain errors dates back to Ada Lovelace's 1843 notes on the analytical engine, in which she speaks of the possibility of program "cards" for Charles Babbage's analytical engine being erroneous:... an analysing process must have been performed in order to furnish the Analytical Engine with the necessary operative data. Granted that the actual mechanism is unerring in its processes, the cards may give it wrong orders; the first documented use of the term "bug" for a technical malfunction was by Thomas Edison. The Open Technology Institute, run by the group, New America, released a report "Bugs in the System" in August 2016 stating that U. S. policymakers should make reforms to help researchers address software bugs. The report "highlights the need for reform in the field of software vulnerability discovery and disclosure."
One of the report’s authors said that Congress has not done enough to address cyber software vulnerability though Congress has passed a number of bills to combat the larger issue of cyber security. Government researchers and cyber security experts are the people who discover software flaws