Wall-e and 9 movie
-
Watch at least two of the following movies:
• Make a comprehensive reaction paper for the two movies in no less than
300 words each.
• Make a comparative ...
13 years ago
Friday, December 18, 2009
All things have a beginning, a middle and an end. Just so, for an IT system.
At some point in the past a wonderful new system was introduced into the company. Everyone was happy. Management could see their business improve. The workflow for employees was smoother and more productive.
After the first few months of bedding in, the system worked well... and for a few years the system did everything it was meant to do.
Time passed, people moved on, the company changed ... that wonderful system began to show its age... the new manufacturing system had problems exchanging data. Customer invoices no longer flowed effortlessly from their new system into your aging computers.
Workers grew tired of using black screens with green text - even their home computers were more modern than this!
It was time for a change. And so the life cycle of the system was complete. The SYSTEM LIFE CYCLE is a term used to describe the stages in an IT project. It is the process by which an existing system is replaced with another.
Why do companies want to change their systems?
After all, they have spent a fortune on developing their existing one. All the staff knows how to use it. The technicians know how to fix it. Management understands its capabilities.
As you can imagine, changing things is an expensive, risky undertaking. Staff will have to re-trained. Equipment will have to be replaced. Offices may need to be re-wired causing disruption to every-day work.
Some of the reasons for introducing a new system may be:
1. The current system may no longer be suitable for its purpose. Changes in the way work is carried out means the system is no longer suitable
Happily, the business has grown. Starting out with only ten staff a few short years ago, the system could easily cope with the workload. But now there are a thousand staff in many offices around the world. The system just can't cope.
External influences. For example, new regulations have come along which insist that certain records are kept for years. The existing system was never designed for this.
2. Technological developments may have made the current system redundant or outdated.
Competitors are using more advanced systems that perhaps reduce their costs compared to yours, thus placing the company at a disadvantage.
Customers use more modern systems and insist that you upgrade yours to allow for easier data transfer.
The software supplier has warned that the version you are using will no longer be supported after next year. You have to plan for change.
3. The current system may be too inflexible or expensive to maintain.
A company has to to be able to cope with changing circumstances and this includes having the systems in place to deliver what the customer needs at the least internal cost.
For example, the customer has changed the way it sends data to its suppliers - you - and now your employees are having to manually type in invoices because the system cannot cope with the new format. Added costs, less profit, less competitive. Time for a new system.
Change is risky.
IT change is particularly risky!
Consider the sobering results obtained from a survey of over 14,000 organisations (OASIG study):
Therefore only between 1 in 5 and 1 in 10 of the IT projects in the survey were successful.
What could have been done better?
What could reduce the chances of failure?
As people have learnt from past mistakes, a model has been developed and refined over the years to try and maximize the chances of a successful project.
This method / model is called the SYSTEMS LIFE CYCLE.
It consists of a series of stages that take a project from its very first stages to the final outcome of a fully working, fully integrated system.
The SYSTEMS LIFE CYCLE is a term used to describe the stages in an IT project. These are:
Notice that the term 'life cycle' is used. This is because the process never really ends. Systems are created, they become mature, they grow old and are replaced by new ones. It is a cycle.
Before a project can begin, there has to be a reason why it should take place. You have to define the problem that the system is meant to be overcome.
This phase is called the 'Problem definition phase'. Some formal effort is made to define exactly what is the problem.
For example the following statements may appear in the Problem Definition.
...The existing system cannot transfer data to the new invoice system ...
...Staff have to spend three hours loading information...
... New legislation insist that financial records are kept for this department ...
And so on.
Methods of defining a problem:
Once the problem definition stage is over, then if the decision is to carry on with the project the next phase is the 'Feasibility Study'.
It is one thing to define the problem with an existing system. The next question is what are the alternatives - what are the broad avenues that may be taken? It is very rare that any company will have just one possible solution open to them.
This is the 'Feasibility Study Phase' of the Systems Life Cycle model.
In this phase, alternative solutions are examined. The costs Vs the benefits are compared in order to see which would best suit the company taking into consideration their requirements and the funds available. In order to arrive at a final decision, sometimes a trade-off has to be accepted e.g. less functionality for less cash.
Consider three imaginary (very brief!) alternatives that a company could choose from:
a) Company does not change anything
Benefit: No disruption to the business. Least cost.
Performance: No change, system remains outdated. Process becomes increasingly less efficient.
b) Company makes alterations to half the system
Benefit: Best parts of the system are retained, whilst the least efficient aspects are redesigned to enhance performance.
Cost: Moderate, training moderate.
Performance improvement: 30%
c) Complete overhaul
Benefit: Reduces company cost base (more profitable).
Cost: High, given that new equipment / software will be required. Training for staff needed.
Performance: 70% improvement over the old system.
As you can see, deciding on the best alternative is often not simple - management have to take many factors into account. There are often complicated relationships between cost, performance and benefit.
So at this point of the system life cycle, you know what the problem is and you are considering options.
The various options are usually presented to management at this stage and it is up to them to make a decision as to how much cash they want to inject into the project.
Once a decision has been made, the next phase is to analyse that option in greater detail.
The management have taken the decision to proceed with the project.
The next phase is called the 'Investigation and Analysis' phase.
First you define how the old system works (investigation) and the problem(s) it is causing.
This is done by a variety of techniques that include:
The investigation part confirms that the true cause of the problem has been correctly defined.
It also confirms that the project will overcome the problem.
The next part is to carefully analyse how the existing system works: Not necessarily the hardware or software - but more about how information is handled and how people interact with it.
As all this needs to be communicated efficiently to all concerned, a number of standard diagrams / methods are used.
System diagrams:
These show the relationships between the various systems in the company (or even outside if relevant) - how they interact, what depends on what and so on.
Data Flow Diagrams:
Most systems deal with information in one way or another. What really matters is how the information flows through the system. How does it branch and re-join. What outputs are created and so on.
The 'data flow' diagram seeks to show this movement through the system.
Process diagrams:
People handle information in a specific way - they have a 'process'. For example, an employee makes an expense claim. First of all their manager counter-signs the claim. It then goes to the account manager who authorises payment and so on...This is 'process flow' in action.
Process diagrams try to show how people interact with the system - who and when (and why).
Having undertaken a thorough investigation and analysis phase, the next stage is to create the 'Requirements Document'
This document does not define the hardware or software design but rather seeks to capture the essence of what needs to be done.
Some fairly standard headings within the document are:
1) An introduction.
Example:
The project has been developed in order to create a new invoicing system to replace the AIX400 computer system...
The introduction gives a broad description of the project and its aspirations.
2) Context
This section provides the background to the project.
Example:
The project was developed in light of the up-coming new regulations and also the increasing awareness that the existing system could no longer meet customer expectations ....
3) Specific Details required
Having provided a broad description and some context to the project, this section deals with specific things that need to be included in the system.
Example:
The system will be able to use a query to create a mail merged personalised letter.
The system must create an invoice in less than 3 seconds
The system will be able to print a management report onto A4 paper, portrait layout.
These specific requirements are all measurable. You should not have vague statements such as "The computer will run as fast as possible..." because you cannot know if 'as fast as possible' has been met when the system finally gets switched on.
Sometimes in a complicated project this section can be sub-divided into smaller sections such as:
And so on.
The Requirements Specification is the 'contract' between project managers and the client. It will be used at the testing stage to confirm that the system performs as the client expects.
Now that the project manager and the client have agreed on the requirements (Requirements Specification), it is time to define how the project is going to be carried out.
This is the Design phase of the project.
In this phase the exact details are defined, for example :-
This is all about the nitty-gritty detail. Once again this phase is trying to define the system in ever greater detail.
Think of the advantages of this phase - if you were the software engineer which would you rather have given to you as a job on a Monday morning?:-
Useless specification ! :-
a) Create a big file on the hard disk that will store all the invoices.
or
Useful, specific details...
b) The invoice file shall include a data record consisting of:-
1. Customer ID (3 digit alpha code)
2. Invoice number (9 digit number)
3. Value of item (displayed as currency)
4. .... yet more detail....
If you were the poor engineer given specification (a) the chances are you would not know where to start as you are bound to get it wrong!
So the design phase is really useful for the IT programmers who have to create the system.
Another aspect of creating a system is how are you going to test it?
It is tempting to leave the testing considerations until after the system has been developed but for the people having to develop the system it is really useful to have a test procedure in place before even starting to write a line of code or to design the hardware.
This is because you know how it will be tested and so it guides you towards a good design.
Example:
The input form shall reject
- any number greater than 1000
- any number less than zero
- any text
The input form shall accept
- any customer id and password the database already recognises
- shall jump to a 'new customer' screen (see details *** ) if it does not recognise the customer id.
Can you see why having this detail in the design phase would be useful to the project team?
Prototyping
A 'prototype' is something that represents what you will finally create without having to worry about all the details - it captures the essential details to confirm that the design is likely to work.
In software, the prototype is often written in a kind of shorthand English 'Read in the record'. The details do not matter at this stage, but a record must be 'read in'.
In hardware, you can test the system on a much cheaper slow computer, knowing that you will be able to run much faster on the final design - but it proves that the system works in principle.
The master document that is created in this phase is the 'Systems Requirement Document'
In a way, this is the contract between the project managers and the development team.
Time to do the work!
Now that the client has agreed on what needs to be done (Requirements Specification), and the Analyst has defined precisely what needs to be done (Systems Requirement Document) - it is time for the project to be actually developed.
The development stage is about taking the design forward and putting it into practice
One thing to note though, is that there may be several teams involved at this stage - so it is sensible to break down the Systems Requirement document into chunks that each teams can develop. It is no use informing the hardware team of the software requirements or vice versa.
At this stage the following things may take place (depending on the how extensive the project is) : -
This is an interesting time.... the implementation stage has been reached. The system has been developed and tested. It is working correctly and doing everything that was agreed during the design stage. The business is waiting in eager anticipation for the new system to be handed over to them.
The key events in this stage are:
DATA CONVERSION
Data stored in files on the old system are now converted into the correct format for the new system.
SYSTEM CHANGE-OVER
Now it is time to switch off the old system and turn on the new.
It sounds simple, but most of the time it isn't!
What are the alternatives?
1) Switch off the old system and switch on the new.
Of course, this is the simplest scenario! All the workers are waiting for the fabulous new system to come 'on -line' but as the minutes tick by, a new customer has just ordered a holiday / medical operation / flight / mortgage.
How do you deal with these last-minute (but vital) clients?
Answer: You must deal with last minute changes and accept that there may be some upheaval and mistakes made in the short term.
2) You run the old and new system in parallel for a time.
A popular method compared to the switch off / switch on approach. After all, the customer does not care what your IT system is made up of - they are only (rightly) concerned with their holiday / medical operation / mortgage etc being booked correctly.
And so, a popular method is to allow the old system to run alongside the new one. Then in the quiet period (say overnight) , the new system absorbs all the old system's information. By the next morning, the system is fully loaded and ready to go.
3) You run only part of the new system
This is the 'phased approach' to system testing. Imagine a system so sensitive to change that only a very careful change can be considered.
Example: A new air traffic control system.
Neither of the other two approaches would be suitable for such a critical system.
TRAINING
It is at the implementation stage that staff training takes place. Staff need to be shown how to use the new system and how to access help should they run into difficulties. There may be member of the development team on call for a short period of time or there may be a dedicated help line that staff can ring to get answers.
There will most definitely be a user manual to act as a source of reference.
The implementation stage is over: The system is up and running, Staff are fully trained and bugs have been ironed out.
This new stage is called the 'Evaluation phase'
It is at this point two key questions are considered:
Does the finished solution meet its requirements?
Does it solve the problem?
These questions are answered by considering details written down in the original Requirements Specification and comparing it to the performance of the new system.
For example:
Requirements specification states that the system should be able read the data file in less than 3 seconds.
Question: Does the system meet this specification?
Answer: Yes, the data file is read in 2.8 seconds.
In a complicated project, there may be hundreds of requirements specified. It could take many weeks to complete the evaluation phase.
The project manager and the client review whether or not the project has been completed successfully.
The Evaluation stage is over and the system is running smoothly. However as time passes, it will no doubt need to be looked after. This is the Maintenance phase of the Systems Life Cycle.
At this stage the following takes place:
This phase never really ends until the Life Cycle of the system is complete i.e. the system is switched off for the last time and a replacement system is introduced.
As you may now realise, the System Life Cycle model has been developed to make it more likely that projects are completed as planned, within budget and on time. However, even with this rigorous process, there are no guarantees that a project will succeed.
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/index.htm
At some point in the past a wonderful new system was introduced into the company. Everyone was happy. Management could see their business improve. The workflow for employees was smoother and more productive.
After the first few months of bedding in, the system worked well... and for a few years the system did everything it was meant to do.
Time passed, people moved on, the company changed ... that wonderful system began to show its age... the new manufacturing system had problems exchanging data. Customer invoices no longer flowed effortlessly from their new system into your aging computers.
Workers grew tired of using black screens with green text - even their home computers were more modern than this!
It was time for a change. And so the life cycle of the system was complete. The SYSTEM LIFE CYCLE is a term used to describe the stages in an IT project. It is the process by which an existing system is replaced with another.
Why do companies want to change their systems?
After all, they have spent a fortune on developing their existing one. All the staff knows how to use it. The technicians know how to fix it. Management understands its capabilities.
As you can imagine, changing things is an expensive, risky undertaking. Staff will have to re-trained. Equipment will have to be replaced. Offices may need to be re-wired causing disruption to every-day work.
Some of the reasons for introducing a new system may be:
1. The current system may no longer be suitable for its purpose. Changes in the way work is carried out means the system is no longer suitable
Happily, the business has grown. Starting out with only ten staff a few short years ago, the system could easily cope with the workload. But now there are a thousand staff in many offices around the world. The system just can't cope.
External influences. For example, new regulations have come along which insist that certain records are kept for years. The existing system was never designed for this.
2. Technological developments may have made the current system redundant or outdated.
Competitors are using more advanced systems that perhaps reduce their costs compared to yours, thus placing the company at a disadvantage.
Customers use more modern systems and insist that you upgrade yours to allow for easier data transfer.
The software supplier has warned that the version you are using will no longer be supported after next year. You have to plan for change.
3. The current system may be too inflexible or expensive to maintain.
A company has to to be able to cope with changing circumstances and this includes having the systems in place to deliver what the customer needs at the least internal cost.
For example, the customer has changed the way it sends data to its suppliers - you - and now your employees are having to manually type in invoices because the system cannot cope with the new format. Added costs, less profit, less competitive. Time for a new system.
Change is risky.
IT change is particularly risky!
Consider the sobering results obtained from a survey of over 14,000 organisations (OASIG study):
- 80-90% of systems fail to meet performance goals
- 80% of systems are late and over budget
- 40% of systems fail or are abandoned
- Less than 40% of businesses fully address training and skills requirements
- Less than 25% properly integrate business and technology objectives
- Just 10-20% of businesses meet all their success criteria.
Therefore only between 1 in 5 and 1 in 10 of the IT projects in the survey were successful.
What could have been done better?
What could reduce the chances of failure?
As people have learnt from past mistakes, a model has been developed and refined over the years to try and maximize the chances of a successful project.
This method / model is called the SYSTEMS LIFE CYCLE.
It consists of a series of stages that take a project from its very first stages to the final outcome of a fully working, fully integrated system.
The SYSTEMS LIFE CYCLE is a term used to describe the stages in an IT project. These are:
- Definition of the problem
- Feasibility Study
- Investigation and Analysis
- Design
- Development (programming)
- Testing
- Implementation
- Evaluation
- Maintenance
Notice that the term 'life cycle' is used. This is because the process never really ends. Systems are created, they become mature, they grow old and are replaced by new ones. It is a cycle.
Before a project can begin, there has to be a reason why it should take place. You have to define the problem that the system is meant to be overcome.
This phase is called the 'Problem definition phase'. Some formal effort is made to define exactly what is the problem.
For example the following statements may appear in the Problem Definition.
...The existing system cannot transfer data to the new invoice system ...
...Staff have to spend three hours loading information...
... New legislation insist that financial records are kept for this department ...
And so on.
Methods of defining a problem:
- Interview employees about their issues with the current system
- Analysing the total costs of the current system
- Key external factors that may point towards developing a new system.
- Performance of the existing system.
Once the problem definition stage is over, then if the decision is to carry on with the project the next phase is the 'Feasibility Study'.
It is one thing to define the problem with an existing system. The next question is what are the alternatives - what are the broad avenues that may be taken? It is very rare that any company will have just one possible solution open to them.
This is the 'Feasibility Study Phase' of the Systems Life Cycle model.
In this phase, alternative solutions are examined. The costs Vs the benefits are compared in order to see which would best suit the company taking into consideration their requirements and the funds available. In order to arrive at a final decision, sometimes a trade-off has to be accepted e.g. less functionality for less cash.
Consider three imaginary (very brief!) alternatives that a company could choose from:
a) Company does not change anything
Benefit: No disruption to the business. Least cost.
Performance: No change, system remains outdated. Process becomes increasingly less efficient.
b) Company makes alterations to half the system
Benefit: Best parts of the system are retained, whilst the least efficient aspects are redesigned to enhance performance.
Cost: Moderate, training moderate.
Performance improvement: 30%
c) Complete overhaul
Benefit: Reduces company cost base (more profitable).
Cost: High, given that new equipment / software will be required. Training for staff needed.
Performance: 70% improvement over the old system.
As you can see, deciding on the best alternative is often not simple - management have to take many factors into account. There are often complicated relationships between cost, performance and benefit.
So at this point of the system life cycle, you know what the problem is and you are considering options.
The various options are usually presented to management at this stage and it is up to them to make a decision as to how much cash they want to inject into the project.
Once a decision has been made, the next phase is to analyse that option in greater detail.
The management have taken the decision to proceed with the project.
The next phase is called the 'Investigation and Analysis' phase.
First you define how the old system works (investigation) and the problem(s) it is causing.
This is done by a variety of techniques that include:
- Questionnaires and interviews
- Observing people actually using the existing system
- 'Paper trail' : Following information from the point it enters the system and observing what outputs are created at each point in the system.
- Noting how / why the defined problem happens.
The investigation part confirms that the true cause of the problem has been correctly defined.
It also confirms that the project will overcome the problem.
The next part is to carefully analyse how the existing system works: Not necessarily the hardware or software - but more about how information is handled and how people interact with it.
As all this needs to be communicated efficiently to all concerned, a number of standard diagrams / methods are used.
System diagrams:
These show the relationships between the various systems in the company (or even outside if relevant) - how they interact, what depends on what and so on.
Data Flow Diagrams:
Most systems deal with information in one way or another. What really matters is how the information flows through the system. How does it branch and re-join. What outputs are created and so on.
The 'data flow' diagram seeks to show this movement through the system.
Process diagrams:
People handle information in a specific way - they have a 'process'. For example, an employee makes an expense claim. First of all their manager counter-signs the claim. It then goes to the account manager who authorises payment and so on...This is 'process flow' in action.
Process diagrams try to show how people interact with the system - who and when (and why).
Having undertaken a thorough investigation and analysis phase, the next stage is to create the 'Requirements Document'
This document does not define the hardware or software design but rather seeks to capture the essence of what needs to be done.
Some fairly standard headings within the document are:
1) An introduction.
Example:
The project has been developed in order to create a new invoicing system to replace the AIX400 computer system...
The introduction gives a broad description of the project and its aspirations.
2) Context
This section provides the background to the project.
Example:
The project was developed in light of the up-coming new regulations and also the increasing awareness that the existing system could no longer meet customer expectations ....
3) Specific Details required
Having provided a broad description and some context to the project, this section deals with specific things that need to be included in the system.
Example:
The system will be able to use a query to create a mail merged personalised letter.
The system must create an invoice in less than 3 seconds
The system will be able to print a management report onto A4 paper, portrait layout.
These specific requirements are all measurable. You should not have vague statements such as "The computer will run as fast as possible..." because you cannot know if 'as fast as possible' has been met when the system finally gets switched on.
Sometimes in a complicated project this section can be sub-divided into smaller sections such as:
- Its functions
- Its expected performance
- How it connects to other systems
- How it is going to be maintained, kept secure. Its expected reliability.
And so on.
The Requirements Specification is the 'contract' between project managers and the client. It will be used at the testing stage to confirm that the system performs as the client expects.
Now that the project manager and the client have agreed on the requirements (Requirements Specification), it is time to define how the project is going to be carried out.
This is the Design phase of the project.
In this phase the exact details are defined, for example :-
- The data inputs
- The data outputs
- Screen layouts
- Any documents that are printed out
- What happens to the data as it flows through the system (procedures)
- The structure of any files that store data.
- How information is accessed and indexed or sorted.
- The operating system to be used
- The hardware to be used.
This is all about the nitty-gritty detail. Once again this phase is trying to define the system in ever greater detail.
Think of the advantages of this phase - if you were the software engineer which would you rather have given to you as a job on a Monday morning?:-
Useless specification ! :-
a) Create a big file on the hard disk that will store all the invoices.
or
Useful, specific details...
b) The invoice file shall include a data record consisting of:-
1. Customer ID (3 digit alpha code)
2. Invoice number (9 digit number)
3. Value of item (displayed as currency)
4. .... yet more detail....
If you were the poor engineer given specification (a) the chances are you would not know where to start as you are bound to get it wrong!
So the design phase is really useful for the IT programmers who have to create the system.
Another aspect of creating a system is how are you going to test it?
It is tempting to leave the testing considerations until after the system has been developed but for the people having to develop the system it is really useful to have a test procedure in place before even starting to write a line of code or to design the hardware.
This is because you know how it will be tested and so it guides you towards a good design.
Example:
The input form shall reject
- any number greater than 1000
- any number less than zero
- any text
The input form shall accept
- any customer id and password the database already recognises
- shall jump to a 'new customer' screen (see details *** ) if it does not recognise the customer id.
Can you see why having this detail in the design phase would be useful to the project team?
Prototyping
A 'prototype' is something that represents what you will finally create without having to worry about all the details - it captures the essential details to confirm that the design is likely to work.
In software, the prototype is often written in a kind of shorthand English 'Read in the record'. The details do not matter at this stage, but a record must be 'read in'.
In hardware, you can test the system on a much cheaper slow computer, knowing that you will be able to run much faster on the final design - but it proves that the system works in principle.
The master document that is created in this phase is the 'Systems Requirement Document'
In a way, this is the contract between the project managers and the development team.
Time to do the work!
Now that the client has agreed on what needs to be done (Requirements Specification), and the Analyst has defined precisely what needs to be done (Systems Requirement Document) - it is time for the project to be actually developed.
The development stage is about taking the design forward and putting it into practice
One thing to note though, is that there may be several teams involved at this stage - so it is sensible to break down the Systems Requirement document into chunks that each teams can develop. It is no use informing the hardware team of the software requirements or vice versa.
At this stage the following things may take place (depending on the how extensive the project is) : -
- The software developers write code
- The hardware people develop equipment
- The testing team develop test plans
- The user-testing groups follow the test plans and check that the system works as expected. If not an error report is sent to the developers and corrections are made. The test is then performed again.
This is an interesting time.... the implementation stage has been reached. The system has been developed and tested. It is working correctly and doing everything that was agreed during the design stage. The business is waiting in eager anticipation for the new system to be handed over to them.
The key events in this stage are:
DATA CONVERSION
Data stored in files on the old system are now converted into the correct format for the new system.
SYSTEM CHANGE-OVER
Now it is time to switch off the old system and turn on the new.
It sounds simple, but most of the time it isn't!
What are the alternatives?
1) Switch off the old system and switch on the new.
Of course, this is the simplest scenario! All the workers are waiting for the fabulous new system to come 'on -line' but as the minutes tick by, a new customer has just ordered a holiday / medical operation / flight / mortgage.
How do you deal with these last-minute (but vital) clients?
Answer: You must deal with last minute changes and accept that there may be some upheaval and mistakes made in the short term.
2) You run the old and new system in parallel for a time.
A popular method compared to the switch off / switch on approach. After all, the customer does not care what your IT system is made up of - they are only (rightly) concerned with their holiday / medical operation / mortgage etc being booked correctly.
And so, a popular method is to allow the old system to run alongside the new one. Then in the quiet period (say overnight) , the new system absorbs all the old system's information. By the next morning, the system is fully loaded and ready to go.
3) You run only part of the new system
This is the 'phased approach' to system testing. Imagine a system so sensitive to change that only a very careful change can be considered.
Example: A new air traffic control system.
Neither of the other two approaches would be suitable for such a critical system.
TRAINING
It is at the implementation stage that staff training takes place. Staff need to be shown how to use the new system and how to access help should they run into difficulties. There may be member of the development team on call for a short period of time or there may be a dedicated help line that staff can ring to get answers.
There will most definitely be a user manual to act as a source of reference.
The implementation stage is over: The system is up and running, Staff are fully trained and bugs have been ironed out.
This new stage is called the 'Evaluation phase'
It is at this point two key questions are considered:
Does the finished solution meet its requirements?
Does it solve the problem?
These questions are answered by considering details written down in the original Requirements Specification and comparing it to the performance of the new system.
For example:
Requirements specification states that the system should be able read the data file in less than 3 seconds.
Question: Does the system meet this specification?
Answer: Yes, the data file is read in 2.8 seconds.
In a complicated project, there may be hundreds of requirements specified. It could take many weeks to complete the evaluation phase.
The project manager and the client review whether or not the project has been completed successfully.
The Evaluation stage is over and the system is running smoothly. However as time passes, it will no doubt need to be looked after. This is the Maintenance phase of the Systems Life Cycle.
At this stage the following takes place:
- Problems are cleared as they arise
- Tweaks to the system are applied to improve performance
- New circumstances might arise such as an office move. The system has to be moved.
- Data is backed up and kept safe.
- Printers, Monitors and other equipment are replaced as required.
This phase never really ends until the Life Cycle of the system is complete i.e. the system is switched off for the last time and a replacement system is introduced.
As you may now realise, the System Life Cycle model has been developed to make it more likely that projects are completed as planned, within budget and on time. However, even with this rigorous process, there are no guarantees that a project will succeed.
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/index.htm
Discuss the role of a systems analyst as a project manager.
Last December 7, 2009, our group in SAD1 visited the AMS Group of Companies located at F. Torres St., Davao City for an interview regarding our report on the said subject. During our interview, we have been given a chance to include the question on our SAD1 assignment in this forum which is “What skills and characteristics must a systems analyst develop in order to be more effective in any design modeling process?” To answer that question, we approached Mr. Gemrald R. Glibara, the M.I.S Department Head of AMS Group of Companies.
Also, in our SAD1 subject, out group was assigned to report about the Chapter 3 which is The Role of a System Analyst as a Project Manager.
A systems analyst is responsible for researching, planning, coordinating and recommending software and system choices to meet an organization's business requirements. The systems analyst plays a vital role in the systems development process. A successful systems analyst must acquire four skills: analytical, technical, managerial, and interpersonal. Analytical skills enable systems analysts to understand the organization and its functions, which helps him/her to identify opportunities and to analyze and solve problems. Technical skills help systems analysts understand the potential and the limitations of information technology. The systems analyst must be able to work with various programming languages, operating systems, and computer hardware platforms. Management skills help systems analysts manage projects, resources, risk, and change. Interpersonal skills help systems analysts work with end users as well as with analysts, programmers, and other systems professionals.
Because they must write user requests into technical specifications, the systems analysts are the liaisons between vendors and the IT professionals of the organization they represent[1] They may be responsible for developing cost analysis, design considerations, and implementation time-lines. They may also be responsible for feasibility studies of a computer system before making recommendations to senior management.
A systems analyst performs the following tasks:
• Interact with the customers to know their requirements
• Interact with designers to convey the possible interface of the software
• Interact/guide the coders/developers to keep track of system development
• Perform system testing with sample/live data with the help of testers
• Implement the new system
• Prepare High quality Documentation
A Systems Analyst analyzes, designs and implements the information gathered previously to a system, the final product which is a report of yearly sales, profits, etc.
The first thing a Systems Analyst does is to interview the company which wants the report, (called the user) to find out what kind of report they want, format, etc. They must find whether the report is feasible or not, and to find out, they do an analysis of the project.
To analyze the project, they must find out where are they going to get the information, how, when is the project going to be done, etc. They then design the system, which is to make a 'skeleton' of the project. They write specifications, of what is to be in the final report. They do flow charting, specifications for the programmers of the report, and development control.
Development control is where the Systems Analyst works with the programmers along a critical path. A critical path is like a due date, if the report is to be done in thirty days, the Systems Analyst makes sure the report is done in thirty days. The Systems Analyst also follows the first analysis of when the project will be finished. The critical path also calculates how many man hours it will take to finish, etc. A critical path flowchart also helps the programmers along.
After the development is finished and a prototype of the report is finished, the Systems Analyst helps the programmers in testing the program for bugs. This is similar to quality control. The Systems Analyst helps to makes sure the work is done until the final report is achieved. Once the final report is finished and free of bugs, it is sent to the user.
The Systems Analyst has a big job to do, he/she is responsible for the design, the development, and implementation of the report, ie: what purpose will it serve, presentation, etc. The Systems Analyst creates and helps finish the final product, making all the specifications and charts for what is to be done.
A Systems Analyst requires a computer science degree to get the job. He/She must have good analytical skills, (to be able to analyze for the report) good communication skills, and experience in programming is a help also.
Basically a Systems Analyst is responsible for systems projects, from beginning to the end of a project, and they must implement the system to good use. The Systems Analyst then must follow up to make sure the program is running smoothly.
The system analyst is the person (or persons) who guides through the development of an information system. In performing these tasks the analyst must always match the information system objectives with the goals of the organization.
Role of System Analyst differs from organization to organization. Most common responsibilities of System Analyst are following:
1) System analysis
It includes system's study in order to get facts about business activity. It is about getting information and determining requirements. Here the responsibility includes only requirement determination, not the design of the system.
2) System analysis and design
Here apart from the analysis work, Analyst is also responsible for the designing of the new system/application.
3) Systems analysis, design, and programming
Here Analyst is also required to perform as a programmer, where he actually writes the code to implement the design of the proposed application.
Due to the various responsibilities that a system analyst requires to handle, he has to be multifaceted person with varied skills required at various stages of the life cycle. In addition to the technical know-how of the information system development a system analyst should also have the following knowledge.
• Business knowledge: As the analyst might have to develop any kind of a business system, he should be familiar with the general functioning of all kind of businesses.
• Interpersonal skills: Such skills are required at various stages of development process for interacting with the users and extracting the requirements out of them
• Problem solving skills: A system analyst should have enough problem solving skills for defining the alternate solutions to the system and also for the problems occurring at the various stages of the development process.
The project manager is responsible for the overall success of the project. In some companies, this person might be called a Project Coordinator, or a Team Leader, however, the key aspect is that the person is responsible for ensuring the success of the project.
What does it take for the project to be a success? If you follow the Ten Step Project Management Process, or a similar approach, you first must define the project and build the schedule. This is where the project manager's responsibilities start. If the project begins and you find out later that you are not clear on scope, the project manager is the one who is accountable. If your project is executing a poor schedule, the project manager is accountable.
The work around defining the project means that you understand and gain agreement on the overall objectives, scope, risk, approach, budget, etc. It also includes defining or adopting the specific project management procedures that will be used to manage the project.
This does not mean that the project manager must do all this work themselves. There may be an entire team of people helping to create the Project Charter and schedule. However, if something does not go right, the project manager is accountable.
Process Responsibilities
Once the project starts, the project manager must successfully manage and control the work, including:
• Identifying, tracking managing and resolving project issues
• Proactively disseminating project information to all stakeholders
• Identifying, managing and mitigating project risk
• Ensuring that the solution is of acceptable quality
• Proactively managing scope to ensure that only what was agreed to is delivered, unless changes are approved through scope management
• Defining and collecting metrics to give a sense for how the project is progressing and whether the deliverables produced are acceptable
• Managing the overall schedule to ensure work is assigned and completed on time and within budget
Again, this does not mean that the project manager physically does all of this, but they must make sure it happens. If the project has problems, or scope creep, or faces risks, or is not setting expectations correctly, then the project manager is the person held accountable.
To manage the project management processes, a person should be well organized, have great follow-up skills, be process oriented, be able to multi-task, have a logical thought process, be able to determine root causes, have good analytical ability, be a good estimator and budget manager, and have good self-discipline.
People Responsibilities
In addition to process skills, a project manager must have good people management skills. This includes:
• Having the discipline and general management skills to make sure that people follow the standard processes and procedures
• Establishing leadership skills to get the team to willingly follow your direction. Leadership is about communicating a vision and getting the team to accept it and strive to get there with you.
• Setting reasonable, challenging and clear expectations for people, and holding them accountable for meeting the expectations. This includes providing good performance feedback to team members
• Team building skills so that the people work together well, and feel motivated to work hard for the sake of the project and their other team members. The larger your team and the longer the project, the more important it is to have good team-building skills.
• Proactive verbal and written communicator skills, including good, active listening skills.
Again, you are responsible for the success of the project. If the team has poor morale and is missing deadlines, you need to try to resolve it. If team members don't understand exactly what they need to do and when it is due, then you are responsible.
Multiple Roles
Depending on the size and complexity of the project, the project manager may take on other responsibilities in addition to managing the work. For instance, the project manager may assist with gathering business requirements. Or they may help design a database management system or they may write some of the project documentation. Project management is a particular role that a person fills, even if the person who is the project manager is working in other roles as well.
For instance, a project manager might manage the project for 45% of their time, perform business analysis for 25%, work on design for 15% and write documentation for 15%. This does not mean that one of the responsibilities of a project manager role is to spend 15% of their time on design. Instead, it just means that the project is not large enough to need a full-time project manager. The project manager spends the rest of their time in other project roles such as Business Analyst, Designer and Technical Writer. Depending on the size of your projects and the way your company is organized, a project manager’ time may be allocated one of three ways.
• They may have a full time role on a large project.
• They may have project management responsibilities for multiple projects, each of which is less than full time, but the combination of which adds up to a full-time role.
• They may fill multiple roles, each of which requires a certain level of skill and responsibility. On one project, for instance, they may be both a project manager and an analyst.
Having Project Management Accountability but not Responsibility
In some organizations, the project manager is accountable for the success of the project, but does not have the right level of responsibility. Managing the team in a matrix organization is an example of that. You are asked to manage a project utilizing people that you do not have direct management responsibility for. In other cases, you may find that your ability to resolve issues is hampered because you are not high enough in the organization to get an issue resolved quickly. In other instances, you may find that your ability to be innovative and flexible is constrained by organizational policies and inertia.
All of these cases can be cause for frustration. One way to deal with this is to define roles and responsibilities as a part of the Project Charter. This can help set and manage expectations. For instance, if you have no budget or expense approval authority, then note that up front, along with a process for expense approval. That way, if problems do arise later, everyone knows who has the right level of authority to resolve them. For most project managers, the frustration level is not caused so much by a lack of power as much as it is caused by ambiguity. If the project manager does not have the authority, it is important to know who does, and what process is needed to gain action.
***DURING THE INTERVIEW
http://www.studyworld.com/newsite/reportessay/Science/Social%5CThe_Duties_of_A_Systems_Analyst-34848.htm
http://en.wikipedia.org/wiki/Systems_analyst
http://www.freetutes.com/systemanalysis/role-of-system-analyst.html
http://www.lifecyclestep.com/open/407.1TheRoleoftheProjectManager.htm
Last December 7, 2009, our group in SAD1 visited the AMS Group of Companies located at F. Torres St., Davao City for an interview regarding our report on the said subject. During our interview, we have been given a chance to include the question on our SAD1 assignment in this forum which is “What skills and characteristics must a systems analyst develop in order to be more effective in any design modeling process?” To answer that question, we approached Mr. Gemrald R. Glibara, the M.I.S Department Head of AMS Group of Companies.
Also, in our SAD1 subject, out group was assigned to report about the Chapter 3 which is The Role of a System Analyst as a Project Manager.
A systems analyst is responsible for researching, planning, coordinating and recommending software and system choices to meet an organization's business requirements. The systems analyst plays a vital role in the systems development process. A successful systems analyst must acquire four skills: analytical, technical, managerial, and interpersonal. Analytical skills enable systems analysts to understand the organization and its functions, which helps him/her to identify opportunities and to analyze and solve problems. Technical skills help systems analysts understand the potential and the limitations of information technology. The systems analyst must be able to work with various programming languages, operating systems, and computer hardware platforms. Management skills help systems analysts manage projects, resources, risk, and change. Interpersonal skills help systems analysts work with end users as well as with analysts, programmers, and other systems professionals.
Because they must write user requests into technical specifications, the systems analysts are the liaisons between vendors and the IT professionals of the organization they represent[1] They may be responsible for developing cost analysis, design considerations, and implementation time-lines. They may also be responsible for feasibility studies of a computer system before making recommendations to senior management.
A systems analyst performs the following tasks:
• Interact with the customers to know their requirements
• Interact with designers to convey the possible interface of the software
• Interact/guide the coders/developers to keep track of system development
• Perform system testing with sample/live data with the help of testers
• Implement the new system
• Prepare High quality Documentation
A Systems Analyst analyzes, designs and implements the information gathered previously to a system, the final product which is a report of yearly sales, profits, etc.
The first thing a Systems Analyst does is to interview the company which wants the report, (called the user) to find out what kind of report they want, format, etc. They must find whether the report is feasible or not, and to find out, they do an analysis of the project.
To analyze the project, they must find out where are they going to get the information, how, when is the project going to be done, etc. They then design the system, which is to make a 'skeleton' of the project. They write specifications, of what is to be in the final report. They do flow charting, specifications for the programmers of the report, and development control.
Development control is where the Systems Analyst works with the programmers along a critical path. A critical path is like a due date, if the report is to be done in thirty days, the Systems Analyst makes sure the report is done in thirty days. The Systems Analyst also follows the first analysis of when the project will be finished. The critical path also calculates how many man hours it will take to finish, etc. A critical path flowchart also helps the programmers along.
After the development is finished and a prototype of the report is finished, the Systems Analyst helps the programmers in testing the program for bugs. This is similar to quality control. The Systems Analyst helps to makes sure the work is done until the final report is achieved. Once the final report is finished and free of bugs, it is sent to the user.
The Systems Analyst has a big job to do, he/she is responsible for the design, the development, and implementation of the report, ie: what purpose will it serve, presentation, etc. The Systems Analyst creates and helps finish the final product, making all the specifications and charts for what is to be done.
A Systems Analyst requires a computer science degree to get the job. He/She must have good analytical skills, (to be able to analyze for the report) good communication skills, and experience in programming is a help also.
Basically a Systems Analyst is responsible for systems projects, from beginning to the end of a project, and they must implement the system to good use. The Systems Analyst then must follow up to make sure the program is running smoothly.
The system analyst is the person (or persons) who guides through the development of an information system. In performing these tasks the analyst must always match the information system objectives with the goals of the organization.
Role of System Analyst differs from organization to organization. Most common responsibilities of System Analyst are following:
1) System analysis
It includes system's study in order to get facts about business activity. It is about getting information and determining requirements. Here the responsibility includes only requirement determination, not the design of the system.
2) System analysis and design
Here apart from the analysis work, Analyst is also responsible for the designing of the new system/application.
3) Systems analysis, design, and programming
Here Analyst is also required to perform as a programmer, where he actually writes the code to implement the design of the proposed application.
Due to the various responsibilities that a system analyst requires to handle, he has to be multifaceted person with varied skills required at various stages of the life cycle. In addition to the technical know-how of the information system development a system analyst should also have the following knowledge.
• Business knowledge: As the analyst might have to develop any kind of a business system, he should be familiar with the general functioning of all kind of businesses.
• Interpersonal skills: Such skills are required at various stages of development process for interacting with the users and extracting the requirements out of them
• Problem solving skills: A system analyst should have enough problem solving skills for defining the alternate solutions to the system and also for the problems occurring at the various stages of the development process.
The project manager is responsible for the overall success of the project. In some companies, this person might be called a Project Coordinator, or a Team Leader, however, the key aspect is that the person is responsible for ensuring the success of the project.
What does it take for the project to be a success? If you follow the Ten Step Project Management Process, or a similar approach, you first must define the project and build the schedule. This is where the project manager's responsibilities start. If the project begins and you find out later that you are not clear on scope, the project manager is the one who is accountable. If your project is executing a poor schedule, the project manager is accountable.
The work around defining the project means that you understand and gain agreement on the overall objectives, scope, risk, approach, budget, etc. It also includes defining or adopting the specific project management procedures that will be used to manage the project.
This does not mean that the project manager must do all this work themselves. There may be an entire team of people helping to create the Project Charter and schedule. However, if something does not go right, the project manager is accountable.
Process Responsibilities
Once the project starts, the project manager must successfully manage and control the work, including:
• Identifying, tracking managing and resolving project issues
• Proactively disseminating project information to all stakeholders
• Identifying, managing and mitigating project risk
• Ensuring that the solution is of acceptable quality
• Proactively managing scope to ensure that only what was agreed to is delivered, unless changes are approved through scope management
• Defining and collecting metrics to give a sense for how the project is progressing and whether the deliverables produced are acceptable
• Managing the overall schedule to ensure work is assigned and completed on time and within budget
Again, this does not mean that the project manager physically does all of this, but they must make sure it happens. If the project has problems, or scope creep, or faces risks, or is not setting expectations correctly, then the project manager is the person held accountable.
To manage the project management processes, a person should be well organized, have great follow-up skills, be process oriented, be able to multi-task, have a logical thought process, be able to determine root causes, have good analytical ability, be a good estimator and budget manager, and have good self-discipline.
People Responsibilities
In addition to process skills, a project manager must have good people management skills. This includes:
• Having the discipline and general management skills to make sure that people follow the standard processes and procedures
• Establishing leadership skills to get the team to willingly follow your direction. Leadership is about communicating a vision and getting the team to accept it and strive to get there with you.
• Setting reasonable, challenging and clear expectations for people, and holding them accountable for meeting the expectations. This includes providing good performance feedback to team members
• Team building skills so that the people work together well, and feel motivated to work hard for the sake of the project and their other team members. The larger your team and the longer the project, the more important it is to have good team-building skills.
• Proactive verbal and written communicator skills, including good, active listening skills.
Again, you are responsible for the success of the project. If the team has poor morale and is missing deadlines, you need to try to resolve it. If team members don't understand exactly what they need to do and when it is due, then you are responsible.
Multiple Roles
Depending on the size and complexity of the project, the project manager may take on other responsibilities in addition to managing the work. For instance, the project manager may assist with gathering business requirements. Or they may help design a database management system or they may write some of the project documentation. Project management is a particular role that a person fills, even if the person who is the project manager is working in other roles as well.
For instance, a project manager might manage the project for 45% of their time, perform business analysis for 25%, work on design for 15% and write documentation for 15%. This does not mean that one of the responsibilities of a project manager role is to spend 15% of their time on design. Instead, it just means that the project is not large enough to need a full-time project manager. The project manager spends the rest of their time in other project roles such as Business Analyst, Designer and Technical Writer. Depending on the size of your projects and the way your company is organized, a project manager’ time may be allocated one of three ways.
• They may have a full time role on a large project.
• They may have project management responsibilities for multiple projects, each of which is less than full time, but the combination of which adds up to a full-time role.
• They may fill multiple roles, each of which requires a certain level of skill and responsibility. On one project, for instance, they may be both a project manager and an analyst.
Having Project Management Accountability but not Responsibility
In some organizations, the project manager is accountable for the success of the project, but does not have the right level of responsibility. Managing the team in a matrix organization is an example of that. You are asked to manage a project utilizing people that you do not have direct management responsibility for. In other cases, you may find that your ability to resolve issues is hampered because you are not high enough in the organization to get an issue resolved quickly. In other instances, you may find that your ability to be innovative and flexible is constrained by organizational policies and inertia.
All of these cases can be cause for frustration. One way to deal with this is to define roles and responsibilities as a part of the Project Charter. This can help set and manage expectations. For instance, if you have no budget or expense approval authority, then note that up front, along with a process for expense approval. That way, if problems do arise later, everyone knows who has the right level of authority to resolve them. For most project managers, the frustration level is not caused so much by a lack of power as much as it is caused by ambiguity. If the project manager does not have the authority, it is important to know who does, and what process is needed to gain action.
***DURING THE INTERVIEW
http://www.studyworld.com/newsite/reportessay/Science/Social%5CThe_Duties_of_A_Systems_Analyst-34848.htm
http://en.wikipedia.org/wiki/Systems_analyst
http://www.freetutes.com/systemanalysis/role-of-system-analyst.html
http://www.lifecyclestep.com/open/407.1TheRoleoftheProjectManager.htm
Identify and discuss at least 3 systems development models .. discuss each phases ...
A software development process is a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process.
The activities of the software development process:
• Planning
The important task in creating a software product is extracting the requirements or requirements analysis. Customers typically have an abstract idea of what they want as an end result, but not what software should do. Incomplete, ambiguous, or even contradictory requirements are recognized by skilled and experienced software engineers at this point. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect. Once the general requirements are gleaned from the client, an analysis of the scope of the development should be determined and clearly stated. This is often called a scope document. Certain functionality may be out of scope of the project as a function of cost or as a result of unclear requirements at the start of development. If the development is done externally, this document can be considered a legal document so that if there are ever disputes, any ambiguity of what was promised to the client can be clarified.
• Implementation, testing and documenting
Implementation is the part of the process where software engineers actually program the code for the project. Software testing is an integral and important part of the software development process. This part of the process ensures that bugs are recognized as early as possible. Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the authoring of an API, be it external or internal.
• Deployment and maintenance
Deployment starts after the code is appropriately tested, is approved for release and sold or otherwise distributed into a production environment. Software Training and Support is important because a large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are often resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to have training classes for new clients of your software. Maintenance and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. It may be necessary to add code that does not fit the original design to correct an unforeseen problem or it may be that a customer is requesting more functionality and code can be added to accommodate their requests. It is during this phase that customer calls come in and you see whether your testing was extensive enough to uncover the problems before customers do. If the labor cost of the maintenance phase exceeds 25% of the prior-phases' labor cost, then it is likely that the overall quality, of at least one prior phase, is poor. In that case, management should consider the option of rebuilding the system (or portions) before maintenance cost is out of control. Bug Tracking System tools are often deployed at this stage of the process to allow development teams to interface with customer/field teams testing the software to identify any real or perceived issues. These software tools, both open source and commercially licensed, provide a customizable process to acquire, review, acknowledge, and respond to reported issues.
Process is “Ordered set of activities to solve a problem”.
Process models are core concepts in the discipline of Process Engineering.
Process models are processes of the same nature that are classified together into a model. Thus, a process model is a description of a process at the type level. Since the process model is at the type level, a process is an instantiation of it. The same process model is used repeatedly for the development of many applications and thus, has many instantiations. One possible use of a process model is to prescribe how things must/should/could be done in contrast to the process itself which is really what happens. A process model is roughly an anticipation of what the process will look like. What the process shall be will be determined during actual system development.
It is an iterative, milestone-based approach to the development process. The way in which activities in a systems development life cycle are sequenced, and the time and formality committed to each life-cycle stage. It is the combination of clearly defined life cycle model, project team roles, delivery milestones, and solution development principles.
Waterfall model
The waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and maintenance. Progress flows from the top to the bottom, like a waterfall.The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.
The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995), although Royce did not use the term "waterfall" in this article. Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development—as a way to criticize a commonly used software practice.
In Royce's original Waterfall model, the following phases are followed in order:
1. Requirements specification
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA Validation)
6. Installation
7. Maintenance
To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes requirements specification, which are set in stone. When the requirements are fully completed, one proceeds to design. The software in question is designed and a blueprint is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, separate software components produced are combined to introduce new functionality and reduced risk through the removal of errors. Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. However, there are various modified waterfall models (including Royce's final model) that may include slight or major variations upon this process.
Agile software development
Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated. Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Conceptual foundations of this framework are found in modern approaches to operations management and analysis, such as lean manufacturing, soft systems methodology, speech act theory (network of conversations approach), and Six Sigma. There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the life-cycle of the project.
Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames ("timeboxes") that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.[1] Multiple iterations may be required to release a product or new features.
Team composition in an agile project is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meet an iteration's requirements.
Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc. Most agile teams work in a single open office (called bullpen), which facilitates such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. Larger development efforts may be delivered by multiple teams working toward a common goal or different parts of an effort. This may also require a coordination of priorities across teams.
No matter what development disciplines are required, each agile team will contain a customer representative. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment and ensuring alignment with customer needs and company goals. Most agile implementations use a routine and formal daily face-to-face communication among team members. This specifically includes the customer representative and any interested stakeholders as observers. In a brief session, team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. This standing face-to-face communication prevents problems being hidden.
Agile emphasizes working software as the primary measure of progress. This, combined with the preference for face-to-face communication, produces less written documentation than other methods—though, in an agile project, documentation and other artifacts rank equally with a working product. The agile method encourages stakeholders to prioritize wants with other iteration outcomes based exclusively on business value perceived at the beginning of the iteration. Specific tools and techniques such as continuous integration, automated or xUnit test, pair programming, test driven development, design patterns, domain-driven design, code refactoring and other techniques are often used to improve quality and enhance project agility.
Iterative and incremental development
Iterative and Incremental development is a cyclic software development process developed in response to the weaknesses of the waterfall model. It starts with an initial planning and ends with deployment with the cyclic interaction in between. The iterative and incremental development is an essential part of the Rational Unified Process, the Dynamic Systems Development Method, Extreme Programming and generally the agile software development frameworks. Incremental development is a scheduling and staging strategy, in which the various parts of the system are developed.The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process are to start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving sequence of versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added.
The Procedure itself consists of the Initialization step, the Iteration step, and the Project Control List. The initialization step creates a base version of the system. The goal for this initial implementation is to create a product to which the user can react. It should offer a sampling of the key aspects of the problem and provide a solution that is simple enough to understand and implement easily. To guide the iteration process, a project control list is created that contains a record of all tasks that need to be performed. It includes such items as new features to be implemented and areas of redesign of the existing solution. The control list is constantly being revised as a result of the analysis phase.
The iteration involves the redesign and implementation of a task from the project control list, and the analysis of the current version of the system. The goal for the design and implementation of any iteration is to be simple, straightforward, and modular, supporting redesign at that stage or as a task added to the project control list. The level of design detail is not dictated by the interactive approach. In a light-weight iterative project the code may represent the major source of documentation of the system; however, in a mission-critical iterative project a formal Software Design Document may be used. The analysis of an iteration is based upon user feedback, and the program analysis facilities available. It involves analysis of the structure, modularity, usability, reliability, efficiency, & achievement of goals. The project control list is modified in light of the analysis results.
V-Model
The V-model is a software development process which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The V-model deploys a well-structured method in which each phase can be implemented by the detailed documentation of the previous phase. Testing activities like test designing start at the beginning of the project well before coding and therefore saves a huge amount of the project time.The Phases of the V-model
The V-model consists of a number of phases. The Verification Phases are on the left hand side of the V, the Coding Phase is at the bottom of the V and the Validation Phases are on the right hand side of the V.
Verification Phases
Requirements analysis
In the Requirements analysis phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the system’s functional, physical, interface, performance, data, security requirements etc as expected by the user. It is one which the business analysts use to communicate their understanding of the system back to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase.
System Design
Systems design is the phase where system engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly. The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing is prepared in this phase.
Architecture Design
The phase of the design of computer architecture and software architecture can also be referred to as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in this phase.
Module Design
The module design phase can also be referred to as low-level design. The designed system is broken up into smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudocode:
• database tables, with all elements, including their type and size
• all interface details with complete API references
• all dependency issues
• error message listings
• complete input and outputs for a module.
The unit test design is developed in this stage.
Validation Phases
Unit Testing
In the V-model of software development, unit testing implies the first stage of dynamic testing process. According to software development expert Barry Boehm, a fault discovered and corrected in the unit testing phase is more than a hundred times cheaper than if it is done after delivery to the customer. It involves analysis of the written code with the intention of eliminating errors. It also verifies that the codes are efficient and adheres to the adopted coding standards. Testing is usually white box. It is done using the Unit test design prepared during the module design phase. This may be carried out by software developers.
Integration Testing
In integration testing the separate modules will be tested together to expose faults in the interfaces and in the interaction between integrated components. Testing is usually black box as the code is not directly checked for errors.
System Testing
System testing will compare the system specifications against the actual system. The system test design is derived from the system design documents and is used in this phase. Sometimes system testing is automated using testing tools. Once all the modules are integrated several errors may arise. Testing done at this stage is called system testing.
User Acceptance Testing
Acceptance testing is the phase of testing used to determine whether a system satisfies the requirements specified in the requirements analysis phase. The acceptance test design is derived from the requirements document. The acceptance test phase is the phase used by the customer to determine whether to accept the system or not.
http://en.wikipedia.org/wiki/Software_development_process#Models
http://dictionary.babylon.com/process_model
http://keremkosaner.wordpress.com/category/process-modeling/
http://en.wikipedia.org/wiki/Waterfall_model
http://en.wikipedia.org/wiki/Agile_software_development
http://en.wikipedia.org/wiki/Iterative_and_incremental_development
http://en.wikipedia.org/wiki/V-Model_(software_development)
;;
Subscribe to:
Posts (Atom)
