A software development process is a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process.

Phases

There exist several process steps, phases, in each model. They all concern one or several of the following terms:

Domain Analysis

Often the first step in attempting to design a new piece of software, whether it be an addition to an existing software, a new application, a new subsystem or a whole new system, is, what is generally referred to as "Domain Analysis". Assuming that the developers (including the analysts) are not sufficiently knowledgeable in the subject area of the new software, the first task is to investigate the so-called "domain" of the software. The more knowledgeable they are about the domain already, the less work required. Another objective of this work is to make the analysts, who will later try to elicit and gather the requirements from the area experts, speak with them in the domain's own terminology, facilitating a better understanding of what is being said by these experts.

Software Elements Analysis

The most important task in creating a software product is extracting the requirements. Customers typically have an abstract idea of what they want as an end result, but not what software should do. Incomplete, ambiguous, or even contradictory requirements are recognized by skilled and experienced Redstone software engineers at this point.

Scope Analysis

Once the general requirements are gleaned from the client, an analysis of the scope of the development should be determined and clearly stated. This is often called a scope document. Certain functionality may be out of scope of the project as a function of cost or as a result of unclear requirements at the start of development. If the development is done externally, this document can be considered a legal document so that if there are ever disputes, any ambiguity of what was promised to the client can be clarified.

Read more

Specification

Specification is the task of precisely describing the software to be written, possibly in a rigorous way. Specifications are most important for external interfaces that must remain stable. A good way to determine whether the specifications are sufficiently precise is to have a third party review the documents making sure that the requirements are logically sound.

Software architecture

The architecture of a software system refers to an abstract representation of that system. Architecture is concerned with making sure the software system will meet the requirements of the product, as well as ensuring that future requirements can be addressed. The architecture step also addresses interfaces between the software system and other software products, as well as the underlying hardware or the host operating system.

Read more

Implementation

This is the part of the process where software developers actually program the code for the project.

Read more

Testing

Testing software is an integral and highly important part of the software development process. This part of the process ensures that bugs are recognized as early as possible.

Read more

Deployment

After the code is appropriately tested, it is approved for release and sold or otherwise disbursed into a production environment.

Documentation

Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the authoring of an API, be it external or internal.

Read more

Training and Support

A large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are often resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to have training classes for new clients of your software.

Read more

Maintenance

Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. It may be necessary to add code that does not fit the original design to correct an unforeseen problem or it may be that a customer is requesting more functionality and code can be added to accommodate their requests. It is during this phase that customer calls come in and you see whether your testing was extensive enough to uncover the problems before customers do.

Read more

Process Models

Waterfall processes

Waterfall model

The best-known and oldest process is the waterfall model, where developers are to follow these steps in order.

1. Requirements specification (AKA Verification)
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA validation)
6. Installation
7. Maintenance

After each step is finished, the process proceeds to the next step

Iterative processes

Iterative development

Iterative development prescribes the construction of initially small but even larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster. Iterative processes are preferred by commercial developers because it allows a potential of reaching the design goals of a customer who does not know how to define what they want.

Agile software development

Agile software development processes are built on the foundation of iterative development. To that foundation they add a lighter, more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

Extreme Programming

Extreme Programming (XP) is the best-known iterative process. In XP, the phases are carried out in extremely small (or "continuous") steps compared to the older, "batch" processes. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than the months or years of each complete step in the Waterfall model. First, one writes automated tests, to provide concrete goals for development. Next is coding (by a pair of programmers), which is complete when all the tests pass, and the programmers can't think of any more tests that are needed. Design and architecture emerge out ofrefactoring , and come after coding. Design is done by the same people who do the coding. (Only the last feature - merging design and code - is common to all the other agile processes.) The incomplete but functional system is deployed or demonstrated for (some subset of) the users (at least one of which is on the development team). At this point, the practitioners start again on writing tests for the next most important part of the system.

Test Driven Development

Test Driven Development (TDD) is a useful output of the Agile camp but some suggest that it raises a conundrum. TDD requires that a unit test be written for a class before the class is written. It might be thought, then, that the class firstly has to be "discovered" and secondly defined in sufficient detail to allow the write-test-once-and-code-until-class-passes model that TDD actually uses. This would be actually counter to Agile approaches, particularly (so-called) Agile Modeling, where developers are still encouraged to code early, with light design. However, to get the claimed benefits of TDD a full design down to class and responsibilities (captured using, for example, Design By Contract) is not necessary. This would count towards iterative development, with a design locked down, but not iterative design - as heavy refactoring and re-engineering might negate the usefulness of TDD.

Scrum

Scrum is a process skeleton that includes a set of practices and predefined roles. The main roles in scrum are the ScrumMaster who maintains the processes and works similar to a project manager, the Product Owner who represents the stakeholders and the Team which includes the developers.

During each sprint, a 15-30 day period (length decided by the team), the team creates an increment of potential shippable (usable) software. The set of features that go into each sprint come from the product backlog, which is a prioritized set of high level requirements of work to be done. What backlog items go into the sprint is determined during the sprint planning meeting. During this meeting the Product Owner informs the team of the items in the product backlog that he wants completed. The team then determines how much of this they can commit to complete during the next sprint. During the sprint, no one is able to change the sprint backlog, which means that the requirements are frozen for sprint.

There are several good implementations of systems for managing the Scrum process and the "sprints" while other prefer to use yellow stickers and white-boards. One of Scrum's biggest advantage is that it is very easy to learn and requires little effort in general terms to start using.

Prototyping

Prototyping

Prototyping is the process of quickly putting together a working model (a prototype) in order to test various aspects of a design, illustrate ideas or features and gather early user feedback. Prototyping is often treated as an integral part of the system design process, where it is believed to reduce project risk and cost. Often one or more prototypes are made in a process of iterative and incremental development where each prototype is influenced by the performance of previous designs, in this way problems or deficiencies in design can be corrected. When the prototype is sufficiently refined and meets the functionality, robustness, manufacturability and other design goals, the product is ready for production.

There exist tons of other approaches for software development, but the presented processes above is the most common in Redstone’s work context. There also exist positive and negative elements for each of the listed processes. If you need to discuss this further, please contact us for more elaboration.

Client Requirements/Trends

• Evolving business and technology requirements (requirements is a moving target)
• Outsourcing means higher demands of accurate requirements and documentations when a global team is working on the same task, even in small and mid-sized projects
• Waterfall approach is used in high risk projects
• Agile, TDD and Scrum getting more popular
• Increased productivity for agile models (source: survey, published in August 2006 by VersionOne and Agile Alliance)

Redstone Offering/Experiences

• Redstone offering you consultants and/or subcontractors for all phases within software development; both for new projects, change requests, training or only if you need to stabilize a critical path in ongoing project.
• Select process model based on what kind of project we are running
• Recommendation for time and cost-effective tools that help organizations achieve project business goals effectively
• Make sure all parties is aware of what process model documentation is expected

Success Key 2: Involve customer in the complete development process and try to have iterative deliverables to reduce risk in all layers.

Meaning; Give the customer (a technical responsible, not necessary end-customers) option to address feedback in early steps and also increase possibility for acceptance from end-customer when the system is deployed.

Business Value

• A well defined structure about the target and how we get there
• Alignment between IT and business goals
• Enhanced ability to manage changing priorities by using Agile methods

By partnering with Redstone you are always assured of:

• Resources familiar with several well known software methods and processes used in both large, mid-sized and small projects