Software Process Models
--------------------------------------------------------------------------------
The software process model maybe defined as a simplified description of a software process, presented from a particular perspective. In essence, each stage of the software process is identified and a model is then employed to represent the inherent activities associated within that stage. Consequently, a collection of ‘local’ models may be utilised in generating the global picture representative of the software process. Examples of models include the workflow model, the data-flow model, and the role model.
· The workflow model shows the sequence of activities in the process along with their inputs, outputs and dependencies. The activities in the model represent human actions.
· The dataflow model represents the process as a set of activities each of which carries out some data transformation. It shows how the input to the process such as specification is transformed to an output such as design. The activities here maybe lower than in a workflow model. They may represent transformations carries out by people or computers.
· The role model represents the roles of people involved in the software process and the activities for which they are responsible.
In this section of the course focuses on the traditional generic software process models to highlight they effectively demonstrate the different approaches to software development. Such models include the:
Build And Fix
Waterfall Model
Formal Systems Development Model
Prototyping Model [Additional information on Prototyping]
Rapid Application Development (RAD) Model
Evolutionary Process Models
Incremental Model
Spiral Model
WIN WIN Spiral Model
Note that these are not definitive descriptions of any particular software process but give an overview of different approaches to software development.
Reference:
ds'f
'nlf
gl;
;
hf
Friday, February 20, 2009
PROCESS MODELS
Software Process Models
--------------------------------------------------------------------------------
The software process model maybe defined as a simplified description of a software process, presented from a particular perspective. In essence, each stage of the software process is identified and a model is then employed to represent the inherent activities associated within that stage. Consequently, a collection of ‘local’ models may be utilised in generating the global picture representative of the software process. Examples of models include the workflow model, the data-flow model, and the role model.
· The workflow model shows the sequence of activities in the process along with their inputs, outputs and dependencies. The activities in the model represent human actions.
· The dataflow model represents the process as a set of activities each of which carries out some data transformation. It shows how the input to the process such as specification is transformed to an output such as design. The activities here maybe lower than in a workflow model. They may represent transformations carries out by people or computers.
· The role model represents the roles of people involved in the software process and the activities for which they are responsible.
In this section of the course focuses on the traditional generic software process models to highlight they effectively demonstrate the different approaches to software development. Such models include the:
Build And Fix
Waterfall Model
Formal Systems Development Model
Prototyping Model [Additional information on Prototyping]
Rapid Application Development (RAD) Model
Evolutionary Process Models
Incremental Model
Spiral Model
WIN WIN Spiral Model
Note that these are not definitive descriptions of any particular software process but give an overview of different approaches to software development.
Reference:
ds'f
'nlf
gl;
;
hf
--------------------------------------------------------------------------------
The software process model maybe defined as a simplified description of a software process, presented from a particular perspective. In essence, each stage of the software process is identified and a model is then employed to represent the inherent activities associated within that stage. Consequently, a collection of ‘local’ models may be utilised in generating the global picture representative of the software process. Examples of models include the workflow model, the data-flow model, and the role model.
· The workflow model shows the sequence of activities in the process along with their inputs, outputs and dependencies. The activities in the model represent human actions.
· The dataflow model represents the process as a set of activities each of which carries out some data transformation. It shows how the input to the process such as specification is transformed to an output such as design. The activities here maybe lower than in a workflow model. They may represent transformations carries out by people or computers.
· The role model represents the roles of people involved in the software process and the activities for which they are responsible.
In this section of the course focuses on the traditional generic software process models to highlight they effectively demonstrate the different approaches to software development. Such models include the:
Build And Fix
Waterfall Model
Formal Systems Development Model
Prototyping Model [Additional information on Prototyping]
Rapid Application Development (RAD) Model
Evolutionary Process Models
Incremental Model
Spiral Model
WIN WIN Spiral Model
Note that these are not definitive descriptions of any particular software process but give an overview of different approaches to software development.
Reference:
ds'f
'nlf
gl;
;
hf
Thursday, September 11, 2008
Critical Path Method
Critical Path Method (CPM) charts are similar to PERT charts and are sometimes known as PERT/CPM. In a CPM chart, the critical path is indicated. A critical path consists that set of dependen tasks (each depedent on the preceding one) which together take the longest time to complete. Although it is not normally done, a CPM chart can define multiple, equally critical paths. Tasks which fall on the critical path should be noted in some way, so that they may be given special attention. One way is to draw critical path tasks with a double line instead of a single line.
Tasks which fall on the critical path should receive special attention by both the project manager and the personnel assigned to them. The critical path for any given method may shift as the project progresses; this can happen when tasks are completed either behind or ahead of schedule, causing other tasks which may still be onschedule to fall on the new critical path.
Reference:
A Professional's Guide to Systems Analysis", Martin E. Modell, 2nd. Ed. McGraw Hill, 1996.
http://studentweb.tulane.edu/~mtruill/dev-pert.html
Accessed: September 11, 2008
Tasks which fall on the critical path should receive special attention by both the project manager and the personnel assigned to them. The critical path for any given method may shift as the project progresses; this can happen when tasks are completed either behind or ahead of schedule, causing other tasks which may still be onschedule to fall on the new critical path.
Reference:
A Professional's Guide to Systems Analysis", Martin E. Modell, 2nd. Ed. McGraw Hill, 1996.
http://studentweb.tulane.edu/~mtruill/dev-pert.html
Accessed: September 11, 2008
Pert Evaluation and Review Technique
Program evaluation and review technique (PERT) charts depict task, duration, and dependency information. Each chart starts with an initiation node from which the first task, or tasks, originates. If multiple tasks begin at the same time, they are all started from the node or branch, or fork out from the starting point. Each task is represented by a line which states its name or other identifier, its duration, the number of people assigned to it, and in some cases the initials of the personnel assigned. The other end of the task line is terminated by another node which identifies the start of another task, or the beginning of any slack time, that is, waiting time between tasks.
Each task is connected to its successor tasks in this manner forming a network of nodes and connecting lines. The chart is complete when all final tasks come together at the completion node. When slack time exists between the end of one task and the start of another, the usual method is to draw a broken or dotted line between the end of the first task and the start of the next dependent task.
A PERT chart may have multiple parallel or interconnecting networks of tasks. If the scheduled project has milestones, checkpoints, or review points (all of which are highly recommended in any project schedule), the PERT chart will note that all tasks up to that point terminate at the review node. It should be noted at this point that the project review, approvals, user reviews, and so forth all take time. This time should never be underestimated when drawing up the project plan. It is not unusual for a review to take 1 or 2 weeks. Obtaining management and user approvals may take even longer.
When drawing up the plan, be sure to include tasks for documentation writing, documentation editing, project report writing and editing, and report reproduction. These tasks are usually time-consuming, so don't underestimate how long it will take to complete them.
PERT charts are usually drawn on ruled paper with the horizontal axis indicating time period divisions in days, weeks, months, and so on. Although it is possible to draw a PERT chart for an entire project, the usual practice is to break the plans into smaller, more meaningful parts. This is very helpful if the chart has to be redrawn for any reason, such as skipped or incorrectly estimated tasks.
Many PERT charts terminate at the major review points, such as at the end of the analysis. Many organizations include funding reviews in the projects life cycle. Where this is the case, each chart terminates in the funding review node.
Funding reviews can affect a project in that they may either increase funding, in which case more people have to made available, or they may decrease funding, in which case fewer people may be available. Obviously more or less people will affect the length of time it takes to complete the project.
Visit this site for futher reference
http://www.bridgeport.edu/sed/projects/cs597/unfiled/zhipingli/report.html
Reference:
A Professional's Guide to Systems Analysis", Martin E. Modell, 2nd. Ed. McGraw Hill, 1996
http://studentweb.tulane.edu/~mtruill/dev-pert.html
Accessed : September 11, 2008
Each task is connected to its successor tasks in this manner forming a network of nodes and connecting lines. The chart is complete when all final tasks come together at the completion node. When slack time exists between the end of one task and the start of another, the usual method is to draw a broken or dotted line between the end of the first task and the start of the next dependent task.
A PERT chart may have multiple parallel or interconnecting networks of tasks. If the scheduled project has milestones, checkpoints, or review points (all of which are highly recommended in any project schedule), the PERT chart will note that all tasks up to that point terminate at the review node. It should be noted at this point that the project review, approvals, user reviews, and so forth all take time. This time should never be underestimated when drawing up the project plan. It is not unusual for a review to take 1 or 2 weeks. Obtaining management and user approvals may take even longer.
When drawing up the plan, be sure to include tasks for documentation writing, documentation editing, project report writing and editing, and report reproduction. These tasks are usually time-consuming, so don't underestimate how long it will take to complete them.
PERT charts are usually drawn on ruled paper with the horizontal axis indicating time period divisions in days, weeks, months, and so on. Although it is possible to draw a PERT chart for an entire project, the usual practice is to break the plans into smaller, more meaningful parts. This is very helpful if the chart has to be redrawn for any reason, such as skipped or incorrectly estimated tasks.
Many PERT charts terminate at the major review points, such as at the end of the analysis. Many organizations include funding reviews in the projects life cycle. Where this is the case, each chart terminates in the funding review node.
Funding reviews can affect a project in that they may either increase funding, in which case more people have to made available, or they may decrease funding, in which case fewer people may be available. Obviously more or less people will affect the length of time it takes to complete the project.
Visit this site for futher reference
http://www.bridgeport.edu/sed/projects/cs597/unfiled/zhipingli/report.html
Reference:
A Professional's Guide to Systems Analysis", Martin E. Modell, 2nd. Ed. McGraw Hill, 1996
http://studentweb.tulane.edu/~mtruill/dev-pert.html
Accessed : September 11, 2008
Tuesday, September 9, 2008
GANTT CHART
EVOLUTION OF THE GANTT CHART
Here's a simple example that might have been used around the time Gantt charts were invented (if computers had also been available to make the charts look this precise:)
Early Gantt chart users showed progress using a simple "fill in the bar" method to show how much of the project was complete:
They also might have shown the planned bar along side the progress bar like this:
Another type of chart which was used along with the Gantt chart was the basic "Milestone chart". This type of chart shows only important project events or milestones:
Milestone charts are very popular today, especially for management reporting. A major benefit is that it's easy to communicate a great deal of information in a single presentation slide. This example shows how the complete overall progress of two major projects might be presented to upper management:
Combining the gantt chart and the milestone chart was the next logical step. This "Remodeling Project" uses bars to show the time required for each phase of the remodeling project. Important milestones are shown with a single diamond symbol:
REFERENCE:
Here's a simple example that might have been used around the time Gantt charts were invented (if computers had also been available to make the charts look this precise:)
Early Gantt chart users showed progress using a simple "fill in the bar" method to show how much of the project was complete:
They also might have shown the planned bar along side the progress bar like this:
Another type of chart which was used along with the Gantt chart was the basic "Milestone chart". This type of chart shows only important project events or milestones:
Milestone charts are very popular today, especially for management reporting. A major benefit is that it's easy to communicate a great deal of information in a single presentation slide. This example shows how the complete overall progress of two major projects might be presented to upper management:
Combining the gantt chart and the milestone chart was the next logical step. This "Remodeling Project" uses bars to show the time required for each phase of the remodeling project. Important milestones are shown with a single diamond symbol:
REFERENCE:
Gantt Charts. http://www.ganttchart.com/Evolution.html
Accessed: September 9, 2008
Subscribe to:
Posts (Atom)