<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Learn Software Development &#187; Stages</title>
	<atom:link href="http://learnsoftwareprocesses.com/category/stages/feed/" rel="self" type="application/rss+xml" />
	<link>http://learnsoftwareprocesses.com</link>
	<description>All about the processes involved in software development</description>
	<lastBuildDate>Tue, 07 Feb 2012 19:53:10 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Overview Of Process</title>
		<link>http://learnsoftwareprocesses.com/2009/08/26/overview-of-process/</link>
		<comments>http://learnsoftwareprocesses.com/2009/08/26/overview-of-process/#comments</comments>
		<pubDate>Wed, 26 Aug 2009 09:59:05 +0000</pubDate>
		<dc:creator>ashish</dc:creator>
				<category><![CDATA[PCB]]></category>
		<category><![CDATA[Process]]></category>
		<category><![CDATA[Process Control Block]]></category>
		<category><![CDATA[Stages]]></category>
		<category><![CDATA[State]]></category>

		<guid isPermaLink="false">http://learnsoftwareprocesses.com/?p=317</guid>
		<description><![CDATA[<p>A process is an activity which takes place over time and which has a precise aim regarding the result to be achieved. The concept of a process is hierarchical which means that a process may consist of a partially ordered set of sub-processes. A process is rather abstract. It describes the essentials of the purpose, [...]]]></description>
			<content:encoded><![CDATA[<p>A process is an activity which takes place over time and which has a precise aim regarding the result to be achieved. The concept of a process is hierarchical which means that a process may consist of a partially ordered set of sub-processes. A process is rather abstract. It describes the essentials of the purpose, structure, rationale, roles and timing, leaving plenty of implementation freedom. The power of a process is its abstraction, which enables its application in a wide range of applications, by tailoring its implementation to the specific application. A process can be tailored and elaborated in one or more procedures, which describe cookbook-like what need to be done when and by whom.<br />
The process has been given many definitions for instance :<br />
* A program in Execution.<br />
* An asynchronous activity.<br />
* The &#8216;animated sprit&#8217; of a procedure in execution.<br />
* The entity to which processors are assigned.<br />
* The &#8216;dispatchable&#8217; unit.<br />
In Process model, all software on the computer is organized into a number of sequential processes. A process includes PC, registers, and variables. Conceptually, each process has its own virtual CPU. In reality, the CPU switches back and forth among processes.<br />
A process goes through a series of discrete process states :<br />
* New State: The process being created.<br />
* Running State: A process is said to be running if it has the CPU, that is, process actually using the CPU at that particular instant.<br />
* Blocked (or waiting) State: A process is said to be blocked if it is waiting for some event to happen such that as an I/O completion before it can proceed. Note that a process is unable to run until some external event happens.<br />
* Ready State: A process is said to be ready if it use a CPU if one were available. A ready state process is runable but temporarily stopped running to let another process run.<br />
* Terminated state: The process has finished execution.</p>
<p>A process in an operating system is represented by a data structure known as a process control block (PCB) or process descriptor. The PCB contains important information about the specific process including :<br />
* The current state of the process i.e., whether it is ready, running, waiting, or whatever.<br />
* Unique identification of the process in order to track &#8220;which is which&#8221; information.  * A pointer to parent process.<br />
* Similarly, a pointer to child process (if it exists).<br />
* The priority of process (a part of CPU scheduling information).<br />
* Pointers to locate memory of processes.<br />
* A register save area.<br />
* The processor it is running on.</p>
]]></content:encoded>
			<wfw:commentRss>http://learnsoftwareprocesses.com/2009/08/26/overview-of-process/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Stages of a complete test cycle</title>
		<link>http://learnsoftwareprocesses.com/2008/12/23/stages-of-a-complete-test-cycle/</link>
		<comments>http://learnsoftwareprocesses.com/2008/12/23/stages-of-a-complete-test-cycle/#comments</comments>
		<pubDate>Tue, 23 Dec 2008 17:16:38 +0000</pubDate>
		<dc:creator>ashish</dc:creator>
				<category><![CDATA[Process]]></category>
		<category><![CDATA[Software]]></category>
		<category><![CDATA[Stages]]></category>
		<category><![CDATA[Testing]]></category>

		<guid isPermaLink="false">http://learnsoftwareprocesses.com/2008/12/23/stages-of-a-complete-test-cycle/</guid>
		<description><![CDATA[<p>People who are involved in the business of software testing know many parts of the testing process, but there are few people who have covered all the stages involved from the time of getting the project requirements, to the last stages of testing. Here is a timeline of the steps involved in this process: </p> [...]]]></description>
			<content:encoded><![CDATA[<p>People who are involved in the business of software testing know many parts of the testing process, but there are few people who have covered all the stages involved from the time of getting the project requirements, to the last stages of testing. Here is a timeline of the steps involved in this process: </p>
<p>• Requirements Phase: Get the requirements, along with the functional design, the internal design specifications<br />
• Resourcing estimation: Obtain budget and schedule requirements<br />
• Get into details of the project-related personnel and their responsibilities and the reporting requirements<br />
• Work out the required processes (such as release processes, change processes, etc.). Defining such processes can typically take a lot of time.<br />
• Identify application&#8217;s higher-risk aspects, set priorities, and determine scope and limitations of tests<br />
• Test methods: This is the time to plan and determine test approaches and methods &#8211; unit, integration, functional, system, load, usability tests, etc., the whole breakup of the types of tests to be done<br />
• Determine test environment requirements (hardware, software, communications, etc.). These are critical to determine because the testing success depends on getting a good approximation of the test environment<br />
• Determine testware requirements (record/playback tools, coverage analyzers, test tracking, problem/bug tracking, etc.). In many cases, a complete coverage of these tools is not done.<br />
• Determine test input data requirements. This can be a fairly intensive task, and needs to be thought through carefully.<br />
• People assignment: This is stage where for the project, task identification, those responsible for tasks, and labor requirements all need to be calculated.<br />
• Find out schedule estimates, timelines, milestones. Absolutely critical, since these determine the overall testing schedule along with resource needs.<br />
• Determine input equivalence classes, boundary value analyses, error classes<br />
• Prepare test plan document and have needed reviews/approvals. A test plan document encapsulates the entire testing proposal and needs to be properly reviewed for completeness.<br />
• Once the test plan is done and accepted, the next step is to write test cases<br />
• Have needed reviews/inspections/approvals of test cases. This may include reviews by the development team as well.<br />
• Prepare test environment and testware, obtain needed user manuals/reference documents/configuration guides/installation guides, set up test tracking processes, set up logging and archiving processes, set up or obtain test input data<br />
• Obtain and install software releases. If a daily build is available, the smoke testing regime for build acceptance needs to be brought in.<br />
• Perform tests. The actual phase where you start to see the results of all the previous efforts.<br />
• Evaluate and report results<br />
• Track problems/bugs and fixes. This phase can take up a substantial portion of the overall project time.<br />
• Retest as needed, including regression testing<br />
• Maintain and update test plans, test cases, test environment, and testware through life cycle</p>
]]></content:encoded>
			<wfw:commentRss>http://learnsoftwareprocesses.com/2008/12/23/stages-of-a-complete-test-cycle/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

