Content deleted Content added
Line 2:
==Software development process==
A [[software development process]] is concerned primarily with the production aspect of [[software development]], as opposed to the technical aspect, such as [[software tools]]. These processes exist primarily for supporting the management of software development, and are generally skewed toward addressing business concerns. Many software development processes can be run in a similar way to general project management processes. Examples are:
* [[Risk management]] is the process of measuring or [[Risk assessment|assessing risk]] and then developing strategies to manage the risk. In general, the strategies employed include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk.
[[Requirements management]] is the process of identifying, [[Requirements elicitation|eliciting]], documenting, analyzing, [[Requirements traceability|tracing]], prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. new or altered [[computer system]]<ref name="Stellman05"/> Requirements management, which includes [[Requirements analysis]], is an important part of the [[software engineering]] process; whereby business analysts or [[software developers]] identify the needs or requirements of a client; having identified these requirements they are then in a position to design a solution.▼
▲* [[Requirements management]] is the process of identifying, [[Requirements elicitation|eliciting]], documenting, analyzing, [[Requirements traceability|tracing]], prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders.
▲[[Risk management]] is the process of measuring or [[Risk assessment|assessing risk]] and then developing strategies to manage the risk. In general, the strategies employed include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Traditional risk management, which is discussed here, focuses on risks stemming from physical or legal causes (e.g. natural disasters or fires, accidents, death, and lawsuits).
* [[Change management]] is the process of identifying, documenting, analyzing, prioritizing and agreeing on changes to [[scope (project management)]] and then controlling changes and communicating to relevant stakeholders. [[Change impact analysis]] of new or altered scope, which includes [[Requirements analysis]] at the change level, is an important part of the [[software engineering]] process; whereby business analysts or [[software developers]] identify the altered needs or requirements of a client; having identified these requirements they are then in a position to re-design or modify a solution. Theoretically, each change can impact the timeline and budget of a software project, and therefore by definition must include [[risk-benefit analysis]] before approval.
* [[Software configuration management]] is the process of identifying, and documenting the scope itself, which is the softare product underway, including all sub-products and changes and enabling communication of these to relevant stakeholders. In general, the processes employed include [[version control]], [[naming convention (programming)]], and software archival agreements.
* [[Release management]] is the process of identifying, documenting, prioritizing and agreeing on releases of software and then controlling the release schedule and communicating to relevant stakeholders. Most software projects have access to three software environments to which software can be released; Development, Test, and Production. In very large projects, where distributed teams need to integrate their work before release to users, there will often be more environments for testing, called [[unit testing]], [[system testing]], or [[integration testing]], before release to [[User acceptance testing]] (UAT).
** A subset of release management that is gaining more and more attention is [[Data Management]], as obviously the users can only test based on data that they know, and "real" data is only in the software environment called "production". In order to test their work, programmers must therefore also often create "dummy data" or "data stubs". Traditionally, older versions of a production system were once used for this purpose, but as companies rely more and more on outside contributors for software development, company data may not be released to development teams. In complex environments, datasets may be created that are then migrated across test environments according to a test release schedule, much like the overall software release schedule.
==Project planning, monitoring and control==
| |||