2014 ~ Mechanical Engineering

Tuesday 1 July 2014

Functional independence and its need | Software engineering

Posted by Roy on 23:30

Functional independence

A module having high cohesion and low coupling is said to be functionally independent of other modules. By the term functional independence, we mean that a cohesive module performs a single task or function. A functionally independent module has minimal interaction with other modules.

Need for functional independence

Functional independence is a key to any good design due to the following reasons:

•     Error isolation: Functional independence reduces error propagation. The reason behind this is that if a module is functionally independent, its degree of interaction with the other modules is less. Therefore, any error existing in a module would not directly effect the other modules.

•     Scope of reuse: Reuse of a module becomes possible. Because each module does some well-defined and precise function, and the interaction of the module with the other modules is simple and minimal. Therefore, a cohesive module can be easily taken out and reused in a different program.

•     Understandability: Complexity of the design is reduced, because different modules can be understood in isolation as modules are more or less independent of each other.

Monday 31 March 2014

Coupling and its types | software design

Posted by Roy on 08:57

Coupling

Coupling between two modules is a measure of the degree of interdependence or interaction between the two modules. A module having high cohesion and low coupling is said to be functionally independent of other modules. If two modules interchange large amounts of data, then they are highly interdependent. The degree of coupling between two modules depends on their interface complexity.
Types of coupling

Data coupling
Stamp coupling
Control coupling
Common coupling
Content coupling

Data coupling: Two modules are data coupled, if they communicate through a parameter. An example is an elementary data item passed as a parameter between two modules, e.g. an integer, a float, a character, etc. This data item should be problem related and not used for the control purpose.

Stamp coupling: Two modules are stamp coupled, if they communicate using a composite data item such as a record in PASCAL or a structure in C.

Control coupling: Control coupling exists between two modules, if data from one module is used to direct the order of instructions execution in another. An example of control coupling is a flag set in one module and tested in another module.

Common coupling: Two modules are common coupled, if they share data through some global data items.

Content coupling: Content coupling exists between two modules, if they share code, e.g. a branch from one module into another module.

Cohesion and its type | software design

Posted by Roy on 08:48

Cohesion
Cohesion is a measure of functional strength of a module. A module having high cohesion and low coupling is said to be functionally independent of other modules. By the term functional independence, we mean that a cohesive module performs a single task or function. A functionally independent module has minimal interaction with other modules.

Types of cohesion:

coincidental cohesion
logical cohesion
Temporal cohesion
Procedural cohesion
Communicational cohesion
Sequential cohesion
Functional cohesion

Coincidental cohesion: A module is said to have coincidental cohesion, if it performs a set of tasks that relate to each other very loosely, if at all. In this case, the module contains a random collection of functions. It is likely that the functions have been put in the module out of pure coincidence without any thought or design. For example, in a transaction processing system (TPS), the get-input, print-error, and summarize-members functions are grouped into one module. The grouping does not have any relevance to the structure of the problem.

Logical cohesion: A module is said to be logically cohesive, if all elements of the module perform similar operations, e.g. error handling, data input, data output, etc. An example of logical cohesion is the case where a set of print functions generating different output reports are arranged into a single module.

Temporal cohesion: When a module contains functions that are related by the fact that all the functions must be executed in the same time span, the module is said to exhibit temporal cohesion. The set of functions responsible for initialization, start-up, shutdown of some process, etc. exhibit temporal cohesion.

Procedural cohesion: A module is said to possess procedural cohesion, if the set of functions of the module are all part of a procedure (algorithm) in which certain sequence of steps have to be carried out for achieving an objective, e.g. the algorithm for decoding a message.

Communicational cohesion: A module is said to have communicational cohesion, if all functions of the module refer to or update the same data structure, e.g. the set of functions defined on an array or a stack.

Sequential cohesion: A module is said to possess sequential cohesion, if the elements of a module form the parts of sequence, where the output from one element of the sequence is input to the next. For example, in a TPS, the get-input, validate-input, sort-input functions are grouped into one module.

Functional cohesion: Functional cohesion is said to exist, if different elements of a module cooperate to achieve a single function. For example, a module containing all the functions required to manage employees’ pay-roll exhibits functional cohesion. Suppose a module exhibits functional cohesion and we are asked to describe what the module does, then we would be able to describe it using a single sentence

Monday 24 March 2014

Software design and its types

Posted by Roy on 06:25

Software design deals with transforming the customer requirements, as described in the SRS document, into a form (a set of documents) that is suitable for implementation in a programming language. A good software design is seldom arrived by using a single step procedure but rather through several iterations through a series of steps.

Design activities can be broadly classified into two important parts:

Sunday 16 March 2014

Formal technique | Formal specification language| Formal requirements specification

Posted by Roy on 06:41

Formal technique

A formal technique is a mathematical method to specify a hardware and/or software system, verify whether a specification is realizable, verify that an implementation satisfies its specification, prove properties of a system without necessarily running the system, etc. The mathematical basis of a formal method is provided by the specification language.

Decision table | Requirement analysis and specification

Posted by Roy on 06:21

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.

Dicision tree | Requirement analysis and specification

Posted by Roy on 04:21

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: -

properties of SRS documents | SRS documents

Posted by Roy on 00:00

    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

Role of Software Architecture

Posted by Roy on 07:11

What is architecture?
Generally speaking, architecture of a system provides a very high level view of the parts of the system and how they are related to form the whole system. That is, architecture partitions the system in logical parts such that each part can be comprehended independently, and then describes the system in terms of these parts and the relationship between these parts

Architecture Views of software engineering

Posted by Roy on 02:46

There is a general view emerging that there is no unique architecture of a system. The definition that we have adopted (given above) also expresses this sentiment. Consequently, there is no one architecture drawing of the system. The situation is similar to that of civil construction, a discipline that is the original user of the concept of architecture and from where the concept of software architecture has been borrowed.

SRS document |Parts of a SRS document |software engineering

Posted by Roy on 02:35

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 | Requirement and analysis |software engineering

Posted by Roy on 02:07

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 | software engineering

Posted by Roy on 23:19

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 |life cycle model|software engineering

Posted by Roy on 21:23

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 Life Cycle Model | software engineering

Posted by Roy on 20:46

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 |life cycle model | software engineering

Posted by Roy on 20:38

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,

Shortcomings of the classical waterfall model | waterfall model | software engineering

Posted by Roy on 20:29

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 waerfall model |waterfall model |software engineering

Posted by Roy on 20:21

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

phase of waterfall model |software engineering

Posted by Roy on 22:58

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.

Types of software life cycle models | software engineering

Posted by Roy on 22:46

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

need for a software life cycle model |software engineering

Posted by Roy on 22:40

The need for a software life cycle model

The development team must identify a suitable life cycle model for the particular project and then adhere to it. Without using of a particular life cycle model the development of a software product would not be in a systematic and disciplined manner.

When a software product is being developed by a team there must be a clear understanding among team members about when and what to do. Otherwise it would lead to chaos and project failure.

Basics of Software Life Cycle | software engineering

Posted by Roy on 22:37

Life cycle model

A software life cycle model (also called process model) is a descriptive and diagrammatic representation of the software life cycle.
A life cycle model represents all the activities required to make a software product transit through its life cycle phases. It also captures the order in which these activities are to be undertaken.

Exploratory style vs. modern style of software development. | software development | software engineering

Posted by Roy on 22:22

Difference between Exploratory style and modern style of software development

An important difference is that the exploratory software development style is based on error correction while the software engineering principles are primarily based on error prevention. Inherent in the software engineering principles is the realization that it is much more cost-effective to prevent errors from occurring than to correct them as and when they are detected.

Read More [...]

Evolution of software design techniques | software engineering

Posted by Roy on 22:16

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.

advantages of structured programming | software engineering

Posted by Roy on 22:10

Important advantages of structured programming.

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

Important features of a structured program.| Structured Programming |software engineering

Posted by Roy on 22:04

Important features of a structured program.

A structured program uses three types of program constructs

selection,

sequence

and iteration.

Read More [...]

Program vs. software product | software engineering

Posted by Roy on 21:28

Difference between program and software product:

Programs are developed by individuals for their personal use. They are therefore, small in size and have limited functionality but software products are extremely large. In case of a program, the programmer himself is the sole user but on the other hand,

Read More [...]

Causes of software crisis and solutions for software crisis. |software engineering

Posted by Roy on 21:21

Causes of and solutions for software crisis

Software engineering appears to be among the few options available to tackle the present software crisis.

To explain the present software crisis in simple words, consider the following.

The expenses that organizations all around the world are incurring on software purchases compared to those on hardware purchases have been showing a worrying trend over the years .Organizations are spending larger and larger portions of their budget on software.

Read More [...]

Scope and necessity of software engineering

Posted by Roy on 03:34

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

{ Mechanical Engineering }

Tuesday 1 July 2014

Monday 31 March 2014

Monday 24 March 2014

Sunday 16 March 2014

Saturday 8 February 2014

Friday 7 February 2014

Tuesday 4 February 2014

Spiral model

Prototype

Phase-entry and phase-exit criteria of each phase

phase of the life cycle of waterfall model

feasibility study: -

Monday 3 February 2014

Different phases of the classical waterfall model

Different software life cycle models

The need for a software life cycle model

Life cycle model

Difference between Exploratory style and modern style of software development

Evolution of software design techniques .

Important advantages of structured programming.

Important features of a structured program.

Difference between program and software product:

Causes of and solutions for software crisis

Scope and necessity:-

Search

Popular Posts

Blogger templates

Blogger news

Blogroll

Archives

Pages

Ads 468x60px

Followers

About Me

Labels