No silver bullet
The objectives of this essay are to examine whether or not Brook's original scepticism that "no single new development in the next ten years would give software developers an order-of-magnitude improvement in productivity, reliability, or simplicity" and "...future progress depends upon addressing the data" are reversible. We will discuss Brook's original thoughts and we will try to give alternative solutions (if any). This essay, in general, accepts Brook's thoughts as he worked on OS/360 one of the most known, for their size, software projects.Before we discuss what Fred Brooks is arguing, we ought to refer to the differences between software engineering and programming. These two concepts are, in fact, totally different. On one hand, programming is primarily a personal activity while on the other hand software engineering is essentially a team activity. In other words, a software engineering team, which is working on a project, may consist of many programmers. On the contrary, a programmer writes a complete program while a software engineer writes a software component that will be combined with components written by other software engineers to build a system. Furthermore, the component on
" The idea is that if we can specify what is inherent the software process implementation then we will have a context within which to address the accidental problems that limit our productivity. Brooke's fundamental changes have a lot of advantages. For this reason, software is very soon out of date. It is not an accident that most of the money spent on software involves the maintenance of it. Form what history has shown us up to now people learn from their mistakes, so it is possible that in a few years time other more effective techniques can be detected in order to manage large software projects. For that reason, before a project is implemented its objectives, scope and deliverables should be addressed and defined. Furthermore, we have to decide whether we want to spend money on maintaining the existing software or building new one. In other words, it is only towards the end that the developer and the customer are able to discover if the delivered product is satisfactory. So the problem of managing large software projects exists even in our days and we are unable to predict when it is going and if it is going to find a solution. Advances in software techniques (multiprogramming and time-sharing) lead to more ways to use computers. But it has not provided, and seems increasingly unlikely to do so, a fundamental solution to the software crisis. Thus, when people decided that the time has come to build complex programs only then they realise how difficult was to monitor large software projects. This situation was referred to us, as "software crisis" and it was characterised by many symptoms. Basically, I believe that the gap between the hardware and the software progress is one of the biggest problems that we are up to. The reason for having many people, with the same level of knowledge, working together is that you can minimise the gap between their thoughts.
Common topics in this essay:
Software Engineering,
Moreover Brooks,
Fred Brooks,
Analysis Software,
,
software projects,
software engineering,
Brook's OS/360,
software crisis,
Word Count,
size software,
delivered product,
silver bullet,
inherent nature software,
os/360 size software,
manage software projects,
manage software,
complex programs,
difficult monitor,
fundamental changes,
people level knowledge,
size software projects,
|