IT WORLD NET

Basic Hardware Components

2009-01-22T00:03:00.000+08:00

Network card
A network card, network adapter or NIC (network interface card) is a piece of computer hardware designed to allow computers to communicate over a computer network. It provides physical access to a networking medium and often provides a low-level addressing system through the use of MAC addresses. It allows users to connect to each other either by using cables or wirelessly.The NIC provides the transfer of data in megabytes.

Repeater
A repeater is an electronic device that receives a signal and retransmits it at a higher power level, or to the other side of an obstruction, so that the signal can cover longer distances without degradation. In most twisted pair ethernet configurations, repeaters are required for cable runs longer than 100 meters away from the computer.

Network hub
A hub contains multiple ports. When a packet arrives at one port, it is copied to all the ports of the hub for transmission. When the packets are copied, the destination address in the frame does not change to a broadcast address. It does this in a rudimentary way: It simply copies the data to all of the Nodes connected to the hub.[2]

Network bridge
A network bridge connects multiple network segments at the data link layer (layer 2) of the OSI model. Bridges do not promiscuously copy traffic to all ports, as hubs do, but learn which MAC addresses are reachable through specific ports. Once the bridge associates a port and an address, it will send traffic for that address only to that port. Bridges do send broadcasts to all ports except the one on which the broadcast was received.

Bridges learn the association of ports and addresses by examining the source address of frames that it sees on various ports. Once a frame arrives through a port, its source address is stored and the bridge assumes that MAC address is associated with that port. The first time that a previously unknown destination address is seen, the bridge will forward the frame to all ports other than the one on which the frame arrived.

Bridges come in three basic types:
1. Local bridges: Directly connect local area networks (LANs)
2. Remote bridges: Can be used to create a wide area network (WAN) link between LANs. Remote bridges, where the connecting link is slower than the end networks, largely have been replaced by routers.
3. Wireless bridges: Can be used to join LANs or connect remote stations to LANs.

Network switch
A switch is a device that performs switching. Specifically, it forwards and filters OSI layer 2 datagrams (chunk of data communication) between ports (connected cables) based on the MAC addresses in the packets.[3] This is distinct from a hub in that it only forwards the datagrams to the ports involved in the communications rather than all ports connected. Strictly speaking, a switch is not capable of routing traffic based on IP address (layer 3) which is necessary for communicating between network segments or within a large or complex LAN. Some switches are capable of routing based on IP addresses but are still called switches as a marketing term. A switch normally has numerous ports, with the intention being that most or all of the network is connected directly to the switch, or another switch that is in turn connected to a switch.[4]

Switch is a marketing term that encompasses routers and bridges, as well as devices that may distribute traffic on load or by application content (e.g., a Web URL identifier). Switches may operate at one or more OSI model layers, including physical, data link, network, or transport (i.e., end-to-end). A device that operates simultaneously at more than one of these layers is called a multilayer switch.

Overemphasizing the ill-defined term "switch" often leads to confusion when first trying to understand networking. Many experienced network designers and operators recommend starting with the logic of devices dealing with only one protocol level, not all of which are covered by OSI. Multilayer device selection is an advanced topic that may lead to selecting particular implementations, but multilayer switching is simply not a real-world design concept.

Router
Routers are networking devices that forward data packets between networks using headers and forwarding tables to determine the best path to forward the packets. Routers work at the network layer of the TCP/IP model or layer 3 of the OSI model. Routers also provide interconnectivity between like and unlike media (RFC 1812). This is accomplished by examining the Header of a data packet, and making a decision on the next hop to which it should be sent (RFC 1812) They use preconfigured static routes, status of their hardware interfaces, and routing protocols to select the best route between any two subnets. A router is connected to at least two networks, commonly two LANs or WANs or a LAN and its ISP's network. Some DSL and cable modems, for home (and even office) use, have been integrated with routers to allow multiple home/office computers to access the Internet through the same connection. Many of these new devices also consist of wireless access points (waps) or wireless routers to allow for IEEE 802.11g/b/n wireless enabled devices to connect to the network without the need for cabled connections.

Internetwork

2009-01-18T12:05:00.000+08:00

Internetwork
A Internetworking involves connecting two or more distinct computer networks or network segments via a common routing technology. The result is called an internetwork (often shortened to internet). Two or more networks or network segments connected using devices that operate at layer 3 (the 'network' layer) of the OSI Basic Reference Model, such as a router. Any interconnection among or between public, private, commercial, industrial, or governmental networks may also be defined as an internetwork.

In modern practice, the interconnected networks use the Internet Protocol. There are at least three variants of internetwork, depending on who administers and who participates in them:
* Intranet
* Extranet
* Internet

Intranets and extranets may or may not have connections to the Internet. If connected to the Internet, the intranet or extranet is normally protected from being accessed from the Internet without proper authorization. The Internet is not considered to be a part of the intranet or extranet, although it may serve as a portal for access to portions of an extranet.

Intranet
An intranet is a set of networks, using the Internet Protocol and IP-based tools such as web browsers and file transfer applications, that is under the control of a single administrative entity. That administrative entity closes the intranet to all but specific, authorized users. Most commonly, an intranet is the internal network of an organization. A large intranet will typically have at least one web server to provide users with organizational information.

Extranet
An extranet is a network or internetwork that is limited in scope to a single organization or entity but which also has limited connections to the networks of one or more other usually, but not necessarily, trusted organizations or entities (e.g. a company's customers may be given access to some part of its intranet creating in this way an extranet, while at the same time the customers may not be considered 'trusted' from a security standpoint). Technically, an extranet may also be categorized as a CAN, MAN, WAN, or other type of network, although, by definition, an extranet cannot consist of a single LAN; it must have at least one connection with an external network.

Internet
The Internet is a specific internetwork. It consists of a worldwide interconnection of governmental, academic, public, and private networks based upon the networking technologies of the Internet Protocol Suite. It is the successor of the Advanced Research Projects Agency Network (ARPANET) developed by DARPA of the U.S. Department of Defense. The Internet is also the communications backbone underlying the World Wide Web (WWW). The 'Internet' is most commonly spelled with a capital 'I' as a proper noun, for historical reasons and to distinguish it from other generic internetworks.

Participants in the Internet use a diverse array of methods of several hundred documented, and often standardized, protocols compatible with the Internet Protocol Suite and an addressing system (IP Addresses) administered by the Internet Assigned Numbers Authority and address registries. Service providers and large enterprises exchange information about the reachability of their address spaces through the Border Gateway Protocol (BGP), forming a redundant worldwide mesh of transmission paths

Application Layer 's Function

2009-01-16T00:03:00.000+08:00

In the Open Systems Interconnection (OSI) communications model, the application layer provides services for an application program to ensure that effective communication with another application program in a network is possible. The application layer is not the application itself that is doing the communication. It is a service layer that provides these services:

* Makes sure that the other party is identified and can be reached
* If appropriate, authenticates either the message sender or receiver or both
* Makes sure that necessary communication resources exist
* Ensures agreement at both ends about error recovery procedures, data integrity, and privacy
* Determines protocol and data syntax rules at the application level

It may be convenient to think of the application layer as the high-level set-up services for the application program or an interactive user.

The Network Layer

2009-01-14T00:21:00.000+08:00

In essence, the Network Layer is responsible for end-to-end (source to destination) packet delivery including any routing through intermediate hosts, whereas the link layer is responsible for node-to-node (hop-to-hop) frame delivery on the same link.

The Network Layer provides the functional and procedural means of transferring variable length data sequences from a source to a destination via one or more networks while maintaining the quality of service, and error control functions.

The Network Layer deals with transmitting information all the way from its source to its destination - transmitting from anywhere, to anywhere. Here are some things that the Network Layer needs to address:

Is the network connection-oriented or connectionless?
For example, snail mail is connectionless, in that a letter can travel from a sender to a recipient without the recipient having to do anything. On the other hand, the telephone system is connection-oriented, because the other party is required to pick up the phone before communication can be established. The OSI Network Layer protocol can be either connection-oriented, or connectionless. The IP Internet Layer (equivalent to OSI's Network Layer) supports only the connectionless Internet Protocol (IP); however, connection-oriented protocols, such as TCP, exist higher in the stack by enforcing reliability constraints through timeouts and resending packets.

What are the Global Addresses?
Everybody in the network needs to have a unique address which determines who he is. This address will normally be hierarchical, so you can be "Fred Murphy" to Dubliners, or "Fred Murphy, Dublin" to people in Ireland, or "Fred Murphy, Dublin, Ireland" to people anywhere in the world. On the internet, these addresses are known as IP Addresses.

How do you forward a message?
This is of particular interest to mobile applications, where a user may rapidly move from place to place, and it must be arranged that his messages follow him. Version 4 of the Internet Protocol (IPv4) doesn't really allow for this, though it has been hacked somewhat since its inception. Fortunately, the forthcoming IPv6 has a much better designed solution, which should make this type of application much smoother.

The Presentation Layer

2009-01-12T00:19:00.000+08:00

The Presentation Layer is responsible for the delivery and formatting of information to the application layer for further processing or display. It relieves the application layer of concern regarding syntactical differences in data representation within the end-user systems. Note: An example of a presentation service would be the conversion of an EBCDIC-coded text file to an ASCII-coded file.

The Presentation Layer is the first one where people start to care about what they are sending at a more advanced level than just a bunch of ones and zeros. This layer deals with issues like how strings are represented - whether they use the Pascal method (an integer length field followed by the specified amount of bytes) or the C/C++ method (null-terminated strings, i.e. "thisisastring\0"). The idea is that the application layer should be able to point at the data to be moved, and the Presentation Layer will deal with the rest.

Encryption is typically done at this level too, although it can be done at the Application, Session, Transport, or Network Layer; each having its own advantages and disadvantages. Another example is representing structure, which is normally standardized at this level, often by using XML. As well as simple pieces of data, like strings, more complicated things are standardized in this layer. Two common examples are 'objects' in object-oriented programming, and the exact way that streaming video is transmitted.

In many widely used applications and protocols, no distinction is made between the presentation and application layers. For example, HTTP, generally regarded as an application layer protocol, has Presentation Layer aspects such as the ability to identify character encoding for proper conversion, which is then done in t

The Data Link Layer

2009-01-10T00:15:00.000+08:00

The Data Link Layer is the protocol layer which transfers data between adjacent network nodes in a wide area network or between nodes on the same local area network segment. The Data Link Layer provides the functional and procedural means to transfer data between network entities and might provide the means to detect and possibly correct errors that may occur in the Physical Layer. Examples of data link protocols are Ethernet for local area networks (multi-node) and PPP, HDLC and ADCCP for point-to-point (dual-node) connections.

The data link is all about getting information from one place to a selection of other close, local places. At this layer one does not need to be able to go everywhere globally, just able to go somewhere else locally. In the OSI model protocol stack the Network Layer, which is on top of the Data Link Layer, is analogous to the postal office making a best effort to delivering international mail. If a parcel is to be delivered from London to New York it can be sent via a variety of means: it can travel across the Atlantic by air or by sea, for which the exact route itself can also vary. The postal office (the Network Layer) only needs to try to get the parcel from the source to the correct destination regardless of the exact path it takes. The Data Link Layer in this analogy will be more akin to the role of a truck driver: the driver needs to know the local route to get from the post office to the airport/port. In fact, the driver would not need to know that the parcel he/she is delivering is ultimately bound for New York.

The Data Link Layer also serves the function of media access control. An example would be in an apartment building there is an WLAN access point (AP) in each of two neighboring apartments. A client can request access to one of the APs (say, AP A) by sending radio-frequency signals from his/her laptop. Since the two APs are in close proximity they may both be able to receive the request signals sent out by the client. It is the job of the Data Link Layer protocol to let AP B know that when it receives the client's signals they are not intended for it but for another AP. For AP A the decision as to whether the client is permitted access can also occur on the Data Link Layer.

The data link thus provides data transfer across the physical link. That transfer might or might not be reliable; many data link protocols do not have acknowledgments of successful frame reception and acceptance, and some data link protocols might not even have any form of checksum to check for transmission errors. In those cases, higher-level protocols must provide flow control, error checking, and acknowledgments and retransmission.

In some networks, such as IEEE 802 local area networks, the Data Link Layer is described in more detail with Media Access Control (MAC) and Logical Link Control (LLC) sublayers; this means that the IEEE 802.2 LLC protocol can be used with all of the IEEE 802 MAC layers, such as Ethernet, token ring, IEEE 802.11, etc., as well as with some non-802 MAC layers such as FDDI. Other Data Link Layer protocols, such as HDLC, are specified to include both sublayers, although some other protocols, such as Cisco HDLC, use HDLC's low-level framing as a MAC layer in combination with a different LLC layer.

The Session Layer

2009-01-08T00:20:00.000+08:00

The Session Layer is level five of the seven level OSI model. It responds to service requests from the Presentation Layer and issues service requests to the Transport Layer.

The Session Layer provides the mechanism for opening, closing and managing a session between end-user application processes, i.e. a semi-permanent dialogue. Communication sessions consist of requests and responses that occur between applications. Session Layers are commonly used in application environments that make use of remote procedure calls (RPCs).

An example of a Session Layer protocol is the OSI protocol suite Session Layer Protocol, also known as X.225 or ISO 8327. In case of a connection loss this protocol may try to recover the connection. If a connection is not used for a long period, the Session Layer protocol may close it and re-open it. It provides for either full duplex or half-duplex operation and provides synchronization points in the stream of exchanged messages.[1]

Other examples of session-layer implementations include Zone Information Protocol (ZIP) – the AppleTalk protocol that coordinates the name binding process; and Session Control Protocol (SCP) – the DECnet Phase IV Session Layer protocol.
In brief: the Session Layer establishes, manages and terminates connections (sessions) among cooperating applications. It also adds traffic flow information

Application Layer

2009-01-08T00:14:00.000+08:00

The application layer is the OSI layer closest to the end user, which means that both the OSI application layer and the user interact directly with the software application. This layer interacts with software applications that implement a communicating component. Such application programs fall outside the scope of the OSI model. Application layer functions typically include identifying communication partners, determining resource availability, and synchronizing communication. When identifying communication partners, the application layer determines the identity and availability of communication partners for an application with data to transmit. When determining resource availability, the application layer must decide whether sufficient network resources for the requested communication exist. In synchronizing communication, all communication between applications requires cooperation that is managed by the application layer. Some examples of application layer implementations include Telnet, File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP).

Physical Layer

2009-01-06T04:00:00.000+08:00

The Presentation Layer is the sixth level of the seven layer OSI model. It responds to service requests from the Application Layer and issues service requests to the Session Layer.

The Presentation Layer is responsible for the delivery and formatting of information to the application layer for further processing or display. It relieves the application layer of concern regarding syntactical differences in data representation within the end-user systems. Note: An example of a presentation service would be the conversion of an EBCDIC-coded text file to an ASCII-coded file.

The Presentation Layer is the first one where people start to care about what they are sending at a more advanced level than just a bunch of ones and zeros. This layer deals with issues like how strings are represented - whether they use the Pascal method (an integer length field followed by the specified amount of bytes) or the C/C++ method (null-terminated strings, i.e. "thisisastring\0"). The idea is that the application layer should be able to point at the data to be moved, and the Presentation Layer will deal with the rest.

Encryption is typically done at this level too, although it can be done at the Application, Session, Transport, or Network Layer; each having its own advantages and disadvantages. Another example is representing structure, which is normally standardized at this level, often by using XML. As well as simple pieces of data, like strings, more complicated things are standardized in this layer. Two common examples are 'objects' in object-oriented programming, and the exact way that streaming video is transmitted.

In many widely used applications and protocols, no distinction is made between the presentation and application layers. For example, HTTP, generally regarded as an application layer protocol, has Presentation Layer aspects such as the ability to identify character encoding for proper conversion, which is then done in the Application Layer.

OSI Layer's FUNCTION

2009-01-04T07:09:00.002+08:00

Transport Layer Function

* Ports: (Part of the Transport Layer in the TCP/IP model, but of the Session Layer in the OSI model) Ports are essentially ways to address multiple entities in the same location. For example, the first line of a postal address is a kind of port, and distinguishes between different occupants of the same house. Computer applications will each listen for information on their own ports, which is why you can use more than one network-based application at the same time.

* Same Order Delivery: The Network layer doesn't generally guarantee that packets of data will arrive in the same order that they were sent, but often this is a desirable feature, so the Transport Layer provides it. The simplest way of doing this is to give each packet a number, and allow the receiver to reorder the packets.

* Reliable data: Packets may be lost in routers, switches, bridges and hosts due to network congestion, when the packet queues are filled and the network nodes have to delete packets. Packets may be lost or corrupted in Ethernet due to interference and noise, since Ethernet does not retransmit corrupted packets. Packets may be delivered in the wrong order by an underlying network. Some Transport Layer protocols, for example TCP, can fix this. By means of an error detection code, for example a checksum, the transport protocol may check that the data is not corrupted, and verify that by sending an ACK message to the sender. Automatic repeat request schemes may be used to retransmit lost or corrupted data. By introducing segment numbering in the Transport Layer packet headers, the packets can be sorted in order. Of course, error free is impossible, but it is possible to substantially reduce the numbers of undetected errors.

* Connection-oriented: This is normally easier to deal with than connection-less models, so where the Network layer only provides a connection-less service, often a connection-oriented service is built on top of that in the Transport Layer.

* Flow control: The amount of memory on a computer is limited, and without flow control a larger computer might flood a computer with so much information that it can't hold it all before dealing with it. Nowadays, this is not a big issue, as memory is cheap while bandwidth is comparatively expensive, but in earlier times it was more important. Flow control allows the receiver to say "Whoa!" before it is overwhelmed. Sometimes this is already provided by the network, but where it is not, the Transport Layer may add it on.

* Congestion avoidance: Network congestion occurs when a queue buffer of a network node is full and starts to drop packets. Automatic repeat request may keep the network in a congested state. This situation can be avoided by adding congestion avoidance to the flow control, including slow-start. This keeps the bandwidth consumption at a low level in the beginning of the transmission, or after packet retransmission.

* Byte orientation: Rather than dealing with things on a packet-by-packet basis, the Transport Layer may add the ability to view communication just as a stream of bytes. This is nicer to deal with than random packet sizes, however, it rarely matches the communication model which will normally be a sequence of messages of user defined sizes.

Types of Networks

2009-01-02T12:02:00.001+08:00

LANs (Local Area Networks)
A network is any collection of independent computers that communicate with one another over a shared network medium. LANs are networks usually confined to a geographic area, such as a single building or a college campus. LANs can be small, linking as few as three computers, but often link hundreds of computers used by thousands of people. The development of standard networking protocols and media has resulted in worldwide proliferation of LANs throughout business and educational organizations.

WANs (Wide Area Networks)
Wide area networking combines multiple LANs that are geographically separate. This is accomplished by connecting the different LANs using services such as dedicated leased phone lines, dial-up phone lines (both synchronous and asynchronous), satellite links, and data packet carrier services. Wide area networking can be as simple as a modem and remote access server for employees to dial into, or it can be as complex as hundreds of branch offices globally linked using special routing protocols and filters to minimize the expense of sending data sent over vast distances.

Internet
The Internet is a system of linked networks that are worldwide in scope and facilitate data communication services such as remote login, file transfer, electronic mail, the World Wide Web and newsgroups.

With the meteoric rise in demand for connectivity, the Internet has become a communications highway for millions of users. The Internet was initially restricted to military and academic institutions, but now it is a full-fledged conduit for any and all forms of information and commerce. Internet websites now provide personal, educational, political and economic resources to every corner of the planet.

Intranet
With the advancements made in browser-based software for the Internet, many private organizations are implementing intranets. An intranet is a private network utilizing Internet-type tools, but available only within that organization. For large organizations, an intranet provides an easy access mode to corporate information for employees.

MANs (Metropolitan area Networks)
The refers to a network of computers with in a City.

VPN (Virtual Private Network)
VPN uses a technique known as tunneling to transfer data securely on the Internet to a remote access server on your workplace network. Using a VPN helps you save money by using the public Internet instead of making long–distance phone calls to connect securely with your private network. There are two ways to create a VPN connection, by dialing an Internet service provider (ISP), or connecting directly to Internet.

Network Adapter Cards

2008-12-30T00:28:00.000+08:00

Network Adapter Cards

The role of the network Adapter cards it to:
· Prepare data from the computer for the network cable
· Send the data to another computer
· Control the flow of data between the computer and the cabling system

NIC's contain hardware and firmware (software routines in ROM) programming that implements the
· Logical Link Control and
· Media Access Control
Functions of the Data Link layer of the OSI

Preparing Data
· Data moves along paths in the computer called a BUS - can be 8, 16, 32 bits wide.

· On network cable, data must travel in a single bit stream in what's called a serial transmission (b/c on bit follows the next).

· The transceiver is the component responsible for translating parallel (8, 16, 32-bit wide) into a 1 bit wide serial path.

· A unique network address or MAC address is coded into chips in the card

· card uses DMA (Direct Memory Access) where the computer assigns memory space to the NIC
if the card can't move data fast enough, the card's buffer RAM holds it temporarily during transmission or reception of data

Sending and Controlling Data
The NICs of the two computers exchanging data agree on the following:
1. Maximum size of the groups of data being sent
2. The amount of data to be sent before confirmation
3. The time intervals between send data chunks
4. The amount of time to wait before confirmation is sent
5. How much data each card can hold before it overflows
6. The speed of the data transmission

Network Card Configuration
· IRQ: a unique setting that requests service from the processor.

IRQ #---- Common Use---- I/O Address
IRQ 1 - Keyboard
IRQ 2(9)- Video Card
IRQ 3 - Com2, Com4 2F0 to 2FF
IRQ 4 - Com1, Com3 3F0 to 3FF
IRQ 5 - Available (Normally LPT2 or sound card )
IRQ 6 - Floppy Disk Controller
IRQ 7 - Parallel Port (LPT1)
IRQ 8 - Real-time clock
IRQ 9 - Redirected IRQ2 370 - 37F
IRQ 10 - Available (maybe primary SCSI controller)
IRQ 11 - Available (maybe secondary SCSI controller)
IRQ 12 - PS/2 Mouse
IRQ 13 - Math Coprocessor
IRQ 14 -Primary Hard Disk Controller
IRQ 15 - Available (maybe secondary hard disk controller)

Base I/O port: Channel between CPU and hardware
Specifies a channel through which information flows between the computer's adapter card and the CPU. Ex. 300 to 30F.

Each hardware device must have a different base I/O port

Base Memory address: Memory in RAM used for buffer area
Identifies a location in the computer's RAM to act as a buffer area to store incoming and outgoing data frames. Ex. D8000 is the base memory address for the NIC.

Each device needs its own unique address.

some cards allow you to specify the size of the buffer ( 16 or 32 k, for example)

Transceiver:
Sometimes selected as on-board or external. External usually will use the AUI/DIX connector: Thicknet, for example

Use jumpers on the card to select which to use

Data Bus Architecture
The NIC must
· match the computer's internal bus architecture and

· have the right cable connector for the cable being used
· ISA (Industry Standard Architecture): original 8-bit and later 16-bit bus of the IBM-PC.
· EISA (Extended Industry Standard Architecture): Introduced by consortium of manufacturers and offers a 32-bit data path.
· Micro-Channel Architecture (MCA): Introduced by IBM in its PS/2 line. Functions as either 16 or 32 bit.
· PCI (Peripheral Component Interconnect): 32-bit bus used by Pentium and Apple Power-PC's. Employs plug and play.

Improving Network Card Performance
Direct Memory Access (DMA):
Data is moved directly from the network adapter card's buffer to computer memory.

Shared Adapter Memory:
Network adapter card contains memory which is shared with the computer.
The computer identifies RAM on the card as if it were actually installed on the computer

Shared System Memory:
The network adapter selects a portion of the computer's memory for its use.
MOST common

Bus Mastering:
The adapter card takes temporary control of the computer's bus, freeing the CPU for other tasks.
moves data directly to the computer's system memory
Available on EISA and MCA
can improve network performance by 20% to 70%

RAM buffering:
Ram on the adapter card acts as a buffer that holds data until the CPU can process it.
this keeps the card from being a bottleneck

·On-board microprocessor:
enables the adapter card to process its own data without the need of the CPU

Wireless Adapter Cards
· Used to create an all-wireless LAN
· Add wireless stations to a cabled LAN
· uses a wireless concentrator, which acts as a transceiver to send and receive signals

Remote-Boot PROMS (Programmable Read Only Memory)
· Enables diskless workstations to boot and connect to a network.
· Used where security is important.

Putting Data on the Cable

2008-12-27T00:19:00.000+08:00

Access Methods
The 4 major methods
Carrier Sense Multiple Access Methods
1. with collision detection (CSMA/CD)
2. with collision avoidance (CSMA/CA)

Token passing that allows only a singe opportunity to send data

A Demand Priority method

Carrier Sense Multiple Access with Collision Detection. (CSMA/CD)
1. Computer senses that the cable is free.
2. Data is sent.
3. If data is on the cable, no other computer can transmit until the cable is free again.
4. If a collision occurs, the computers wait a random period of time and retransmit.
o Known as a contention method because computers compete for the opportunity to send data. (Database apps cause more traffic than other apps)
o This can be a slow method
o More computers cause the network traffic to increase and performance to degrade.
o The ability to "listen" extends to a 2,500 meter cable length => segments can't sense signals beyond that distance.

Carrier Sense Multiple Access with Collision Avoidance　 (CSMA/CA)
in CSMA/CA, the computer actually broadcasts a warning packet before it begins transmitting on the wire. This packet eliminates almost all collisions on the network because each computer on the network does not attempt to broadcast when another computer sends the warning packet.
All other computers wait until the data is sent.
The major drawback of trying to avoid network collisions is that the network traffic is high due to the broadcasting of the intent to send a message.

Token Passing
Special packet is passed from computer to computer.
A computer that wants to transmit must wait for a free token.
Computer takes control of the token and transmits data. Only this computer is allowed to transmit; others must wait for control of the token.
Receiving computer strips the data from the token and sends an acknowledgment.
Original sending computer receives the acknowledgment and sends the token on.
the token comes from the Nearest Active Upstream Neighbor　 and when the computer is finished, it goes to the Nearest Active Downstream Neighbor
uses "beaconing" to detect faults => this method is fault tolerant
NO contention => equal access to all computers on the network
NO collisions

Demand Priority
0. 100 Mbps standard called 100VG-AnyLAN. "Hub- based".
1. Repeaters manage network access by performing cyclical searches for requests to send from all nodes on the network. The repeater or HUB is responsible for noting all addresses, links and end nodes and verifying if they are all functioning. An "end node" can be a computer, bridge, router or switch.
2. Certain types of data are given priority if data reaches the repeater simultaneously. If two have the same priority, BOTH are serviced by alternating between the two.

Advantages over CSMA/CD　
1. Computers Uses four pairs of wires which can send and receive simultaneously.
2. Transmissions are through the HUB and are not broadcast to all other computers on the network.
3. There is only communication between the sending computer, the hub and the destination computer.
　
Other methods 　
Appletalk
The cabling system for an AppleTalk network is called LocalTalk.
LocalTalk uses　 CSMA/CA
AppleTalk has a dynamic network addressing scheme.
During bootup, the AppleTalk card broadcasts a random number on the network as its card address. If no other computer has claimed that address, the broadcasting computer configures the address as its own. If there is a conflict with another computer, the computer will try to use different IP combinations until it finds a working configuration.
　
　
ARC Net
ARC Net uses a token passing method in a logical ring similar to Token Ring networks.
However, the computers in an ARC Net network do not have to be connected in any particular fashion.
ARC Net can utilize a star, bus, or star bus topology.
Data transmissions are broadcast throughout the entire network, which is similar to Ethernet.
However, a token is used to allow computers to speak in turn.
The token is not passed in a logical ring order because ARCNet does not use the ring topology; instead the token is passed to the next highest numerical station
Use DIP switches to set the number (the Station Identifier) of the workstations, which you want to be beside each other so the token is passed to the next computer efficiently.
ARC Net isn't popular anymore => ARC Net speeds are a mere 2.5 Mbps.

Most important ARC Net facts for you to know:
ARC Net uses RG-62 (93 ohms) cabling;
it can be wired as a star, bus, or star bus; and
it uses a logical-ring media access method.

Summary Chart 　

Type of Communication
CSMA/CD - Broadcast-based
CSMA/CA - Broadcast-based
Token Passing-Token-based
Demand Priority-Hub-based

Type of Access Method
CSMA/CD - Contention
CSMA/CA -Contention
Token Passing-Non-Contention
Demand Priority-Contention

Type of Network
CSMA/CD -Ethernet
CSMA/CA -Local Talk
Token Passing-Token Ring ARCnet
Demand Priority-100VG-AnyLAN

Protocols

2008-12-25T14:26:00.002+08:00

Protocols are rules and procedures for communication.

　How Protocols Work
The Sending Computer
Breaks data into packets.
Adds addressing information to the packet
Prepares the data for transmission.

The Receiving Computer (same steps in reverse)
Takes the packet off the cable.
Strips the data from the packet.
Copies the data to a buffer for reassembly.
Passes the reassembled data to the application.

Protocol Stacks (or Suites)
A combination of protocols, each layer performing a function of the communication process.
Ensure that data is prepared, transferred, received and acted upon.

The Binding Process
Allows more than one protocol to function on a single network adapter card. (e.g. both TCP/IP and IPX/SPX can be bound to the came card
Binding order dictates which protocol the operating systems uses first.
binding also happens with the Operating System architecture: for example, TCP/IP may be bound to the NetBIOS session layer above and network card driver below it. The NIC device driver is in turn bound to the NIC.

Standard Stacks
ISO/OSI
IBM SNA (Systems Network Architecture)
Digital DECnet
Novell NetWare
Apple AppleTalk
TCP/IP

Protocol types map roughly to the OSI Model into three layers:
Application Level Service Users　
Application Layer　 Presentation Layer　 Session Layer

Transport Services　
Transport Layer

Network Services　
Network Layer　 Data Link Layer　 Physical Layer

Application Protocols
Work at the upper layer of the OSI model and provide application to application interaction and data exchange.　

Examples:
APPC-IBM's peer to peer SNA protocol used on AS400's
FTAM: an OSI file access protocol.
X.400: international e-mail transmissions.
X.500: file and directory services across systems.
SMTP: Internet e-mail.
FTP: Internet file transfer
SNMP: Internet network management protocol.
Telnet: Internet protocol for logging on to remote hosts.
Microsoft SMB: client shells and redirectors.
NCP: Novell client shells or redirectors.
AppleTalk and AppleShare: Apple's protocol suite.
AFP: Apple's protocol for remote file access.
DAP (data access protocol): DECnet file access protocol.

Transport Protocols
These protocols provide communication sessions between computers and ensure data is moved reliably between computers.　

Examples:
TCP (transmission control protocol): internet protocol for guaranteed delivery of sequenced data.
SPX (sequenced packet exchange): Novell protocol suite.
NWLink: Microsoft implementation of IPX/SPX.
NetBEUI: establishes communications sessions between computers and provides the underlying data transport services.
ATP, NBP: Apple's communication session and transport protocols.

Network Protocols
These provide link services　
They also　
handle
o addressing and routing,
o error checking and
o retransmission requests.
Define rules for Ethernet or Token Ring.

Examples:
IP (Internet Protocol): packet forwarding and routing.
IPX: (Internetwork Packet Exchange): Novell's protocol for packet forwarding and routing.
NWLink: Microsoft implementation of IPX/SPX.
NetBEUI: Transport for NetBIOS sessions and applications.
DDP (datagram delivery protocol): An AppleTalk data transport protocol.

A Network Functions

2008-12-23T00:16:00.002+08:00

The OSI Model
International Standards Organization (ISO) specifications for network architecture.
Called the Open Systems Interconnect or OSI model.
Seven layered model, higher layers have more complex tasks.
Each layer provides services for the next higher layer.
Each layer communicates logically with its associated layer on the other computer.
Packets are sent from one layer to another in the order of the layers, from top to bottom on the sending computer and then in reverse order on the receiving computer.

OSI Layers
Application
Presentation
Session
Transport
Network
Data Link
Physical

Application Layer
Serves as a window for applications to access network services.
Handles general network access, flow control and error recovery.
Presentation Layer
Determines the format used to exchange data among the networked computers.
Translates data from a format from the Application layer into an intermediate format.
Responsible for protocol conversion, data translation, data encryption, data compression, character conversion, and graphics expansion.
Redirector operates at this level.

Session Layer
Allows two applications running on different computers to establish use and end a connection called a Session.
Performs name recognition and security.
Provides synchronization by placing checkpoints in the data stream.
Implements dialog control between communicating processes.

Transport Layer
Responsible for packet creation.
Provides an additional connection level beneath the Session layer.
Ensures that packets are delivered error free, in sequence with no losses or duplications.
Unpacks, reassembles and sends receipt of messages at the receiving end.
Provides flow control, error handling, and solves transmission problems.

Network Layer
Responsible for addressing messages and translating logical addresses and names into physical addresses.
Determines the route from the source to the destination computer.
Manages traffic such as packet switching, routing and controlling the congestion of data.

Data Link Layer
Sends data frames from the Network layer to the Physical layer.
Packages raw bits into frames for the Network layer at the receiving end.
Responsible for providing error free transmission of frames through the Physical layer.

Physical Layer
Transmits the unstructured raw bit stream over a physical medium.
Relates the electrical, optical mechanical and functional interfaces to the cable.
Defines how the cable is attached to the network adapter card.
Defines data encoding and bit synchronization.

OSI Model Enhancements
The bottom two layers - Data Link and Physical - define how multiple computers can simultaneously use the network without interfering with each other.

Divides the Data-link layer in to the Logical Link Control and Media Access Control sub layers.

Logical Link Control
manages error and flow control and
Defines logical interface points called Service Access Points (Sap’s). These SAP's are used to transfer information to upper layers

Media Access Control
communicates directly with the network adapter card and
Is responsible for delivering error-free data between two computers.
Categories
802.3
802.4
802.5 and
802.12 define standards for both this sub layer and the Physical layer

Drivers
a device driver is software that tells the computer how to drive or work with the device so that the device performs the job it's supposed to.

Drivers are called

Network Drivers,

MAC drivers,

NIC drivers.

Provide communication between a network adapter card and the redirector in the computer.

Resides in the Media Access Control sublayer of the Data Link layer. Therefore, the NIC driver ensures direct communication between the computer and the NIC

the Media Access Control driver is another name for the network card device driver

When installing a driver, you need to know these things
IRQ
I/O Port Address
Memory Mapped (Base Memory Address)
Transceiver Type

Packets
Data is broken down into smaller more manageable pieces called packets.

Special control information is added in order to:
disassemble packets
reassemble packets
check for errors

Types of data sent includes
Can contain information such as messages or files.
Computer control data and commands and requests.
Session control codes such as error correction and retransmission requests.
Original block of data is converted to a packet at the Transport layer.

Packet Components
Header
Alert signal to indicate packet is being transmitted
Source address.
Destination address.
Clock synchronization information.

Data
Contains actual data being sent.
Varies from 512 to 4096 bytes (4K), depending on the network

Trailer
Content varies by protocol.
Usually contains a CRC.

Packet Creation
Look at the example on pp. 201 - 204
Begins at the Application layer where data is generated.
Each layer subsequently adds information to the packet; the corresponding layer on the receiving machine reads the information.
Transport layer breaks the data into packets and adds sequencing information needed to reassemble data at the other end => the structure of the packets is defined by the common protocol being used between the two computers.
Data is passed through the Physical layer to the cable.

Packet Addressing
every NIC sees all packets sent on its cable segment but only interrupts the computer if the packet address matches the computer's address
a broadcast type address gets attention of all computers on the network

Adobe Photoshop Shortcuts

2008-12-22T00:20:00.000+08:00

Transform>
Again Shift+Ctrl+T
Scale
Rotate
Skew
Distort
Perspective
Warp
Rotate 180°
Rotate 90° CW
Rotate 90° CCW
Flip Horizontal
Flip Vertical
Define Brush Preset...
Define Pattern...
Define Custom Shape...

Purge>
Undo
Clipboard
Histories
All

Adobe PDF Presets...
Preset Manager...
Color Settings... Shift+Ctrl+K
Assign Profile...
Convert to Profile...
Keyboard Shortcuts... Alt+Shift+Ctrl+K
Menus... Alt+Shift+Ctrl+M

Preferences>
General... Ctrl+K
File Handling...
Display & Cursors...
Transparency & Gamut...
Units & Rulers...
Guides, Grid & Slices...
Plug-Ins & Scratch Disks...
Memory & Image Cache...
Type...

Adobe Photoshop Shortcuts

2008-12-21T00:16:00.000+08:00

Adobe Photoshop Shortcuts

2008-12-20T00:15:00.000+08:00

Adobe Photoshop Keyboard Shortcuts

2008-12-18T20:49:00.001+08:00

Adobe Photoshop CS2 Keyboard Shortcuts

2008-12-18T18:18:00.005+08:00

Continuous Professional Development (CPD) Programme

2008-12-16T12:32:00.000+08:00

The pace of change in the application of information technology is so rapid that it is easy for the IS professional, focussed on a specific assignment, to fall behind recent developments. Continuous Professional Development is about keeping vital skills current – and it's not just confined to skills in information technology. Employers need to know that staff are keeping themselves informed on the latest developments, and are broadening their skills base as their job specification changes. Practitioners need a simple and practical method of monitoring the CPD work that they do.
Continuing Professional Development (CPD) is about continuously updating professional knowledge, personal skills and competencies. Even in retirement many people may make a contribution to their profession and still have personal learning goals.

Principles and Benefits of CPD
Principles:
The Professional development needs to be carefully planned, properly evaluated and carefully recorded for it to provide maximum benefit.

The provision of world-class management development resources can improve skill levels, increase motivation and aid recruitment and retention of key talent.

The professional should always be actively seeking to improve performance

Planning, Evaluating, Recording and Development are continuous

Development is a personal matter and should be owned and managed by the individual with the support of the employer

Learning outcomes should relate to the overall career plan of the individual and recognize current organizational needs where possible

Investment in training and development should be regarded as valuable as any other form of investment

Any development plan must start with the individual's current learning needs, take into account previous development, fit into their overall life and career plan and, where relevant, meet current organisational needs

Development goals should be clearly defined and accompanied by specific measures of what will constitute a successful outcome

Members should regularly assess their achievement against these measures, either as self-assessment or through peer assessment or with the help of a mentor

Investment in training, development and learning should be regarded as a fundamental principle of enhancing professional and commercial success

Enabling personal, professional and organisational growth

Enhancing patient care through clinical effectiveness and multiprofessional working

Adopting the principles of adult learning, featuring reflectiveness, responsiveness and personal review

Fairness in terms of access to, and time for, learning

Being supportive to colleagues in terms of a flexible approach to their career development

Mutual commitment in terms of sharing responsibility and agreement on resources

Being purposeful in terms of linking educational planning to clear organisational and individual goals

Supporting individuals through personal transitions and transformations in significant features of the service they deliver

Assuring educational effectiveness in terms of evaluating the quality and outcome for educational activities

Assuring cost effectiveness in terms of how learning opportunities are provided

Benefits:
Employers have a better skilled and more efficient work force

Informed employers attract high calibre staff and keep them

Good CPD policies can provide the most cost effective means of providing training, particularly if
carried out in partnership with institutions

Individuals will have the skills to react to a changing profession more readily

Staff will be more adaptable aiding diversification opportunities

CPD support from the employer as far as the employee's are concerned improves motivation and retention

Although the benefits of CPD are primarily felt by the individual, there are benefits to be gained by employers and the Society of Archivists as indicated by the table below.

Benefits to the Individual
Increases self esteem as you look back on achievements

Financial reward-CPD could support a claim for promotion

Encourages analytical thinking; about your job, the tasks that you do and how you do them thereby increasing performance

Provides the opportunity to enrich and develop your existing job

Aids career development; you can plan to learn skills which will equip you to move your career in a direction which interests you

Reflective practice encourages you to assess alternative approaches to tasks and gives you encouragement to thing creatively

Reflective practice can help you to feel in control of your work circumstances and might help to relieve stress

A written record of your CPD allows you to demonstrate your skills in a very concrete way
CPD can help you recognize the way in which skills learnt in other areas of your life could be applied in the workplace

Reflective practice is a safe environment for thinking about and assessing your mistakes, problems and perceived failures. It allows you to ask “what did I learn from this?” and think about what you would do differently in the future

A written record of CPD can help you to define and make clear in your mind your mind your achievements and the progress you have made

Computer Assisted Software Engineering CASE

2008-12-15T11:42:00.002+08:00

Introduction
Computer-assisted software engineering (CASE) tools are a set of programs and aids that assist analysts, software engineers, and programmers during all phases of the system development life cycle (The stages in the system development life cycle are: Preliminary Investigation, Analysis, Design, Implementation, and Installation). The implementation of a new system requires a lot of tasks to be organized and completed correctly and efficiently. CASE tools were developed to automate these process and to ease the task of coordinating the events that need to be performed in the system development life cycle. CASE tools can be divided into two main groups - those that deal with the first three parts of the system development life cycle (preliminary investigation, analysis, and design) are referred to as Front-End CASE tools or Upper CASE tools, and those that deal mainly with the Implementation and Installation are referred to as Back-End CASE tools or Lower CASE tools.

The major reason for the development of CASE tools was to increase the speed of the development of systems. By doing so, companies were able to develop systems without facing the problem of having business needs change before the system could be finished being developed. Quicker installation also allowed the companies to complte more effectively using its newly developed system that matched its current business needs. In a highly competitive market, staying on the leading edge can make the difference between success and failure.
CASE tools also allowed analysts to allocate more time to the analysis and design stages of development and less time coding and testing. Previous methods saw only 35% of the time being spent of analysis and design and 65% of the time being used to develop code and testing. CASE tools allowed analysts to use as much as 85% of the time in the analysis and design stages of the development. This resulted in systems that more closely mirrored the requirement from the users and allowed for more efficient and effective systems to be developed.
By using a set of CASE tools, information generated from one tool can be passed to other tools which, in turn, will use the information to complete its task, and then pass the new information back to the system to be used by other tools. This allows for important information to be passed very efficiently and effectively between many planning tools with practically no resistance. When using the old methods, incorrect information could very easily be passed between designers or could simply be lost in the shuffle of papers.

History of Case Tools
CASE tools began with the simple word processor which was used for creating and manipulating documentation. The seventies saw the introduction of graphical techniques and structured data flow diagrams. Up until this point, design and specifications in pictorial form had been extremely complex and time consuming to change. The introduction of CASE tools to aid this process allowed diagrams to be easily created and modified, improving the quality of software designs. Data dictionaries, a very useful document that holds the details of each data type and processes within a system, are the direct result of the arrival of data flow design and structural analysis made possible through the improvements of CASE tools. Early graphics packages were soon replaced by specialist’s packages which enabled editing, updating and printing multiple versions of a design. Eventually, graphic tools integrated with data dictionary databases to produce powerful design and development tools that could hold complete design cycle documents. As a final step, error checking and test case generators were included to validate software design. All these processes can know is integrated into a single CASE tool that supports all of the development cycle.

Early 80's Computer aided documentation computer aided diagramming analysis and design tools
Mid 80's Automated design analysis and checking automated system information repositories
Late 80's Automated code generation from design specification linking design automation
Early 90's Intelligent methodology driver habitable user interface reusability as a development methodology

Advantages of CASE Tools
Current trends are showing a significant decrease in the cost of hardware with a corresponding increase in the cost of computer software. This reflects the labor intensive nature of the software. Developing effective software packages takes the work of many people and can take years to complete. Furthermore, small errors in the logic of the programs can have huge consequences for the user. CASE tools are an important part of resolving the problems of application development and maintenance. CASE tools significantly alter the time taken by each phase and the distribution of cost with in the software life cycle. Software engineers are now placing greater emphasis on analysis and design. Much of the code can now be generated automatically with the development of detailed specifications. Improvements in both these areas made possible through the use of CASE tools are showing dramatic reductions in maintenance costs. The power of CASE tools lies in their central repository which contains descriptions of all the central components of the system. These descriptions are used at all stages of the cycle; creation of input/output designs, automatic code generation, etc. Later tasks continue to add to and build upon this repository so that by the conclusion of the project it contains a complete description of the entire system. This is a powerful device which was not feasible before the introduction of CASE tools.

More specifically CASE tools:
Ensure consistency, completeness and conformance to standards
Encourage an interactive, workstation environment
Speeds up development process
Allows precision to be replicated
Reduces costs, especially in maintenance
Increases productivity
Makes structured techniques practical

Selection of a CASE Tool
With thousands of tools available the decision of which one will best fit your needs is not an easy one. The failure or success of the tool is relative to your expectations. Therefore a clear understanding of the specifications and expectations of the CASE tool are of utmost necessity before beginning your search. There are three common points of failure; the selection process itself, the pre-requisites of the tool, your business. As previously mentioned the evaluation and selection of a CASE tool is a major project which should not be taken lightly. Time and resources need to be allocated to identifying the criteria on which the selection is to be based. Next, examine if these expectations are reasonable. Make sure you have a clear understanding of the tools purpose. There must be a common vision of the systems development environment in which the tools will be used. Finally, know your organization and its needs. Identify the infra structure and in particular, the level of discipline in the information technology department. Is your selection of a CASE tool compatible with the personalities, and expertise of the individuals who will be using it? If these three areas are taken into consideration the tools is sure to be a success and offer all the benefits outlined above to your development project.

Upper (Front-End) CASE Tools
During the initial stages of the system development, analysts are required to determine system requirements, and analyze this information to design the most effective system possible. To complete this task, an analyst will use data flow diagrams, data dictionaries, process specifications, documentation and structure charts. When completing these tasks manually, it becomes very tedious to have to redraw the diagrams each time a change is made to the system. Computerized CASE tools allows for these types of changes to be made very quickly and accurately. However, using the old methods, a bigger problem arises when changes need to be made to the system - a change to one diagram may require many changes to occur throughout all the documentation. For a very large system, it is very easy to forget to make the changes in all documentation, leading to an erroneous representation of the system which could lead to problems during the implementation phase. By using CASE tool's analysis feature, information shared throughout the flowcharts and documentation can be checked against each other to ensure that they match.

CASE tools are also a very helpful tool to use during the design phase of the system development. CASE provides tools to help develop prototype screens, reports and interfaces. These prototypes can then be check and approved by the users and management very quickly. This avoids the problem of having to redesign the interfaces during the implementation phase, that users do not like or do not complete the task they are suppose to handle.

Lower (Back-End) CASE Tools
Lower CASE tools are most often used to help with the generation of the program code. Forth generation programming languages and code generators measurably reduce the time and cost needed to produce the code necessary to run the system. Code generators also produce a high quality of code that is easy to maintain and that is portable (i.e. is easily transferable to other hardware platforms).
Forth generation program code is also much easier to test. Since forth generation code tends to focus on the logic of the program, there are much fewer lines of code for the programmer to examine and test. Fewer lines also aids in the maintenance of the program since fewer lines need to be examined, and only the higher level forth generation code will need to be changed, not the lower level third generation code.
Code generators also have the feature that they are able to interact with the upper CASE tools. Information that was stored from the upper CASE tools can be accessed using the code generators to aid in the development of the code. Code generators also allow for specialized code to be inserted into the generated program code. This allows special features to be designed and implemented into the program.

Benefits and drawback of CASE tool:

Benefits of CASE tool:
Produce systems with a longer effective operational life
Produce systems that more closely meet user needs and requirements
Produce systems with excellent documentation
Produce systems that need less systems support
Produce more flexible systems

Drawback of CASE tool:
Produce initial systems that are more expensive to build and maintain
Require more extensive and accurate definition of ser needs and requirements
May be difficult to customize
Require training of maintenance staff
May be difficult to use with existing systems

Prototyping model and Object oriented model

2008-12-14T00:52:00.000+08:00

The prototyping model is a software development process that begins with requirements collection, followed by prototyping and user evaluation
Often the end users may not be able to provide a complete set of application objectives, detailed input, processing, or output requirements in the initial stage.
After the user evaluation, another prototype will be built based on feedback from users, and again the cycle returns to customer evaluation.
The cycle starts by listening to the user, followed by building or revising a mock-up, and letting the user test the mock-up, then back. There is now a new generation of tools called Application Simulation Software which help quickly simulate application before their development.

Advantages of prototyping
May provide the proof of concept necessary to attract funding
Early visibility of the prototype gives users an idea of what the final system looks like
Encourages active participation among users and producer
Enables a higher output for user
Cost effective (Development costs reduced)
Increases system development speed
Assists to identify any problems with the efficacy of earlier design, requirements analysis and coding activities
Helps to refine the potential risks associated with the delivery of the system being developed

Disadvantages of prototyping
User’s expectation on prototype may be above its performance
Possibility of causing systems to be left unfinished
Possibility of implementing systems before they are ready
Producer might produce a system inadequate for overall organization needs
User can get too involved where as the program can not be to a high standard
Structure of system can be damaged since many changes could be made
Producer might get too attached to it (might cause legal involvement)
Not suitable for large applications

Electronics prototyping
In electronics, prototyping means building an actual circuit to a theoretical design to verify that it works, and to provide a physical platform for debugging it if it does not.
The prototype is often constructed using techniques such as wire wrap or using Vero board or breadboard, that create an electrically correct circuit, but one that is not physically identical to the final product

mass produce custom printed circuit boards than these other kinds of prototype boards. This is for the same reasons that writing a poem is fastest by hand for one or two, but faster by printing press if you need several thousand copies.
[Edit] Rapid Electronics prototyping
The proliferation of quick-turn pub fob companies and quick-turn pub assembly houses has enabled the concepts of rapid prototyping to be applied to electronic circuit design. It is now possible, even with the smallest passive components and largest fine-pitch packages, to have boards fobbed and parts assembled in a matter of day

Strength of object oriented model.
Object-oriented models have rapidly become the model of choice for programming most new computer applications. Since most application programs need to deal with persistent data, adding persistence to objects is essential to making object-oriented applications useful in practice. There are three classes of solutions for implementing persistence in object-oriented applications: the gateway-based object persistence approach, which involves adding object-oriented programming access to persistent data stored using traditional non-object-oriented data stores, the object-relational database management system (DBMS) approach, which involves enhancing the extremely popular relational data model by adding object-oriented modeling features, and the object-oriented DBMS approach (also called the persistent programming language approach), which involves adding persistence support to objects in an object-oriented programming language. In this paper, we describe the major characteristics and requirements of object-oriented applications and how they may affect the choice of a system and method for making objects persistent in that application. We discuss the user and programming interfaces provided by various products and tools for object-oriented applications that create and manipulate persistent objects. In addition, we describe the pros and cons of choosing a particular mechanism for making objects persistent, including implementation requirements and limitations imposed by each of the three approaches to object persistence previously mentioned. Given that several object-oriented applications might need to share the same data, we describe how such applications can interoperate with each other. Finally, we describe the problems and
solutions of how object-oriented applications can coexist with non-object-oriented (legacy) applications that access the same data.

Strength and weakness of object oriented model
Benchmarks between Odom’s and RDBMS have shown that ODBMS can be clearly superior for certain kinds of tasks. The main reason for this is that many operations are performed using navigational rather than declarative interfaces, and
navigational access to data is usually implemented very efficiently by following pointers.[3]
Critics of Navigational Database-based technologies like ODBMS suggest that pointer-based techniques are optimized for very specific "search routes" or viewpoints. However, for general-purpose queries on the same information, pointer-based techniques will tend to be slower and more difficult to formulate than relational. Thus, navigation appears to simplify specific known uses at the expense of general, unforeseen, and varied future uses. (However, it may be possible to apply generic reordering and optimizations of pointer routes in some cases).
Other things that work against ODBMS seem to be the lack of interoperability with a great number of tools/features that are taken for granted in the SQL world including but not limited to industry standard connectivity, reporting tools, OLAP tools and backup and recovery standards. Additionally, object databases lack a formal mathematical foundation, unlike the relational model, and this in turn leads to weaknesses in their query support. However, this objection is offset by the fact that some Odom’s fully support SQL in addition to navigational access, e.g. Objectivity/SQL++, Matisse, and Intersystem CACHÉ. Effective use may require compromises to keep both paradigms in sync.

In fact there is an intrinsic tension between the notion of encapsulation, which hides data and makes it available only through a published set of interface methods, and the assumption underlying much database technology, which is that data should be accessible to queries based on data content rather than predefined access paths. Database-centric thinking tends to view the world through a declarative and attribute-driven viewpoint, while OOP tends to view the world through a behavioral viewpoint. This is one of the many impedance mismatch issues surrounding OOP and databases.
Although some commentators have written off object database technology as a failure, the essential arguments in its favor remain valid, and attempts to integrate database
Functionality more closely into object programming languages continue in both the research and the industrial communities

Investigate the prototyping model and any object-oriented model.
Discussion, see Object-oriented analysis and design and Object-oriented programming. The description of these Objects is a Schema.
As an example, in a model of a Payroll System, a Company is an Object. An Employee is another Object. Employment is a Relationship or Association. An Employee Class (or Object for simplicity) has Attributes like Name, Birthdates, etc. The Association itself may be considered as an Object, having Attributes, or Qualifiers like Position, etc. An Employee Method may be Promote, Raise, etc.

The Model description or Schema may grow in complexity to require a Notation. Many notations has been proposed, based on different paradigms, diverged, and converged in a more popular one known as UML.

An informal description or a Schema notation is translated by the programmer or a Computer-Aided Software Engineering tool in the case of Schema notation (created using a Module specific to the CASE tool application) into a specific programming language that supports Object-Oriented Programming (or a Class Type), a Declarative Language or into a Database schema.

Strengths and Weakness of SDLC Models

2008-12-13T00:34:00.000+08:00

Waterfall Model
This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Unlike what I mentioned in the general model, phases do not overlap in a waterfall model.
Strengths
· Simple and easy to use.
· Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.
· Phases are processed and completed one at a time.
· Works well for smaller projects where requirements are very well understood.

Weaknesses
· Adjusting scope during the life cycle can kill a project
· No working software is produced until late during the life cycle.
· High amounts of risk and uncertainty.
· Poor model for complex and object-oriented projects.
· Poor model for long and ongoing projects.

V-Shaped Model
Strengths
· Simple and easy to use.
· Each phase has specific deliverables.
· Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle.
· Works well for small projects where requirements are easily understood.

Weaknesses
· Very rigid, like the waterfall model.
· Little flexibility and adjusting scope is difficult and expensive.
· Software is developed during the implementation phase, so no early prototypes of the software are produced.
· Model doesn’t provide a clear path for problems found during testing phases

Incremental Model
Stengths
·Generates working software quickly and early during the software life cycle.
·More flexible – less costly to change scope and requirements.
·Easier to test and debug during a smaller iteration.
·Easier to manage risk because risky pieces are identified and handled during its iteration.
·Each iteration is an easily managed milestone.

Weaknesses
·Each phase of an iteration is rigid and do not overlap each other.
·Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle.

Spiral Model
The spiral model is the most generic of the models. Most life cycle models can be derived as special cases of the spiral model. The spiral uses a risk management approach to software development. Some advantages of the spiral model are:
· defers elaboration of low risk software elements
· incorporates prototyping as a risk reduction strategy
· gives an early focus to reusable software
· accommodates life-cycle evolution, growth, and requirement changes
· incorporates software quality objectives into the product
· focus on early error detection and design flaws
· sets completion criteria for each project activity to answer the question: "How much is enough?"
· uses identical approaches for development and maintenance can be used for hardware-software system develop
Strengths
· High amount of risk analysis
· Good for large and mission-critical projects.
· Software is produced early in the software life cycle.

Weaknesses
Can be a costly model to use.
Risk analysis requires highly specific expertise.
Project’s success is highly dependent on the risk analysis phase.
Doesn’t work well for smaller projects.

Evolutionary Prototyping
Evolutionary prototyping uses multiple iterations of requirements gathering and analysis, design and prototype development. After each iteration, the result is analyzed by the customer. Their response creates the next level of requirements and defines the next iteration
Strengths
· Customers can see steady progress
· This is useful when requirements are changing rapidly, when the customer is reluctant to commit to a set of requirements, or when no one fully understands the application area

Weakness
· It is impossible to know at the outset of the project how long it will take.
· There is no way to know the number of iterations that will be required.
Evolutionary Prototyping Summary The manager must be vigilant to ensure it does not become an excuse to do code-and-fix development.

Code-and-Fix
If you don't use a methodology, it's likely you are doing code-and-fix. Code-and-fix rarely produces useful results. It is very dangerous as there is no way to assess progress, quality or risk.
Strengths
· No time spent on "overhead" like planning, documentation, quality assurance, standards enforcement or other non-coding activities
· Requires little experience

Weakness
· Dangerous.
· No means of assessing quality or identifying risks.
· Fundamental flaws in approach do not show up quickly, often requiring work to be thrown out.
Code-and-Fix Summary Code-and-fix is only appropriate for small throwaway projects like proof-of-concept, short-lived demos or throwaway prototypes

Weakness
· Won't be able to predict the full range of functionality.
Design-to-Schedule SummaryIn design-to-schedule delivery, it is critical to prioritize features and plan stages so that the early stages contain the highest-priority features. Leave the lower priority features for later

Staged Delivery
Although the early phases cover the deliverables of the pure waterfall, the design is broken into deliverables stages for detailed design, coding, testing and deployment.
Strengths
· Can put useful functionality into the hands of customers earlier than if the product were delivered at the end of the project.

Weakness
· Doesn't work well without careful planning at both management and technical levels

Staged Delivery Summary For staged delivery, management must ensure that stages are meaningful to the customer. The technical team must account for all dependencies between different components of the system

Evolutionary Delivery
Evolutionary delivery straddles evolutionary prototyping and staged delivery
Strengths
Enables customers to refine interface while the architectural structure is as

Weakness
Doesn't work well without careful planning at both management and

Evolutionary Delivery Summary For evolutionary delivery, the initial emphasis should be on the core components of the system. This should consist of lower level functions which are unlikely to be changed by customer feedback

Design-to-Schedule
Like staged delivery, design-to-schedule is a staged release model. However, the number of stages to be accomplished are not known at the outset of the project.
Strengths
· Produces date-driven functionality, ensuring there is a product at the critical date.
· Covers for highly suspect estimates

Software Life Cycle Models

2008-12-12T05:07:00.008+08:00

Software Development Life Cycle (SDLC) is a methodology that is typically used to develop, maintain and replace information systems for improving the quality of the software design and development process. The typical phases are analysis, estimation, design, development, integration and testing and implementation. The success of software largely depends on proper analysis, estimation, design and testing before the same is implemented. This article discusses SDLC in detail and provides guidance for building successful software.

Methods
Life cycle models describe the interrelationships between software development phases. The common life cycle models are:
spiral model
Incremental model
V-shaped model
waterfall model
General model
throwaway prototyping model
evolutionary prototyping model
code-and-fix model
reusable software model
automated software synthesis

Because the life cycle steps are described in very general terms, the models are adaptable and their implementation details will vary among different organizations. The spiral model is the most general. Most life cycle models can in fact be derived as special instances of the spiral model. Organizations may mix and match different life cycle models to develop a model more tailored to their products and capabilities.

The Spiral Model
The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts.The spiral model was defined by Barry Boehm in his article A Spiral Model of Software Development and Enhancement from 1985. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters. As originally envisioned, the iterations were typically
6 months to 2 years long.Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project.

The steps in the spiral model can be generalized as follows:
1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
2.A preliminary design is created for the new system.
3.A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
4. A second prototype is evolved by a fourfold procedure:
1. evaluating the first prototype in terms of its strengths, weaknesses, and risks;
2. defining the requirements of the second prototype;
3. planning and designing the second prototype;
4. constructing and testing the second prototype.
5. At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product.
6. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
7.The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.
8. The final system is constructed, based on the refined prototype.

Incremental Model
The incremental model is an intuitive approach to the waterfall model. Multiple development cycles take place here, making the life cycle a “multi-waterfall” cycle. Cycles are divided up into smaller, more easily managed iterations. Each iteration passes through the requirements, design, implementation and testing phases.
A working version of software is produced during the first iteration, so you have working software early on during the software life cycle. Subsequent iterations build on the initial software produced during the first iteration.

V Shaped Model
Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins. Testing is emphasized in this model more so than the waterfall model though. The testing procedures are developed early in the life cycle before any coding is done, during each of the phases preceding implementation.

Requirements begin the life cycle model just like the waterfall model. Before development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in the requirements gathering.
The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together.

The low-level design phase is where the actual software components are designed, and unit tests are created in this phase as well.
The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.

Waterfall Model

This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Unlike what I mentioned in the general model, phases do not overlap in a waterfall model

The General Model
Software life cycle models describe phases of the software cycle and the order in which those phases are executed. There are tons of models, and many companies adopt their own, but all have very similar patterns. The general, basic model is shown below:
General Life Cycle
Model
REQUIRMENT DESIGN IMPLEMENTATION TESTING

Each phase produces deliverables required by the next phase in the life cycle. Requirements are translated into design. Code is produced during implementation that is driven by the design. Testing verifies the deliverable of the implementation phase against requirements.

Requirements
Business requirements are gathered in this phase. This phase is the main focus of the project managers and stake holders. Meetings with managers, stake holders and users are held in order to determine the requirements. Who is going to use the system? How will they use the system? What data should be input into the system? What data should be output by the system? These are general questions that get answered during a requirements gathering phase. This produces a nice big list of functionality that the system should provide, which describes functions the system should perform, business logic that processes data, what data is stored and used by the system, and how the user interface should work. The overall result is the system as a whole and how it performs, not how it is actually going to do it.

Design
The software system design is produced from the results of the requirements phase. Architects have the ball in their court during this phase and this is the phase in which their focus lies. This is where the details on how the system will work is produced. Architecture, including hardware and software, communication, software design (UML is produced here) are all part of the deliverables of a design phase.

Implementation
Code is produced from the deliverables of the design phase during implementation, and this is the longest phase of the software development life cycle. For a developer, this is the main focus of the life cycle because this is where the code is produced. Implementation my overlap with both the design and testing phases. Many tools exists (CASE tools) to actually automate the production of code using information gathered and produced during the design phase.

Testing
During testing, the implementation is tested against the requirements to make sure that the product is actually solving the needs addressed and gathered during the requirements phase. Unit tests and system/acceptance tests are done during this phase. Unit tests act on a specific component of the system, while system tests act on the system as a whole.
So in a nutshell, that is a very basic overview of the general software development life cycle model. Now lets delve into some of the traditional and widely used variations.

Throwaway Prototyping Model
Useful in " proof of concept" or situations where requirements and user's needs are unclear or poorly specified. The approach is to construct a quick and dirty partial implementation of the system during or before the requirements phase.

Evolutionary Prototyping Model
Use in projects that have low risk in such areas as losing budget, schedule predictability and control, large-system integration problems, or coping with information sclerosis, but high risk in user interface design.

Code-and-Fix
If you don't use a methodology, it's likely you are doing code-and-fix. Code-and-fix rarely produces useful results. It is very dangerous as there is no way to assess progress, quality or risk.
Code-and-fix is only appropriate for small throwaway projects like proof-of-concept, short-lived demos or throwaway prototypes.

NETWORK TOPOLOGIES

2008-12-11T02:44:00.006+08:00

In networking, the term topology refers to the layout of connected devices on a network.
Network topologies are categorized into the following basic types:
bus
ring
star
tree
mesh

BUS
More complex networks can be built as hybrids of two or more of the above basic topologies.

Bus networks (not to be confused with the system bus of a computer) use a common backbone to connect all devices. A single cable, the backbone functions as a shared communication medium, those devices attach or tap into with an interface connector. A device wanting to communicate with another device on the network sends a broadcast message onto the wire that all other devices see, but only the intended recipient actually accepts and processes the message.

Bus consists of a single linear cable called a trunk.
Data is sent to all computers on the trunk. Each computer examines EVERY packet on the wire to determine who the packet is for and accepts only messages addressed to them.

Bus is a passive topology.
Performance degrades as more computers are added to the bus.
Signal bounce is eliminated by a terminator at each end of the bus.
Barrel connectors can be used to lengthen cable.
Usually uses Thin net or Thicket
both of these require 50 ohm terminator
good for a temporary, small (fewer than 10 people) network
But it’s difficult to isolate malfunctions and if the backbone goes down, the entire network goes down.
Repeaters can be used to regenerate signals.

Ethernet bus topologies are relatively easy to install and don't require much cabling compared to the alternatives. 10Base-2 ("ThinNet") and 10Base-5 ("ThickNet") both were popular Ethernet cabling options years ago. However, bus networks work best with a limited number of devices. If more than a few dozen computers are added to a bus, performance problems will likely result. In addition, if the backbone cable fails, the entire network effectively becomes unusable.

Ring

In a ring network, every device has exactly two neighbors for communication purposes. All messages travel through a ring in the same direction (effectively either "clockwise" or "counterclockwise"). A failure in any cable or device breaks the loop and can take down the entire network.

To implement a ring network, one typically uses FDDI, Sonet , or Token Ring tech Ring Topology

Computers are connected on a single circle of cable.
usually seen in a Token Ring or FDDI (fiber optic) network
Each computer acts as a repeater and keeps the signal strong => no need for repeaters on a ring topology
No termination required => because its a ring
Token passing is used in Token Ring networks. The token is passed from one computer to the next, only the computer with the token can transmit. The receiving computer strips the data from the token and sends the token back to the sending computer with an acknowledgment. After verification, the token is regenerated.
relatively easy to install, requiring ;minimal hardware

Star

Many home networks use the star topology. A star network features a central connection point called a "hub" that may be an actual hub or a switch. Devices typically connect to the hub with Unshielded Twisted Pair (UTP) Ethernet.

Compared to the bus topology, a star network generally requires more cable, but a failure in any star network cable will only take down one computer's network access and not the entire LAN. (If the hub fails, however, the entire network also fails.)
Computers are connected by cable segments to a centralized hub.

Signal travels through the hub to all other computers.
Requires more cable.
If hub goes down, entire network goes down.
If a computer goes down, the network functions normally.
most scalable and reconfigurable of all topologies

Mesh
The mesh topology connects each computer on the network to the others
Meshes use a significantly larger amount of network cabling than do the other network topologies, which makes it more expensive.
The mesh topology is highly fault tolerant.
Every computer has multiple possible connection paths to the other com-putters on the network, so a single cable break will not stop network communications between any two computers.

Star Bus Topology
Several star topologies linked with a linear bus.
No single computer can take the whole network down. If a single hub fails, only the computers and hubs connected to that hub are affected.

Star Ring Topology
Also known as star wired ring because the hub itself is wired as a ring. This means it's a physical star, but a logical ring.
This topology is popular for Token Ring networks because it is easier to implement than a physical ring, but it still provides the token passing capabilities of a physical ring inside the hub.
Just like in the ring topology, computers are given equal access to the network media

through
The passing of the token.
A single computer failure cannot stop the entire network, but if the hub fails, the ring that the hub controls also fails.

Hybrid Mesh
most important aspect is that a mesh is fault tolerant
a true mesh is expensive because of all the wire needed
Another option is to mesh only the servers that contain information that everyone has to get to. This way the servers (not all the workstations) have fault tolerance at the cabling level.

Project Management

2008-12-09T00:34:00.003+08:00

Project management is a carefully planned and organized effort to accomplish a specific (and usually) one-time effort, for example, construct a building or implement a new computer system. Project management includes developing a project plan, which includes defining project goals and objectives, specifying tasks or how goals will be achieved, what resources are need, and associating budgets and timelines for completion. It also includes implementing the project plan, along with careful controls to stay on the "critical path", that is, to ensure the plan is being managed according to plan. Project management usually follows major phases (with various titles for these phases), including feasibility study, project planning, implementation, evaluation and support/maintenance. (Program planning is usually of a broader scope than project planning, but not always.)

Project management, is the application of knowledge, skills, tools, and techniques to describe, organize, oversee and control the various project processes.

Project Management is the ongoing process of directing and coordinating all the steps in the development of an information system. Effective project management is necessary throughout the entire systems development and implementation. The need for effective project management is most often recognized during system development.

The goal of project management is to produce an information system that is acceptable to its users and that is developed within the specified time frame and budget. The acceptability, deadline and budget criteria must all be met for a project to be considered completely successful. Failing to meet any one of these three criteria usually indicates a failure, at least in part, in project management.

According to the Project Management Institute the components of project management are organized into nine Project Management Knowledge Areas.

But perhaps project management can best be described in terms of the things that you need to do to successfully manage a project:

Project Integration Management:
Develop and manage a project plan. The processes required to ensure that elements of the project are properly coordinated. It consists of project plan development, project plan execution, and overall change control.

Project Scope Management:
Plan, define and manage project scope. The processes required to ensure that all the work required, and only the work required, is included to complete the project successfully. It consists of initiation, scope planning, scope definition, scope verification and scope change control.

Project Time Management:
Create a project schedule. The processes required to ensure the project is completed in a timely way. It consists of activity definition, activity sequencing, activity duration estimating, schedule development, and schedule control.

Project Cost Management:
Create plan resources and budget costs. The processes required to ensure the project is completed within he approved budget. It consists of resource planning, cost estimating, cost budgeting, and cost control.

Project Quality Management:
Develop a quality plan and carry out quality assurance and quality control activities. The processes required to ensure that the project satisfies the needs for which it was undertaken. It consists of quality planning, quality assurance, and quality control.

Project Human Resource Management:
Perform organizational planning, manage staff acquisitions and promote team development. The processes required to most effectively use the people involved in the project. It consists of organizational planning, staff acquisition, and team development.

Project Communications Management:
Develop a communications plan. The processes required to timely and appropriately generate, collect, disseminate, store, and ultimately dispose of project information. It consists of communications planning, information distribution, performance reporting, and administrative closure.

Project Risk Management:
Identify risks, prepare risk mitigation plans and execute contingency actions. The processes concerned with identifying, analyzing, and responding to project risk. It consists of risk identification, risk quantification, risk response development, and risk response control.

Project Procurement Management:
The processes required to acquire goods and services from outside the organization. It consists of procurement planning, solicitation planning, solicitation, source selection, contract administration, and contract closeout.

Activities of Project Manager:
A project manager is a facilitator. The ideal project manager does whatever it takes to ensure that the members of the software project team can do their work. This means working with management to ensure they provide the resources and support required as well as dealing with team issues that are negatively impacting a team's productivity. The project manager must possess a combination of skills including the ability to ask penetrating questions, identify unstated assumptions, and resolve personnel conflicts along with more systematic management skills.
The actions of a project manager should be almost unnoticeable and when a project is moving along smoothly people are sometimes tempted to question the need for a project manager. However, when you take the skilled project manager out of the mix, the project is much more likely to miss deadlines and exceed budgets.
The project manager is the one who is responsible for making decisions in such a way that risk is controlled and uncertainty minimized. Every decision made by the project manager should ideally be directly benefit the project.
On small projects, the project manager will likely deal directly with all members of the software development team. On larger projects, there is often a lead developer, lead graphic designer, lead analyst, etc. that report directly to the project manager.

Essential qualities of project manager:
a) Strong leadership ability
Leadership is getting things done through others; the project manager achieves the results through project team. He needs to inspire the project team members, needs to create a vision of the result. Project leadership requires a participative and conclusive leadership style, in which the project manager provides guidance and coaching to the project team. It also requires involvement and empowerment of the project team. He should motivate the team to achieve its objective.

b) Ability to develop people
The effective project manager has a commitment to the training and development of people working on the project. The project manager should establish an environment where people can learn from the tasks they perform and situations they experience. He should provide opportunities for learning and development by encouraging the individuals. A final way in which a project manager can develop people is by having them attend formal training sessions.

c)Excellent communication skills
Project managers must be good communicators. It’s important for the project manager to provide timely feedback to the team and customer. The project manager needs to communicate regularly with the project team, as well as with any subcontractor, the customer and their own company’s upper management. Effective and frequent communication is critical for keeping the project moving, identifying potential problems, and soliciting suggestions to improve project performance, keeping customer satisfaction and avoiding surprises.

d) Ability to handle stress
Project managers need to handle the stress that can arise from work situations. Stress is likely to be high when some critical problems arise. The project managers can improve their ability to handle stress by keeping physically fit through regular exercise and good nutrition, he can also organize stress relief activities playing outdoor games etc.

e)Good interpersonal skills
Good interpersonal depends on how good his oral and written communication. The project manager needs to establish clear expectations of the members of the project team so that everyone knows the importance their roles in the project. A project manager needs good interpersonal skills to try to influence the thinking and action of others, to deal with disagreement or divisiveness among the team members.

f)Problem-solving skills
A project manager should encourage project team to identify problems early and solve them. Team members should be asked to give suggestions to solve the problem. The project manager should then use analytical skills to evaluate the information and develop the optimal solution.
Developing skills needed to be a project manager:
Gain experience.
Seek out feed back from others.
Conduct a self-evaluation, and learn from your mistakes.
Interview project managers who have the skills you want to develop in yourself.
Participate in training programs, volunteer yourself in other work.

Windows Explorer keyboard shortcuts

2008-12-08T04:15:00.000+08:00

END - Display the bottom of the active window.

HOME - Display the top of the active window.

NUM LOCK+ASTERISK on numeric keypad (*) - Display all subfolders under the selected folder.

NUM LOCK+PLUS SIGN on numeric keypad (+) - Display the contents of the selected folder.

NUM LOCK+MINUS SIGN on numeric keypad (‐) - Collapse the selected folder

LEFT ARROW - Collapse current selection if it's expanded, or select parent
folder.

RIGHT ARROWn- Display current selection if it's collapsed, or select first subfolder

System Analysis Design

2008-12-07T13:41:00.000+08:00

Analysis
The third phase of the SDLC in which the current system is studied and alternative replacement system is proposed. Description of current system and where problems or opportunities are with a general recommendation on how to fix. Enhance, or replace current system, explanation of alternative systems and justification for chosen alternative

Analysis Phase – One phase of the SDLC whose objective is to understand the user’s needs and develop requirements
Gather information
Define system Requirements
Build Prototypes for Discovery of Requirements
Prioritize Requirements
Generate and Evaluate Alternative
Review recommendations with Management

Requirement Analysis
Based on the survey have been conducted and studied several analysis had been performed on some existing solutions that are currently used. The following of the requirements will be incorporate into this “Modern Acrobatic Centre” in order to make it successfully adopted by users.
a. Easy to use.
The system will not incorporate complicated functions to make it difficult to use. The user interface will be properly designed, so that the user can understand it clearly.

b.Easy to maintain.
The system will be easy developed with easing technology so that it is easy to maintain and does not depend on proprietary technology.

c.Easy to support.
By developing the system on Visual Basic environment, it will make easy to support. By ensuring the user interface is properly clear and good help modules is designed for the system, we will ensure that minimal support required for the system.

d.Support multi levels of security control to access the different parts of the system.

e.System must be able to update frequently.
System must be able for future enhancement

Design
The next mode is focus on physical and logical design. This shows that this phase is devoted to designing the new enhanced system. During this phase, I have converted the description of the recommended alternatives solutions into logical and physical system specifications. It explains more on all the aspects of the system from input and output screens to log files and computer processes. The physical aspects always specifies the system being designed either as model or as detailed documentation which can guide those who wish to implement this system.

Logical Design
The logical design is all the functional features of the system chosen for development. During logical design, the “look and feel” of all system input and output as well as interfaces and dialogues are defined. It includes the following step:

Physical Design
Once the overall high-level design of the system is worked out, and then begins the turning of all the logical specifications into physical design. This physical design consist of various part of system which perform the physical operations necessary to facilitate data handling, processing and information output. This can be done in many ways, from creating a working model of system to be implemented, to writing detailed specification describing all the different parts of the system and how they should be build. In many cases, the working model becomes the basis for the actual system to be used. During physical design, we must determine many of the physical aspects of the system which is from the programming language until the single data capture within the system.

Design phase – the phase of the SDLC in which the system and programs are designed
Design and integrate the Network
Design the Application Architecture
Design the User interfaces
Design the system interfaces
Design the integrate the database
Prototype for Design Details
Design and integrate the System Controls

Good Disign
'Design' could refer to many things, but often refers to 'functional design' or 'internal design'. Good internal design is indicated by software code whose overall structure is clear, understandable, easily modifiable, and maintainable; is robust with sufficient error-handling and status logging capability; and works correctly when implemented. Good functional design is indicated by an application whose functionality can be traced back to customer and end-user requirements. For programs that have a user interface, it's often a good idea to assume that the end user will have little computer knowledge and may not read a user manual or even the on-line help; some common rules-of-thumb include:
the program should act in a way that least surprises the user
it should always be evident to the user what can be done next and how to exit
the program shouldn't let the users do something stupid without warning them

Project planning
Effective management of a software project depends on thoroughly planning the progress of the priject .The project manager must anticipate problems which might arise and prepare tentative solutions to those problems. Aplan, drawn up at the start of a project, should be used as the driver for the project. This intial plan is not static but must be modified as the project progresses and better information becomes available.
Quality plan- Describes the quality procedures and standards that will be used in a Project

Validation plan - Describes the approach, resources And schedule used for system Validation

Configuration management plan- Describes the configuration Management procedures and structures to be used

Maintenance plan- Predicts the maintenance requirements of the system maintenance costs and effort required

Staff development plan- describes how the skills and experience of the project team members will be developed

Project planning is probably the activity that takes most management time planning is required for development activities from specification through to delivery of the system. Organization must, of course, have longer-term business and strategic plans these will be used to guide choices on which projects have the highest priority and to assess whether or not software systems are needs.

Testing
Testing involves operation of a system or application under controlled conditions and evaluating the results (eg, 'if the user is in interface A of the application while using hardware B, and does C, then D should happen'). The controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn't or things don't happen when they should. It is oriented to 'detection'.
Organizations vary considerably in how they assign responsibility for QA and testing. Sometimes they're the combined responsibility of one group or individual. Also common are project teams that include a mix of testers and developers who work closely together, with overall QA processes monitored by project managers. It will depend on what best fits an organization's size and business structure.

kinds of testing
Black box testing - not based on any knowledge of internal design or code. Tests are based on requirements and functionality.

White box testing - based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths, conditions.

Unit testing - the most 'micro' scale of testing; to test particular functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses.

Incremental integration testing - continuous testing of an application as new functionality is added; requires that various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed; done by programmers or by testers.

Integration testing - testing of combined parts of an application to determine if they function together correctly. The 'parts' can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.

Functional testing - black-box type testing geared to functional requirements of an application; this type of testing should be done by testers. This doesn't mean that the programmers shouldn't check that their code works before releasing it (which of course applies to any stage of testing.)

System testing - black-box type testing that is based on overall requirements specifications; covers all combined parts of a system.

End-to-end testing - similar to system testing; the 'macro' end of the test scale; involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

Sanity testing or smoke testing - typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or corrupting databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state.

Regression testing - re-testing after fixes or modifications of the software or its environment. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Automated testing tools can be especially useful for this type of testing.

Acceptance testing - final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.

Load testing - testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system's response time degrades or fails.

Stress testing - term often used interchangeably with 'load' and 'performance' testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.

Performance testing - term often used interchangeably with 'stress' and 'load' testing. Ideally 'performance' testing (and any other 'type' of testing) is defined in requirements documentation or QA or Test Plans.

Usability testing - testing for 'user-friendliness'. Clearly this is subjective, and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.

Install/uninstall testing - testing of full, partial, or upgrade install/uninstall processes.

Recovery testing - testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

Failover testing - typically used interchangeably with 'recovery testing'

Security testing - testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques.

Compatability testing - testing how well software performs in a particular hardware/software/operating system/network/etc. environment.

Exploratory testing - often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it.

Ad-hoc testing - similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it.

Context-driven testing - testing driven by an understanding of the environment, culture, and intended use of software. For example, the testing approach for life-critical medical equipment software would be completely different than that for a low-cost computer game.

User acceptance testing - determining if software is satisfactory to an end-user or customer.

Comparison testing - comparing software weaknesses and strengths to competing products.

Alpha testing - testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.

Beta testing - testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers.

Mutation testing - a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes ('bugs') and retesting with the original test data/cases to determine if the 'bugs' are detected. Proper implementation requires large computational resources.

A sample testing cycle
there is a typical cycle for testing:
Requirements analysis: Testing should begin in the requirements phase of the Soft development life cycle During the design phase, testers work with developers in determining what aspects of a design are testable and with what parameters those tests work.

Test planning: Test strategy, test plan test bed creation. A lot of activities will be carried out during testing, so that a plan is needed.

Test development: Test procedures, test, test cases, test scripts to use in testing software.

Test execution: Testers execute the software based on the plans and tests and report any errors found to the development team.

Test reporting: Once testing is completed, testers generate metrics and make final reports on their test effort and whether or not the software tested is ready for release.
Test result analysis: Or Defect Analysis, is done by the development team usually along with the client, in order to decide what defects should be treated, fixed, rejected (i.e. found software working properly) or deferred to be dealt with at a later time. .

Coding
is the production f machine comprehensible instruction. Techniques used here include
structured programme techniques coding maybe performed in one of 4 types of languages
a) 1st generation languages-machine code i.e.1’s and 0’s
b) 2nd generation languages-simple instruction such as arithmetic function
e.g. assembly language
c) 3rd generation languages-languages which use more English or more scientific constructs
e.g. COMOL,PLI,FORTRAN
d) 4th generation languages-languages which use powerful commands to perform multiple operations
e.g. FOCUS,POWERHOUSE

Documentation
Documentation may refer to the process of providing evidence ("to document something") or to the communicable material used to provide such documentation (i.e. a document). Documentation may also (seldom) refer to tools aiming at identifying documents (see bibliography) or to the field of study devoted to the study of documents and bibliographies (see documentation (field).Subfields of documentation includes. Documentation understood as document is any communicable material (such as text, video, audio, etc., or combinations thereof) used to explain some attributes of an object, system or procedure. It is often used to mean engineering documentation or software documentation, which is usually paper books or computer readable files (such as HTML pages) that describe the structure and components, or on the other hand, operation, of a system/product.
A professional whose field and work is documentation used to be termed a document list. Normally, document lists are trained or have a background in both a specific subject and in the field of documentation (today information science). A person more or less exclusively to write technical documentation is called a technical writer. Technical writers are similarly trained or have a background in technical writing, along with some knowledge of the subject(s) they are documenting. Often, though, they collaborate with subject matter experts (SMEs), such as engineers.

Meeting agenda
An agenda is a list of meeting activities in the order in which they are to be taken up, beginning with the call to order and ending with adjournment. It usually includes one or more specific items of business to be considered. It may, but is not required to, include specific times for one or more activities. The agenda is usually headed with the date, time and location of the meeting, followed by a series of points outlining the order of the meeting.

Points on a typical agenda
Welcome/open meeting
Support for absence
Approve minutes of the previous meeting
Matters arising from the previous meeting
A list of specific points to be discussed — this section is where the bulk of the discussion in the meeting usually takes place.
Any other business (AOB) — allowing a participant to raise another point for discussion.
Arrange/announce details of next meeting
Close meeting
In purchase order system meetings of deliberative bodies, the agenda may also be known as the orders of the day. The agenda is usually distributed to a meeting's participants prior to the meeting, so that they will be aware of the subjects to be discussed, and are able to prepare for the meeting accordingly. In parliamentary procedure, an agenda is not binding upon an assembly unless its own rules make it so, or unless it has been adopted as the agenda for the meeting by majority vote at the start of the meeting. Otherwise, it is merely for the guidance of the chair. If an agenda is binding upon an assembly, and a specific time is listed for an item, that item cannot be taken up before that time, and must be taken up when that time arrives even if other business is pending. If it is desired to do otherwise, the rules can be suspended for that purpose

Validation
Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walkthroughs, and inspection meetings. Validation typically involves actual testing and takes place after verifications are completed. The term 'IV & V' refers to Independent Verification and Validation.

In common usage, validation is the process of checking if something satisfies a certain criterion. Examples would include checking if a statement is true (validity), if an appliance works as intended, if a computer system is secure, or if computer data are compliant with an open standard. Validation implies one is able to document that a solution or process is correct or is suited for its intended use.
In engineering or as part of quality management system , validation confirms that the needs of an external customer or user of a product, service, or system are met. Verification is usually an internal quality process of determining compliance with a regulation, standard, or specification. An easy way of recalling the difference between validation and verification is that validation is ensuring "you built the right product" and verification is ensuring "you built the product right." Validation is testing to confirm that it satisfies stakeholder or user's needs.
Validation can mean to declare or make legally valid or to prove valid or confirm the validity of data, information, or processes:
By Mr P.Rajamohan

Accessibility keyboard shortcuts

2008-12-07T03:56:00.000+08:00

Right SHIFT for eight seconds - Switch FilterKeys on and off.

Left ALT +left SHIFT +PRINT SCREEN Switch High Contrast on and off.

Left ALT +left SHIFT +NUM LOCK - Switch MouseKeys on and off.

SHIFT five times - Switch StickyKeys on and off.

NUM LOCK for five seconds - Switch ToggleKeys on and off.

.

Software Quality Assurance part1

2008-12-06T22:00:00.000+08:00

What is 'Software Quality Assurance'?
Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with.

What is 'Software Testing'?
Testing involves operation of a system or application under controlled conditions and evaluating the results (eg, 'if the user is in interface A of the application while using hardware B, and does C, then D should happen'). The controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn't or things don't happen when they should. It is oriented to 'detection'. Organizations vary considerably in how they assign responsibility for QA and testing. Sometimes they're the combined responsibility of one group or individual. Also common are project teams that include a mix of testers and developers who work closely together, with overall QA processes monitored by project managers. It will depend on what best fits an organization's size and business structure.

What are some recent major computer system failures caused by software bugs?
Software problems in the automated baggage sorting system of a major airport in February 2008 prevented thousands of passengers from checking baggage for their flights. It was reported that the breakdown occurred during a software upgrade, despite pre-testing of the software. The system continued to have problems in subsequent months.

News reports in December of 2007 indicated that significant software problems were continuing to occur in a new ERP payroll system for a large urban school system. It was believed that more than one third of employees had received incorrect paychecks at various times since the new system went live the preceding January, resulting in overpayments of $53 million, as well as underpayments. An employees' union brought a lawsuit against the school system, the cost of the ERP system was expected to rise by 40%, and the non-payroll part of the ERP system was delayed. Inadequate testing reportedly contributed to the problems.

In November of 2007 a regional government reportedly brought a multi-million dollar lawsuit against a software services vendor, claiming that the vendor 'minimized quality' in delivering software for a large criminal justice information system and the system did not meet requirements. The vendor also sued its subcontractor on the project.

In June of 2007 news reports claimed that software flaws in a popular online stock-picking contest could be used to gain an unfair advantage in pursuit of the game's large cash prizes. Outside investigators were called in and in July the contest winner was announced. Reportedly the winner had previously been in 6th place, indicating that the top 5 contestants may have been disqualified.

A software problem contributed to a rail car fire in a major underground metro system in April of 2007 according to newspaper accounts. The software reportedly failed to perform as expected in detecting and preventing excess power usage in equipment on a new passenger rail car, resulting in overheating and fire in the rail car, and evacuation and shutdown of part of the system.

Tens of thousands of medical devices were recalled in March of 2007 to correct a software bug. According to news reports, the software would not reliably indicate when available power to the device was too low.

September 2006 news report indicated problems with software utilized in a state government's primary election, resulting in periodic unexpected rebooting of voter checkin machines, which were separate from the electronic voting machines, and resulted in confusion and delays at voting sites. The problem was reportedly due to insufficient testing.

In August of 2006 a U.S. government student loan service erroneously made public the personal data of as many as 21,000 borrowers on it's web site, due to a software error. The bug was fixed and the government department subsequently offered to arrange for free credit monitoring services for those affected.

A software error reportedly resulted in overbilling of up to several thousand dollars to each of 11,000 customers of a major telecommunications company in June of 2006. It was reported that the software bug was fixed within days, but that correcting the billing errors would take much longer.

News reports in May of 2006 described a multi-million dollar lawsuit settlement paid by a healthcare software vendor to one of its customers. It was reported that the customer claimed there were problems with the software they had contracted for, including poor integration of software modules, and problems that resulted in missing or incorrect data used by medical personnel.

In early 2006 problems in a government's financial monitoring software resulted in incorrect election candidate financial reports being made available to the public. The government's election finance reporting web site had to be shut down until the software was repaired.
Trading on a major Asian stock exchange was brought to a halt in November of 2005, reportedly due to an error in a system software upgrade. The problem was rectified and trading resumed later the same day.

May 2005 newspaper article reported that a major hybrid car manufacturer had to install a software fix on 20,000 vehicles due to problems with invalid engine warning lights and occasional stalling. In the article, an automotive software specialist indicated that the automobile industry spends $2 billion to $3 billion per year fixing software problems.
Media reports in January of 2005 detailed severe problems with a $170 million high-profile U.S. government IT systems project. Software testing was one of the five major problem areas according to a report of the commission reviewing the project. In March of 2005 it was decided to scrap the entire project.

In July 2004 newspapers reported that a new government welfare management system in Canada costing several hundred million dollars was unable to handle a simple benefits rate increase after being put into live operation. Reportedly the original contract allowed for only 6 weeks of acceptance testing and the system was never tested for its ability to handle a rate increase.

Millions of bank accounts were impacted by errors due to installation of inadequately tested software code in the transaction processing system of a major North American bank, according to mid-2004 news reports. Articles about the incident stated that it took two weeks to fix all the resulting errors, that additional problems resulted when the incident drew a large number of e-mail phishing attacks against the bank's customers, and that the total cost of the incident could exceed $100 million.

A bug in site management software utilized by companies with a significant percentage of worldwide web traffic was reported in May of 2004. The bug resulted in performance problems for many of the sites simultaneously and required disabling of the software until the bug was fixed.

According to news reports in April of 2004, a software bug was determined to be a major contributor to the 2003 Northeast blackout, the worst power system failure in North American history. The failure involved loss of electrical power to 50 million customers, forced shutdown of 100 power plants, and economic losses estimated at $6 billion. The bug was reportedly in one utility company's vendor-supplied power monitoring and management system, which was unable to correctly handle and report on an unusual confluence of initially localized events. The error was found and corrected after examining millions of lines of code.

In early 2004, news reports revealed the intentional use of a software bug as a counter-espionage tool. According to the report, in the early 1980's one nation surreptitiously allowed a hostile nation's espionage service to steal a version of sophisticated industrial software that had intentionally-added flaws. This eventually resulted in major industrial disruption in the country that used the stolen flawed software.

A major U.S. retailer was reportedly hit with a large government fine in October of 2003 due to web site errors that enabled customers to view one anothers' online orders.
News stories in the fall of 2003 stated that a manufacturing company recalled all their transportation products in order to fix a software problem causing instability in certain circumstances. The company found and reported the bug itself and initiated the recall procedure in which a software upgrade fixed the problems.

In August of 2003 a U.S. court ruled that a lawsuit against a large online brokerage company could proceed; the lawsuit reportedly involved claims that the company was not fixing system problems that sometimes resulted in failed stock trades, based on the experiences of 4 plaintiffs during an 8-month period. A previous lower court's ruling that "...six miscues out of more than 400 trades does not indicate negligence." was invalidated.

In April of 2003 it was announced that a large student loan company in the U.S. made a software error in calculating the monthly payments on 800,000 loans. Although borrowers were to be notified of an increase in their required payments, the company will still reportedly lose $8 million in interest. The error was uncovered when borrowers began reporting inconsistencies in their bills.

News reports in February of 2003 revealed that the U.S. Treasury Department mailed 50,000 Social Security checks without any beneficiary names. A spokesperson indicated that the missing names were due to an error in a software change. Replacement checks were subsequently mailed out with the problem corrected, and recipients were then able to cash their Social Security checks.

In March of 2002 it was reported that software bugs in Britain's national tax system resulted in more than 100,000 erroneous tax overcharges. The problem was partly attributed to the difficulty of testing the integration of multiple systems.

A newspaper columnist reported in July 2001 that a serious flaw was found in off-the-shelf software that had long been used in systems for tracking certain U.S. nuclear materials. The same software had been recently donated to another country to be used in tracking their own nuclear materials, and it was not until scientists in that country discovered the problem, and shared the information, that U.S. officials became aware of the problems.

According to newspaper stories in mid-2001, a major systems development contractor was fired and sued over problems with a large retirement plan management system. According to the reports, the client claimed that system deliveries were late, the software had excessive defects, and it caused other systems to crash.

In January of 2001 newspapers reported that a major European railroad was hit by the aftereffects of the Y2K bug. The company found that many of their newer trains would not run due to their inability to recognize the date '31/12/2000'; the trains were started by altering the control system's date settings.

News reports in September of 2000 told of a software vendor settling a lawsuit with a large mortgage lender; the vendor had reportedly delivered an online mortgage processing system that did not meet specifications, was delivered late, and didn't work.

In early 2000, major problems were reported with a new computer system in a large suburban U.S. public school district with 100,000+ students; problems included 10,000 erroneous report cards and students left stranded by failed class registration systems; the district's CIO was fired. The school district decided to reinstate it's original 25-year old system for at least a year until the bugs were worked out of the new system by the software vendors.
A review board concluded that the NASA Mars Polar Lander failed in December 1999 due to software problems that caused improper functioning of retro rockets utilized by the Lander as it entered the Martian atmosphere.

In October of 1999 the $125 million NASA Mars Climate Orbiter spacecraft was believed to be lost in space due to a simple data conversion error. It was determined that spacecraft software used certain data in English units that should have been in metric units. Among other tasks, the orbiter was to serve as a communications relay for the Mars Polar Lander mission, which failed for unknown reasons in December 1999. Several investigating panels were convened to determine the process failures that allowed the error to go undetected.

Bugs in software supporting a large commercial high-speed data network affected 70,000 business customers over a period of 8 days in August of 1999. Among those affected was the electronic trading system of the largest U.S. futures exchange, which was shut down for most of a week as a result of the outages.

In April of 1999 a software bug caused the failure of a $1.2 billion U.S. military satellite launch, the costliest unmanned accident in the history of Cape Canaveral launches. The failure was the latest in a string of launch failures, triggering a complete military and industry review of U.S. space launch programs, including software integration and testing processes. Congressional oversight hearings were requested.

A small town in Illinois in the U.S. received an unusually large monthly electric bill of $7 million in March of 1999. This was about 700 times larger than its normal bill. It turned out to be due to bugs in new software that had been purchased by the local power company to deal with Y2K software issues.

In early 1999 a major computer game company recalled all copies of a popular new product due to software problems. The company made a public apology for releasing a product before it was ready.

The computer system of a major online U.S. stock trading service failed during trading hours several times over a period of days in February of 1999 according to nationwide news reports. The problem was reportedly due to bugs in a software upgrade intended to speed online trade confirmations.

In April of 1998 a major U.S. data communications network failed for 24 hours, crippling a large part of some U.S. credit card transaction authorization systems as well as other large U.S. bank, retail, and government data systems. The cause was eventually traced to a software bug.
January 1998 news reports told of software problems at a major U.S. telecommunications company that resulted in no charges for long distance calls for a month for 400,000 customers. The problem went undetected until customers called up with questions about their bills.
In November of 1997 the stock of a major health industry company dropped 60% due to reports of failures in computer billing systems, problems with a large database conversion, and inadequate software testing. It was reported that more than $100,000,000 in receivables had to be written off and that multi-million dollar fines were levied on the company by government agencies.

A retail store chain filed suit in August of 1997 against a transaction processing system vendor (not a credit card company) due to the software's inability to handle credit cards with year 2000 expiration dates.
In August of 1997 one of the leading consumer credit reporting companies reportedly shut down their new public web site after less than two days of operation due to software problems. The new site allowed web site visitors instant access, for a small fee, to their personal credit reports. However, a number of initial users ended up viewing each others' reports instead of their own, resulting in irate customers and nationwide publicity. The problem was attributed to "...unexpectedly high demand from consumers and faulty software that routed the files to the wrong computers."

In November of 1996, newspapers reported that software bugs caused the 411 telephone information system of one of the U.S. RBOC's to fail for most of a day. Most of the 2000 operators had to search through phone books instead of using their 13,000,000-listing database. The bugs were introduced by new software modifications and the problem software had been installed on both the production and backup systems. A spokesman for the software vendor reportedly stated that 'It had nothing to do with the integrity of the software. It was human error.'

On June 4 1996 the first flight of the European Space Agency's new Ariane 5 rocket failed shortly after launching, resulting in an estimated uninsured loss of a half billion dollars. It was reportedly due to the lack of exception handling of a floating-point error in a conversion from a 64-bit integer to a 16-bit signed integer.

Software bugs caused the bank accounts of 823 customers of a major U.S. bank to be credited with $924,844,208.32 each in May of 1996, according to newspaper reports. The American Bankers Association claimed it was the largest such error in banking history. A bank spokesman said the programming errors were corrected and all funds were recovered.

On January 1 1984 all computers produced by one of the leading minicomputer makers of the time reportedly failed worldwide. The cause was claimed to be a leap year bug in a date handling function utilized in deletion of temporary operating system files. Technicians throughout the world worked for several days to clear up the problem. It was also reported that the same bug affected many of the same computers four years later.

Software bugs in a Soviet early-warning monitoring system nearly brought on nuclear war in 1983, according to news reports in early 1999. The software was supposed to filter out false missile detections caused by Soviet satellites picking up sunlight reflections off cloud-tops, but failed to do so. Disaster was averted when a Soviet commander, based on what he said was a '...funny feeling in my gut', decided the apparent missile attack was a false alarm. The filtering software code was rewritten.

Does every software project need testers? While all projects will benefit from testing, some projects may not require independent test staff to succeed.

Which projects may not need independent test staff?
The answer depends on the size and context of the project, the risks, the development methodology, the skill and experience of the developers, and other factors. For instance, if the project is a short-term, small, low risk project, with highly experienced programmers utilizing thorough unit testing or test-first development, then test engineers may not be required for the project to succeed.

In some cases an IT organization may be too small or new to have a testing staff even if the situation calls for it. In these circumstances it may be appropriate to instead use contractors or outsourcing, or adjust the project management and development approach (by switching to more senior developers and agile test-first development, for example). Inexperienced managers sometimes gamble on the success of a project by skipping thorough testing or having programmers do post-development functional testing of their own work, a decidedly high risk gamble.

For non-trivial-size projects or projects with non-trivial risks, a testing staff is usually necessary. As in any business, the use of personnel with specialized skills enhances an organization's ability to be successful in large, complex, or difficult tasks. It allows for both a) deeper and stronger skills and b) the contribution of differing perspectives. For example, programmers typically have the perspective of 'what are the technical issues in making this functionality work?'. A test engineer typically has the perspective of 'what might go wrong with this functionality, and how can we ensure it meets expectations?'. Technical people who can be highly effective in approaching tasks from both of those perspectives are rare, which is why, sooner or later, organizations bring in test specialists.

Why does software have bugs?
miscommunication or no communication - as to specifics of what an application should or shouldn't do (the application's requirements).

software complexity - the complexity of current software applications can be difficult to comprehend for anyone without experience in modern-day software development. Multi-tier distributed systems, applications utilizing mutliple local and remote web services applications, data communications, enormous relational databases, security complexities, and sheer size of applications have all contributed to the exponential growth in software/system complexity.
programming errors - programmers, like anyone else, can make mistakes.

changing requirements (whether documented or undocumented) - the end-user may not understand the effects of changes, or may understand and request them anyway - redesign, rescheduling of engineers, effects on other projects, work already completed that may have to be redone or thrown out, hardware requirements that may be affected, etc. If there are many minor changes or any major changes, known and unknown dependencies among parts of the project are likely to interact and cause problems, and the complexity of coordinating changes may result in errors. Enthusiasm of engineering staff may be affected. In some fast-changing business environments, continuously modified requirements may be a fact of life. In this case, management must understand the resulting risks, and QA and test engineers must adapt and plan for continuous extensive testing to keep the inevitable bugs from running out of control
time pressures - scheduling of software projects is difficult at best, often requiring a lot of guesswork. When deadlines loom and the crunch comes, mistakes will be made.

egos - people prefer to say things like:
'no problem'
'piece of cake'
'I can whip that out in a few hours'
'it should be easy to update that old code'

instead of:
that adds a lot of complexity and we could end up
making a lot of mistakes'
'we have no idea if we can do that; we'll wing it'
'I can't estimate how long it will take, until I
take a close look at it'
'we can't figure out what that old spaghetti code
did in the first place'
If there are too many unrealistic 'no problem's', the
result is bugs.

poorly documented code - it's tough to maintain and modify code that is badly written or poorly documented; the result is bugs. In many organizations management provides no incentive for programmers to document their code or write clear, understandable, maintainable code. In fact, it's usually the opposite: they get points mostly for quickly turning out code, and there's job security if nobody else can understand it ('if it was hard to write, it should be hard to read').
software development tools - visual tools, class libraries, compilers, scripting tools, etc. often introduce their own bugs or are poorly documented, resulting in added bugs.

How can new Software QA processes be introduced in an existing organization?
A lot depends on the size of the organization and the risks involved. For large organizations with high-risk (in terms of lives or property) projects, serious management buy-in is required and a formalized QA process is necessary.

Where the risk is lower, management and organizational buy-in and QA implementation may be a slower, step-at-a-time process. QA processes should be balanced with productivity so as to keep bureaucracy from getting out of hand.

For small groups or projects, a more ad-hoc process may be appropriate, depending on the type of customers and projects. A lot will depend on team leads or managers, feedback to developers, and ensuring adequate communications among customers, managers, developers, and testers.

The most value for effort will often be in (a) requirements management processes, with a goal of clear, complete, testable requirement specifications embodied in requirements or design documentation, or in 'agile'-type environments extensive continuous coordination with end-users, (b) design inspections and code inspections, and (c) post-mortems/retrospectives.
Other possibilities include incremental self-managed team approaches such as 'Kaizen' methods of continuous process improvement, the Deming-Shewhart Plan-Do-Check-Act cycle, and others

What is verification? validation?
Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walkthroughs, and inspection meetings. Validation typically involves actual testing and takes place after verifications are completed. The term 'IV & V' refers to Independent Verification and Validation.
What is a 'walkthrough'? A 'walkthrough' is an informal meeting for evaluation or informational purposes. Little or no preparation is usually required.

What's an 'inspection'?
An inspection is more formalized than a 'walkthrough', typically with 3-8 people including a moderator, reader, and a recorder to take notes. The subject of the inspection is typically a document such as a requirements spec or a test plan, and the purpose is to find problems and see what's missing, not to fix anything. Attendees should prepare for this type of meeting by reading thru the document; most problems will be found during this preparation. The result of the inspection meeting should be a written report. Thorough preparation for inspections is difficult, painstaking work, but is one of the most cost effective methods of ensuring quality. Employees who are most skilled at inspections are like the 'eldest brother' in the parable in why is it often hard for organizations to get serious about quality assurance? Their skill may have low visibility but they are extremely valuable to any software development organization, since bug prevention is far more cost-effective than bug detection.

What kinds of testing should be considered?
Black box testing - not based on any knowledge of internal design or code. Tests are based on requirements and functionality.

White box testing - based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths, conditions.

Unit testing - the most 'micro' scale of testing; to test particular functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses.

Incremental integration testing - continuous testing of an application as new functionality is added; requires that various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed; done by programmers or by testers.

Integration testing - testing of combined parts of an application to determine if they function together correctly. The 'parts' can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.

Functional testing - black-box type testing geared to functional requirements of an application; this type of testing should be done by testers. This doesn't mean that the programmers shouldn't check that their code works before releasing it (which of course applies to any stage of testing.)

System testing - black-box type testing that is based on overall requirements specifications; covers all combined parts of a system.

End-to-end testing - similar to system testing; the 'macro' end of the test scale; involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

Sanity testing or smoke testing - typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or corrupting databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state.

Regression testing - re-testing after fixes or modifications of the software or its environment. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Automated testing tools can be especially useful for this type of testing.

Acceptance testing - final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.

Load testing - testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system's response time degrades or fails.

Stress testing - term often used interchangeably with 'load' and 'performance' testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.

Performance testing - term often used interchangeably with 'stress' and 'load' testing. Ideally 'performance' testing (and any other 'type' of testing) is defined in requirements documentation or QA or Test Plans.

Usability testing - testing for 'user-friendliness'. Clearly this is subjective, and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.

Install/uninstall testing - testing of full, partial, or upgrade install/uninstall processes.

Recovery testing - testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

Failover testing - typically used interchangeably with 'recovery testing'

Security testing - testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques.

Compatability testing - testing how well software performs in a particular hardware/software/operating system/network/etc. environment.

Exploratory testing - often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it.

Ad-hoc testing - similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it.

Context-driven testing - testing driven by an understanding of the environment, culture, and intended use of software. For example, the testing approach for life-critical medical equipment software would be completely different than that for a low-cost computer game.

User acceptance testing - determining if software is satisfactory to an end-user or customer.

Comparison testing - comparing software weaknesses and strengths to competing products.

Alpha testing - testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.

Beta testing - testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers.

Mutation testing - a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes ('bugs') and retesting with the original test data/cases to determine if the 'bugs' are detected. Proper implementation requires large computational resources.

What are 5 common problems in the software development process?
Poor requirements - if requirements are unclear, incomplete, too general, and not testable, there will be problems.

Unrealistic schedule - if too much work is crammed in too little time, problems are inevitable.
Inadequate testing - no one will know whether or not the program is any good until the customer complains or systems crash.

Featuritis - requests to pile on new features after development is underway; extremely common.
Miscommunication - if developers don't know what's needed or customer's have erroneous expectations, problems can be expected

What are 5 common solutions to software development problems?
Solid requirements - clear, complete, detailed, cohesive, attainable, testable requirements that are agreed to by all players. In 'agile'-type environments, continuous close coordination with customers/end-users is necessary to ensure that changing/emerging requirements are understood.

Realistic schedules - allow adequate time for planning, design, testing, bug fixing, re-testing, changes, and documentation; personnel should be able to complete the project without burning out.

Adequate testing - start testing early on, re-test after fixes or changes, plan for adequate time for testing and bug-fixing. 'Early' testing could include static code analysis/testing, test-first development, unit testing by developers, built-in testing and diagnostic capabilities, automated post-build testing, etc.

Stick to initial requirements where feasible - be prepared to defend against excessive changes and additions once development has begun, and be prepared to explain consequences. If changes are necessary, they should be adequately reflected in related schedule changes. If possible, work closely with customers/end-users to manage expectations. In 'agile'-type environments, initial requirements may be expected to change significantly, requiring that true agile processes be in place.

Communication - require walkthroughs and inspections when appropriate; make extensive use of group communication tools - groupware, wiki's, bug-tracking tools and change management tools, intranet capabilities, etc.; ensure that information/documentation is available and up-to-date - preferably electronic, not paper; promote teamwork and cooperation; use protoypes and/or continuous communication with end-users if possible to clarify expectations.

What is software 'quality'?
Quality software is reasonably bug-free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable. However, quality is obviously a subjective term. It will depend on who the 'customer' is and their overall influence in the scheme of things. A wide-angle view of the 'customers' of a software development project might include end-users, customer acceptance testers, customer contract officers, customer management, the development organization's management/accountants/testers/salespeople, future software maintenance engineers, stockholders, magazine columnists, etc.
Each type of 'customer' will have their own slant on 'quality' - the accounting department might define quality in terms of profits while an end-user might define quality as user-friendly and bug-free.

What is 'good code'?
'Good code' is code that works, is reasonably bug free, and is readable and maintainable. Some organizations have coding 'standards' that all developers are supposed to adhere to, but everyone has different ideas about what's best, or what is too many or too few rules. There are also various theories and metrics, such as McCabe Complexity metrics. It should be kept in mind that excessive use of standards and rules can stifle productivity and creativity. 'Peer reviews', 'buddy checks' pair programming, code analysis tools, etc. can be used to check for problems and enforce standards. For example, in C/C++ coding, here are some typical ideas to consider in setting rules/standards; these may or may not apply to a particular situation:
minimize or eliminate use of global variables.

use descriptive function and method names - use both upper and lower case, avoid abbreviations, use as many characters as necessary to be adequately descriptive (use of more than 20 characters is not out of line); be consistent in naming conventions.
use descriptive variable names - use both upper and lower case, avoid abbreviations, use as many characters as necessary to be adequately descriptive (use of more than 20 characters is not out of line); be consistent in naming conventions.
function and method sizes should be minimized; less than 100 lines of code is good, less than 50 lines is preferable.

function descriptions should be clearly spelled out in comments preceding a function's code.
organize code for readability.
use whitespace generously - vertically and horizontally
each line of code should contain 70 characters max.
one code statement per line.

coding style should be consistent throught a program (eg, use of brackets, indentations, naming conventions, etc.)
in adding comments, err on the side of too many rather than too few comments; a common rule of thumb is that there should be at least as many lines of comments (including header blocks) as lines of code.

no matter how small, an application should include documentaion of the overall program function and flow (even a few paragraphs is better than nothing); or if possible a separate flow chart and detailed program documentation.

make extensive use of error handling procedures and status and error logging.
for C++, to minimize complexity and increase maintainability, avoid too many levels of inheritance in class heirarchies (relative to the size and complexity of the application). Minimize use of multiple inheritance, and minimize use of operator overloading (note that the Java programming language eliminates multiple inheritance and operator overloading.)
for C++, keep class methods small, less than 50 lines of code per method is preferable.
for C++, make liberal use of exception handlers

What is 'good design'?
'Design' could refer to many things, but often refers to 'functional design' or 'internal design'. Good internal design is indicated by software code whose overall structure is clear, understandable, easily modifiable, and maintainable; is robust with sufficient error-handling and status logging capability; and works correctly when implemented. Good functional design is indicated by an application whose functionality can be traced back to customer and end-user requirements. For programs that have a user interface, it's often a good idea to assume that the end user will have little computer knowledge and may not read a user manual or even the on-line help; some common rules-of-thumb include:
the program should act in a way that least surprises the user
it should always be evident to the user what can be done next and how to exit
the program shouldn't let the users do something stupid without warning them.

What is SEI? CMM? CMMI? ISO? IEEE? ANSI? Will it help?
SEI = 'Software Engineering Institute' at Carnegie-Mellon University; initiated by the U.S. Defense Department to help improve software development processes.

CMM = 'Capability Maturity Model', now called the CMMI ('Capability Maturity Model Integration'), developed by the SEI. It's a model of 5 levels of process 'maturity' that determine effectiveness in delivering quality software. It is geared to large organizations such as large U.S. Defense Department contractors. However, many of the QA processes involved are appropriate to any organization, and if reasonably applied can be helpful. Organizations can receive CMMI ratings by undergoing assessments by qualified auditors.

Level 1 - characterized by chaos, periodic panics, and heroic
efforts required by individuals to successfully
complete projects. Few if any processes in place;
successes may not be repeatable.

Level 2 - software project tracking, requirements management,
realistic planning, and configuration management
processes are in place; successful practices can
be repeated.

Level 3 - standard software development and maintenance processes
are integrated throughout an organization; a Software
Engineering Process Group is is in place to oversee
software processes, and training programs are used to
ensure understanding and compliance.

Level 4 - metrics are used to track productivity, processes,
and products. Project performance is predictable,
and quality is consistently high.

Level 5 - the focus is on continouous process improvement. The
impact of new processes and technologies can be
predicted and effectively implemented when required.

Perspective on CMM ratings: During 1997-2001, 1018 organizations
were assessed. Of those, 27% were rated at Level 1, 39% at 2,
23% at 3, 6% at 4, and 5% at 5. (For ratings during the period
1992-96, 62% were at Level 1, 23% at 2, 13% at 3, 2% at 4, and
0.4% at 5.) The median size of organizations was 100 software
engineering/maintenance personnel; 32% of organizations were
U.S. federal contractors or agencies. For those rated at
Level 1, the most problematical key process area was in
Software Quality Assurance.

ISO = 'International Organisation for Standardization' - The ISO 9001:2000 standard (which replaces the previous standard of 1994) concerns quality systems that are assessed by outside auditors, and it applies to many kinds of production and manufacturing organizations, not just software. It covers documentation, design, development, production, testing, installation, servicing, and other processes. The full set of standards consists of: (a)Q9001-2000 - Quality Management Systems: Requirements; (b)Q9000-2000 - Quality Management Systems: Fundamentals and Vocabulary; (c)Q9004-2000 - Quality Management Systems: Guidelines for Performance Improvements. To be ISO 9001 certified, a third-party auditor assesses an organization, and certification is typically good for about 3 years, after which a complete reassessment is required.
ISO 9126 defines six high level quality characteristics that can be used in software evaluation. It includes functionality, reliability, usability, efficiency, maintainability, and portability.

IEEE = 'Institute of Electrical and Electronics Engineers' - among other things, creates standards such as 'IEEE Standard for Software Test Documentation' (IEEE/ANSI Standard 829), 'IEEE Standard of Software Unit Testing (IEEE/ANSI Standard 1008), 'IEEE Standard for Software Quality Assurance Plans' (IEEE/ANSI Standard 730), and others.

ANSI = 'American National Standards Institute', the primary industrial standards body in the U.S.; publishes some software-related standards in conjunction with the IEEE and ASQ (American Society for Quality).
Other software development/IT management process assessment methods besides CMMI and ISO 9000 include SPICE, Trillium, TickIT, Bootstrap, ITIL, MOF, and CobiT..
What is the 'software life cycle'? The life cycle begins when an application is first conceived and ends when it is no longer in use. It includes aspects such as initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, retesting, phase-out, and other aspects.
BY : MR P.RAJAMOHAN

Software Quality Assurance part2

2008-12-06T02:04:00.000+08:00

Quality
Quality software is reasonably bug-free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable. However, quality is obviously a subjective term. It will depend on who the 'customer' is and their overall influence in the scheme of things. A wide-angle view of the 'customers' of a software development project might include end-users, customer acceptance testers, customer contract officers, customer management, the development organization's management/accountants/testers/salespeople, future software maintenance engineers, stockholders, magazine columnists, etc

A Software Quality Assurance Engineer is involved in the entire software development process to ensure the quality of the final product. This can include processes such as requirements gathering and documentation, source code control, code review, change management, configuration management, release management and the actual testing of the software. Software QA is often confused with Software Testing but should not be. Testing is a big part of Software Quality Assurance, but it is not, by any means, the only part of it.

Becoming a Software Quality Assurance Engineer
Software QA Engineers must be familiar with the entire SDLC in order to be effective. They may start out as Software Engineers or as Testing Engineers. They should have strong communication skills, be good at documenting their work, and must be able to work well with different groups. They often become the middle person between the Developers and the Customers, so they need to be able to understand, and convey, both viewpoints

Software Quality Assurance Engineer Career Path
A Software Quality Assurance Engineer usually starts out as either a Developer or a Testing Engineer. As they become more proficient as Software QA Engineers, they may more on to more complicated projects with more complex code. They make take on more responsibility for the process, being promoted to Senior Software Quality Engineers and eventually on to a Software QA Manager role.

Quality Assurance and Software Testing Certification
When we think of IT (Information Technology) we tend to focus on development, network and database issues. It's easy to forget that before sending work out to the user there is a crucial middleman. That person or team is Quality Assurance.
QA comes in many forms, from the developer who tests her own code, to the testing gurus who work with automated testing tools. Many vendors and groups have recognized testing as an integral part of the development and maintenance process and have developed certifications to standardize and demonstrate knowledge of the QA process and testing tools.
Vendors who offer Testing Certifications:
· Mercury
· Segue
· Rational
· Empirix

Vendor-Neutral Testing Certifications:
Certified Software Quality Analyst (CSQA)
Certified Software Test Engineer (CSTE)
ISTQB Certified Tester, Foundation Level (CTFL)
Quality improment associte certification(CQIA)
Certified Test Manager (CTM)
Certified Software Test Professional (CSTP)
Six Sigma Black Belt Certification (SSBB).

Although this list is short, the links above go to sites that offer more niche certifications for you to research. Those listed here are respected in IT and are a must-have for anyone considering an entry into the world of testing and Quality Assurance. For additional information and links regarding testing certifications, visit the Testing Certifications Subject on this site.

Software Test Engineer
A Software Test Engineer is involved in the testing of software and is generally a member of the software quality assurance team. Software QA Engineers may test software, but are not always expert Test Engineers.

There are two main types of testing, which are white box testing and black box testing. The differences between the two are based on the assumptions and the view points taken by the testers while performing the tests. White box testing assumes an internal view of the software and black box testing basically assumes an external view of the software.
Testing is done at different phases of the software development life cycle (SDLC) and includes unit testing, integration testing, functional testing, system testing, acceptance testing (often performed by the internal or external client) and regression testing (which is often automated).

Education – Software Test Engineers
Software Testers do not always have Computer Science degree. There are several notable certifications for Software Testing. The top ones are:

Ø American Society for Quality
Ø Quality Assurance International
Ø International Institute for software testing
·
Software Test Engineer Career Path
There are different level of Test Engineers. At an entry level, a testing engineer may set up and document simple test cases. As they become more experienced, Software Test Engineers may set up very complex test case scenarios, write test scripts and perform white box
Ø Companies Hiring Software Test Engineers:
Ø Microsoft Corporation
Ø Sun Microsystems
Ø Cisco Systems
Ø Oracle Corporation
Ø Apple Computers
Ø Google
Beta Software
Definition: beta software: Development copies that are released prior to the full version. They are released to aid debugging of the software and to obtain real world reports of its operation. An expiry date is often built into the software. See alpha software

Beta Test
Definition: When software is nearly completed, the software developers often put out a beta release for testing by the general public. This is to find any small, overlooked problems before marketing the software in stores or online.
During the beta test, people agree to try out the software on their own computers to offer suggestions on improving the software. Some beta tests are open to anyone who wishes to try out the software, but many beta tests are offered to select individuals.
Pronunciation: bay-tah test

Project Manager Overview

PMP - Project Management Professional
A Project Manager is responsible for managing the resources of large projects. For Tech Careers, can mean managing large Software Development projects, Networking projects, IT installations or conversions, or any other function where business and technology needs have to be managed and resources have to be coordinated.
The Project Manager is responsible for making sure a project is completed within a certain set of restraints. These restraints usually involve time, money, people and materials. The project must then be completed to a certain level of quality.
Project Managers usually use Project Management Software to help keep track of resources and project deliverables (or outputs). This software helps document the project objectives, status, time lines and expected outcomes. Current popular project management software products include:
· Microsoft project
· 24seven office
· Omniplan
· At task

Education
Project Managers usually have a degree and several years of experience in their field of expertise. Ideally, a Project Manager will have additional Project Management Training, such as a certification through the Project Management Institute.

Becoming a Project Manager
In Technology Careers, a Project Manager is often promoted from the individual contributor ranks. Most technical companies prefer to hire Project Managers that have worked in a similar technical environment and can appreciate the complexities that are usually involved.
Becoming a project manager can be a good way to take on management responsibilities while staying current in development. Taking classes or becoming certified in project management is a good way to branch into this field.

Project Manager Career Path
There are various levels of Project Management, and differences between the size and scope of projects to manage. A Project Manager may be promoted to larger projects. A good project manager will often, given enough experience, be eligible for promotion to a senior role, such as a Group Manager or a Group Director.
Companies Hiring Technical Project Managers:
· Microsoft Corporation
· Sun Microsystems
· Cisco Systems
· Oracle Corporation
· Apple Computers
· Google
· Intuit
· Adobe
· Amazon.com
· eBay
· Qualcomm
Project Managers are in high demand, especially those with a technical background. Check out the best places to work listings for other great companies to research.

PMP Certification From PMI:
PMI’s PMP credential is designed to demonstrate a strong level of project management leadership skills. In order to be eligible for a PMP credential from PMI, you must meet certain guidelines. These guidelines are designed to measure experience, education and professional knowledge. There is also a four hour exam that you must pass, which is designed to assesses project management skills and knowledge.
In order to be eligible for a PMP certification, you must meet the following guidelines as laid out by the Project Management Institute:

You must have 35 hours of specific project management education.
· If you have a Bachelor’s Degree (or the global equivalent), you must also have a minimum three years’ professional project management experience, during which 4,500 hours are spent leading and directing project tasks, up to eight years from the time of application.

· If you do not have a Bachelor’s Degree (or the global equivalent), you must have a minimum five years’ professional project management experience, during which at least 7,500 hours are spent leading and directing project tasks, up to eight years from the time of application.

PMP - Other Information
Project Manager ProfileCAPM CertificationTech Industry Publications
Description: The American Academy of Project Managers offers three levels of project management certification: PME ™ Project Manager E-Business, CIPM ™ Certified International Project Manager and MPM ™ Master Project Manager. Each of these is targeted towards managers and executives and require graduate degrees and a high level of experience.
Requirements: All three certifications, the PME, CIPM, and MPM require at least three years of verifiable project management experience. In lieu of PM experience, there are several training programs and seminars that are approved by the AAPM to obtain certification.
by Mr P.Rajamohan

Dialog box keyboard shortcuts

2008-12-05T15:47:00.000+08:00

CTRL+TAB - Move forward through tabs.

CTRL+SHIFT+TAB - Move backward through tabs.

TAB - Move forward through options.

SHIFT+TAB - Move backward through options.

ALT+Underlined letter - Carry out the corresponding command or select the corresponding option.

ENTER - Carry out the command for the active option or button.

SPACEBAR - Select or clear the check box if the active option is a check box.

Arrow keys - Select a button if the active option is a group of option buttons.

F1 - Display Help.

F4 - Display the items in the active list.

BACKSPACE - Open a folder one level up if a folder is selected in the Save As or Open dialogbox.

General keyboard shortcuts

2008-12-05T15:42:00.000+08:00

CTRL+C - Copy.

CTRL+X - Cut.

CTRL+V - Paste.

CTRL+Z - Undo.

DELETE - Delete.

SHIFT+DELETE - Delete selected item permanently without placing the item in the Recycle Bin.

CTRL while dragging an item - Copy selected item.

CTRL+SHIFT while dragging an item - Create shortcut to selected item.
F2 Rename selected item.

CTRL+RIGHT ARROW - Move the insertion point to the beginning of the next word.

CTRL+LEFT ARROW - Move the insertion point to the beginning of the previous word.

CTRL+DOWN ARROW - Move the insertion point to the beginning of the next paragraph.

CTRL+UP ARROW - Move the insertion point to the beginning of the previous paragraph.

CTRL+SHIFT with any of the arrow keys - Highlight a block of text.

SHIFT with any of the arrow keys - Select more than one item in a window or on the desktop, or select text within a document.

CTRL+A - Select all.

F3 - Search for a file or folder.

ALT+ENTER - View properties for the selected item.

ALT+F4 - Close the active item, or quit the active program.

ALT+Enter - Displays the properties of the selected object.

ALT+SPACEBAR - Opens the shortcut menu for the active window.

CTRL+F4 - Close the active document in programs that allow you to have
multiple documents open simultaneously.

ALT+TAB - Switch between open items.

ALT+ESC - Cycle through items in the order they were opened.

F6 - Cycle through screen elements in a window or on the desktop.

F4 - Display the Address bar list in My Computer or Windows
Explorer.
SHIFT+F10 - Display the shortcut menu for the selected item.

ALT+SPACEBAR - Display the System menu for the active window.

CTRL+ESC - Display the Start menu.

ALT+Underlined letter in a menuName - Display the corresponding menu.

Underlined letter in a command name
on an open menu - Carry out the corresponding command.

F10 - Activate the menu bar in the active program.

RIGHT ARROW - Open the next menu to the right, or open a submenu.

LEFT ARROW - Open the next menu to the left, or close a submenu

F5 - Refresh the active window.

BACKSPACE - View the folder one level up in My Computer or Windows
Explorer.

ESC - Cancel the current task.

SHIFT when you insert a CD into the CD‐ROM drive - Prevent the CD from automatically playing.

How to Create Keyboard Shortcuts

2008-12-05T11:03:00.000+08:00

In this tutorial I teach you how to create simple and efficient Keyboard shortcuts that can be binded to everyday programs such as Firefox, and Windows Media Player.

1) Create a desktop shortcut if you don't have one already.

2) Right click on it, and select Properties.

3) Make sure you're on the 'Shortcuts' tab, and look for a field labled 'Shortcut Key', make sure that field is activated, and type in your shortcut

4) Click Apply, and OK.

5)Test out your shortcut

Computer Networking

2008-12-04T13:48:00.000+08:00

Computer Networking is a focus within engineering that deals with communication between computer systems or devices. Computer networking is often considered a sub-discipline of a few areas: telecommunications, computer science, information technology and/or computer engineering. Computer networks rely heavily on the theoretical and practical application of each of these engineering disciplines.

A computer network is any set of computers or devices connected to each other with the ability to exchange data. Examples of different networks are:

A Definition of Information Technology

2008-12-04T13:26:00.000+08:00

We use the term information technology or IT to refer to an entire industry. In actuality, information technology is the use of computers and software to manage information. In some companies, this is referred to as Management Information Services (or MIS) or simply as Information Services (or IS). The information technology department of a large company would be responsible for storing information, protecting information, processing the information, transmitting the information as necessary, and later retrieving information as necessary.