Lecture 2: The Software Process
Published Thursday, March 02, 2006 by Mathieu.
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.
Lecture 1: Inroduction to Software Engineering
Published Wednesday, March 01, 2006 by Mathieu.
Analysis and Design
A lot compressed into this one course, but there is some that overlaps with other subjects.
It will help you better your career.
We're talking about being methodical. Distinction between computer programming and software Engineering. It's not hard to write easy programs.
Analysis. It's hard to do this part well. This course is about coming up with the specifications. This is hard.
There is a lot of ancient software out there that needs to be maintained.
Design. OO using UML. Interaction diagrams etc.
There is a temptation to think about soft eng as about how to specify a diagram. But doing this is generally the easy bit. Knowing what is in the diagrams is the hard bit, and isn't told well in the soft eng books.
Affordances, awareness of mental models, visibility, mapping and feedback.
This course has everything junked into it!
How do I pass?
Exam %40
Assignments 60% (Group 45%, indi 15%)
There is a 50% hurdle for both.
Often there aren't clearly right and wrong answers to your analysis. People don't necesarily agree on what is a good analysis or design.
There are two practice classes each week (on Friday).
These are important to learn why there are more important answers to an analysis.
You will find that people write thick books, probably because other people have, and that then they can justify selling them for around $100. Really you don't need these, and the thickness of the book isn't a good indication of how good the book is.
Work collaboratively, don't copy.
Group work is going to be interesting because you have to interact with human beings and not computers. And human beings are more complex than computers. So you will probably run into problems.
You can look at the material from 2005, it is still all relevant.
So what is software Engineering?
Designing, bulding and maintaing large software systems in a cost-effective way.
Every man and his dog has his own definition though.
Engineering is about solving problems. If you can solve problems, you are employable. Many engineers don't work in software, but in management. Because they are good with solving problems.
So soft eng is about solving problems about software.
There are problems that we need software engineers for. This is good for us!
You don't need to be a soft engineer to be sucessful. (Microsoft, ID Doom, etc etc). But they are not repeatable. It's because these people got lucky. But with engineering, we want to get things right, but not because it's an accident. So we can increace our chances.
If you practice your programming, you will get better at it.
This coure gives you a chance to become a better programmer. To think about how to become a better programmer. You might not be a good programmer, but a better programmer than before.
Projects often fail because they are so much bigger than they were before. Or because they made something that the user didn't want. Or something else comes in that makes the project obsolete.
There are classic disasters. The problem is that there were needed large numbers of people to write these softwares.
Sometimes there are problems with real time systems. A 10 year old with VB isn't necessearily going to get that right.
Mission critical software: pacemakers.
These are fairly large software systems.
Large systems take years to develop.
Product and Process
Both key aspects of SE.
We move from emphasis on product to process, and back and forth.
A software product is not the same as a hardware product. mIt is developed, not manufactured.
In the real world, your software exists for a long time, and as the world changes, you're going to have to keep fixing it.
A lot compressed into this one course, but there is some that overlaps with other subjects.
It will help you better your career.
We're talking about being methodical. Distinction between computer programming and software Engineering. It's not hard to write easy programs.
Analysis. It's hard to do this part well. This course is about coming up with the specifications. This is hard.
There is a lot of ancient software out there that needs to be maintained.
Design. OO using UML. Interaction diagrams etc.
There is a temptation to think about soft eng as about how to specify a diagram. But doing this is generally the easy bit. Knowing what is in the diagrams is the hard bit, and isn't told well in the soft eng books.
Affordances, awareness of mental models, visibility, mapping and feedback.
This course has everything junked into it!
How do I pass?
Exam %40
Assignments 60% (Group 45%, indi 15%)
There is a 50% hurdle for both.
Often there aren't clearly right and wrong answers to your analysis. People don't necesarily agree on what is a good analysis or design.
There are two practice classes each week (on Friday).
These are important to learn why there are more important answers to an analysis.
You will find that people write thick books, probably because other people have, and that then they can justify selling them for around $100. Really you don't need these, and the thickness of the book isn't a good indication of how good the book is.
Work collaboratively, don't copy.
Group work is going to be interesting because you have to interact with human beings and not computers. And human beings are more complex than computers. So you will probably run into problems.
You can look at the material from 2005, it is still all relevant.
So what is software Engineering?
Designing, bulding and maintaing large software systems in a cost-effective way.
Every man and his dog has his own definition though.
Engineering is about solving problems. If you can solve problems, you are employable. Many engineers don't work in software, but in management. Because they are good with solving problems.
So soft eng is about solving problems about software.
There are problems that we need software engineers for. This is good for us!
You don't need to be a soft engineer to be sucessful. (Microsoft, ID Doom, etc etc). But they are not repeatable. It's because these people got lucky. But with engineering, we want to get things right, but not because it's an accident. So we can increace our chances.
If you practice your programming, you will get better at it.
This coure gives you a chance to become a better programmer. To think about how to become a better programmer. You might not be a good programmer, but a better programmer than before.
Projects often fail because they are so much bigger than they were before. Or because they made something that the user didn't want. Or something else comes in that makes the project obsolete.
There are classic disasters. The problem is that there were needed large numbers of people to write these softwares.
Sometimes there are problems with real time systems. A 10 year old with VB isn't necessearily going to get that right.
Mission critical software: pacemakers.
These are fairly large software systems.
Large systems take years to develop.
Product and Process
Both key aspects of SE.
We move from emphasis on product to process, and back and forth.
A software product is not the same as a hardware product. mIt is developed, not manufactured.
In the real world, your software exists for a long time, and as the world changes, you're going to have to keep fixing it.