TM Blog

Monday, April 17, 2006

Software Design Patterns: How much do you understand?

Most i understand: Adapter Pattern, Bridge Pattern.

  • Adapter Pattern: Convert the interface of a class into another interface clients expect.
  • Bridge Pattern: It's to decouple interface from implementation; more beyond encapsulation to insulation.simply mean provide multiple implementation under the same interface.


Benefits of using design patterns?

  • Main benefits is more efficient. It is because you can use the this Pattern(Solution) a million times over, without ever doing it the same twice.
  • Another one is design patterns can solve protecting a caller from changes associated with specific platforms.

Wednesday, March 15, 2006

Why do software projects fail so often?

First of all, now give you some worrying statistic. According to the research, only about 16% of software projects are successful, 53% challenged (that is cost overruns, budget overruns or content deficiencies) and 31% cancelled. Is it very horrible?

Here is some key reasons why software projects fail:
  • Not Enough Time
  • Insufficient Budget
  • Poor Communication
  • Never Reviewing Project Progress
  • Inadequate Testing
  • Testing in the Production Environment
  • Lack of Quality Assurance
  • Not Conforming to Industry Standards
  • Stakeholder Conflicts
  • Skills that Do Not Match the Job
  • Poor Architecture
  • Late Failure Warning Signals

Failure has become the I.T. industry norm? So what can we do about it?

Here is the 3 Keys to Project Success:

  • Top management support
  • A sound methodology
  • Solid technical leadership by someone who has successfully completed a similar project

Without each of these solidly in place, the tripod will topple and the project will fail.

Other Interdependent Factors in Project Success:

  • Cost
  • Quality
  • Speed
  • Risk

Reference links:

What is test-driven development?

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.

What is the goal of test-driven development?

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.


In Test driven development simply have 5 cycle:
  1. Write the test --- It begins with writing 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.
  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.
  4. Refactor --- The final step is the refactoring step and any code clean-up necessary will occur here.
  5. Repeat --- The cycle will then repeat itself and start with either adding additional functionality or fixing any errors.

Reference links:

What makes a program code good?

Here is some key reason how to determine the program code is good or not.
  • Clarity
  • Flexibility
  • Contingency
  • Structure
  • Efficiency

Reference link:

http://www.smith.edu/its/sctsummit04/color/P%20Technical/215.pdf

Wednesday, January 11, 2006

YAGNI --- YouArentGonnaNeedIt is an ExtremeProgramming practice which states:

"Always implement things when you actually need them, never when you just foresee that you need them."

Even if you're totally, totally, totally sure that you'll need a feature later on, don't implement it now. Usually, it'll turn out either a) you don't need it after all, or b) what you actually need is quite different from what you foresaw needing earlier.

This doesn't mean you should avoid building flexibility into your code. It means you shouldn't overengineer something based on what you think you might need later on.


There are two main reasons to practise YAGNI:


  • You save time, because you avoid writing code that you turn out not to need.
  • Your code is better, because you avoid polluting it with 'guesses' that turn out to be more or less wrong but stick around anyway.

YAGNI 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.

Reference Links:

---------------------------------------------------------------
JsUnit --- JsUnit is a Unit Testing framework for client-side (in-browser) JavaScript. It is essentially a port of JUnit to JavaScript. Also included is a platform for automating the execution of tests on multiple browsers and mutiple machines running different OSs. Its development began in January 2001.

The Usage of JsUnit is described in the follwing sections:


Additional Source:

Reference Links:

Compare the CSDP and MT356

Compare the CSDP(Certified Software Development Professional) body of knowledge with our current Software Engineering course(MT356). I have find that following knowledges areas are not included in our textbook.
  • Business Practices
  • Professional Practices
  • Engineering Economics
  • Software Maintenance
  • Software Quality Methods

Sunday, October 30, 2005

My Favorite UML Tool:
In our view, Poseidon for UML Community Edition is the better one(compare with two others).
There are several reasons to support our idea
.

1) In the class, Steven Sir already give me the
Poseidon for UML Community Edition. We does not waste any time to download.
2) Software Size --
Poseidon for UML Community Edition only 30mb, much less than other two softwares.
3) Operation -- Not most of people have newest PC. I still using Celeron(School PC lab also like that) but i can running this software very stable.
4) installation -- My slow pc just spend a short moment to install this software.
5) User-Friendly -- I just spend 30 mins to learn how to control.

In the past, i have used "Visio" to draw UML diagrams. It is very user-friendly software.