INDEX

SNo. Practical
Study of CASE tools used for designing the DFD (data flow diagram), ER diagram, Data dictionary and Flow chart. 1.1 To study the Entity Relationship Diagrams of various case studies. 1.2 To study the Data Flow Diagrams of various case studies. 1.3 To study the Data Dictionary of various case studies. 1.4 To study the Flow Chart of various case studies. To study Unified Modeling Language (UML). Introduction to Documentation. Introduction to Beta Testing. Introduction to Jackson Structured Programming ( JSP) and Jackson Structured Development(JSD). 29 40 42 45 11 18 22 5

Page No.
3

REMARKS

Practical No.-1 AIM: Study of CASE tools used for designing the DFD (data flow diagram) , ER diagram ,
Data dictionary and Flow chart.

Pre-requisite: Knowledge of characteristics of software, basic waterfall life cycle. Theory:SmartDraw

is a business graphics software developed by SmartDraw.com.

SmartDraw is used to create business graphics such as flowcharts, entity relationship diagrams, data flow diagrams and data dictionary that are used in the project development. Smartdraw automatically aligns shapes, lines and text. Its unique, built-in library of design styles lets you pick professional looking color schemes, shadows, and textures for your drawings with the click of a mouse. Libraries of Smartdraw Symbols provide an unlimited selection of clip art that you can use in your own drawings or in any of the ready-made Smartdraw Templates. Smartdraw works as a stand-alone program, and as part of Microsoft Office and other programs that support Object Linking and Embedding (OLE). We can insert a Smartdraw drawing directly into Microsoft Word for Windows, using the Insert Object command. With the Professional version of Smartdraw, we can also insert Office documents, like graphs, equations, and spreadsheets into your drawings as Smartdraw symbols. ADVANTAGES OF SMART DRAW: Easy "drag-and-drop" drawingno skill required! Over 50,000 built-in symbols and clip art Works hand-in-hand with Microsoft Office Automatic alignment for neat, crisp drawings Built-in templates and examples Import our own symbols and clipart

Save your drawings for the web as GIF, JPG, or HTML Easily convert drawings made in other software.

Home page of full version of smart draw when search option found

Smart draw work screen

Practical No.- 1.1 AIM: To study the Entity Relationship Diagrams of various case studies. Pre-requisite:
process and project. Knowledge of characteristics of software, basic waterfall life cycle,

Theory:
ER Diagram: An entity relationship diagram is a graphical representation of an organizations data storage requirements. Entity relationship diagrams are abstractions of the real world which simplify the problem to be solved while retaining its essential features. Entity relationship diagrams are used to: identify the data that must be captured, stored and retrieved in order to support the business activities performed by an organization; and identify the data required to derive and report on the performance measures that an organization should be monitoring. Entity relationship diagrams have three different components: ENTITIES ATTRIBUTES RELATIONSHIPS Entities - These are the people, places, things, events and concepts of interest to an organization. In short, anything which an organization needs to store data about. Entities are represented on the diagram by labelled boxes. Attributes - Entities are further described by their attributes (sometimes called data elements). These are the smallest units of data that can be described in a meaningful manner. Relationships - Frequently, a meaningful relationship exists between two different types of entity. There are potentially three types of relationship which can exist between two different entities:

One-to-One Relationships This type of relationship takes place when a single occurrence of an entity is related diagram by a line connecting the two Entities. to

just one occurrence of a second entity. A One-to-One relationship is shown on the

One-to-Many Relationships This type of relationship takes place when a single occurrence of an entity is related to many occurrences of a second entity. A One-to-Many relationship is shown on the diagram by a line connecting the two entities with a crows feet symbol denoting the "many" end of the relationship.

Many-to-Many Relationships This type of relationship takes place when many occurrences of an entity are related to many occurrences of a second entity. A Many-to-Many relationship is shown on the diagram by a line connecting the two entities with a crows feet at each end of the line.

The steps involved in creating an ERD are: 1. 2. 3. 4. Identify the entities. Determine all significant interactions. Analyze the nature of the interactions. Draw the ERD.

5.

ER DIAGRAMS OF VARIOUS CASE STUDIES.

Practical No.- 1.2 AIM: To study the Data Flow Diagrams of various case studies. Pre-requisite: Knowledge of characteristics of software, basic waterfall life cycle, process
and project.

Theory:
DATA FLOW DIAGRAM -> A data flow diagram, also known as bubble chart has the purpose of clarifying system requirements and identifying major transformation that will become programs in system design. It is a graphic representation of a system or portion of system. A DFD consists of a series of bubbles joined by lines. It consists of data flows, processes, sources, destinations and stores all described through the use of easily understood symbols. An entire system can be described from the viewpoint of the data it processes with only four symbols. The DFD is also powerful enough to show parallel activities. TYPES OF DATA FLOW DIAGRAM

Physical data flow diagram: - Physical data flow diagram is implementation

dependent. They show the actual devices, department, people etc. involved in the current system.

Logical data flow diagram: - It describes the system independently of how it is actually

implemented, that is , they show what takes place, rather than how an activity is accomplished. COMPONENTS OF DATA FLOW DIAGRAM:a) Source or Destination: - The source or destination is graphically represented as a rectangle. Source or destination external entities with which the system communicates. A source or destination is a person or a group of persons that are outside the control of the system being modeled. b) Data Flow: - The flow is represented graphically by an arrow into or out of a process. The flow is used to describe the movement of chunks or packet of information from one part of the system to another part. The flow represents data in motion.

c) Process: - The process shows a part of the system that transforms input into output. The process is represented graphically as a circle or bubble. d) Data Store: - The data store is used to model a collection of data packet at rest. The notation of a data store is two parallel lines. Data stores are typically implemented as files or databases in computerized system. Data stores are connected by flow to processes. Basic Symbols for Data Flow Diagram:1.
or

= Source or destination of data

2. = Data Flow

3. or = Process that transforms data flow

4.

or

= Data Store

In data flow diagrams a single process node on a high level diagram expanded to show a more detailed data flow diagram. The first level DFD shows the main processes within the system. Each of these processes can be broken into further processes until we reach pseudo code.

The various elements used for drawing structure chart using Smart Draw are the following: 1. Circles: Circles are used to represent the process 2. Rectangles: Rectangles are used to represent the external entity. 3. Straight Line: Straight line is formatted to arrow head to show the flow of control from one process to another and also represents the data flowing from one process to another. 4. Edit Text: To add text to various processes and to define data flowing from one process to another DFDS OF VARIOUS CASE STUDIES Context diagram:

D IS P L A Y USER MOVE
Level 1 DFD:
GET EXAMINATION MODULE DISPLAY RESULT RESULT

O N L IN E E X A M IN A T IO N
B u y S m a r t!- pru rw h a s e d c o p ie s p r in t th is D a c d o c u m e n t w ith o u t a .w a te r m a r k V is it w .s m a r td .caowm o r 1-8 ll -07 6 -83 7 2. 9 ww r ca0

LOGS IN

TEST

LOGIN
!PERFORM Buy S m artD rawpurchased copies print this TEST docum ent without a w aterm ark . Visit w ww artdraw .sm .com or call 1-800-768-3729 .

Practical No.- 1.3 AIM: To study the Data Dictionary of various case studies. Pre-requisite: Theory:
DATA DICTIONARY - Data dictionary may cover the whole organization, a part of the organization or a database. In its simplest form, the data dictionary is only a collection of data element definitions, according to descriptions below. More advanced data dictionary contains database schema with reference keys, still more advanced data dictionary contains entityrelationship model of the data elements or objects. The term "data element" is the same concept as "data object" or "object" in some database texts. Data dictionary consists of the following:1. D A T A
ELEMENT DEFINITIONS

Knowledge of characteristics of software, basic waterfall life cycle,

process, project and DBMS.

Data element definitions may be independent of table definitions or a part of each table definition . 2. T A B L E Table
DEFINITIONS

definition

is

usually

available

with

SQL

command

help

table

tablename 3. D A T A B A S E
SCHEMA

Database schema is usually graphical presentation of the whole database. Tables are connected with external keys and key colums. When accessing data from several tables, database schema will be needed in order to find joining data elements and in complex cases to find proper intermediate tables. Some database products use the schema to join the tables automatically.

4. E N T I T Y - R E L A T I O N S H I P

MODEL OF DATA

Entity-relationship model is database analysis and design tool. It lists real-life application entities, attributes of entities and relationships amongst entities. The type of each relationship is also indicated. Entity-relationship model is represented in graphical form. 5. D A T A B A S E
SECURITY MODEL

Database security model associates users, groups of users or applications (programs) with database access rights. DATA DICIONARY FOR VARIOUS CASE STUDIES

U E ID SR

u iq eu e idisg e toe c u e n u sr iv n ah s r

Ue n m sr a e

u e n m o th u e u u llyu iq e sr a e f e sr sa n u

P s w rd as o

e c u e is ah s r

as gd s in e

u iq ek yfo lo in n u e r g

L G O IN

toc n u th p c s o v ws d n o tin e e ro e s f ie tu e t

d tia e l

R G T A IO E IS R T N

tog t th s d n re is r fo a p a gine a e e tu e t g te r p e rin xm

E A IN T N X M A IO

tog t a p a fo te t e per r s

E A IN T NM D L X M A IO O U E

c n in gd re t s b c inap rtic la fo a o ta in iffe n u je ts a u r rm t

P R O MT S EF R ET

e rtso s d n inte t ffo f tu e t s

P E A ER S L R P R E UT

tom rkth s d n p rfo a c & a e tu e t e rm n e

B yS a ra u m rtD w !- p rc a e c p sp t th u h s d o ie rin is d c m n w o t aw te a o u e t ith u a rm rk . V it w w is w .s a ra m rtd w .c mo c ll o r a 1-8 0 -7 8 -3 2 . 0 6 79

c na a o c tin te

it

D PA R S L IS L Y E U T

s o in th re u o s d n h w g e s lts f tu e ts

Practical NO. -1.4

AIM: To study the Flow Chart of various case studies. Pre-requisite: Theory:
FLOW CHART - A flow chart is defined as a pictorial representation describing a process being studied or even used to plan stages of a project. Flow charts tend to provide people with a common language or reference point when dealing with a project or process. The flowchart is a means of visually presenting the flow of data through an information processing systems, the operations performed within the system and the sequence in which they are performed. When dealing with a process flow chart, two separate stages of the process should be considered: the finished product and the making of the product. In order to analyze the finished product or how to operate the process, flow charts tend to use simple and easily recognizable symbols. Flowcharts are usually drawn using some standard symbols; however, some special symbols can also be developed when required. Some standard symbols, which are frequently required for flowcharting many computer programs are shown below:Symbol Name Process Function an action done by the program (e.g. calculate the area of a square) shows the direction and sequence of processes asks a question and then determines which route the program will take Knowledge of characteristics of software, basic waterfall life cycle,

process, project and DBMS.

Arrows

Decision

connects one part of the flowchart to Connector another part of the flowchart on the same page using matching symbols represents when something is input into the program or output from the program

input/output

The following are some guidelines in flowcharting: a. b. c. d. In drawing a proper flowchart, all necessary requirements should be listed out in logical order. The flowchart should be clear, neat and easy to follow. There should not be any room for ambiguity in understanding the flowchart. The usual direction of the flow of a procedure or system is from left to right or top to bottom. Only one flow line should come out from a process symbol.

or e. Only one flow line should enter a decision symbol, but two or three flow lines, one for each possible answer, should leave the decision symbol.

f.

Only one flow line is used in conjunction with terminal symbol.

g.

Write within standard symbols briefly. As necessary, you can use the annotation symbol to describe data or computational steps more clearly.

h.

If the flowchart becomes complex, it is better to use connector symbols to reduce the number of flow lines. Avoid the intersection of flow lines if you want to make it more effective and better way of communication.

i.

Ensure that the flowchart has a logical start and finish. It is useful to test the validity of the flowchart by passing through it with a simple test data.

j.

FLOW CHARTS OF VARIOUS CASE STUDIES:

S rt ta

S U E TL G T D N O IN

C EK HC V L A IO A ID T N

RG TR T N E IS E A IO

E TR NE E A IN T N X M A IO

C O E H IC

E A IN T N X M A IO M D L O UE

CL N U G A G A E

C +L N U G + A G A E

O P OS

DM B S

P R O MT S EF R ET

P E A ER S L RP R EUT

S O ER S L IN T R EUT D T B S AA AE

D PA RS L IS L Y E U T

E D N

Buy SmartDraw !- purchased copies print this document without a watermark . Visit www .smartdraw .com or call 1-800 -768 -3729 .

Practical No.:- 2 AIM: To study Unified Modeling Language (UML). Pre-requisite: Knowledge of characteristics of software, process and project. Theory: In the field of software engineering, the Unified Modeling Language (UML) is a
standardized visual specification language for object modeling. UML is a general-purpose modeling language that includes a graphical notation used to create an abstract model of a system, referred to as a UML model. The Unified Modeling Language or UML is a mostly graphical modeling language that is used to express designs. It is a standardized language in which to specify the artifacts and components of a software system. It is important to understand that the UML describes a notation and not a process. It does not put forth a single method or process of design, but rather is a standardized tool that can be used in a design process. UML diagrams represent three different views of a system model:

Various Diagrams Are: 1.Structural (static) Diagrams: a) Class diagram: The class diagram shows how the different entities (people, things, and data) relate to each other; in other words, it shows the static structures of the system. Various relationships are:

Dependency represnted by ------------> Association represented by Generalization represented by

Realization represented by ------------

Boxes represent the class as shown below:

Where the first section gives the class name and the second one gives the attributes and the last section gives the class operations(methods).

Example: Class diagram of online examination system:

STUDENT # userid # password # studentid # firstname # middlename # lastname # signin() signup() registration() # getExaminationmodule() result()

Buy SmartDraw!- purchased copies print this document without a watermark. Visit www.smartdraw.com or call 1-800-768-3729.

b) Component Diagram: A component diagram provides a physical view of the system. Its purpose is to show the dependencies that the software has on the other software components. Example: component diagram of online examination system:

su e tG I t dn U

M i a pi ai n an p l c to

n t ok ew r

dt bs aa ae mn g mn aae et

dt bs aa ae

V it w w is w

B y S a ra u m rtD w !- p rc a e c p s p t th u h s d o ie rin is d c m n w o t aw te a o u e t ith u a rm rk . .s a ra m rtd w .c mo c ll o r a 1-8 0 -7 8 -3 2 . 0 6 79

c) Object Diagram: In the Unified Modeling Language (UML), an object diagram is a diagram that shows a complete or partial view of the structure of a modeled system at a specific time. This snapshot focuses on some particular set of object instances and attributes, and the links between the instances. A correlated set of object diagrams provides insight into how an arbitrary view of a system is expected to evolve over time. Object diagrams are more concrete than class diagrams, and are often used to provide examples, or act as test cases for the class diagrams. Only those aspects of a model that are of current interest need be shown on an object diagram.Each object and link on an object diagram is represented by an InstanceSpecification. This can show an object's classifier (e.g. an abstract or concrete class) and instance name, as well as attributes and other structural features using slots. Each slot corresponds to a single attribute or feature, and may include a value for that entity.The name on an instance specification optionally shows an instance name, a ':' separator, and optionally one or more classifier names separated by commas.

The contents of slots, if any, are included below the names, in a separate attribute compartment. A link is shown as a solid line, and represents an instance of an association. Example: object diagram of university system

SU E T T DN a it 2 m13 ***** ***** 950018 08371 a it m k mr u a ja in # ig in ( s n ) s n p) ig u ( r g t a io ( e is r t n ) # e E a in t n o u g t x m a io m d le r s lt ) eu (

Visit w w w

B Sm uy artD w ra !- pu rchased copies print this docum w ent ithout a w aterm ark . .sm artdraw .comor call 1-8 -7 -3729 . 00 68

( )

d) Deployement Diagram: The deployment diagram shows how a system will be physically deployed in the hardware environment. Its purpose is to show where the different components of the system will physically run and how they will communicate with each other. Since the diagram models the physical runtime, a system's production staff will make considerable use of this diagram. The notation in a deployment diagram includes the notation elements used in a component diagram, with a couple of additions, including the concept of a node. A node represents either a physical machine or a virtual machine node (e.g., a mainframe node). To model a node, simply draw a three-dimensional cube with the name of the node at the top of the cube.

Use the naming convention used in sequence diagrams: [instance name] : [instance type]. Example: deployement diagram of university system

student

online examination system

B uy S m artD raw urchased co pies prin t this !- p docum e nt w ith out a w aterm ark . V is it w w .sm artdraw om exam result w .c o r call 1-800-768-372 9 .

2. Functional(Dynamic) Diagrams: a) Sequence Diagrams: Sequence diagrams show a detailed flow for a specific use case or even just part of a specific use case. They are almost self explanatory; they show the calls between the different objects in their sequence and can show, at a detailed level, different calls to different objects. A sequence diagram has two dimensions: The vertical dimension shows the sequence of messages/calls in the time order that they occur; the horizontal dimension shows the object instances to which the messages are sent. A sequence diagram is very simple to draw. Across the top of your diagram, identify the class instances (objects) by putting each class instance. Reading a sequence diagram is very simple.

Start at the top left corner with the "driver" class instance that starts the sequence. Then follow each message down the diagram. Example: Sequence diagram of university system

b) Use Case Diagram: A use case illustrates a unit of functionality provided by the system. The main purpose of the use-case diagram is to help development teams visualize the functional requirements of a system, including the relationship of "actors" (human beings who will interact with the system) to essential processes, as well as the relationships among different use cases. Use-case diagrams generally show groups of use cases -- either all use cases for the complete system, or a breakout of a particular group of use cases with related functionality. To show a use case on a use-case diagram, you draw an oval in the middle of the diagram and put the name of the use case in the center of, or below, the oval. To draw an actor (indicating a system user) on a use-case diagram,

you draw a stick person to the left or right of your diagram. Use simple lines to depict relationships between actors and use cases. Example: use case diagram of university system

c) Activity Diagram: Activity diagrams show the procedural flow of control between two or more class objects while processing an activity. Activity diagrams can be used to model higher-level business process at the business unit level, or to model low-level internal class actions. activity diagrams are best used to model higher-level processes, such as how the company is currently doing business, or how it would like to do business. This is because activity diagrams are "less technical" in appearance, compared to sequence diagrams, and business-minded people tend to understand them more quickly.

An activity diagram's notation set is similar to that used in a statechart diagram. Like a state chart diagram, the activity diagram starts with a solid circle connected to the initial activity. The activity is modeled by drawing a rectangle with rounded edges, enclosing the activity's name. Activities can be connected to other activities through transition lines, or to decision points that connect to different activities guarded by conditions of the decision point. Activities that terminate the modeled process are connected to a termination point (just as in a statechart diagram). Optionally, the activities can be grouped into swimlanes, which are used to indicate the object that actually performs the activity. Example : Activity diagram of university system

d) StateChart Diagram: The statechart diagram models the different states that a class can be in and how that class transitions from state to state. It can be argued that every class has a state, but that every class shouldn't have a statechart diagram. Only classes with "interesting" states -- that is, classes with three or more potential states during system activity -- should be modeled. the initial starting point, which is drawn using a solid circle; a transition between states, which is drawn using a line with an open arrowhead; a state, which is drawn using a rectangle with rounded corners; a decision point, which is drawn as an open circle; and one or more termination points, which are

drawn using a circle with a solid circle inside it. To draw a statechart diagram, begin with a starting point and a transition line pointing to the initial state of the class. Draw the states themselves anywhere on the diagram, and then simply connect them using the state transition lines. Example: Statechart diagram of university system
student login [logged] valid member

LOGGING

LOGGED STUDENT

[invalid] get registered

select exam

REGISTRATION view result RUN EXAM RESULT

Buy SmartDraw !- purchased copies print this document without a watermark . Visit www .smartdraw .com or call 1-800-768-3729.

e) Collaboration Diagram: An interaction diagram captures the behaviour of a single case by showing the collaboration of the objects in the system to accomplish the task. These diagrams show objects in the system and the messages that are passed between them.In this the methods on the various clasees are numberd. Example: Collaboration diagram of university system

LOGIN

STUDENT

student EXAMINATION MODULE TestID() TestName() choiceselected

Buy SmartDraw!- purchased copies print this datasaved() document without a watermark . PERFORMVisit www.smartdraw.com or call 1-800-768-3729. TEST CHOICE

REGISTRATION

studentid() testid() calculatemarks() RESULT

Practical no- 3 AIM:

Introduction to Documentation. Knowledge of various phases and their activities of water fall software

Pre-requisite: Theory:

development lifecycle model.

Document - A document is a file that contains information that the user can view or hear. It is most often a word processed letter, a picture, a sound byte, or something similar. Documents are usually created and edited using programs such as Microsoft Word, or Adobe Photoshop. In the PC world, the term was originally used for a file created with a word processor. In addition to text, documents can contain graphics, charts, and other objects. Increasingly, the line separating word processing files from files produced by other applications is becoming blurred. A word processing application can produce graphics and a graphics application can produce words. This trend has accelerated with technologies such as OLE and that allow an application to combine many components. Consequently, the term document is used more and more to describe any file produced by an application. DOCUMENTATION Computer hardware and software product development, documentation is the information that describes the product to its users. It consists of the product technical manuals and online information (including online versions of the technical manuals and help facility descriptions). The term is also sometimes used to mean the source information about the product contained in design documents, detailed code comments, white papers, and blackboard session notes. The term is derived from the idea that engineers and programmers "document" their products in formal writing. The earliest computer users were sometimes simply handed the engineers' or programmers' "documentation." As the product audience grew, it became necessary to add professional technical writers and editors to the process. Today, IBM and other companies look at developing product information based on what users actually need to do when using the product. In this task-oriented view, product information can be divided into and sometimes physically organized into these task categories: evaluating, planning for, setting up or installing, customizing, administering, using, and maintaining the product. Documentation is now often built directly into the product as part of the user interface and in help pages. Documentation can appear in a variety of forms, the most common being manuals. When you buy a computer product (hardware or software), it almost always comes with one or more manuals that describe how to install and operate the product. In addition, many software products include an online version of the documentation that you can display on your screen or

print out on a printer. A special type of online documentation is a help system, which has the documentation embedded into the program. Help systems are often called context-sensitive because they display different information depending on the user's position (context) in the application. Documentation is often divided into the following categories:
1

Installation: Describes how to install a program or device but not how to use it.

Reference: Detailed descriptions of particular items presented in alphabetical order. Reference documentation is designed for people who are already somewhat familiar with the product but need reminders or very specific information about a particular topic.

Tutorial: Teaches a user how to use the product. Tutorials move at a slower pace than reference manuals and generally contain less detail.

Types of documentation file:

Codebook: Information on the structure, contents, and layout of a data file. The

codebook may also contain information on study design and methodology.

Dictionary file: Information on column locations and labeling of variables. Data collection instrument: Original survey instrument or questionnaire. Data map: Similar to a dictionary file. Frequency file: Frequency of response or descriptive statistics for selected

variables in a collection.

Cross-tabulation file: Cross-tabulations for some or all variables in a collection. User Guide: More detailed information about a particular collection, often

provided by the principal investigator.

Manual: Instructions prepared by the principal investigator on some aspect of

the data collection.

2Appendices: Additional documentation.

Reports: Description of findings or results based on analysis of a dataset.

Prepared by the principal investigator.

Data documentation file: Additional documentation. Record layout file: Similar to a dictionary file.

Practical No.-:4 AIM: Introduction to Beta Testing. Pre-requisite: Knowledge of various Testing strategies Theory:
BETA TEST - In software and Web development, a beta test is the second phase of testing in which a sampling of the intended audience tries the product out. (Beta is the second letter of the Greek alphabet.) Originally, the term alpha test meant the first phase of testing in a software development process. The first phase includes unit testing, component testing, and system testing. Beta testing can be considered "pre-release testing. In software engineering, development stage terminology expresses how the development of a piece of software has progressed and how much further development it may require. Each major version of a product usually goes through a stage when new features are added (alpha stage), then a stage when it is actively debugged (beta stage), and finally a stage when all important bugs have been removed (stable stage). Intermediate stages may also be recognized. The software has reached "beta" stage when it is operating with most of its functionality, and is ready for user feedback. During the beta test, end users who will likely use the software perform testing and provide feedback to EPRI and the developers. EPRI requires obtaining feedback from at least one beta tester who is an actual user outside EPRI. Recommended are 5-10 beta testers. EPRI Corporate Software Quality must review all beta software before it is sent to beta testers BETA TESTING Beta testing is a common final check on system content and accuracy. When feature or defect problems come back from beta testing, that's bad news, and we might have to freeze the code. Therefore, treat beta testing as "business as usual". THE PURPOSE
OF

BETA TESTING

Most commonly, we do beta testing because someone somewhere wants a final check that everything is OK. In XP terms, we fear that if we don't beta test, something bad will happen. Beta testing is done to alleviate that fear. One of the XP values is Courage. If the organization feels enough fear to want to do beta testing, then I'd like to suggest that there is not enough courage. The response isn't just to hold our chin up and say "Be brave, little Piglet," or "Damn the beta testing, full speed ahead." But the response might be to examine the information that comes back to those who hold this fear, and try to get it sooner. INFORMATION
FRO M

BETA

Beta gives us back two basic dimensions of feedback, which I'll call Defect Feedback and Feature Feedback. DEFECT FEEDBA CK We might find actual defects in beta. The system might not run correctly on some user configurations, or there might just be defects in the software. The technical term for this is "bad". Beta testing, in its common form, is done very late in the development cycle. We think we are done and just want to be sure. This is a very bad time to be finding defects. Whenever a defect escapes from a coding cycle or from an iteration, an XP team improves its tests and its practices to prevent that kind of escape from happening again. This is an application of the XP value of Feedback. A defect found during beta testing was probably injected, on the average, halfway from the last beta test until the current one. By XP standards, where we expect testing feedback every couple of hours, this is seriously open-loop, not the best case of the XP value Feedback. Therefore, a wise XP team will do pre-beta testing or on-site configuration testing, or take whatever measures are necessary to reduce the chance for Defect Feedback during beta. We want beta to be a non-event. FEATURE FEEDBA CK Even if the software works as planned, we might also do beta testing to be sure that it is what the customers want. We might not have built quite the features they asked for, it might be harder

to use than they like, and so on. This is, in essence, feedback to the XP Customer about how good a job she has done. As with Defect Feedback, a problem discovered in Feature Feedback was probably injected, on the average, a long time back. As with programming defects, this feedback is too slow to be really useful. The wise customer will find ways to be sure, long before beta-time, how well her decisions match up with the needs and preferences of the buyers and users. The XP Customer, too, wants beta to be a non-event.

Practical No : 5 AIM:
Introduction to Jackson Structured Programming( JSP) and Jackson Structured

Development(JSD).

Theory: Michael Jackson (not the singer) created Jackson System Development (JSD) using
the principles laid out in Jackson Structured Programming (JSP). In Jacksons thinking, the design of a program follows from static structure Of a programs text: :what is the relationship of the parts of the whole? Basic program design method (Jackson Structured Programming)

system diagram input/output structure diagrams program structure diagram allocation of operations to program structure ,which part? how many times? "read-ahead rule" constructive method of design (not top-down, not stepwise

refinement) Design is about structure, about the relation of parts to the whole. Programs consist of the following parts or components: (i) elementary components (ii) composite components There are three types of composite components--components having one or more parts:
a.

Sequence - A sequence is a composite component that has two or more parts occurring

once each, in order.

(b) Selection - A selection is a composite component that consists of two or more parts, only one of which is selected, once.

(iv) iteration - An iteration is a composite component that consists of one part that repeats zero or more times.

Regular Expressions

structure (tree) diagrams model programs and objects

Jacksons Structured Devolvement: Jackson System Development (JSD) is a method of system development that covers the software life cycle either directly or, by providing a framework into which more specialized techniques can fit. Jackson System Development can start from the stage in a project when there is only a general statement of requirements. However, many projects that have used Jackson System Development actually started slightly later in the life cycle, doing the first steps largely from existing documents rather than directly with the users. The later steps of JSD produce the code of the final system. Jacksons first method, Jackson Structured Programming (JSP), is used to produce the final code. The output of the earlier steps of JSD are a set of program design problems, the design of which is the subject matter of JSP. Maintenance is also addressed by reworking whichever of the earlier steps are appropriate. From the technical point of view there are three major stages in Jackson System Development, each divided into steps and substeps. From a manager's point of view there are a number of ways of organizing this technical work. In this overview we first describe the three major technical stages and then discuss JSD project planning, the variation between plans, and the reasons for choosing one rather than another. JSD is a structured analysis and design method similar to SSADM. It uses Entity Structure Diagrams (ESD) and Network Diagrams (ND) to model a system. There are two main differences between JSD and other system development methods. The first is that the initial area of interest for JSD is the domain of the software, not the software itself. Secondly, the method is focused on event sequencing. The domain is the set of real world events, which sequentially ordered in time. Steps: 1 Modelling Stage (Analysis) Entity/Action Step Entity Structures Step 2 Network Stage (Design)

Initial Model Step Function Step System Timing Step 3 Implementation Stage (Realisation) Implementation Step MODELL ING STAGE In the modelling stage the designer creates a collection of entity structure diagrams and identifies the entities in the system, the actions they perform, the time-ordering of the actions in the life of the entities, and the attributes of the actions and entities. Entity Structure Diagrams (ESD) Entity Structure Diagrams (ESDs) illustrate the time-ordered actions entities perform within the system.

A N E N T I T Y S T R U C T U R E D I A G R A M (ESD) E N T I T Y S T R U C T U R E D I A G R A M (ESD) N O T A T I O N S

Entity An entity is an object that acts and is acted on by the system. The root of the ESD parent-child tree is a single entity .

Action - Actions are carried out by entities and actions affect other entities. They are linked to the root entity and each other in a parent-child hierarchy.

Constructs - Sequence JSD constructs are identical to SSADM Entity Life History constructs. Use a sequence construct to illustrate actions that are executed in order from left to right.

Constructs - Selection To represent a choice between two or more mutually exclusive actions, mark the actions with a small "o" (for option) on the upper right hand corner.

Constructs - Iteration If an action is repeated, place a small asterisk (*) in its upper right hand corner. There is usually only one action under an iteration construct.

Null Component In an If-Else statement, a null component can illustrate a "do nothing" alternative. Network Stage In the network stage a model of the system as a whole is developed and represented as a system specification diagram (SSD) (also known as a network diagram). Network diagrams show processes (rectangles) and how they communicate with each other, either via state vector connections (diamonds) or via datastream connections (circles). In this stage is the functionality of the system defined. Each entity becomes a process or program in the network diagram. External programs are later added to the network diagrams. The purpose of these programs is to process input, calculate output and to keep the entity processes up-to-date. The whole system is described with these network diagrams and are completed with descriptions about the data and connections between the processes and programs. The Initial Model Step specifies a simulation of the real world. The Function Step adds to this simulation the further executable operations and processes needed to produce output of the system. System Timing Step provides synchronisation among processes, introduces constraints.

This stage is the combination of the former Initial model step, the Function step and the System Timing step.Network Diagram (ND) Network Diagrams (NDs) show interaction between processes. They are sometimes referred to as System Specification Diagrams (SSDs).

A JSD N E T W O R K D I A G R A M N E T W O R K D I A G R A M (ND)

Process Processes represent system functions. A model process represents primary system functions. It is usually connected to an outside entity via a datastream. Learn how to edit text on a process.

DataStream Datastreams connect processes and specify what information is passed between them.

State Vector State vectors are an alternative way of connecting processes. They specify the characteristic or state of the entity being changed by a process. IMPL EMENTATION STAGE In the implementation stage the abstract network model of the solution is converted into a physical system, represented as a system implementation diagram (SID). The SID shows the system as a scheduler process that calls modules that implement the processes. Datastreams are represented as calls to inverted processes. Database symbols represent collections of entity state-vectors, and there are special symbols for file buffers (which must be implemented when processes are scheduled to run at different time intervals). The central concern of Implementation Step is optimization of system. It is necessary to reduce the number of processes because it is impossible to provide each process that is contained in specification with its own virtual processor. By means of transformation, processes are combined in order to limits their number to the number of processors.