Sunday, April 09, 2006

Why Software development failure?

Here is some main reason for software development failure:

Fail in requirement elicitation.

Project failure usually started at the very beginning. The misunderstanding between SW engineer and the customers will lead to a disaster. Sometimes clients fail to tell the SW engineer what the product can do for them. This can be avoided by using prototyping. Using prototyping, the prototype can give clients a brief to their final product. Any critical errors can be avoided before project finals.

Budgets

Wrongly estimate budget will lead to project failure, over budget will even terminate the entire project. Therefore, carefully estimate the budget is essential.

Time management

Software development is different with building a bridge. It is difficult to estimate how long the development time takes. A late of a single component will make the project late.

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

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.

Saturday, April 08, 2006

Q6. How email works

1. There are totally six steps of sending a email.
2. The email format

The email format is design by David Crocker.

The format of Internet e-mail messages is defined in RFC 2822 and a series of RFCs, RFC 2045 through RFC 2049, collectively called Multipurpose Internet Mail Extensions (MIME). Although as of July 13, 2005 (see [4]) RFC 2822 is technically a proposed IETF standard and the MIME RFCs are draft IETF standards, these documents are the de facto standards for the format of Internet e-mail. Prior to the introduction of RFC 2822 in 2001 the format described by RFC 822 was the de facto standard for Internet e-mail for nearly two decades; it is still the official IETF standard. The IETF reserved the numbers 2821 and 2822 for the updated versions of RFC 821 (SMTP) and RFC 822, honoring the extreme importance of these two RFCs. RFC 822 was published in 1982 and based on the earlier RFC 733.

Internet e-mail messages consist of two major sections:

* Header - Structured into fields such as summary, sender, receiver, and other information about the e-mail
* Body - The message itself as unstructured text; sometimes containing a signature block at the end

The header is separated from the body by a blank line.
Email Header

The message header consists of fields. Each header field has a name and a value. RFC 2822 specifies the precise syntax. Informally, the field name starts in the first character of a line, followed by a ":", followed by the value which is continued on non-null subsequent lines that have a space or tab as their first character. Field names and values are restricted to 7-bit ASCII characters. Non-ASCII values may be represented using MIME encoded words. Messages usually have at least four fields in the header:

1. From: The e-mail address, and optionally name, of the sender of the message
2. To: The e-mail addresses, and optionally names, of the receiver of the message
3. Subject: A brief summary of the contents of the message
4. Date: The local time and date when the message was originally sent

Note however that the "To" field in the header is not necessarily related to the addresses to which the e-mail is delivered. The actual delivery list is supplied in the SMTP protocol, not extracted from the header content. The "To" field is similar to the greeting at the top of a conventional letter which is delivered according to the address on the outer envelope. Also note that the "From" field does not have to be the real sender of the e-mail. It is very easy to fake the "From" field and let an e-mail seem to be from any mail address. It is possible to digitally sign an e-mail, which is much harder to fake. Some Internet service providers do not relay e-mails claiming to come from a domain not hosted by them, but very few (if any) check to make sure that the person or even e-mail address named in the "From" field is the one associated with the connection.

Other common header fields include:

1. Cc: Carbon copy (because typewriters use carbon paper to make copies of letters)
2. Received: Tracking information generated by mail servers that have previously handled a message
3. Content-Type: Information about how the message has to be displayed, usually a MIME type

Many e-mail clients present "Bcc" (Blind carbon copy, recipients not visible in the "To" field) as a header field. Since the entire header is visible to all recipients, "Bcc" is not included in the message header. Addresses added as "Bcc" are only added to the SMTP delivery list, and do not get included in the message data.

3.
Simple Mail Transfer Protocol(SMTP)

SMTP is a relatively simple, text-based protocol, where one or more recipients of a message are specified (and in most cases verified to exist) and then the message text is transferred. It is quite easy to test a SMTP server using the telnet program (see below).

SMTP uses TCP port 25. To determine the SMTP server for a given domain name, the MX (Mail eXchange) DNS record is used.

SMTP started becoming widely used in the early 1980s. At the time, it was a complement to UUCP which was better suited to handle e-mail transfers between machines that were intermittently connected. SMTP, on the other hand, works best when both the sending and receiving machines are connected to the network all the time.

The article about sender rewriting contains technical background info about the early SMTP history and source routing before RFC 1123 (1989, obsoleted by RFC 2821 ).

Sendmail was one of the first (if not the first) mail transfer agents to implement SMTP. As of 2001 there are at least 50 programs that implement SMTP as a client (sender of messages) or a server (receiver of messages). Some other popular SMTP server programs include exim, Postfix, qmail, and Microsoft Exchange Server.

Since this protocol started out as purely ASCII text-based, it did not deal well with binary files. Standards such as MIME were developed to encode binary files for transfer through SMTP. Today, most SMTP servers support the 8BITMIME extension, permitting binary files to be transmitted almost as easily as plain text.

SMTP is a "push" protocol that does not allow one to "pull" messages from a remote server on demand. To do this a mail client must use POP3 or IMAP. Another SMTP server can trigger a delivery in SMTP using ETRN.



Multipurpose Internet Mail Extensions(MIME)

The basic Internet e-mail transmission protocol, SMTP, supports only 7-bit ASCII characters (see also 8BITMIME). This effectively limits Internet e-mail to messages which, when transmitted, include only the characters sufficient for writing a small number of languages, primarily English. Other languages based on the Latin alphabet typically include diacritics not supported in 7-bit ASCII, meaning text in these languages cannot be correctly represented in basic e-mail.

MIME defines mechanisms for sending other kinds of information in e-mail, including text in languages other than English using character encodings other than ASCII as well as 8-bit binary content such as files containing images, sounds, movies, and computer programs. MIME is also a fundamental component of communication protocols such as HTTP, which requires that data be transmitted in the context of e-mail-like messages, even though the data may not actually be e-mail.

Mapping messages into and out of MIME format is typically done automatically by an e-mail client or by mail servers when sending or receiving Internet (SMTP/MIME) e-mail.

The basic format of Internet e-mail is defined in RFC 2822, which is an updated version of RFC 822. These standards specify the familiar formats for text e-mail headers and body and rules pertaining to commonly used header fields such as "To:", "Subject:", "From:", and "Date:". MIME defines a collection of e-mail headers for specifying additional attributes of a message including content type, and defines a set of transfer encodings which can be used to represent 8-bit binary data using characters from the 7-bit ASCII character set. MIME also specifies rules for encoding non-ASCII characters in e-mail message headers, such as "Subject:", allowing these header fields to contain non-English characters.

MIME is extensible. Its definition includes a method to register new content types and other MIME attribute values.

One of the explicit goals of the MIME definition was to not require changes to pre-existing e-mail servers, and to allow plain text e-mail to function in both directions with pre-existing clients. This goal is achieved by allowing all MIME message attributes to be optional, with default values making a non-MIME message likely to be interpreted correctly by a MIME-capable client. In addition, a simple MIME text message is likely to be interpreted correctly by a non-MIME client although it has e-mail headers the non-MIME client won't know how to interpret. Similarly, if the quoted printable transfer encoding (see below) is used, the ascii parts of the message will be intelligible to users with non-mime clients.


Whatis MUA & MTA?

mail user agent [MUA]) is a computer program that is used to read and send e-mail.

Originally, the MUA was intended to be just a little program to read the messages, which the MDA in conjunction with the MTA would transfer into a local mailbox.

The most important mailbox formats are mbox and Maildir. These rather simple protocols for locally storing e-mails make import, export and backup of mailfolders quite easy.

E-mails to be sent would be handed over to the MTA (perhaps via an MSA), therefore an MUA would not have to provide any transport-related functions.

Since the various Windows versions intended for home use never provided an MTA, most modern MUAs have to support protocols like POP3 and IMAP to comunicate with a remote MTA located at the e-mail providers machine.

IMAP and the updated IMAP4 are optimized for storage of e-mail on the server, while the POP3 protocol generally assumes that the e-mail is downloaded to the client. The SMTP protocol is used by most e-mail clients to send e-mail.

In addition to the fat client e-mail clients (or small MUAs in cooperation with a local MDA/MTA) presented here, there are also Web-based e-mail programs ("webmail").

An important standard supported by most e-mail clients is MIME, which is used to send binary attachments. Attachments are files that are not part of the e-mail proper, but are sent with the e-mail.

MAPI (Messaging Application Programming Interface) is a proprietary Microsoft Windows API which can be used to access the Microsoft Exchange e-mail server or to interact with the Microsoft Outlook client.

Javamail, part of the platform-independent Java API, can be used to develop e-mail clients or servers using any of the standard e-mail protocols.

MTA

A mail transfer agent or MTA (also called a mail transport agent, mail server, or a mail exchange server in the context of the Domain Name System) is a computer program or software agent that transfers electronic mail messages from one computer to another.

It receives messages from another MTA (relaying), a mail submission agent (MSA) that itself got the mail from a mail user agent (MUA), or directly from an MUA, thus acting as an MSA itself. The MTA works behind the scenes, while the user usually interacts with the MUA.

The delivery of e-mail to a user's mailbox typically takes place via a mail delivery agent (MDA); many MTAs have basic MDA functionality built in, but a dedicated MDA like procmail can provide more sophistication.

Q.7 Design Patterns

Patterns understand:
-Facade
Using simplified interface to a larger body of code, such as a class library. Java is a example of using facade, the Java Standard library contains dozens of classes for parsing font files and rederint text into geometric outlines and ultimately into pixel.

- Proxy
The proxy pattern usually have a main core object that is complex or in a remote place. A proxy is used to transfer the job to that main object. As the word "proxy" says, it is just a "middleman" of the program. Moreover, usually many proxies are occurs, that means the main object can serve multiple clients through different proxies.

-Observer
The pattern use two class Observer and Listener to handle events.

Don't understand:
-Prototype
-Adapter



Design patterns are templates and examples of sepecific solutions for specific problems. However, it is not the final solution of the problem, it just provide a direction for solving the problem. Using design patterns can speed up the development process. Also, Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.

Wednesday, March 29, 2006

Q5. Software quality: What makes a program code good?

I'll consider in these aspects:

1. Length of code(LOC)
It is a rather technical issue. In some ogranisation, it calculate the LOC as a figure to evaluate a program is good or not. For example, both two program have same functions, a program that have use lesser code can show that the pogrammer wrote it in a cleverer way, in some means.

2. Structure
A program that is well structurize will make it possible for reuse, understand and analysis. A program can do the job but only the author can understand is not a good program.

Friday, March 17, 2006

Q4. Stuff that lets agile software developers show off what they believe in

YAGNI stands for:

You Arent Gonna Need It

"Always implement things when you actually need them, never when you just foreseethat 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.


DTSTTCPW stands for:

Do the simplest thing that could possibly work.


It is one of the slogan of XP(Extreme Programming)'s 12 best practices. This is something an XP coach will say when he sees an XP developer doing something that is needlessly complicated. In general, XP says don't overdesign your system.

Link: http://xp.c2.com/YouArentGonnaNeedIt.html
http://www.aka.org.cn/Docs/latest/Extreme%20Programming%20FAQ_Chinese.html

Q3 Comparation between CSDP & our course

Here are the difference between our course and CSDP thats do not coverage in our course of SW Engineering:

-Buiness Practice
-Professional Practices
-Engineering Economics
-Software Maintenance
-Software Quality Methods

Q2. UML tools, What is your favorite?

Comparation of Eclipse, Viusal Paradigm & Poseidon.

I’ve try out three UML programs. And I thought that the “Omondo EclipseUML Free Edition” is the most useful tool for me. I will compare those programs on these aspects:
-User friendliness-Number of functions-Installation.
User friendliness
I think both Poseidon and Visual Paradigm are quite user friendly because there interface is easy to understand. In Poseidon, you can understand what parameters the program ask you to enter graphically. Unlike Eclipse, once you click on an UML element icons, it just pop up a window and ask you to enter all of the parameters before you can see the icon shown on the panel. It is quite confusing for the user who are not familiar with all the parameters of Java. In this issue, Poseidon can just drag the icon out and build up the relationship first and can enter those parameters later.
Number of functions
Basically, the Poseidon and Visual Paradigm are focus on drawing UML diagrams. Compare with Eclipse, it is a program that consolidate with the IDE. That means you can write your code at the Eclipse, too. Therefore, the UML functions is quite little in Eclipse.
InstallationWith no doubt, the installation of Poseidon is the easiest one. You can select nothing except selecting which folder you want to in install in. Visual Paradigm also pack its program as a windows installer. However with the copyrights, the installer requires user to make a number of decisions. Which license user want to use, e.g. In Eclipse, the UML function is install as a plugin. Therefore after you have install the main program, you have to install the Omondo EclipseUML Free Edition in command prompt. But I think it is not a problem compare with installing Visual Paradigm.
Conclusion
As seen from above, my final decision is Eclipse. The decision is base on some factors affecting I haven’t mention above. Poseidon is too simple for me, I did not find another functions else than drawing UML diagrams.(At least I haven’t find it out yet.) Also, the alignment function of Poseidon is quite poor and the help function is inadequate. For Visual Paradigm, though the functions and UI is quite good. However, it has a vital weakness; the response time. When I run the program, lagging always occurs when I just drag an icon. It is a useless program for user even though how many functions it contains. For Eclipse, I think it is a rather professional tools, and the UI is not easy to under, compare with other two programs. However I still choose it because the UI is similar with NetBeans.

Q1. Basic Skills for a Software Engineer

I have search both on the web and in job recruitment ads, and I’ve found these skills are mostly require to be a software engineer:

- SW development expreience

This is the basic skill to be a SW engineer. In order to implement the project, you should have been in a part of the project.Then you know the routine, what problem will face during the project,etc.

- Solid software language(s) knowledge

I can’t imagine a SW engineer that without this knowledge.It just like a captain that don’t know how to operate a ship.

- Initiative

Being a SW engineer should be shelf motivate, as the sofatware development is a tough work. You should like your job.

- Problem solving skill

The present of a SW engineer is to help the clients solving problems.

- Communication skill

I think this is the key to define whether a SW engineer is good or not. As SW development is a highly Client oriented work. What the client want(so called requiement engineering) is define what will the software like.Therfore good communication skills can greatly eumlimlates fatl error cause by missunderstanding.

- Language skills(one or more)

As the trend of globalization, our clients will be come from all over the world, equipping foreign language skills(at least English skill) is important.

- Team working spirit

As SW development is not a solo work, SW engineer relies on its team during development.So working as a team is vital.

Wednesday, September 21, 2005

Hello, everyone!

Here is my new blog