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
Agile
Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
Scrum
Scrum is an agile development framework that allows teams to adapt to the changing nature of requirements by delivering software in small pieces that can be used to garner feedback from the stakeholders and users. This radically improves the quality of a final product as well as reducing risk along with long return on investment is realized sooner. Scrum term is actually In rugby, ‘scrum’ is the term for a mass of players engaged with each other to get a job done.
Scrum just provides a framework and leaves the task of description of the methodology to the developers and the development team. Scrum includes all the major functionality of agile software development process, which are known as the five manifesto of agile software development process. It gives preference to individuals and interactions over processes and tools, customer collaboration over contract negotiation, working software over comprehensive documentation and responding to change over following a plan.
Scrum framework is briefly explained here
[Here http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2012/ch2a_2w6_ar#Advantage_of_Scrum_over_traditional_classical_models] are few advantages of scrum over traditional classical models.
Fundamental Roles in Scrum practice are:
There are several activities which form the basis of scrum implementation for team management. Following are the various sprint activities:
In Scrum, work or tasks allotted to a particular team or a group of team is limited to a regular, repeatable work cycle, known as a sprint. Thus sprint is called the basic unit of development in Scrum. Ideally a sprint is considered as 30 days long, but many teams prefer shorter sprints, such as two-week, or three-week sprints depending on the sprint capacity and sprint velocity. But how long each sprint lasts is something for the team to decide considering the advantages or disadvantages of a longer or shorter sprint for their specific development environment.
Here is a real world example of scrum.
Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the sprint backlog. There are also open-source and proprietary packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their artifacts in hard-copy forms such as paper, whiteboards and sticky notes.
Here are some of the factors which should be considered before selecting the correct scrum tool:
Some of the examples of open-source scrum project management tools are:
Some of the examples of proprietary scrum project management tools are:
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:
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:
3) Behavioral Pattern, which are concerned with communication between objects. Some of the behavioral design patterns in the wiki 2b are:
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
Software design principles represent a set of guidelines that help us to avoid having a bad design. An example of a design principle in the wiki 2b topics is Law of Demeter. Law of demeter(LoD) states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B in this case and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.
References
<references/>