Showing posts with label notes of software engineering. Show all posts
Showing posts with label notes of software engineering. Show all posts

Sunday, 16 March 2014


Decision table:

A decision table is used to represent the complex processing logic in a tabular or a matrix form. The upper rows of the table specify the variables or conditions to be evaluated. The lower rows of the table specify the actions to be taken when the corresponding conditions are satisfied.
Decision tree :

A decision tree gives a graphic view of the processing logic involved in decision making and the corresponding actions taken. The edges of a decision tree represent conditions and the leaf nodes represent the actions to be performed depending on the outcome of testing the condition.

Example: -
    The important properties of a good SRS document are the         following:
    There are six properties of good SRS document:
      1.concise
      2.structured
      3.black- box view
      4.conceptual integrity
      5.Response to undesired events
      6.verifiable
ƒ Concise: The SRS document should be concise and at the same time unambiguous, consistent, and complete. Verbose and irrelevant descriptions reduce readability and also increase error possibilities.

Saturday, 8 February 2014

Parts of a SRS document
    The important parts of SRS document are:

  • ƒ       Functional requirements of the system 
  •        Non-functional requirements of the system 
  •        Goals of implementation

Functional requirements:-

ƒ     The functional requirements part discusses the functionalities required from the system.
Role of a system analyst

The analyst starts requirements gathering and analysis activity by collecting all information from the customer which could be used to develop the requirements of the system. He then analyzes the collected information to obtain a clear and thorough understanding of the product to be developed,

Friday, 7 February 2014

Comparison of different life-cycle models

The classical waterfall model can be considered as the basic model and all other life cycle models as embellishments of this model. However, the classical waterfall model can not be used in practical development projects

Tuesday, 4 February 2014

Spiral model


The Spiral model of software development is shown in fig. 2.2. The diagrammatic representation of this model appears like a spiral with many loops. The exact number of loops in the spiral is not fixed. Each loop of the spiral represents a phase of the software process. For example, the innermost loop might be concerned with feasibility study. The next loop with

Prototype 

A prototype is a toy implementation of the system. A prototype usually exhibits limited functional capabilities, low reliability, and inefficient performance compared to the actual software. A prototype is usually built using several shortcuts. The shortcuts might involve using inefficient, inaccurate,

Phase-entry and phase-exit criteria of each phase


At the starting of the feasibility study, project managers or team leaders try to understand what is the actual problem by visiting the client side. At the end of that phase they pick the best solution and determine whether the solution is feasible financially and technically.

At the starting of requirements analysis and specification phase the required data is collected. After that requirement specification is carried out. Finally,


The classical waterfall model is an idealistic one since it assumes that no development error is ever committed by the engineers during any of the life cycle phases. However, in practical development environments,

  the engineers do commit a large number of errors in almost every phase of the life cycle.  The source of the defects can be many:
  •  oversight
  • wrong assumptions

 phase of the life cycle of waterfall model


 feasibility study: -  

The main aim of feasibility study is to determine whether it would be financially and technically feasible to develop the product.

ƒ     At first project managers or team leaders try to have a rough understanding of what is required to be done by visiting the client side. They study different input data to the system and output data to be produced by the system.

Monday, 3 February 2014

Different phases of the classical waterfall model


The classical waterfall model is intuitively the most obvious way to develop software. Though the classical waterfall model is elegant and intuitively obvious, it is not a practical model in the sense that it can not be used in actual software development projects. Thus, this model can be considered to be a theoretical way of developing software. But all other life cycle models are essentially derived from the classical waterfall model.

Different software life cycle models


Many life cycle models have been proposed so far. Each of them has some advantages as well as some disadvantages. A few important and commonly used life cycle models are as follows:

  • ƒClassical Waterfall Model
  • ƒIterative Waterfall Model

Evolution of software design techniques .


During the 1950s, most programs were being written in assembly language. These programs were limited to about a few hundreds of lines of assembly code, i.e. were very small in size. Every programmer developed programs in his own individual style - based on his intuition. This type of programming was called Exploratory Programming.

The next significant development which occurred during early 1960s in the area computer programming was the high-level language programming.

Important advantages of structured programming.


  • Structured programs are easier to read and understand.
  •  Structured programs are easier to maintain.

Scope and necessity:-

  Software engineering is an engineering approach for software development. we can alternatively view it as a systematic collection of past experience. The experience is arranged in the form of methodologies and guidelines. A small can be written without using software engineering principles. But if one  wants to develop a large software product, then software engineering principles   are indispensable to achieve a good quality software cost effectively. These can be elaborated with the help of a building construction analogy