幼儿园助教活动Software Development Methodologies
Introduction运河博物馆
海底两万里主要内容600字Software methodologies are concerned with the process of creating software - not so much the technical side but the organizational aspects. In this, the first of two articles, I will introduce the different types of methodologies. I will describe them from an historical perspective, as one way to understand where we are and where we are going is to know where we have been.
There will also be a subquent companion article looking at the current state of the art and what I believe the future holds. This cond article is given the rather controversial title of "Why Creating Software is not Engineering", which I will, of cour, explain. In the 2nd article I will discuss veral popular agile methodologies particularly their most important aspects (such as unit testing), which are generally neglected or glosd over.
Before beginning I should warn the reader of my penchant for analogy. Actually this whole a
rticle is one big analogy stretched almost to breaking point. I like them becau many of the concepts in software development are abstract and hard to grasp, but using a familiar real-world situation, like taking a taxi to the pub, can clarify the ideas. Of cour, there is always the caveat that no analogy is perfect. Be careful to understand the similarities and the differences. 古代诗歌大全
Ad-hoc
Historically, the first methodology was basically no methodology at all. This is generally called the "ad hoc" methodology.
We'll start with a simple scenario. You are to meet your friend Jim at the Station Hotel. You have no idea where that is but you jump in a cab and tell the taxi driver where you want to go. A few minutes later you arrive at your destination safely and without wasting any drinking time!
计算机英语词汇In this analogy you are the "customer" and the taxi driver is the "developer". The above is
the ideal ca where the customer knows where they want to go and the developer knows how to get there. Unfortunately the real world is never this simple. Consider the variations.
Problems
1. You tell the driver where to go but you end up at the train station not the Station Hotel. Obviously he misheard you and after all many of his pasngers go there.
You clarify the situation but the taxi driver is uncommunicative and you end up at the wrong hotel. Eventually, you work out that the driver does not speak English well.
三地速查表At some point you give up. If you are really persistent you might get to your destination but by then Jim has already left.
2. You ask the taxi driver to take you to the Station Hotel to which the immediate reply is "Which one?". Apparently, there are three within a ten mile radius and you don't know which one Jim went to. You try them all but can't find Jim.
The driver suggests it might be the "Fire Station Hotel" which was actually not far from where you started.
3. The taxi driver kindly informs you that your destination is quite distant and you do not have enough money. He suggests that you take the bus.
Of cour, the bus is slow and does not go directly past the pub. You get there eventually.
4. The taxi takes you straight to the hotel but it's clod for business.
5. You are half way there when you reali you need to post a letter. Then Jim calls your mobile and says that he has gone to a different hotel. Then you get stuck in traffic and also need to u the bathroom. The whole trip is much longer and more expensive than expected.
6. The taxi driver ems to know where to go but is inexperienced and after quite a while he realis that he is going completely the wrong direction. Several times he has to backt
rack but eventually finds the destination though the trip takes much longer than expected.
I'm sure you can think of many more things that can go wrong.
Summary
The ad-hoc methodology can work provided you have a simple problem. If the customer knows exactly what they want and the developer knows how to give it to them and has the right tools to do so (a reliable vehicle and a street directory if necessary) then there is a good chance of success. However, most of the time you get there late or not at all.
The above scenarios reprent veral common problems en in software development, namely miscommunication (1), a customer who doesn't know exactly what they want (2) or thinks they do until they try it (4), changing requirements (5) and inexperienced developers (6). I leave it the reader to work out what scenario 3 means. 仙桥地下河
Waterfall
OK, you want to avoid all the above problems, but what do you do? Conventional wisdom is to ask an expert for help and there are many willing helpers ready to provide their rvices, for a fee, of cour. You find that you need an "analyst" to work out where you really want to go and a "designer" to provide detailed unambiguous instructions on how to get there.
