SE

MOHD ZIAUN NABI
0948710023 CSE III YEAR
EXPERIMENT-1 What is the Flow Chart and describes its types with suitable example.
Flowchart Definitions
Flowcharts are maps or graphical representations of a process. Steps in a process are shown with symbolic shapes, and the flow of the process is indicated with arrows connecting the symbols. Computer programmers popularized flowcharts in the 1960's, using them to map the logic of programs Flowcharts can help you see whether the steps of a process are logical, uncover problems or miscommunications, define the boundaries of a process, and develop a common base of knowledge about a process. Flowcharting a process often brings to light redundancies, delays, dead ends, and indirect paths that would otherwise remain unnoticed or ignored. But flowcharts don't work if they aren't accurate, if team members are afraid to describe what actually happens, or if the team is too far removed from the actual workings of the process. Flowchart (also spelled flow-chart and flow chart) is a schematic representation of a process. They are commonly used in business/economic presentations to help the audience visualize the content better, or to find flaws in the process.
A flowchart is a type of diagram that represents an algorithm or process, showing the steps as boxes of various kinds, and their order by connecting these with arrows. This diagrammatic representation can give a step-by-step solution to a given problem.
Flow charts are used in analyzing, designing, documenting or managing a process or program in various fields.
AVNEESH GAUR
Page 1
MOHD ZIAUN NABI MEANING OF A FLOWCHART
A flowchart is a diagrammatic representation that illustrates the sequence of

operations to be performed to get the solution of a problem.
Flowcharts are generally drawn in the early stages of formulating computer

solutions.
Flowcharts facilitate communication between programmers and business people.
These flowcharts play a vital role in the programming of a problem and are quite
helpful in understanding the logic of complicated and lengthy problems.
It is correct to say that a flowchart is a must for the better documentation of a

complex program.
Overview:
Flowcharts are used in designing and documenting complex processes. Like other types of diagram, they help visualize what is going on and thereby help the viewer to understand a process, and perhaps also find flaws, bottlenecks, and other less-obvious features within it. There are many different types of flowcharts, and each type has its own repertoire of boxes and notational conventions.
The two most common types of boxes in a flowchart are:
A processing step, usually called activity, and denoted as a rectangular box A decision usually denoted as a diamond.
AVNEESH GAUR
Page 2
MOHD ZIAUN NABI
Flowchart History
Flowcharts were used historically in electronic data processing to represent the conditional logic of computer programs. With the emergence of structured programming and structured design in the 1980s, visual formalisms like data flow diagrams and structure charts began to supplant the use of flowcharts in database programming. Today, flowcharts are one of the main tools of business analysts and others who seek to describe the logic of a process in a graphical format. Flowcharts and cross-functional flowcharts can commonly be found as a key part of project documentation or as a part of a business process document. Flowcharts are widely used in education, clinical settings, service industries and other areas where graphical, logical depiction of process is helpful. The first structured method for documenting process flow, the "flow process chart", was introduced by Frank Gilbert to members of the American Society of Mechanical Engineers (ASME) in 1921 in the presentation Process Charts First Steps in Finding the One Best Way. Gilberts tools quickly found their way into industrial engineering curricula. In the early 1930s, an industrial engineer, Allan H. Mogensen began training business people in the use of some of the tools of industrial engineering at his Work Simplification Conferences in Lake Placid, New York.A 1944 graduate of Mogensen's class, Art Spinanger, took the tools back to Procter and Gamble where he developed their Deliberate Methods Change Program. processing with his development of the multi-flow process chart to display
GUIDELINES FOR DRAWING A FLOWCHART
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.
AVNEESH GAUR Page 3
MOHD ZIAUN NABI
Start or end of the program Computational steps or processing function of a program
Input or output operation
Decision making and branching Connector or joining of two parts of program
Magnetic Tape Magnetic Disk Off-page connector Flow line Annotation Display
AVNEESH GAUR
Page 4
MOHD ZIAUN NABI
Flowchart Symbols
The following are some guidelines in flowcharting: a. In drawing a proper flowchart, all necessary requirements should be listed out in logical order. b. The flowchart should be clear, neat and easy to follow. There should not be any room for ambiguity in understanding the flowchart. c. The usual direction of the flow of a procedure or system is from left to right or top to bottom. d. 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.
AVNEESH GAUR
Page 5
MOHD ZIAUN NABI
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. j. 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.
AVNEESH GAUR
Page 6
MOHD ZIAUN NABI
AVNEESH GAUR
Page 7
MOHD ZIAUN NABI
ADVANTAGES OF USING FLOWCHARTS The benefits of flowcharts are as follows: 1. Communication: Flowcharts are better way of communicating the logic of a system to all concerned. 2. Effective analysis: With the help of flowchart, problem can be analysed in more effective way. 3. Proper documentation: Program flowcharts serve as a good program documentation, which is needed for various purposes. 4. Efficient Coding: The flowcharts act as a guide or blueprint during the systems analysis and program development phase.
AVNEESH GAUR
Page 8
MOHD ZIAUN NABI
5. Proper Debugging: The flowchart helps in debugging process. 6. Efficient Program Maintenance: The maintenance of operating program becomes easy with the help of flowchart. It helps the programmer to put efforts more efficiently on that part .
LIMITATIONS OF USING FLOWCHARTS 1. Complex logic: Sometimes, the program logic is quite complicated. In that case, flowchart becomes complex and clumsy. 2. Alterations and Modifications: If alterations are required the flowchart may require re-drawing completely. 3. Reproduction: As the flowchart symbols cannot be typed, reproduction of flowchart becomes a problem. 4. The essentials of what is done can easily be lost in the technical details of how it is done.
AVNEESH GAUR
Page 9
MOHD ZIAUN NABI
FEW EXAMPLES ON FLOWCHARTING Now we shall present few examples on flowcharting for proper understanding of this technique. This will help in student in program development process at a later stage. Example 1 Draw a flowchart to find the sum of first 50 natural numbers. Answer: The required flowchart is given in Fig. 25.2.
AVNEESH GAUR
Page 10
MOHD ZIAUN NABI
Fig. 25.2 Sum of first 50 natural numbers Flowchart for computing the sum of first 50 natural numbers. Example 2 Draw a flowchart to find the largest of three numbers A,B, and C. Answer: The required flowchart is shown in Fig 25.3
AVNEESH GAUR
Page 11
MOHD ZIAUN NABI
Fig 25.3 Flowchart for finding out the largest of three numbers
Example 3 Draw a flowchart for computing factorial N (N!) Where N! = 1 2 3 N . The required flowchart has been shown in fig 25.4 Answer:
AVNEESH GAUR
Page 12
MOHD ZIAUN NABI
Fig 25.4 Flowchart for computing factorial N
AVNEESH GAUR
Page 13
MOHD ZIAUN NABI
Experiment 2
What are the Data Flow Diagram and its types? Also explain the examples of the DFD. Answers: Definition A data-flow diagram (DFD) is a graphical representation of the "flow" of data through an information system. DFDs can also be used for the visualization of data processing (structured design). On a DFD, data items flow from an external data source or an internal data store to an internal data store or an external data sink, via an internal
process.
A DFD provides no information about the timing or ordering of processes, or about whether processes will operate in sequence or in parallel. It is therefore quite different from a flowchart, which shows the flow of control through an algorithm, allowing a reader to determine what operations will be performed, in what order, and under what circumstances, but not what kinds of data will be input to and output from the system,
nor where the data will come from and go to, nor where the data will be stored (all of
which are shown on a DFD). Overview It is common practice to draw the context-level data flow diagram first, which shows the interaction between the system and external agents which act as data sources and data sinks. On the context diagram the system's interactions with the outside world are modeled purely in terms of data flows across the system boundary. The context
AVNEESH GAUR
Page 14
MOHD ZIAUN NABI
diagram shows the entire system as a single process, and gives no clues as to its internal organization. This context-level DFD is next "exploded", to produce a Level 0 DFD that shows some of the detail of the system being modeled. The Level 0 DFD shows how the system is divided into sub-systems (processes), each of which deals with one or more of the data flows to or from an external agent, and which together provide all of the functionality of the system as a whole. It also identifies internal data stores that must be present in order for the system to do its job, and shows the flow of data between the various parts of the system. Data flow diagrams were proposed by Larry Constantine, the original developer of structured design, based on Martin and Estrin's "data flow graph" model of computation. Data flow diagrams (DFDs) are one of the three essential perspectives of the structured-systems analysis and design method SSADM. The sponsor of a project and the end users will need to be briefed and consulted throughout all stages of a system's evolution. With a data flow diagram, users are able to visualize how the system will operate, what the system will accomplish, and how the system will be implemented. The old system's dataflow diagrams can be drawn up and compared with the new system's data flow diagrams to draw comparisons to implement a more efficient system. Data flow diagrams can be used to provide the end user with a physical idea of where the data they input ultimately has an effect upon the structure of the whole system from order to dispatch to report. How any system is developed can be determined through a data flow diagram. In the course of developing a set of leveled data flow diagrams the analyst/designers is forced to address how the system may be decomposed into component sub-systems, and to identify the transaction data in the data model. There are different notations to draw data flow diagrams (Yourdon & Coad and Gane & Sarson), defining different visual representations for processes, data stores, data flow, and external entities.
AVNEESH GAUR
Page 15
MOHD ZIAUN NABI Combining Data Stores
In a similar way, data stores that are holding related information should be suffixed with a lower case letter. Related data stores can also be combined, and where this is the case the numbers placed after the identifying alphabetic characters are not shown. In the course of developing a set of levelled data-flow diagrams the analyst/designers is forced to address how the system may be decomposed into component sub-systems, and to identify the transaction data in the data model. There are different notations to draw data-flow diagrams, defining different visual representations for processes, data stores, data flow, and external entities. Developing a data-flow diagram
data-flow diagram example
AVNEESH GAUR
Page 16
MOHD ZIAUN NABI Top-down approach
1. The system designer makes "a context level DFD" or Level 0, which shows the "interaction" (data flows) between "the system" (represented by one process) and "the system environment" (represented by terminators). 2. The system is "decomposed in lower-level DFD (Level 1)" into a set of "processes, data stores, and the data flows between these processes and data stores". 3. Each process is then decomposed into an "even-lower-level diagram containing its subprocesses". 4. This approach "then continues on the subsequent subprocesses", until a necessary and sufficient level of detail is reached which is called the primitive process (aka chewable in one bite).
DFD is also a virtually designable diagram that technically or diagrammatically describes the inflow and outflow of data or information that is provided by the external entity. Event partitioning approach Event partitioning was described by Edward Yourdon in Just Enough Structured
Analysis.
A context level Data flow diagram created using Select SSADM.
This level shows the overall context of the system and its operating environment and shows the whole system as just one process. It does not usually show data stores,
AVNEESH GAUR Page 17
MOHD ZIAUN NABI
unless they are "owned" by external systems, e.g. are accessed by but not maintained by this system, however, these are often shown as external entities.[5]
Level 1 (high level diagram)
A Level 1 Data flow diagram for the same system.
This level (level 1) shows all processes at the first level of numbering, data stores, external entities and the data flows between them. The purpose of this level is to show the major high-level processes of the system and their interrelation. A process model will have one, and only one, level-1 diagram. A level-1 diagram must be balanced with its parent context level diagram, i.e. there must be the same external entities and the same data flows, these can be broken down to more detail in the level 1, e.g. the "inquiry" data flow could be split into "inquiry request" and "inquiry results" and still be valid.[5]
AVNEESH GAUR
Page 18
MOHD ZIAUN NABI
Level 2 (low level diagram)
A Level 2 Data flow diagram showing the "Process Enquiry" process for the same system.
This level is a decomposition of a process shown in a level-1 diagram, as such there should be a level-2 diagram for each and every process shown in a level-1 diagram. In this example processes 1.1, 1.2 & 1.3 are all children of process 1, together they wholly and completely describe process 1, and combined must perform the full capacity of this parent process. As before, a level-2 diagram must be balanced with its parent level-1 diagram.
AVNEESH GAUR
Page 19
MOHD ZIAUN NABI Experiment 3
What are the Entity-Relationship Diagrams (ERD) and its process in details? Also describes the examples of ER Diagrams. Answers In software engineering, an entity-relationship model (ER model for short) is an abstract and conceptual representation of data. Entity-relationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic data model of a system, often a relational database, and its requirements in a topdown fashion. Diagrams created by this process are called entity-relationship diagrams or ER diagrams. This article refers to the techniques proposed in Peter Chen's 1976 paper. However, variants of the idea existed previously, and have been devised subsequently. Entity Relationship Diagram Notations Peter Chen developed ERDs in 1976. Since then Charles Bachman and James Martin have added some sligh refinements to the basic ERD principles. Entity An entity is an object or concept about which you want to store information.
Weak Entity
AVNEESH GAUR
Page 20
MOHD ZIAUN NABI
A weak entity is an entity that must defined by a foreign key relationship with another entity as it cannot be uniquely identified by its own attributes alone.
Key attribute A key attribute is the unique, distinguishing characteristic of the entity. For example, an employee's social security number might be the employee's key attribute.
Multivalued attribute A multivalued attribute can have more than one value. For example, an employee entity can have multiple skill values.
Derived attribute A derived attribute is based on another attribute. For example, an employee's monthly salary is based on the employee's annual salary.
Relationships Relationships illustrate how two entities share information in the database structure. Learn how to draw relationships:
MOHD ZIAUN NABI
Cardinality Cardinality specifies how many instances of an entity relate to one instance of another entity. Ordinarily is also closely linked to cardinality. While cardinality specifies the occurrences of a relationship, ordinarily describes the relationship as either mandatory or optional. In other words, cardinality specifies the maximum number of relationships and ordinarily specifies the absolute minimum number of relationships.
Recursive relationship In some cases, entities can be self-linked. For example, employees can supervise other employees. Entity Relationship Diagrams (ERDs) illustrate the logical structure of databases.
AVNEESH GAUR
Page 22
MOHD ZIAUN NABI
Developing an ERD Developing an ERD requires an understanding of the system and its components. Before discussing the procedure, let's look at a narrative created by Professor Harman. How do we start an ERD? 1. Define Entities: these are usually nouns used in descriptions of the system, in the discussion of business rules, or in documentation; identified in the narrative (see highlighted items above).
AVNEESH GAUR
Page 23
MOHD ZIAUN NABI
2. Define Relationships: these are usually verbs used in descriptions of the system or in discussion of the business rules (entity ______ entity); identified in the narrative (see highlighted items above).
3. Add attributes to the relations; these are determined by the queries,and may also suggest new entities, e.g. grade; or they may suggest the need for keys or identifiers. What questions can we ask? a. Which doctors work in which wards? b. How much will be spent in a ward in a given week? c. How much will a patient cost to treat? d. How much does a doctor cost per week? e. Which assistants can a patient expect to see? f. Which drugs are being used? 4. Add cardinality to the relations Many-to-Many must be resolved to two one-to-manys with an additional entity Usually automatically happens Sometimes involves introduction of a link entity (which will be all foreign key) Examples: Patient-Drug 5. This flexibility allows us to consider a variety of questions such as: a. Which beds are free? b. Which assistants work for Dr. X? c. What is the least expensive prescription? d. How many doctors are there in the hospital? e. Which patients are family related?
6. Represent that information with symbols. Generally E-R Diagrams require the use of the following symbols:
MOHD ZIAUN NABI
Reading an ERD It takes some practice reading an ERD, but they can be used with clients to discuss business rules. These allow us to represent the information from above such as the E-R Diagram below:
AVNEESH GAUR
Page 25
MOHD ZIAUN NABI
The Entity Relationship Diagram

We can express the overall logical structure of a database graphically with an E-R diagram. Its components are:

rectangles representing entity sets. ellipses representing attributes. diamonds representing relationship sets. lines linking attributes to entity sets and entity sets to relationship sets.
In the text, lines may be directed (have an arrow on the end) to signify mapping cardinalities for relationship sets. Figures 2.8 to 2.10 show some examples.
AVNEESH GAUR
Page 26
MOHD ZIAUN NABI
Figure 2.7: An E-R diagram
Figure 2.8: One-to-many from customer to account
Figure 2.9: Many-to-one from customer to account
Figure 2.10: One-to-one from customer to account
AVNEESH GAUR
Page 27
MOHD ZIAUN NABI
EXPERIMENT-4
4. What are the Structure Charts and explain its symbols in details? Also explain advantages and disadvantages.
a. Draw a Structure Chart for ATM machine. b. Draw a Structure Chart for Student System Details.
ANSA Structure Chart (SC) in software engineering and organizational theory, is a chart which shows the breakdown of a system to its lowest manageable levels.They are used in structured programming to arrange program modules into a tree. Each module is represented by a box, which contains the module's name. The tree structure visualizes the relationships between modules.
SYMBOLS OF STRUCTURE CHART:The symbols available in STCs are: Symbol Cmnt Name Comment Description Makes a note anywhere in the diagram. Are always surrounded by * characters. A connection point for the initial transition to enter the initial state. Definition Expansion None None
Boundary Point
None
None
Module
A module of software, a routine, either a procedure or a function. A module of software that in the final source code appears within the source code of another module.
Code module Code module
STC
Inclusion Module
STC
Transaction A module that selectively calls one of the Centre set of lower-level modules connected to it on the basis of some condition (it acts like an if-then-else). Library Module A module from a library whose
AVNEESH GAUR
Code module
STC
None
None
Page 28
MOHD ZIAUN NABI Symbol Name Description implementation is not defined by the project. A named object that breaks a single call into two calls on different STCs. Off-Page Connectors are associated with each other if they have the same name. The user can traverse from an Off-Page Connector on one STC to the associated Off-Page Connector on another STC at the same or a different level, directly from the diagram.
0948710023 CSE III YEAR Definition Expansion
Off-Page Connector
None
None
On-Page Connector
A named object that breaks a single call into two calls in the same STC. On-Page Connectors are associated with each other if they have the same name. The user can traverse from an On-Page Connector on one part of an STC to the associated OnPage Connector on another part of the STC directly from the diagram.
None
None
Shared Data A repository of data shared by one or more Data Area modules, used to represent either data definition common to several modules, or preserved between invocations by a single module (such as local static data in the language C), or accessed whenever invoked by a single module.
None
Global Data Area A repository of data shared by all modules that connect to it, used to represent some
AVNEESH GAUR
Data definition
None
Page 29
MOHD ZIAUN NABI Symbol Name
0948710023 CSE III YEAR Description Definition Expansion piece of implementation technology (software and/or hardware based) that stores data in a manner that is independent of any module using that information. Indicates that a module could call another module, and calls it zero or more times at runtime. None None
Module Call
Indicates that a module calls another Module module that thereafter executes in an Invocation independent manner; used for processes and tasks.
None
None
Iterative Module Call
Indicates that one module iteratively calls another module, for example a call within a loop.
None
None
Data Couple Control Couple
An item of data either passed to, or returned by, a module. A control or status value or flag that affects the operation of its recipient module.
Data definition Data definition
None
None
Dialog Couple
An item of data passed to, and updated by, Data a module. definition
None
Function Return
An item of data returned by a module. Data Function returns have no name (it is taken definition from the module they are returning a value from). They cannot, therefore, be named or renamed. Allows you to choose the location of a GIF or JPEG image to be displayed as a diagram symbol or to be embedded in an existing diagram symbol.
None
Picture
None
None
AVNEESH GAUR
Page 30
MOHD ZIAUN NABI
ADVANTAGES OF STRUCTURE CHART:-
Structure charts can are beneficial to visual-spatial learners and to those working outside of the structure. Visual-spatial learns grasp depicted concepts faster than by words. A structure chart allows them to instantly see the big picture and to see the interplay of relationships in the whole. Structure charts also help outsiders to easily ascertain how the company is arranged. For example, corporate attorneys frequently rely on structure charts to gain a basic understanding of how a company is organized. Inside a company, structure charts allow managers to make budgeting and resource allocation decisions as well as acquaint them to the company's employees and their responsibilities .
(a)
Draw a Structure Chart for ATM machine.
AVNEESH GAUR
Page 31
MOHD ZIAUN NABI
(b). Draw a Structure Chart for Student System Details.
AVNEESH GAUR
Page 32
MOHD ZIAUN NABI
EXPERIMENT-5
5. What are the Pseudo Code and its advantages and disadvantages? (a) Write down the Pseudo Code Bubble Sort. (b) Write down the Pseudo Code Binary Search Tree Operations.
ANS:-
Pseudo Code:In computer science and numerical computation, pseudocode is an informal high-level description of the operating principle of a computer program or other algorithm. It uses the structural conventions of a programming language, but is intended for human reading rather than machine reading. Pseudocode typically omits details that are not essential for human understanding of the algorithm, such as variable declarations, system-specific code and some subroutines. The programming language is augmented with natural language description details, where convenient, or with compact mathematical notation. The purpose of using pseudocode is that it is easier for people to understand than conventional programming language code, and that it is an efficient and environmentindependent description of the key principles of an algorithm. It is commonly used in textbooks and scientific publications that are documenting various algorithms, and also in planning of computer program development, for sketching out the structure of the program before the actual coding takes place.
Pseudocode Advantages 1. Can be done easily on a word processor 2. Easily modified 3. Implements structured concepts well Pseudocode Disadvantages 1. It's not visual 2. There is no accepted standard, so it varies widely from company to company
AVNEESH GAUR
Page 33
MOHD ZIAUN NABI
(a)
Write down the Pseudo Code Bubble Sort.
BubbleSort( int a[], int n) Begin for i = 1 to n-1 sorted = true for j = 0 to n-1-i if a[j] > a[j+1] temp = a[j] a[j] = a[j+1] a[j+1] = temp sorted = false end for if sorted break from i loop end for End
AVNEESH GAUR
Page 34
MOHD ZIAUN NABI
(b) Write down the Pseudo Code Binary Search Tree Operations.
find() Operation find(X, node)f if(node = NULL) return NULL if(X = node:data) return node if(X < node:data) return find(X,node:leftChild) else // X > node:data return find(X,node:rightChild) } findMinimum() Operation findMin(node)f if(node = NULL) //empty tree return NULL if(node:leftChild = NULL) return node return findMin(node:leftChild) } insert() Operation insert(X, node)f if(node = NULL)f node = new binaryNode(X,NULL,NULL) return if(X = node:data) return AVNEESH GAUR Page 35
MOHD ZIAUN NABI

} else if(X < node:data) insert(X, node:leftChild) else // X > node:data } insert(X, node:rightChild) }
AVNEESH GAUR
Page 36
MOHD ZIAUN NABI
EXPERIMENT-6
6. What are the CASE Tools and its types in details? Also explain advantages and disadvantages. (a) Write down the CASE Architecture. (b)Write down a Representative List of CASE Products.
ANS:CASE TOOLS:CASE (Computer Aided Software Engineering) technologies are tools that provide the assistance to the developer in the development of software. Main purpose of the CASE tools is to decrease the development time and increase the quality of software. Even the presence of these qualities CASE tools are not being used most often or freely. These tools are not used freely as they should be; there are some points that need improvement, so that the use of CASE tools can be increased. No a days most of the software houses dont bother to use the CASE tools in their development process. And finally the hurdles in the promotion of the CASE tools as a standard. CASE technologies are tools that provide automated assistance for software development to the developers. The goal of introducing CASE tools is to reduce the time of development, reduce the cost of software, and the enhancement of the quality of the software. Upper CASE tools are used to capture, analyze and organize the models of system. These models help designers to focus on the systems linear behaviour. Lower CASE tools are used for development and software maintenance phases. Using these tools developers classify the scope and boundaries, describe current system, model requirements, prototyping, prepare design, etc. Integrated CASE tools provide support for Upper CASE and Lower CASE tool activities. Integrated CASE tools helps specifically in Analysis & Design, Maintenance and system planning. Integrated CASE tools provide the support throughout whole development lifecycle.
USE OF CASE TOOL:The purpose of CASE is to reduce the cost and time required for the system development and the focus is on the quality of the end product. CASE is not being used as it was being expected. Most of the companies are reluctant to adopt the CASE tools. It is observed that CASE is being used but not in many companies. The reasons for abandonment included cost, lack of measurable returns, and unrealistic expectations. Organizations that used CASE tools and found that large numbers of their systems developers were not using CASE tools. He reported that in 57% of the organizations surveyed that were using CASE tools, less than 25% of the systems developers used the tools (Diane Lending 1998). And in those companies where CASE is adopted only few people are using CASE tools. In a survey of 67 companies it has been observed that 69% companies had never used CASE tools. And those people who are using CASE tools admitted that the use of CASE tools improved the standard of documentation and in result the system was
AVNEESH GAUR
Page 37
MOHD ZIAUN NABI
easier to test and maintain. But people who used CASE tools also admitted that using CASE tools requires more time and effort and also adds in overall development time.
TYPES OF CASE TOOLS:On the basis of their activities, sometimes CASE tools are classified into the following categories: 1. Upper CASE tools 2. Lower CASE tools 3. Integrated CASE tools. Upper CASE: Upper CASE tools mainly focus on the analysis and design phases of software development. They include tools for analysis modeling, reports and forms generation. Lower CASE: Lower CASE tools support implementation of system development. They include tools for coding, configuration management, etc. Integrated CASE Tools: Integrated CASE tools help in providing linkages between the lower and upper CASE tools. Thus creating a cohesive environment for software development where programming by lower CASE tools may automatically be generated for the design that has been developed in an upper CASE tool.
(a)
Write down the CASE Architecture.
AVNEESH GAUR
Page 38
MOHD ZIAUN NABI
(b)
Write down a Representative List of CASE Products.
A Representative List of CASE Products Company Microsoft Products
Visual Modeler, Visual Source Safe Rational Rational Rose Digital Equipment Corp. Cohesion Intersolv Excelerator II, PVCS Andersen Consulting Foundation Sterling Software Composer Popkin Software System Architect Hewlett Packard Softbench Oracle Designer PowerSoft Power-Designer LogicWorks ERWIN, BPWIN, OOWIN IBM CMVC, AD/Cycle
AVNEESH GAUR
Page 39
MOHD ZIAUN NABI
EXPERIMENT-7
7. What is the SDLC models and explain different types of SDLC models? Also explain advantages and disadvantages.
(a) Water fall Model (b) Spiral Model (c) Prototype Model (d) EVO Model
SDLC(Software Development Life Cycle):Software Development Life Cycle also known as SDLC is the process of analysis, estimation, design, development, integration, testing and implementation of software system. Proper management of Software Development Life Cycle (SDLC) is critical to success of any software development project. Software Development Life Cycle or SDLC can also be thought as a concept of providing complete support to a product, all the way through its phases of evolution.
Software Development Life Cycle Models:Some of the popular Software Development Life Cycle Models are as below : 1) Water fall Model 2) Incremental Model 3) Iterative Model 4) Spiral Model Each SDLC Model represents different technique to manage software development project. Effectiveness of Software Development Life Cycle is dependent on Scope Restriction, Progressive Enhancement, Pre-defined Structure and Incremental Planning heavily. Selection of proper SDLC can help you solve software development problem effectively.
(A). Water fall Model:AVNEESH GAUR Page 40
MOHD ZIAUN NABI
The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance. The waterfall development model originates in the manufacturing and construction industries: highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.
ADVANTAGES OF WATERFALL MODEL:The advantage of waterfall development is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps. DISADVANTAGES OF WATERFALL MODEL:-
AVNEESH GAUR
Page 41
MOHD ZIAUN NABI
The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), synch and stabilize, build and fix, and the spiral model.
(B). 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. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping and the waterfall model. The spiral model is intended for large, expensive and complicated projects.
Advantages 1. Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier. 2. It is more able to cope with the (nearly inevitable) changes that software development generally entails. 3. Software engineers (who can get restless with protracted design processes) can get
MOHD ZIAUN NABI
their hands in and start working on a project earlier. Disadvantages 1. Highly customized limiting re-usability 2. Applied differently for each application 3. Risk of not meeting budget or schedule 4. Risk of not meeting budget or schedule
(C).PROTOTYPE MODEL:The Prototyping Model is a systems development method (SDM) in which a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed. This model works best in scenarios where not all of the project requirements are known in detail ahead of time. It is an iterative, trialand-error process that takes place between the developers and the users. There are several steps in the Prototyping Model: 1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the departments or 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. The users thoroughly evaluate the first prototype, noting its strengths and weaknesses, what needs to be added, and what should to be removed. The developer collects and analyzes the remarks from the users. 5. The first prototype is modified, based on the comments supplied by the users, and a second prototype of the new system is constructed. 6. The second prototype is evaluated in the same manner as was the first prototype. 7. The preceding steps are iterated as many times as necessary, until the users are satisfied that the prototype represents the final product desired. 8. The final system is constructed, based on the final prototype. 9. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.
MOHD ZIAUN NABI
Advantages of Prototype model 1. Strong Dialogue between users and developers 2. Missing functionality can be identified easily 3. Confusing or difficult functions can be identified 4. Requirements validation, Quick implementation of, incomplete, but functional, application 5. May generate specifications for a production application 6. Environment to resolve unclear objectives 7. Encourages innovation and flexible designs Disadvantages of Prototype model 1. Contract may be awarded without rigorous evaluation of Prototype 2. Identifying non-functional elements difficult to document 3. Incomplete application may cause application not to be used as the full system was designed 4. Incomplete or inadequate problem analysis 5. Client may be unknowledgeable 6. Approval process and requirement is not strict 7. Requirements may frequently change significantly
AVNEESH GAUR
Page 44
MOHD ZIAUN NABI
EXPERIMENT-8
8. What are the Software Requirement Specification and its advantages and disadvantages in details? (a) Write down the SRS for railway reservation system. (b) Write down the SRS for Library Management System ANS:A software requirements specification (SRS) a requirements specification for a software system is a complete description of the behavior of a system to be developed. It includes a set of use cases that describe all the interactions the users will have with the software. In addition to use cases, the SRS also contains non-functional requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints). The software requirement specification document enlists all necessary requirements for project development. To derive the requirements we need to have clear and thorough understanding of the products to be developed. This is prepared after detailed communications with project team and the customer. A general organization of an SRS is as follows. Specific requirements

External interface requirements Functional requirements Performance requirements Design constraints Logical database requirement Software System attributes Other requirements
Benefits of Software Requirement Specification

Below are some good guidelines for what the benefits of a good Software Requirement Specification (SRS): Congruency between the customers (stakeholders) and the suppliers on what the software product is to do. The complete description of the functions to be performed by the
MOHD ZIAUN NABI
software specified in the Software Requirement Specification will help the potential users to determine if the software in question adheres to their needs. Reduce the development effort. The preparation of the Software Requirement Specification forces the various concerned groups in the customers organization to consider rigorously all of the requirements before design begins and reduces later redesign, recoding, and retesting. Careful review of the requirements in the Software Requirement Specification can reveal omissions, misunderstandings, and inconsistencies early in the development cycle when these problems are easier to correct. Provide a basis for estimating costs and schedules. The description of the product to be developed as given in the Software Requirement Specification is a realistic basis for estimating project costs and can be used to obtain approval for bids or price estimates. Provide a baseline for validation and verification. Organizations can develop their validation and Verification plans much more productively from a good Software Requirement Specification. As a part of the development contract, the SRS provides a baseline against which compliance can be measured. Facilitate transfer.The Software Requirement Specification makes it easier to transfer the software product to new users or new machines. Customers thus find it easier to transfer the software to other parts of their organization, and suppliers find it easier to transfer it to new customers. Serve as a basis for enhancement. Because the Software Requirement Specification discusses the product but not the project that developed it, the SRS serves as a basis for later enhancement of the finished product. The SRS may need to be altered, but it does provide a foundation for continued production evaluation.
AVNEESH GAUR
Page 46
MOHD ZIAUN NABI
EXPERIMENT-9
9. What are the feasibility study and its types in details? Also explain advantages and disadvantages. (a) Technical Feasibility Study (b) Operational Feasibility Study (c) Economical Feasibility Study ANS:Feasibility studies aim to objectively and rationally uncover the strengths and weaknesses of the existing business or proposed venture, opportunities and threats as presented by the environment, the resources required to carry through, and ultimately the prospects for success. In its simplest terms, the two criteria to judge feasibility are cost required and value to be attained. As such, a well-designed feasibility study should provide a historical background of the business or project, description of the product or service, accounting statements, details of the operations and management, marketing research and policies, financial data, legal requirements and tax obligations. Generally, feasibility studies precede technical development and project implementation.
Types Of Feasibility Studies:(A).Technology and system feasibility
The assessment is based on an outline design of system requirements in terms of Input, Processes, Output, Fields, Programs, and Procedures. This can be quantified in terms of volumes of data, trends, frequency of updating, etc. in order to estimate whether the new system will perform adequately or not. Technological feasibility is carried out to determine whether the company has the capability, in terms of software, hardware, personnel and expertise, to handle the completion of the project. When writing a feasibility report the following should be taken to consideration:

A brief description of the business to assess more possible factor/s which could affect the study The part of the business being examined The human and economic factor The possible solutions to the problems
AVNEESH GAUR
Page 47
MOHD ZIAUN NABI
At this level, the concern is whether the proposal is both technically and legally feasible (assuming moderate cost).
(B).Economic feasibility
Economic analysis is the most frequently used method for evaluating the effectiveness of a new system. More commonly known as cost/benefit analysis, the procedure is to determine the benefits and savings that are expected from a candidate system and compare them with costs. If benefits outweigh costs, then the decision is made to design and implement the system. An entrepreneur must accurately weigh the cost versus benefits before taking an action. Cost-based study: It is important to identify cost and benefit factors, which can be categorized as follows: 1. Development costs; and 2. Operating costs. This is an analysis of the costs to be incurred in the system and the benefits derivable out of the system. Time-based study: This is an analysis of the time required to achieve a return on investments. The future value of a project is also a factor. (C).Operational feasibility Operational feasibility is a measure of how well a proposed system solves the problems, and takes advantage of the opportunities identified during scope definition and how it satisfies the requirements identified in the requirements analysis phase of system development.
ADVANTAGES OF FEASIBILITY STUDY:There are many advantages for doing a feasibility study, including (but not limited to): - Seeing if the company can afford the project: What if the costs are too high? Why initiate the project if the company doesn't have enough money to do it in the first place? - Seeing if the company has the resources to do the project: What if the company doesn't have enough resources for this project? What if the resources that the company has do not have the necessary (usually technical) experience to execute the project? -Seeing if the project has an acceptable ROI: What if it turns out that the project, after calculating the ROI does not provide a decent return on investment, or even worse, what if the project will lose money? A feasibility study will catch this!
MOHD ZIAUN NABI
DISADVANTAGES OF FEASIBILITY STUDY: Hardware/software selection How to convince management to develop the new system Selection among alternative financing arrangements (rent/lease/purchase)
AVNEESH GAUR
Page 49
MOHD ZIAUN NABI
EXPERIMENT-10
10. Describe the COCOMO Model in details. Also explain advantages and disadvantages. (a) Write down COCOMO Model for cost estimation. (b) Write down COCOMO Model for Source Lines of Codes (LOC).
ANS:Short for Constructive Cost Model, a method for evaluating and/or estimating the cost of software development. There are three levels in the COCOMO hierarchy:
Basic COCOMO: computes software development effort and cost as a function of program size expressed in estimated DSIs. There are three modes within Basic COCOMO: o Organic Mode: Development projects typically are uncomplicated and involve small experienced teams. The planned software is not considered innovative and requires a relatively small amount of DSIs (typically under 50,000). o Semidetached Mode: Development projects typically are more complicated than in Organic Mode and involve teams of people with mixed levels of experience. The software requires no more than 300,000 DSIs. The project has characteristics of both projects for Organic Mode and projects for Embedded Mode. o Embedded Mode: Development projects must fit into a rigid set of requirements because the software is to be embedded in a strongly joined complex of hardware, software, regulations and operating procedures. Intermediate COCOMO: an extension of the Basic model that computes software development effort by adding a set of "cost drivers," that will determine the effort and duration of the project, such as assessments of personnel and hardware. Detailed COCOMO: an extension of the Intermediate model that adds effort multipliers for each phase of the project to determine the cost driver??s impact on each step.
COCOMO was developed by Barry Boehm in his 1981 book, Software Engineering Economics.
AVNEESH GAUR
Page 50
MOHD ZIAUN NABI
Advantages of COCOMO estimating model. Advantages of COCOMO estimating model are: a. COCOMO is factual and easy to interpret. One can clearly understand how it works. b. Accounts for various factors that affect cost of the project. c. Works on historical data and hence is more predictable and accurate. Disadvantages of COCOMO estimating model. Disadvantages: a. COCOMO model ignores requirements and all documentation. b. It ignores customer skills, cooperation, knowledge and other parameters. c. It oversimplifies the impact of safety/security aspects. d. It ignores hardware issues e. It ignores personnel turnover levels f. It is dependent on the amount of time spent in each phase.
AVNEESH GAUR
Page 51

SE

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SE

Hochgeladen von

Copyright:

Verfügbare Formate

MOHD ZIAUN NABI

0948710023 CSE III YEAR

MOHD ZIAUN NABI MEANING OF A FLOWCHART

0948710023 CSE III YEAR

A flowchart is a diagrammatic representation that illustrates the sequence of

Flowcharts are generally drawn in the early stages of formulating computer

Flowcharts facilitate communication between programmers and business people.

It is correct to say that a flowchart is a must for the better documentation of a

The two most common types of boxes in a flowchart are:

MOHD ZIAUN NABI

0948710023 CSE III YEAR

GUIDELINES FOR DRAWING A FLOWCHART

MOHD ZIAUN NABI

0948710023 CSE III YEAR

Start or end of the program Computational steps or processing function of a program

Input or output operation

Decision making and branching Connector or joining of two parts of program

MOHD ZIAUN NABI

0948710023 CSE III YEAR

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

MOHD ZIAUN NABI

0948710023 CSE III YEAR

MOHD ZIAUN NABI

0948710023 CSE III YEAR

MOHD ZIAUN NABI

0948710023 CSE III YEAR

MOHD ZIAUN NABI

0948710023 CSE III YEAR

MOHD ZIAUN NABI

0948710023 CSE III YEAR

MOHD ZIAUN NABI

0948710023 CSE III YEAR

MOHD ZIAUN NABI

0948710023 CSE III YEAR

MOHD ZIAUN NABI

0948710023 CSE III YEAR

Fig 25.4 Flowchart for computing factorial N

MOHD ZIAUN NABI

0948710023 CSE III YEAR

MOHD ZIAUN NABI

0948710023 CSE III YEAR

MOHD ZIAUN NABI Combining Data Stores

0948710023 CSE III YEAR

data-flow diagram example

MOHD ZIAUN NABI Top-down approach

0948710023 CSE III YEAR

A context level Data flow diagram created using Select SSADM.

MOHD ZIAUN NABI

0948710023 CSE III YEAR

Level 1 (high level diagram)

A Level 1 Data flow diagram for the same system.

MOHD ZIAUN NABI

0948710023 CSE III YEAR

Level 2 (low level diagram)

MOHD ZIAUN NABI Experiment 3

0948710023 CSE III YEAR

MOHD ZIAUN NABI

0948710023 CSE III YEAR

MOHD ZIAUN NABI

0948710023 CSE III YEAR

MOHD ZIAUN NABI

0948710023 CSE III YEAR

MOHD ZIAUN NABI

0948710023 CSE III YEAR