Software design patterns

In such many kinds of design patterns, the really let me understand is adapter design pattern.

The Adapter design pattern converts the interface of a component into an interface that the client expects. This interface is called ClientInterface. An Adapter class provides the glue between ClientInterface and LegacyClass.

The other design pattern i still need to get understand through more revision.

Why do software projects fail so often?

Why do software projects fail so often?
I have find a relative article talking about this question:

One of the most pervasive myths in the software industry is that the failure of software projects is due to the technical nature of these projects.
Projects fail or go awry because some basic issues aren't taken care of. And if you'd like to know what these issues are, then here are the Top Ten of them, with the first four certainly being the biggest offenders, and the top one the biggest project killer of all-

(1) The goal of the project isn't defined properly

(2) The Goal of the project is defined properly but then changes to it aren't controlled.

(3) The project is planned properly but then it isn't resourced as was planned

(4) The project is planned such that it has no contingency

(5) The project isn't planned properly

(6) The project isn't led properly

(7) The expectations of project participants aren't managed.

(8) The project is planned properly but then progress against the plan is not monitored and controlled properly

(9) Project reporting is inadequate or non-existent

(10) When projects get in to trouble, people believe the problem can be solved by some simple action e.g. work harder, extend the deadline, add more resources

reference: http://www.etpint.com/whyfail.htm

The importance of software project management
project planning and a good work breakdown structure is very importance.

Building a Plan:
~Brainstorm all required and poossible activities.
~Group items logically
~Order by time sequence
~Identify milestones and checkpoints where you will monitor the wrok

Be S-M-A-R-T about goals:
~Specific: The more precise the target, the greater the chance to hit it
~Measurable: If it's not measureable, it's out of control
~Agreed to: Stakeholder concurrence. If they don't agree now...
~Reachable: If you determine it can't be done...
~Timely: Well-defined milestones

Work Breakdown Strueture:
~Delineation of all significant work
~Task decomposition and assignment of responsibilities
~Framework for scheduling, budgeting, and tracking

What is test-driven development?

What is TDD?
Test-Driven Development (TDD) is a computer programming technique that involves writing test cases first and then implementing the code necessary to pass the tests. The goal of test-driven development is to achieve rapid feedback and implements the "illustrate the main line" approach to constructing a program. This technique is heavily emphasized in Extreme Programming.
Practitioners emphasize that test-driven development is primarily a method of designing software, not just a method of testing. The method is also used for removal of software defects.

I like to describe TDD with this 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.
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.

Test-Driven Development Cycle
1. Write the test
It begins with writing a test. In order to write a test, the developer must understand the specification and the requirements clearly. This is accomplished through use cases and user stories. The design document covers all the test scenarios and exception conditions.
2. Write the code
The next step is to make the test pass by writing the code. This step forces the programmer to take the perspective of a client by seeing the code through its interfaces. This is the design driven part of test-driven development. As part of test calibration, your code should fail the test meaningfully the first time around.
3. Run the automated tests
The next step is to run the automated test cases and observe if they pass or fail. If they pass, the programmer can be more confident that the code meets the test cases as written. If there are failures, the code did not meet the test cases..
4. Refactor
The final step is the refactoring step and any code clean-up necessary will occur here. The test cases are then re-run and observed.
5. Repeat
The cycle will then repeat itself and start with either adding additional functionality or fixing any errors.


Reference website:
http://en.wikipedia.org/wiki/Test_driven_development#Requirements
http://www.agiledata.org/essays/tdd.html#PartingThoughts

Software Quality: What makes a program code good?

As I am the boss to select, I think i will consider about:

Good readability
Easy understandable
Easy maintain
Good framwork

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

To compare the CSDP program with our textbook, the areas that are not include in our textbook are in below:
(highlight with red color is cover in textbook)

These are the topic which are not cover in textbook:
I. Business Practices and Engineering Economics
IV. Software Construction
VI. Software Maintenance
IX. Software Engineering Process
XI. Software Quality


This is the topic which cover in textbook:
VII. Software Configuration Management


These are part of the areas that are not cover in our text book:
II. Software Requirements
A. Requirements Engineering Process
B. Requirements Elicitation
C. Requirements Analysis
D. Software Requirements Specification
E. Requirements Validation
F. Requirements Management

V. Software Testing
A. Types of Tests
B. Test Levels
C. Testing Strategies
D. Test Design
E. Test Coverage of Code
F. Test Coverage of Specifications
G. Test Execution
H. Test Documentation
I. Test Management

VIII. Software Engineering Management
A. Measurement
B. Organizational Management and Coordination
C. Initiation and Scope Definition
D. Planning
E. Software Acquisition
F. Enactment
G. Risk Management
H. Review and Evaluation
I. Project Close Out
J. Post-closure Activities

X. Software Engineering Tools and Methods
A. Management Tools and Methods
B. Development Tools and Methods
C. Maintenance Tools and Methods
D. Support Tools and Methods


This is the topic i have not classify it:
III. Software Design
Reason: We have cover on system design in our textbook, but i am not so clear and sure about, are system design and software design are two kinds of things?

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.

Reference websites:

http://en.wikipedia.org/wiki/YAGNI

http://c2.com/cgi/wiki?YouArentGonnaNeedIt

"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 doesn't scale nicely like JUnit, it's difficult to envision suites of tests under this framework.

Reference Websites:

http://xpdeveloper.org/cgi-bin/oldwiki.cgi?JsUnit

http://c2.com/cgi/wiki?JsUnit

http://www.jsunit.net

http://jsunit.berlios.de/

UML Tools

I have try the uml tools, and i am most favourite on Poseidon for UML, maybe it is the first try of the others, the firs timage is good than the others, and i find the other tools is more difficult to installs.WHen I using Poseidon for UML, although it is the first time to use it, i can find the function button easily, the interface is user friendly. I feel that it’s as like as using the “paint” of the window.But some selection items at the bottom still need time to try to use it.
In before, I have use another program call “Dia” to draw the uml diagram, it is easy to use also. But to compare with Poseidon for UML, I think Poseidon for UML is more professional and easy to control.
Type in “Dia” in search engine, you can see many related website, here is one of the reference website of “Dia”,http://www.gnome.org/projects/dia/
Have u ever heard this program? ^^

About the basic software engineering skill

Software engineering is the profession that creates and maintains software applications by applying technologies and practices from computer science, project management, engineering, application domains and other fields.

Software is the set of directions that enables computer hardware to perform useful work. In the last decades of the twentieth century, cost reductions in computer hardware led to software becoming a ubiquitous component of the devices used by industrialized societies.

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software.