Gregory M. KapfhammerAssociate Professor of Computer Sciencehttp://www.cs.allegheny.edu/~gkapfham/ |
Chapter Three: Is it Really Engineering?
|
The practice of software development can be considered the end of a life cycle that, in most cases, begins with a theoretical computer science background. Theoretical computer science is there to lay down the laws of the field which software development will implement. Software development has no laws and through experimentation, it may prove or disprove the theoretical groundwork which might expose a bug that was present in the original theory and logical work.
Two examples of how theoretical computer science might influence the practice of software development are software testing are testing and flow charts. Before you can test software you must write the code and use the laws of computer science and syntax to write it properly however it is possible that once it gets to the process of implementing the code it does not work thus the user must go back and fix the bugs. Flow charts also map out the same type of software life cycle and operations but if the theory behind the flow chart is incorrect the software implementation will pick up on it.
Noosh Moussavi
I don't understand your example with the flow chart. What is the theory that forms the underpinnings of these "flow charts"? Are you talking about control flow graphs and data flow analysis? Or, are you talking about PERT charts that govern project management and graph theory? Please give us an update and explore your answer further. Greg
One of the aspects of software development that makes it unique is that given sets of theoretical rules exist not to describe the software's actions but rather to prescribe them. In other words, the software is created to fit the established theoretical rules rather than rules being established to describe the software. This relationship is important, because although new technologies may arise, the underlying theories of computing remain constant and provides a level of stability in the quickly changing world of advancing computer technology.
Can you give an example of what you are referring to here? Are you simply stating that some problems are algorithmically unsolvable and thus we cannot hope to compute them? What are some examples of algorithmically unsolvable problems? Greg
Another way is which theory benefits software development is by helping to provide a measure through which one can be reasonable assured of the correctness of their program. This can be of great importance when developing such critical systems on which lives may depend. A final way that theory can influence software development is along the line of probability. In reality it is impossible to tell how often and when a system may fail, but using theory one may obtain reasonable estimates concerning the reliability of the software.
Matt Rummel
- How is a software package like a skyscraper or a bridge? How are these entities different? Some software engineers often talk about building applications out of "software components" and then justify this approach by observing that we do the same thing to build houses. What do you think about this statement?
Software packages are like skyscrapers and bridges because they are built from the bottom up. They all start off as an idea or theory and go through several stages before they are completely implemented and functioning properly. They both need maintenance and design, and in the end they both accomplish a goal or task that previously were left unresolved. They are also different in the fact that actual standing structures such as bridges and skyscrapers was hardware that have constraints on its form that originate from the physics and material science of its manufacture. These constraints must be under human control. However, software packages lack these constraints which allow the software engineer the ability to create software that is not constructed properly and as a result can not work. In other words, with hardware if something in the design or theory is wrong, we can have serious problems in our hands therefore the designs must be in the hands of a human who can control these problems. Software, on the other hand, is already in the hands of humans thus the engineers are able to create structures and packages that can be structured correctly but that will not work.
With regards to software components and building applications from them, there is a difference between building software and building homes. This analogy is just like any other analogy that you could draw with real life and software engineering. The similarities are they both start from the bottom and work up. There is the possibility that just like there will be faulty material in housebuilding you could have a faulty software component, which both will result in disasterous results. On the other hand, it could have the purpose of the software component to be disasterous and since the engineer that created that would be responisble for the chaos we have no other human who can control this problem. With house building, you have inspectors and other officials who will have to give their approval for the house before it can be used and so you can not build a fault house on purpose.
Noosh Moussavi
I believe that this statement is quite true to building software. All software starts out with an idea or blueprint, just as a skyscraper or a bridge does. Then there are software components that one must find sound with minimal defaults. If these software components are not sound, the software could be unstable, like leaving small elements out that would save on cost. Just the same as building a house, only putting half the nails in the frame to save money. It would leave the house unstable. So I do feel a software package can be the same as a skyscraper or bridge.
John Pacino
Software engineering is similar to a bridge or a building in that the parts in the lifecycles of these structures are similar. Like construction projects, software design must (or should) be first carefully planned out in the "software architecture" stage to produce a design that meets the needs of the user, is safe, and provides good security. During the life of the building, parts will need replaced as they wear down. The same is done with software; it is changed to meet to varying needs of its users, correct bugs or security hazards, and to be to date with the newest technology. Just like buildings, software will overtime be too obsolete to upgrade and the developer will have to start over again. Some differences lie in the fact that while one cannot use components of one bridge in future bridges, portions of older code may be used in never versions of software. The user usually is unaware of how much has been changed in an updated version. Furthermore, after the initial expense of developing the software system, it can be cheaply duplicated over and over again and used by others if the application is not specialized for one client's needs.
Like a house, one builds software out of many different components. Each component has a specific purpose or task it performs in the overall structure. A major difference in the approach to each groups respective work is that construction firms face accountability for that which they create. Furthermore, buildings and bridges have become quite safe over the years because in general the functionality of a building or bridge is the same as any other building or bridge, whereas two pieces of software are likely to be totally different and have no common functionality at all. This allows bridge design to improve with each bridge built, whereas the varying functionality of software means that improvements in one system may not be able to be utilized in another. Furthermore, buildings and bridges are regulated by inspectors to make sure that it complies with safety standards. No such regulations exist with software; it is totally up to manufacturer to do testing and no level of testing is requiring by law.
Overall, I think that the statement accurately reflects the way that software is constructed and maintained in the software lifecycle, but that overall a product created in the physical word has totally different qualities than one designed in the abstract. Therefore, in terms of complexity and dependability, the respective products are incomparable.
Matt Rummel
It seems that all of you seem to agree with this analogy. Personally, I have always disagreed with it. If I build a bridge, I can easily estimate the operating conditions under which the bridge will perform in a reliable manner. This is possible because scientists have developed models that describe the ways that metal beams flex. Unfortunately, we do not have models of this nature in the field of software engineering.
Yes, it is possible to build a software system from the bottom-up, but it is also possible to build it in a top-down fashion (witness extreme programming and test-first development). Can you still build bridges and skyscrapers in a top-down manner?
Researchers and practicioners often justify the usage of COTS components through the building analogy. In the past, I have felt that there arguments were partciularly flawed. If we build a bridge (or, a microprocessor, for that matter), we have a sense of the properties of the whole by simply gauging the properties of each element. Software has emergent properties that only appear after the system has been composed. Greg
- The authors discuss different options for the certification of software engineers. Do you think that the accreditation will lead to higher quality software?
I dont believe that more accreditation will lead to higher quality software. As the author mentioned, the medical field has a lot of accreditation that hopeful doctors must go through before they can receive their medical license but that does not mean that we have higher quality doctors. We still have incompetent doctors and doctors who misdiagnose and they are accredited medical professionals because they were took a test and became certified. It really comes down to the engineer or professional themselves to create higher quality software because there really is no way that a test or exam will be able to determine who is a better software engineer. Obviously it is still an ongoing issue if the professional software engineering community and the government have not been able to come up with a training or examination that will differentiate between the good and the bad engineers.
Noosh Moussavi
I do not think that accreditation will lead to higher quality software because like any kind of profession, certification may mean that they know about their field, but may not make the right decisions in certain situations. Like a doctor who went through years of medical school can say he had all the training and passed all the tests, but may not work well in certain situations or under pressure. Plus it is hard for the government to decide on how to certify a software engineer and what kind of test a certification will consist of.
John Pacino
I do not believe that having certifications for software engineers will increase the reliability of software. Like any profession, there will be some individuals who are more capable than others, but I do believe that industry is capable of sorting these individuals out if they have to proper motivation to do so. Ultimately, I believe the only thing that will improve the quality of software is an increase in accountability for poorly written software imposed by government. Products make money on when they are in the stores, not being tested. If companies were held more responsible for what they wrote, then there would be a greater emphasis put on testing, overall proof correctness, and be more rigid with employee standards.
Matt Rummel
If accredidation is not the answer to our software quality problems, what might be proposed as a solution? Jeff Voas has written a short article about the Software Qualtiy Certification Triangle. Do you think that this adequately characterizes the difficulties that will be faced by software engineers and the techniques that can be used to produce high quality software? Greg
Link to this Page
- Introduction to Software Engineering last edited on 30 August 2004 at 1:12 pm by aldenv28.allegheny.edu