Question 8: Why software projects fail so often?

Fun
There is no enthusiasm. 'Fun at work' is a critical success factor. However, none of the participants seems to enjoy the project.

Gap
There is a communication gap between the analyst and the customer. The analyst does not bother to communicate in the user's language and fails to see that the technical schemes deter the user. The user's enthusiasm fades away. The analyst realises that things are not going smooth, but does not get beyond the phase 'Conscious competent' of the 'Unconscious Competent’ theory. To make things worse, the analysts passes the buck to the user, right at the beginning of the project. It is wrong as the customer only knows what he gets, when he sees what he has got. That is way too late. The customer should have had a clear view, right from the beginning at drawing the first specifications.

Shift off
The idea to save time by shifting off issues to the next phase is really bad. A job half done always gives problems. In a later phase nobody will know which half was ready. Very often, the whole analysis gets redone, or just half redone due to time pressure. As a project progresses, it will take more and more time to investigate things and correct errors. 'Save' on analysis like this, and you can be sure that problems will strike back double during the construction phase. At the start of the construction phase, the programmers unjustly accept the incomplete design. They grumble a bit, but fail to take action.

Manpower
Additional manpower is not always effective. The law of diminishing returns goes for extra manpower too. Additional manpower might decrease productivity. Proverb: What 2 man can do in 2 days, a team of 10 can to in 10. Moreover, new staff need to work their way in. And the experienced employees won't have any time for guidance.
The leading thread that runs through the entire project is a lack of quality with 'time pressures' as excuse. There is never time to do things right, with the hope that future will provide time to correct errors. Those who know something of Total Quality Management realise that quality does cost time and money, but it is peanuts compared to the costs of non-quality.

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

Agile software development offers a new mindset and approach to building applications that succeed.

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

Compare with the CSDP program with the textbook, the areas are not include in textbook are:

1. Engineering Economics
2. Professional Practices
3. Specialized Software Design Approaches
4. Code Design, Organization, Documentation, Tuning, Defect Identification and Correction.

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.

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, design and purpose. You must 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.

Reference: MSDN

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

I understood that a pattern is a named nugget of instructive information that captures the essential structure and insight of a successful family of proven solutions to a recurring problem that arises within a certain context and system of forces. The concrete form which recurs is that of a solution to a recurring problem. But a pattern is more than just a battle-proven solution to recurring problems. The problem occurs within a certain context, and in the presence of numerous competing concerns. The proposed solution involves some kind of structure which balances these concerns in the manner most appropriate for the given context. Using the pattern form, the description of the solution tries to capture the essential insight which it embodies, so that others may learn from it, and make use of it in similar situations. The pattern is also given a name, which serves as a conceptual handle, to facilitate discussing the pattern and the jewel of information it represents.

Question 2: UML Tools: What is your favorite?

I think Poseidon for UML is my favorite. Because its a power function I think and the interface is quite clearly, so that I can easy to use it. But it had a limitation, it only have 30-day for trial. If I find the free one, I perfer Visual Paradigm for UML, because it is free, but less powerful than Poseidon.

Question 7: What is test-driven development?

Base on my learning from lecture and searching some of the web site for getting the detail, I have some of own ideas.

The steps of test first development (TFD) are overviewed in the UML activity diagram. 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). 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 is that your pair helps you to stay on track.

The steps:
Write a test that specifies a tiny bit of functionality
Ensure the test fails
Write only the code necessary to make the test pass
Refactor the code, ensuring that it has the simplest design possible for the functionality built to date

The rules:
Test everything that can possibly break
Tests come first
All tests run at 100% all the time

Question 1: Software Engineering Skills: Students’ Opinions

Before I study this subject, I just think "software engineers" only want to do some process similar to programmer. But now... There are some of my point I think:

Software engineers needs:

1) analyze what users want
2) design, process, test, and maintain the applications
3) May be involved in the design and development of many types of software, (E.g. operating systems, network distribution, compilers)
4) solve the problems of the project
5) consider the further use
6 back up supporting