CSC/ECE 517 Fall 2012/Table of Contents for wiki 2b topics

Introduction

This wiki page will give you the outline of the topics from Wiki 2a. A brief introduction to the topics covered(in 2a) and the links to the appropriate topic is available on this page.

Software Process Models

The software process model maybe defined as a simplified description of a software process, presented from a particular perspective. In essence, each stage of the software process is identified and a model is then employed to represent the inherent activities associated within that stage. Consequently, a collection of ‘local’ models may be utilized in generating the global picture representative of the software process. Examples of models include the waterfall model, spiral model, and the V-model.

• The spiral model is a software development process that combines the elements of both design and prototyping-in-stages.This model represents a risk-driven approach to software process analysis. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model incorporates many of the strengths of other models and resolves many of their difficulties. It combines the advantages of top-down and bottom-up concepts and promotes quality assurance through prototyping at each stage.Thus it includes the features of both prototyping and the waterfall model but provides emphasis in a key area which is mostly neglected by other methodologies: deliberate iterative risk analysis. Generally,the spiral model is intended for large, expensive and complicated projects.This approach incorporates elements of specification-driven, prototype-driven process methods, together with the classic software life cycle. More details can be found here

• The V-model also called as Verification and Validation model is a software development process which simplifies the understanding of the complexity associated with the development of a system, and is an extension to the waterfall model. Rather than proceeding linearly downwards, after the coding phase, the process steps are bent upwards to form a V shape. This creates an association between the phases in the development and the testing cycle. More details can be found here

Design Patterns

A Design Pattern in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. The idea was introduced by the architect Christopher Alexander in the field of architecture and has been adapted for various other disciplines, including computer science. An organized collection of design patterns that relate to a particular field is called a pattern language.

"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" - Christopher Alexander.

"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design".

The different types of design patterns can be categorized and listed as below:

1) Creational Pattern, which help create the objects for the user, instead of having the user to instantiate the object. Some of the creational patterns in the wiki 2b are:

• Abstract Factory Pattern
• Builder Pattern

2) Structural Pattern, which employ interfaces to achieve inheritance to enable objects to obtain new functionality. Some of the structural patterns in the wiki 2b are:

• Adapter Design Pattern

3) Behavioral Pattern, which are concerned with communication between objects. Some of the behavioral design patterns in the wiki 2b are:

• Template Method Pattern
• State Pattern

Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way. As the fragility becomes worse, the probability of breakage increases with time, asymptotically approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost. More details of Pattern Fragility is given here.

References

<references/>

http://en.wikipedia.org/wiki/Design_pattern