We want to make success repeatable. You can be successful if you're lucky, but we want to tinker with the chances.
Process: Is a way of doing something. An algorithm.
Step a, step b etc.
A sequence of steps is basically an algorithm.
So what makes a good process?
A whole list of things. See the list. Good is good, bad is bad!
Is there a RIGHT process for soft engineers?
OO?
Well actually there is little agreement about what is best. There's trendy stuff that flies around, and people jump on the bandwagon.
Everyone has their own way of doing things.
Some have NOPROCESS and make it up as they go along.
It's all a matter of opinion, and be prepared to be told by an employer to 'do it like this - our way'.
We need process, however, when we need communication. That's what it's about. But Soft Eng. isn't just about creating diagrams. By scribbling heaps of UML, you can just muddy what's going on. You have to think more about what's going into the diagrams.
The LARGER the project, the greater the need for a formal process.
Determining Process
Most student projects don't really need much of a formal process.
The steps in a GENERIC software Process.
Project Definition
You're presented with a problem. If you can't decide that there is a problem, then nothing much gets done.
Once you have accepted that there is a problem, then you have to nail it down.
You have to agree on the problem. You have to decide on the nature and the extent.
Requirements analysis
You have to find an acceptable solution. This means that the client will pay you for it.
Design
Project Implementation
Meet the requirements of the user, and solve problems.
Component testing
Integration Testing
System testing
^This is implementing from the bottom up ^
System Delivery
Maintenance
This where all the cost is. The more successful your software is, you spend heaps of time and money maintaining it.
But software engineering is all about the top of the list. This doesn't mean that you don't make any money.
The next lecture is looking at the software development management process in-persistently a little more detail.
There is more to processes than the waterfall model!
The waterfall model is generic. It's basically the list from above cascading down and down with all the titles written in little boxes.
Analysis:
Requirements: IS this something that the customer / user wants?
Design: There is more than one way of doing this. How are we going to do it?
The waterfall model is also called the linear sequential model.
Analysis and design is most of the time already done for you as an undergraduate. So when we're asked to do it we don't do it very well :-)
"All models are wrong.
Some models are useful."
The fact that it DOES talk about the different steps makes it useful.
The waterfall model is not state-of-the-art, but it's the most commonly used, when models are used.
Sometimes the problem changes as the world does, and you have to go back a bit and change your plans.
System testing: Does this solution solve the problem?
The working version isn't available until late in the process. So you have to have great confidence in what's happening!
Many customers cancel the project, making it fail. So you have to make sure the customer is as confident you are in the product as you are developing it.
Because you have to backtrack, people are keen on prototyping.
Specifying requirements is often very difficult. They don't understand what is doable or feasible.
Prototyping
Listen to the customer. They are the stake-holders. The people who are filling your pay-check. This becomes the most vital part of the project of defining the requirements.
Then you can go and build / Revise the mock-up, and the customer can test drive it.
So the mock-up serves as a method for identifying the requirements.
It may also create pressures from the user on time of delivery. The quality and performance etc. might not be what is needed in the longer term.
This all led to the advent of Rapid Application Development.
Similar to waterfall but in 60 to 90 days.
You can't build software and freeze it. You have to modify it as the world changes.
You have to predict that it will be accepted and used in the world, and that it is going to undergo substantial change throughout its life.
So we're looking at Incremental development We go though all these sorts of the same phases.
The spiral model is trendy.
We start with a small system, communicating with the customer, risk analysis, engineering, construction and release, customer evaluation etc. etc. etc. round and round and round.
It's not a silver bullet, but it's considered one of the best approaches to large scale software development. It's realistic in that you're not going to get it right the first time. Also you can use prototyping.
Component Assembly.
Is this a way to construct software? It's bottom up. Based on object technologies. Choose applications from pre-packaged components.
Doesn't help if you're doing something new. And it relies on the components being good. Useful where people who have written one kind of program, and then you build upon those components.
Just as toolkits have a different set of tools, so will software engineers have a different set of tools for each task.
Process: Is a way of doing something. An algorithm.
Step a, step b etc.
A sequence of steps is basically an algorithm.
So what makes a good process?
A whole list of things. See the list. Good is good, bad is bad!
Is there a RIGHT process for soft engineers?
OO?
Well actually there is little agreement about what is best. There's trendy stuff that flies around, and people jump on the bandwagon.
Everyone has their own way of doing things.
Some have NOPROCESS and make it up as they go along.
It's all a matter of opinion, and be prepared to be told by an employer to 'do it like this - our way'.
We need process, however, when we need communication. That's what it's about. But Soft Eng. isn't just about creating diagrams. By scribbling heaps of UML, you can just muddy what's going on. You have to think more about what's going into the diagrams.
The LARGER the project, the greater the need for a formal process.
Determining Process
Most student projects don't really need much of a formal process.
The steps in a GENERIC software Process.
Project Definition
You're presented with a problem. If you can't decide that there is a problem, then nothing much gets done.
Once you have accepted that there is a problem, then you have to nail it down.
You have to agree on the problem. You have to decide on the nature and the extent.
Requirements analysis
You have to find an acceptable solution. This means that the client will pay you for it.
Design
Project Implementation
Meet the requirements of the user, and solve problems.
Component testing
Integration Testing
System testing
^This is implementing from the bottom up ^
System Delivery
Maintenance
This where all the cost is. The more successful your software is, you spend heaps of time and money maintaining it.
But software engineering is all about the top of the list. This doesn't mean that you don't make any money.
The next lecture is looking at the software development management process in-persistently a little more detail.
There is more to processes than the waterfall model!
The waterfall model is generic. It's basically the list from above cascading down and down with all the titles written in little boxes.
Analysis:
Requirements: IS this something that the customer / user wants?
Design: There is more than one way of doing this. How are we going to do it?
The waterfall model is also called the linear sequential model.
Analysis and design is most of the time already done for you as an undergraduate. So when we're asked to do it we don't do it very well :-)
"All models are wrong.
Some models are useful."
The fact that it DOES talk about the different steps makes it useful.
The waterfall model is not state-of-the-art, but it's the most commonly used, when models are used.
Sometimes the problem changes as the world does, and you have to go back a bit and change your plans.
System testing: Does this solution solve the problem?
The working version isn't available until late in the process. So you have to have great confidence in what's happening!
Many customers cancel the project, making it fail. So you have to make sure the customer is as confident you are in the product as you are developing it.
Because you have to backtrack, people are keen on prototyping.
Specifying requirements is often very difficult. They don't understand what is doable or feasible.
Prototyping
Listen to the customer. They are the stake-holders. The people who are filling your pay-check. This becomes the most vital part of the project of defining the requirements.
Then you can go and build / Revise the mock-up, and the customer can test drive it.
So the mock-up serves as a method for identifying the requirements.
It may also create pressures from the user on time of delivery. The quality and performance etc. might not be what is needed in the longer term.
This all led to the advent of Rapid Application Development.
Similar to waterfall but in 60 to 90 days.
You can't build software and freeze it. You have to modify it as the world changes.
You have to predict that it will be accepted and used in the world, and that it is going to undergo substantial change throughout its life.
So we're looking at Incremental development We go though all these sorts of the same phases.
The spiral model is trendy.
We start with a small system, communicating with the customer, risk analysis, engineering, construction and release, customer evaluation etc. etc. etc. round and round and round.
It's not a silver bullet, but it's considered one of the best approaches to large scale software development. It's realistic in that you're not going to get it right the first time. Also you can use prototyping.
Component Assembly.
Is this a way to construct software? It's bottom up. Based on object technologies. Choose applications from pre-packaged components.
Doesn't help if you're doing something new. And it relies on the components being good. Useful where people who have written one kind of program, and then you build upon those components.
Just as toolkits have a different set of tools, so will software engineers have a different set of tools for each task.
0 Responses to “Lecture 2: The Software Process”
Leave a Reply