Theatre & Films Productions

Software Engineering

Process Models

A nice presentation on Agile Methodologies and Extreme Programming. The “How it works” section is useful! Thanks Utkarsh.

Another presentation on eXtreme Programming. I really appreciate the pictures of Pair Programming. It gives a really good idea of the concept.

This one on UML

A very interesting presentation on Use Case Diagram

This one on Activity Diagram.

For the lab session, I tried to draw the activity diagram on ArgoUML, and I must admit that ArgoUML rocks! Give it a try, you won’t be disappointed 😀



Today I am going to do presentation for the Software Engineering class at the University. Ahem Ahem. a bit tensed, but no…..lets remain cool as usual. Eihhhhh the slides are not ready yet and I am completing them now. So as soon finished, will upload them and share it to the Software Engineering community on my blog, via slideshare. Keep connected till then!

A major update:

I’ve just uploaded the powerpoint presentation on Slideshare!

How was my presentation? please vote:

Am hyper happy and relieved too. I was not nervous during the presentation. Just wanna say the stuff I couldnot before class:

Firstly I would like to thank our lecturer for giving us the opportunity to enhance our communication skills as IT professionals/ Professional Software Engineers. Yesterday I attended the Prize Giving Ceremony for ACM programming contest. It was a quiet observation to make that the cse student who did his speech before his audience maybe did not bother to look at his audience and talk with them. He was just reading his paper. Communication Skills, maybe he lacked that. Of course, it was a lecture theatre very full and Journalists, MBC TV camera, respected lecturers, people from Accenture, Hot atmosphere na!!!!!

If that guy had the opportunity to talk before the class, just as we are having the opportunity to talk in the Software Engineering class, maybe his speech would had been more interesting, with his touch of charisma in his speaking style.

Concerning my presentation today, that was simply unexpected. I was tensed because of the so much slides to talk on (exceeding 3 minutes even). I was not sure of myself because of the quite good number of students present in ELT 2 – Engineering Tower, for the first time speaking before such a big number of computer students,phewwwwwwwwww. I took a deep breath, talk with the beautiful gurl who was to present with me also, and mustered confidence and set of f to talk, talk and talk. I even talked in creole (li chien – Gimp, peingouin), hindi (“paisa” – meaning money), french (“bracquer la banque pour pouvoir payer IBM Rational Rose)!

Today marks one of my coolest presentation I have ever made. I would like to receive feedback on my style of presention and the design of the slides, and how was it overall? Thanks…

The Software Crisis

Aim: To explain the background of the software crisis and the need for an engineering approach.

When projects became too big and complicated to easily maintain, the “software crisis” was born, with programmers saying, “We can’t get projects done, and if we can, they’re too expensive!”

Source: Bruce Eckel, Thinking in C++

[The major cause of the software crisis is] that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.

Edsger Dijkstra, The Humble Programmer

The causes of the software crisis were linked to the overall complexity of the software process and the relative immaturity of software engineering as a profession. The crisis manifested itself in several ways:

  • Projects running over-budget.
  • Projects running over-time.
  • Software was very inefficient.
  • Software was of low quality.
  • Software often did not meet requirements.
  • Projects were unmanageable and code difficult to maintain.
  • Software was never delivered.
  • The most visible symptoms of the software crisis are
    • Late delivery, over budget
    • Product does not meet specified requirements
    • Inadequate documentation
  • Some observations on the software crisis
    • “A malady that has carried on this long must be called normal” (Booch, p. 8)
    • Software system requirements are moving targets
    • There may not be enough good developers around to create all the new software that users need
    • A significant portion of developers’ time must often be dedicated to the maintenance or preservation of geriatric software

From Wikipedia,

1965 to 1985: The software crisis

Software engineering was spurred by the so-called software crisis of the 1960s, 1970s, and 1980s, which identified many of the problems of software development. Many software projects ran over budget and schedule. Some projects caused property damage. A few projects caused loss of life. The software crisis was originally defined in terms of productivity, but evolved to emphasize quality. Some used the term software crisis to refer to their inability to hire enough qualified programmers.

  • Cost and Budget Overruns: The OS/360 operating system was a classic example. This decade-long[citation needed] project from the 1960s eventually produced one of the most complex software systems at the time. OS/360 was one of the first large (1000 programmers[citation needed]) software projects. Fred Brooks claims in The Mythical Man Month that he made a multi-million dollar mistake of not developing a coherent architecture before starting development.
  • Property Damage: Software defects can cause property damage. Poor software security allows hackers to steal identities, costing time, money, and reputations.
  • Life and Death: Software defects can kill. Some embedded systems used in radiotherapy machines failed so catastrophically that they administered lethal doses of radiation to patients. The most famous of these failures is the Therac 25 incident.

Therac 25 incident:

Researchers who investigated the accidents found several contributing causes. These included the following institutional causes:

  • AECL did not have the software code independently reviewed.
  • AECL did not consider the design of the software during its assessment of how the machine might produce the desired results and what failure modes existed. These form parts of the general techniques known as reliability modeling and risk management.
  • The system noticed that something was wrong and halted the X-ray beam, but merely displayed the word “MALFUNCTION” followed by a number from 1 to 64. The user manual did not explain or even address the error codes, so the operator pressed the P key to override the warning and proceed anyway.
  • AECL personnel, as well as machine operators, initially did not believe complaints. This was likely due to overconfidence.[3]
  • AECL had never tested the Therac-25 with the combination of software and hardware until it was assembled at the hospital.

The researchers also found several engineering issues:

  • The failure only occurred when a particular nonstandard sequence of keystrokes was entered on the VT-100 terminal which controlled the PDP-11 computer: an “X” to (erroneously) select 25MV photon mode followed by “cursor up”, “E” to (correctly) select 25 MeV Electron mode, then “Enter”. This sequence of keystrokes was improbable, and so the problem did not occur very often and went unnoticed for a long time.[2]
  • The design did not have any hardware interlocks to prevent the electron-beam from operating in its high-energy mode without the target in place.
  • The engineer had reused software from older models. These models had hardware interlocks that masked their software defects. Those hardware safeties had no way of reporting that they had been triggered, so there was no indication of the existence of faulty software commands.
  • The hardware provided no way for the software to verify that sensors were working correctly (see open-loop controller). The table-position system was the first implicated in Therac-25’s failures; the manufacturer revised it with redundant switches to cross-check their operation.
  • The equipment control task did not properly synchronize with the operator interface task, so that race conditions occurred if the operator changed the setup too quickly. This was missed during testing, since it took some practice before operators were able to work quickly enough for the problem to occur.
  • The software set a flag variable by incrementing it. Occasionally an arithmetic overflow occurred, causing the software to bypass safety checks.

Peter G. Neumann has kept a contemporary list of software problems and disasters.[2] The software crisis has been slowly fizzling out, because it is unrealistic to remain in crisis mode for more than 20 years. SEs are accepting that the problems of SE are truly difficult and only hard work over many decades can solve them.

More reading: