appdev_topterms_eguide

Top Application Development Terms Fifteen essential definitions you need to know

of 16

Fifteen Essential Application Development Terms

Contents

PERT chart

Systems development lifecycle (SDLC)

Quality assurance (QA surance (QA)

Use case

Work breakdown structure (WBS)

Regression testing

Sprint (software development)

Reverse engineering

Gantt Chart

Debugging

Software requirements specification (SRS)

Requirements analysis

3-tier application

Unit testing

Collaboration diagram

Application Development Glossary

We know its not always easy to keep up-to-date with the latest application development terms. Thats why we have put together the top fifteen terms and definitions that you and your peers need to know.

What is PERT chart (Program Evaluation Review Technique)? A PERT chart is a project management tool used to schedule, organize, and

coordinate tasks within a project. PERT stands for Program Evaluation

Review Technique, a methodology developed by the U.S. Navy in the 1950s

to manage the Polaris submarine missile program. A similar methodology,

the Critical Path Method (CPM) was developed for project management in

the private sector at about the same time.

of 16


Contents

PERT chart



Use case


Regression testing


Reverse engineering

Gantt Chart

Debugging



3-tier application

Unit testing



A PERT chart presents a graphic illustration of a project as a network

diagram consisting of numbered nodes (either circles or rectangles)

representing events, or milestones in the project linked by labeled vectors

(directional lines) representing tasks in the project. The direction of the

arrows on the lines indicates the sequence of tasks. In the diagram, for

example, the tasks between nodes 1, 2, 4, 8, and 10 must be completed in

sequence. These are called dependent or serial tasks. The tasks between

nodes 1 and 2, and nodes 1 and 3 are not dependent on the completion of

one to start the other and can be undertaken simultaneously. These tasks

are called parallel or concurrent tasks. Tasks that must be completed in

sequence but that don't require resources or completion time are considered

to have event dependency. These are represented by dotted lines with

arrows and are called dummy activities. For example, the dashed arrow

linking nodes 6 and 9 indicates that the system files must be converted

before the user test can take place, but that the resources and time required

to prepare for the user test (writing the user manual and user training) are on

another path. Numbers on the opposite sides of the vectors indicate the time

allotted for the task.

The PERT chart is sometimes preferred over the Gantt chart, another

popular project management charting method, because it clearly illustrates

task dependencies. On the other hand, the PERT chart can be much more

difficult to interpret, especially on complex projects. Frequently, project

managers use both techniques.

What is systems development lifecycle (SDLC)?

The systems development life cycle (SDLC) is a conceptual model used in

project management that describes the stages involved in an information

system development project, from an initial feasibility study through

maintenance of the completed application.

Various SDLC methodologies have been developed to guide the processes

involved, including the waterfall model (which was the original SDLC

method); rapid application development (RAD); joint application development

of 16


Contents

PERT chart



Use case


Regression testing


Reverse engineering

Gantt Chart

Debugging



3-tier application

Unit testing



(JAD); the fountain model; the spiral model; build and fix; and synchronize-

and-stabilize. Frequently, several models are combined into some sort of

hybrid methodology. Documentation is crucial regardless of the type of model

chosen or devised for any application, and is usually done in parallel with the

development process. Some methods work better for specific types of

projects, but in the final analysis, the most important factor for the success of

a project may be how closely the particular plan was followed.

In general, an SDLC methodology follows the following steps:

1. The existing system is evaluated. Deficiencies are identified. This

can be done by interviewing users of the system and consulting with

support personnel.

2. The new system requirements are defined. In particular, the

deficiencies in the existing system must be addressed with specific

proposals for improvement.

3. The proposed system is designed. Plans are laid out concerning the

physical construction, hardware, operating systems, programming,

communications, and security issues.

4. The new system is developed. The new components and programs

must be obtained and installed. Users of the system must be trained

in its use, and all aspects of performance must be tested. If

necessary, adjustments must be made at this stage.

5. The system is put into use. This can be done in various ways. The

new system can phased in, according to application or location, and

the old system gradually replaced. In some cases, it may be more

cost-effective to shut down the old system and implement the new

system all at once.

6. Once the new system is up and running for a while, it should be

exhaustively evaluated. Maintenance must be kept up rigorously at

all times. Users of the system should be kept up-to-date concerning

the latest modifications and procedures.

of 16


Contents

PERT chart



Use case


Regression testing


Reverse engineering

Gantt Chart

Debugging



3-tier application

Unit testing



What is quality assurance (QA)?

In developing products and services, quality assurance is any systematic

process of checking to see whether a product or service being developed is

meeting specified requirements. Many companies have a separate

department devoted to quality assurance. A quality assurance system is said

to increase customer confidence and a company's credibility, to improve

work processes and efficiency, and to enable a company to better compete

with others. Quality assurance was initially introduced in World War II when

munitions were inspected and tested for defects after they were made.

Today's quality assurance systems emphasize catching defects before they

get into the final product.

ISO 9000 is an international standard that many companies use to ensure

that their quality assurance system is in place and effective. Conformance to

ISO 9000 is said to guarantee that a company delivers quality products and

services. To follow ISO 9000, a company's management team decides

quality assurance policies and objectives. Next, the company or an external

consultant formally writes down the company's policies and requirements

and how the staff can implement the quality assurance system. Once this

guideline is in place and the quality assurance procedures are implemented,

an outside assessor examines the company's quality assurance system to

make sure it complies with ISO 9000. A detailed report describes the parts of

the standard the company missed, and the company agrees to correct any

problems within a specific time. Once the problems are corrected, the

company is certified as in conformance with the standard.

What is use case?

A use case is a methodology used in system analysis to identify, clarify, and

organize system requirements. The use case is made up of a set of possible

sequences of interactions between systems and users in a particular

environment and related to a particular goal. It consists of a group of

of 16


Contents

PERT chart



Use case


Regression testing


Reverse engineering

Gantt Chart

Debugging



3-tier application

Unit testing



elements (for example, classes and interfaces) that can be used together in a

way that will have an effect larger than the sum of the separate elements

combined. The use case should contain all system activities that have

significance to the users. A use case can be thought of as a collection of

possible scenarios related to a particular goal, indeed, the use case and goal

are sometimes considered to be synonymous.

A use case (or set of use cases) has these characteristics:

Organizes functional requirements

Models the goals of system/actor (user) interactions

Records paths (called scenarios) from trigger events to goals

Describes one main flow of events (also called a basic course of

action), and possibly other ones, called exceptional flows of events

(also called alternate courses of action)

Is multi-level, so that one use case can use the functionality of

another one.

Use cases can be employed during several stages of software development,

such as planning system requirements, validating design, testing software,

and creating an outline for online help and user manuals.

What is breakdown structure (WBS)? A work breakdown structure (WBS) is a chart in which the critical work

elements, called tasks, of a project are illustrated to portray their

relationships to each other and to the project as a whole. The graphical

nature of the WBS can help a project manager predict outcomes based on

various scenarios, which can ensure that optimum decisions are made about

whether or not to adopt suggested procedures or changes.

When creating a WBS, the project manager defines the key objectives first

and then identifies the tasks required to reach those goals. A WBS takes the

form of a tree diagram with the "trunk" at the top and the "branches" below.

of 16


Contents

PERT chart



Use case


Regression testing


Reverse engineering

Gantt Chart

Debugging



3-tier application

Unit testing



The primary requirement or objective is shown at the top, with increasingly

specific details shown as the observer reads down.

When completed, a well-structured WBS resembles a flowchart in which all

elements are logically connected, redundancy is avoided and no critical

elements are left out. Elements can be rendered as plain text or as text within

boxes. The elements at the bottom of the diagram represent tasks small

enough to be easily understood and carried out. Interactions are shown as

lines connecting the elements. A change in one of the critical elements may

affect one or more of the others. If necessary, these lines can include

arrowheads to indicate time progression or cause-and-effect.

A well-organized, detailed WBS can assist key personnel in the effective

allocation of resources, project budgeting, procurement management,

scheduling, quality assurance, quality control, risk management, product

delivery and service oriented management.

What is regression testing?

Regression testing is the process of testing changes to computer programs

to make sure that the older programming still works with the new changes.

Regression testing is a normal part of the program development process

and, in larger companies, is done by code testing specialists. Test

department coders develop code test scenarios and exercises that will test

new units of code after they have been written. These test cases form what

becomes the test bucket. Before a new version of a software product is

released, the old test cases are run against the new version to make sure

that all the old capabilities still work. The reason they might not work is

because changing or adding new code to a program can easily introduce

errors into code that is not intended to be changed.

of 16


Contents

PERT chart



Use case


Regression testing


Reverse engineering

Gantt Chart

Debugging



3-tier application

Unit testing



What is sprint (software development)?

In product development, a sprint is a set period of time during which specific

work has to be completed and made ready for review.

Each sprint begins with a planning meeting. During the meeting, the product

owner (the person requesting the work) and the development team agree

upon exactly what work will be accomplished during the sprint. The

development team has the final say when it comes to determining how much

work can realistically be accomplished during the sprint, and the product

owner has the final say on what criteria needs to be met for the work to be

approved and accepted.

The duration of a sprint is determined by the scrum master, the team's

facilitator. Once the team reaches a consensus for how many days a sprint

should last, all future sprints should be the same. Traditionally, a sprint lasts

30 days.

After a sprint begins, the product owner must step back and let the team do

their work. During the sprint, the team holds daily stand up meeting to

discuss progress and brainstorm solutions to challenges. The project owner

may attend these meetings as an observer but is not allowed to participate

unless it is to answer questions. (See pigs and chickens). The project owner

may not make requests for changes during a sprint and only the scrum

master or project manager has the power to interrupt or stop the sprint.

At the end of the sprint, the team presents its completed work to the project

owner and the project owner uses the criteria established at the sprint

planning meeting to either accept or reject the work.

What is reverse engineering?

Reverse engineering is taking apart an object to see how it works in order to

duplicate or enhance the object. The practice, taken from older industries, is

now frequently used on computer hardware and software. Software reverse

engineering involves reversing a program's machine code (the string of 0s

of 16


Contents

PERT chart



Use case


Regression testing


Reverse engineering

Gantt Chart

Debugging



3-tier application

Unit testing



and 1s that are sent to the logic processor) back into the source code that it

was written in, using program language statements.

Software reverse engineering is done to retrieve the source code of a

program because the source code was lost, to study how the program

performs certain operations, to improve the performance of a program, to fix

a bug (correct an error in the program when the source code is not

available), to identify malicious content in a program such as a virus or to

adapt a program written for use with one microprocessor for use with

another. Reverse engineering for the purpose of copying or duplicating

programs may constitute a copyright violation. In some cases, the licensed

use of software specifically prohibits reverse engineering.

Someone doing reverse engineering on software may use several tools to

disassemble a program. One tool is a hexadecimal dumper, which prints or

displays the binary numbers of a program in hexadecimal format (which is

easier to read than a binary format). By knowing the bit patterns that

represent the processor instructions as well as the instruction lengths, the

reverse engineer can identify certain portions of a program to see how they

work. Another common tool is the disassembler. The disassembler reads the

binary code and then displays each executable instruction in text form. A

disassembler cannot tell the difference between an executable instruction

and the data used by the program so a debugger is used, which allows the

disassembler to avoid disassembling the data portions of a program. These

tools might be used by a cracker to modify code and gain entry to a computer

system or cause other harm.

of 16


Contents

PERT chart



Use case


Regression testing


Reverse engineering

Gantt Chart

Debugging



3-tier application

Unit testing



What is Gantt chart?

A Gantt chart is a horizontal bar chart developed as a production control tool

in 1917 by Henry L. Gantt, an American engineer and social scientist.

Frequently used in project management, a Gantt chart provides a graphical

illustration of a schedule that helps to plan, coordinate, and track specific

tasks in a project.

Gantt charts may be simple versions created on graph paper or more

complex automated versions created using project management applications

such as Microsoft Project or Excel.

A Gantt chart is constructed with a horizontal axis representing the total time

span of the project, broken down into increments (for example, days, weeks,

or months) and a vertical axis representing the tasks that make up the project

(for example, if the project is outfitting your computer with new software, the

of 16


Contents

PERT chart



Use case


Regression testing


Reverse engineering

Gantt Chart

Debugging



3-tier application

Unit testing



major tasks involved might be: conduct research, choose software, install

software). Horizontal bars of varying lengths represent the sequences,

timing, and time span for each task. Using the same example, you would put

"conduct research" at the top of the verticle axis and draw a bar on the graph

that represents the amount of time you expect to spend on the research, and

then enter the other tasks below the first one and representative bars at the

points in time when you expect to undertake them. The bar spans may

overlap, as, for example, you may conduct research and choose software

during the same time span. As the project progresses, secondary bars,

arrowheads, or darkened bars may be added to indicate completed tasks, or

the portions of tasks that have been completed. A vertical line is used to

represent the report date.

Gantt charts give a clear illustration of project status, but one problem with

them is that they don't indicate task dependencies - you cannot tell how one

task falling behind schedule affects other tasks. The PERT chart, another

popular project management charting method, is designed to do this.

Automated Gantt charts store more information about tasks, such as the

individuals assigned to specific tasks, and notes about the procedures. They

also offer the benefit of being easy to change, which is helpful. Charts may

be adjusted frequently to reflect the actual status of project tasks as, almost

inevitably, they diverge from the original plan.

What is debugging?

In computers, debugging is the process of locating and fixing or bypassing

bugs (errors) in computer program code or the engineering of a hardware

device. To debug a program or hardware device is to start with a problem,

isolate the source of the problem, and then fix it. A user of a program that

does not know how to fix the problem may learn enough about the problem

to be able to avoid it until it is permanently fixed. When someone says

they've debugged a program or "worked the bugs out" of a program, they

imply that they fixed it so that the bugs no longer exist.

of 16


Contents

PERT chart



Use case


Regression testing


Reverse engineering

Gantt Chart

Debugging



3-tier application

Unit testing



Debugging is a necessary process in almost any new software or hardware

development process, whether a commercial product or an enterprise or

personal application program. For complex products, debugging is done as

the result of the unit test for the smallest unit of a system, again at

component test when parts are brought together, again at system test when

the product is used with other existing products, and again during customer

beta test, when users try the product out in a real world situation. Because

most computer programs and many programmed hardware devices contain

thousands of lines of code, almost any new product is likely to contain a few

bugs. Invariably, the bugs in the functions that get most use are found and

fixed first. An early version of a program that has lots of bugs is referred to as

"buggy."

Debugging tools (called debuggers) help identify coding errors at various

development stages. Some programming language packages include a

facility for checking the code for errors as it is being written.

What is software requirements specification (SRS)?

A software requirements specification (SRS) is a comprehensive description

of the intended purpose and environment for software under development.

The SRS fully describes what the software will do and how it will be expected

to perform.

An SRS minimizes the time and effort required by developers to achieve

desired goals and also minimizes the development cost. A good SRS defines

how an application will interact with system hardware, other programs and

human users in a wide variety of real-world situations. Parameters such as

operating speed, response time, availability, portability, maintainability,

footprint, security and speed of recovery from adverse events are evaluated.

Methods of defining an SRS are described by the IEEE (Institute of Electrical

and Electronics Engineers) specification 830-1998.

of 16


Contents

PERT chart



Use case


Regression testing


Reverse engineering

Gantt Chart

Debugging



3-tier application

Unit testing



What is requirements analysis (requirements engineering)?

Requirements analysis, also called requirements engineering, is the process

of determining user expectations for a new or modified product. These

features, called requirements, must be quantifiable, relevant and detailed. In

software engineering, such requirements are often called functional

specifications. Requirements analysis is an important aspect of project

management.

Requirements analysis involves frequent communication with system users

to determine specific feature expectations, resolution of conflict or ambiguity

in requirements as demanded by the various users or groups of users,

avoidance of feature creep and documentation of all aspects of the project

development process from start to finish. Energy should be directed towards

ensuring that the final system or product conforms to client needs rather than

attempting to mold user expectations to fit the requirements.

Requirements analysis is a team effort that demands a combination of

hardware, software and human factors engineering expertise as well as skills

in dealing with people.

What is 3-tier application?

A 3-tier application is an application program that is organized into three

major parts, each of which is distributed to a different place or places in a

network. The three parts are:

The workstation or presentation interface

The business logic

The database and programming related to managing it

In a typical 3-tier application, the application user's workstation contains the

programming that provides the graphical user interface (GUI) and

application-specific entry forms or interactive windows. (Some data that is

local or unique for the workstation user is also kept on the local hard disk.)

of 16


Contents

PERT chart



Use case


Regression testing


Reverse engineering

Gantt Chart

Debugging



3-tier application

Unit testing



Business logic is located on a local area network (LAN) server or other

shared computer. The business logic acts as the server for client requests

from workstations. In turn, it determines what data is needed (and where it is

located) and acts as a client in relation to a third tier of programming that

might be located on a mainframe computer.

The third tier includes the database and a program to manage read and write

access to it. While the organization of an application can be more

complicated than this, the 3-tier view is a convenient way to think about the

parts in a large-scale program.

What is unit testing?

Unit testing is a software development process in which the smallest testable

parts of an application, called units, are individually and independently

scrutinized for proper operation. Unit testing is often automated but it can

also be done manually. This testing mode is a component of Extreme

Programming (XP), a pragmatic method of software development that takes

a meticulous approach to building a product by means of continual testing

and revision.

Unit testing involves only those characteristics that are vital to the

performance of the unit under test. This encourages developers to modify the

source code without immediate concerns about how such changes might

affect the functioning of other units or the program as a whole. Once all of the

units in a program have been found to be working in the most efficient and

error-free manner possible, larger components of the program can be

evaluated by means of integration testing.

Unit testing can be time-consuming and tedious. It demands patience and

thoroughness on the part of the development team. Rigorous documentation

must be maintained. Unit testing must be done with an awareness that it may

not be possible to test a unit for every input scenario that will occur when the

program is run in a real-world environment.

of 16


Contents

PERT chart



Use case


Regression testing


Reverse engineering

Gantt Chart

Debugging



3-tier application

Unit testing



What is collaboration diagram?

A collaboration diagram, also called a communication diagram or interaction

diagram, is an illustration of the relationships and interactions among

software objects in the Unified Modeling Language (UML). The concept is

more than a decade old although it has been refined as modeling paradigms

have evolved.

A collaboration diagram resembles a flowchart that portrays the roles,

functionality and behavior of individual objects as well as the overall

operation of the system in real time. Objects are shown as rectangles with

naming labels inside. These labels are preceded by colons and may be

underlined. The relationships between the objects are shown as lines

connecting the rectangles. The messages between objects are shown as

arrows connecting the relevant rectangles along with labels that define the

message sequencing.

Collaboration diagrams are best suited to the portrayal of simple interactions

among relatively small numbers of objects. As the number of objects and

messages grows, a collaboration diagram can become difficult to read.

Several vendors offer software for creating and editing collaboration

diagrams.

Want more? View our Application Development Glossary: http://whatis.techtarget.com/glossary/Application-Development

of 16


Contents

PERT chart



Use case


Regression testing


Reverse engineering

Gantt Chart

Debugging



3-tier application

Unit testing



Free resources for technology professionals TechTarget publishes targeted technology media that address your need for

information and resources for researching products, developing strategy and

making cost-effective purchase decisions. Our network of technology-specific

Web sites gives you access to industry experts, independent content and

analysis and the Webs largest library of vendor-provided white papers,

webcasts, podcasts, videos, virtual trade shows, research reports and more

drawing on the rich R&D resources of technology providers to address

market trends, challenges and solutions. Our live events and virtual seminars

give you access to vendor neutral, expert commentary and advice on the

issues and challenges you face daily. Our social community IT Knowledge

Exchange allows you to share real world information in real time with peers

and experts.

What makes TechTarget unique? TechTarget is squarely focused on the enterprise IT space. Our team of

editors and network of industry experts provide the richest, most relevant

content to IT professionals and management. We leverage the immediacy of

the Web, the networking and face-to-face opportunities of events and virtual

events, and the ability to interact with peersall to create compelling and

actionable information for enterprise IT professionals across all industries

and markets.

Related TechTarget Websites