Question 8: Why do Software Projects fail so often?

Software Engineering is a string of activities which to develop a quality software in time, within a budget. However, there are several reasons make software projects fail. Some of them are

In fact, the project itself might be failed at the very first beginnig, which is, the project aspect may run slightly or even extremely different from the orginal direction. For the example, a bank is going to downsize its system from IBM mainframe to mid-range platform. However, this bank finally chose NCR Unix as its goal instead of AS/400. At first, it sounds that the project will run smoothly. In second, it is suffering from at least 2 things. First, NCR Unix has no job scheduler, therefore, the project team has to develop a new one. Furthermore, the developer has to find a new database in order to replace the DB2 which run in IBM mainframe. Apparently, these 2 things are time and money consuming. At last, this bank chopped the whole downsize project, upgraded the IBM mainframe, failed back mid-range project ot central computer so that she could pass the year of 2000.
( The above example might be wrong becasue system is not encountered in the area of software engineering. )

One step forward and two-step back, debugging is one of the duties of a developer, however, one or more problems may appear when a bug is fixed.

Ten pounds in five-pound sack, people usually put all functions into a system. Nevertheless, it may not be possible to do so.

Question 7: What is test-driven development?

The steps of test first development (TFD) are overviewed in the UML activity. The first step is to quickly add a test, basically just enough code to fail. Next you run your tests, often the complete test suite although for sake of speed you may decide to run only a subset, to ensure that the new test does in fact fail. You then update your functional code to make it pass the new tests. The fourth step is to run your tests again. If they fail you need to update your functional code and retest. Once the tests pass the next step is to start over (you may first need to refactor any duplication out of your design as needed, turning TFD into TDD).

A simple formula: TDD = TFD + refactoring.

TDD completely turns traditional development around. Instead of writing functional code first and then your testing code as an afterthought, if you write it at all, you instead write your test code before your functional code. Furthermore, you do so in very small steps – one test and a small bit of corresponding functional code at a time. A programmer taking a TDD approach refuses to write a new function until there is first a test that fails because that function isn’t present. In fact, they refuse to add even a single line of code until a test exists for it. Once the test is in place they then do the work required to ensure that the test suite now passes (your new code may break several existing tests as well as the new one). Once your code works, you then refactor it to ensure that it's remains of high quality. This sounds simple in principle, but when you are first learning to take a TDD approach it proves require great discipline because it is easy to “slip” and write functional code without first writing a new test. One of the advantages of pair programming (Williams and Kessler 2002) is that your pair helps you to stay on track.

An underlying assumption of TDD is that you have a unit-testing framework available to you. Agile software developers often use the xUnit family of open source tools, such as JUnit or VBUnit, although commercial tools are also viable options. Without such tools TDD is virtually impossible.

Reference: http://www.agiledata.org/essays/tdd.html

Question 6: Software Design Patterns: How much do you understand?

Adapter
Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

Bridge
Decouple an abstraction from its implementation so that the two can vary independently.

Composition
Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

Facade
Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use

Proxy
Provide a surrogate or placeholder for another object to control access to it.

Reference: http://www.dofactory.com/Patterns/Patterns.aspx

Question 5: Software quality: What makes a program code good?

A good program works flawlessly and has no bugs. But what internal qualities produce such perfection? It's no mystery, we just need some occasional reminding. Whether you code in C/C++, C#, Java, Basic, Perl, COBOL, or ASM, all good programming exhibits the same time-honored qualities: simplicity, readability, modularity, layering, design, efficiency, elegance, and clarity.

Simplicity means you don't do in ten lines what you can do in five. It means you make extra effort to be concise, but not to the point of obfuscation. It means you abhor open coding and functions that span pages. Simplicity—of organization, implementation, design—makes your code more reliable and bug free. There's less to go wrong.

Readability means what it says: that others can read your code. Readability means you bother to write comments, to follow conventions, and pause to name your variables wisely. Like choosing "taxrate" instead of "tr".

Modularity means your program is built like the universe. The world is made of molecules, which are made of atoms, electrons, nucleons, quarks, and (if you believe in them) strings. Likewise, good programs erect large systems from smaller ones, which are built from even smaller building blocks. You can write a text editor with three primitives: move, insert, and delete. And just as atoms combine in novel ways, software components should be reusable.

Layering means that internally, your program resembles a layer cake. The app sits on the framework sits on the OS sits on the hardware. Even within your app, you need layers, like file-document-view-frame. Higher layers call ones below, which raise events back up. (Calls go down; events go up.) Lower layers should never know what higher ones are up to. The essence of an event/callback is to provide blind upward notification. If your doc calls the frame directly, something stinks. Modules and layers are defined by APIs, which delineate their boundaries. Thus, design is critical.

Design means you take time to plan your program before you build it. Thoughts are cheaper than debugging. A good rule of thumb is to spend half your time on design. You need a functional spec (what the programs does) and an internal blueprint. APIs should be codified in writing.
Efficiency means your program is fast and economical. It doesn't hog files, data connections, or anything else. It does what it should, but no more. It loads and departs without fuss. At the function level, you can always optimize later, during testing. But at high levels, you must plan for performance. If the design requires a million trips to the server, expect a dog.

Elegance is like beauty: hard to describe but easy to recognize. Elegance combines simplicity, efficiency, and brilliance, and produces a feeling of pride. Elegance is when you replace a procedure with a table, or realize that you can use recursion—which is almost always elegant:

int factorial(int n)
{ return n==0 ? 1 : n * factorial(n-1);}

Clarity is the granddaddy of good programming, the platinum quality all the others serve. Computers make it possible to create systems that are vastly more complex than physical machines. The fundamental challenge of programming is managing complexity. Simplicity, readability, modularity, layering, design, efficiency, and elegance are all time-honored ways to achieve clarity, which is the antidote to complexity.
Clarity of code. Clarity of design. Clarity of purpose. You must understand—really understand—what you're doing at every level. Otherwise you're lost. Bad programs are less often a failure of coding skill than of having a clear goal. That's why design is key. It keeps you honest. If you can't write it down, if you can't explain it to others, you don't really know what you're doing.
There's so much I've left out, but there's one more thing I hesitate to add. Use it sparingly and only in desperation: the clever hack. The clever hack is when you sacrifice your principles to expedience. When you hardcode some condition or make a call up the layer cake—or commit some other embarrassment—because it works and there's no time to do it right.

Reference:
http://msdn.microsoft.com/msdnmag/issues/04/07/EndBracket/
http://chantaising.blogspot.com/2006/04/software-quality-what-makes-program.html

Question 4: Stuff that lets agile software developers show off what they believe in

YAGNI
In software engineering, YAGNI, short for 'You Ain't Gonna Need It', is a reminder for programmers that one should never add functionality until it is necessary. The temptation to write code to that is not necessary at the moment, but is perceived to be necessary in the future, has some overlooked disadvantages: Delays what the programmer was originally working on. There is a chance that the requirements for the software will change and the functionality will become either different or unneeded. By applying the YAGNI principle, the programmer has not wasted time in adding the redundant functionality and no longer has to waste additional time debugging the code. The code is also less cluttered as a result. In another website YAGNI also short for 'You Aren't Gonna Need It', but both the meaning are same.

JsUnit
JSunit is some javascript and an HTML page in which you can include fragments of javaScript to be tested. It provides some asserts and a way of calling all of the test functions on your page plus an output of success or failure. Its really strong point is that it runs in a browser so you get to check for compatibility. The weak point is that it does not scale nicely like JUnit, it's difficult to envision suites of tests under this framework.

Reference: http://en.wikipedia.org/wiki/YAGNI http://c2.com/cgi/wiki?YouArentGonnaNeedIt http://xpdeveloper.org/cgi-bin/oldwiki.cgi?JsUnit http://c2.com/cgi/wiki?JsUnit http://www.jsunit.net/ http://jsunit.berlios.de/

Question 3: Software Engineering Certification Programs: What Can You Learn from Them?

A professional certification, trade certification, or professional designation often called simply certification or qualification is a designation earned by a person to certify that he is qualified to perform a job. Certification indicates that the individual has a specific knowledge, skills, or abilities in the view of the certifying body. Professional certifications are awarded by professional bodies and corporations. The difference between licensure and certification is licensure is required by law, whereas certification is generally voluntary. Sometimes the word certification is used for licensure.
People become certified through training and/or passing an exam. Individuals often advertise their status by appending the certification abbreviation to their name (e.g. "Jane Doe, RHCE"). Strictly speaking, most certifications do not grant post-nominals and it is usually the professional certifications that do.
Certifications may be perpetual, may need to be renewed periodically, or may be valid for a specific period of time (e.g. the life-time of the product upon which the individual is certified). Although it is more common in regard to licensure, sometimes as part or whole of the renewal of an individual's certification, the individual must show evidence of continual learning — often termed continuing education — or earning continuing education units (CEU).
Certifications are offered through a certification body. This is usually a business organization, and sometimes a professional body. Sometimes, the organization's business is directly related to the certification, as in a software firm that certifies individuals as competent to use its products. In other cases, an organization (often a not-for-profit organization) exists wholly, or in large part, to offer a particular certification. Whatever its nature, the certifying body determines the policies of the certification program. Potential consumers of a certification wish to understand the nature of the certifying body and the certification process. An individual who bears a designation but appears unable to perform competently is said to be a paper tiger because their resume suggests that they are more effective than they actually are.
Certifications are very common in industry, and in particular the computer industry. The National Organization for Competency Assurance (NOCA) is a US-based organization which helps certification bodies by providing with information on the latest trends and issues of concern to practitioners and organizations focused on certification, licensure, and human resource development. Many members of the Association of Test Publishers (ATP) are certification bodies.


Reference: http://en.wikipedia.org/wiki/Certification_(software_engineering)

Question 2: UML Tools: What is your favorite?

Three kinds of UML tool were introduced at lab lesson, they are a) Poseidon, b) Eclipse, c) Visual Paradigm(VP). However, I found the Visual Paradigm is not user-friendly to me. On the other hand, Eclipse looks fimiliar to me and it looks like VIM ( a popular editor ). And I like Eclipse the most. In fact, the general outlook of Eclipse and VP are similar to each other. But I was really suffering in using VP during the lab, even move an arrow might spend me ten minutes. Therefore, Visual Paradigm is definily not my favourite. In addition, I am not interested in trying Poseidon because I am too lazy to do so if a software can be subsutited by the other that I have already knew, i.e. Eclipse.

Question 1: Software Engineering Skills: Students’ Opinions

Software Engineering is to solve a certain of problems with a sum of money within a period of time. Therefore, there are a few points that should be handle. Firstly, problems have to be located and to be suited into the requirements. Secondly, by using different UML diagrams to present to different people such as user case diagram to the client. Thirdly, testing is to find out if the solutions are work or not. Finally, implementation is to put all the jobs that the developers had done into the real world.