Chapter1

Introduction to Software Development

1.1 Life Cycle of a Software Development Project

Software development is a complicated process comprising many stages. Each stage requires a
Lot of paperwork and documentation in addition to the development and planning process.
Each software development project has to go through at least the following stages:
 Requirement gathering
 Writing functional specifications
 Creating architecture and design documents
 Implementation and coding
 Testing and quality assurance
 Software release
 Documentation
 Support and new features

There may be many additional steps and stages depending upon the nature of the software
product. You may have to go through multiple cycles during the testing phase as software testers
find problems and bugs and developers fix them before a software product is officially released.
Let us go into some detail of these stages.
1.1.1 Requirement Gathering
Requirement gathering is usually the first part of any software product. This stage starts when
you are thinking about developing software. In this phase, you meet customers or prospective
customers, analyzing market requirements and features that are in demand. You also find out. If
there is a real need in the market for the software product you are trying to develop.
A comprehensive understanding of the customers’ needs and writing down features of the proposed
software product are the keys to success in this phase. This phase is actually a base for the whole
development effort. If the base is not laid correctly, the product will not find a place in the market. If you
develop a very good software product which is not required in the market, it does not matter how well you
build it. You can find many stories about software products that failed in the market because the
customers did not require them.

1.1.2 Writing Functional Specifications

Functional specifications may consist of one or more documents. Functional specification

documents show the behavior or functionality of a software product on an abstract level.
Assuming the product is a student registration, the functional specifications define its
input/output behavior.
Functional specifications are based upon the product requirements documentation put forward by
people who have contact with the end user of the product or the customers.

1|P ag e
Event Driven Programming
In larger products, functional specifications may consist of separate documents for each feature
of the product. For example, in a router product, you may have a functional specification
document for RIP (Routing Information Protocol), another for security features, and so on.
Functional specifications are important because developers use them to create design documents.
The documentation people also use them when they create manuals for end users. If different
groups are working in different physical places, functional specifications and architecture
documents (discussed next) are also a means to communicate among them.

1.1.3 Creating Architecture and Design Documents

When you have all of the requirements collected and arranged, it is the turn of the technical
architecture team, consisting of highly qualified technical specialists, to create the architecture of
the product. The architecture defines different components of the product and how they interact
with each other. In many cases the architecture also defines the technologies used to build the
product. While creating the architecture documents of the project, the team also needs to
consider the timelines of the project. This refers to the target date when the product is required to
be on the market.
Based on the timeline, the architecture team may drop some features of the product if it is not
possible to bring the full-featured product to market within the required time limits.
Once components of the product have been decided and their functionality defined, interfaces are
designed for these components to work together. In most cases, no component works in isolation;
each one has to coordinate with other components of the product. Interfaces are the rules and
regulations that define how these components will interact with each other. There may be major
problems down the road if these interfaces are not designed properly and in a detailed way.
Different people will work on different components of any large software development project
and if they don’t fully understand how a particular component will communicate with others,
integration becomes a major problem.
The design document is the last document completed before development of the software begins.
These design documents are passed on to software developers and they start coding.

1.1.4 Implementation and Coding

The software developers take the design documents and development tools (editors, compilers,
debuggers etc.) and start writing software. This is usually the longest phase in the product life
cycle. Each developer has to write his/her own code and collaborate with other developers to
make sure that different components can interoperate with each other. A revision control system
such as CVS (Concurrent Versions System) is needed in this phase. There are a few other open
source revision control systems as well as commercial options. The version control system pro-
vides a central repository to store individual files. A typical software project may contain
anywhere from hundreds to thousands of files. In large and complex projects, someone also
needs to decide directory hierarchy so that files are stored in appropriate locations. During the
development cycle, multiple persons may modify files. If everyone is not following the rules,
this may easily break the whole compilation and building process. For example, duplicate
definitions of the same variables may cause problems.
Coding guidelines should also be defined by architects or senior software developers.

2|P ag e
Event Driven Programming
During the implementation process, developers must write enough comments inside the code so
that if anybody starts working on the code later on, he/she is able to understand what has already
been written. Writing good comments is very important as all other documents, no matter how
good they are, will be lost eventually.
Development tools also play an important role in this phase of the project. Good development
tools save a lot of time for the developers, as well as saving money in terms of improved
productivity. The most important development tools for time saving are editors and debuggers. A
good editor helps a developer to write code quickly. A good debugger helps make the written
code operational in a short period of time. Before starting the coding process, you should spend
some time choosing good development tools.
Review meetings during the development phase also prove helpful. Potential problems are
caught earlier in the development. These meeting are also helpful to keep track of whether the
product is on time or if more effort is needed complete it in the required time frame. Review
meetings are a great tool to convey these new requirements.

1.1.5 Testing

Testing is probably the most important phase for long-term support as well as for the reputation
of the company. If you don’t control the quality of the software, it will not be able to compete
with other products on the market. If software crashes at the customer site, your customer loses
productivity as well money and you lose credibility. Sometimes these losses are huge.
Unhappy customers will not buy your other products and will not refer other customers to you.
You can avoid this situation by doing extensive testing. This testing is referred to as Quality
Assurance, or QA, in most of the software world.
Usually testing starts as soon as the initial parts of the software are available. There are multiple
types of testing and these are explained in this section. Each of these has its own importance.

1.1.5.1 Unit Testing

Unit testing is testing one part or one component of the product. The developer usually does this
when he/she has completed writing code for that part of the product. This makes sure that the
component is doing what it is intended to do. This also saves a lot of time for software testers as
well as developers by eliminating many cycles of software being passed back and forth between
the developer and the tester.
When a developer is confident that a particular part of the software is ready, he/she can write test
cases to test functionality of this part of the software. The component is then forwarded to the
software testing people who run test cases to make sure that the unit is working properly.
1.1.5.2 Sanity Testing
Sanity testing is a very basic check to see if all software components compile with each other
without a problem. This is just to make sure that developers have not defined conflicting or
multiple functions or global variable definitions.
1.1.5.3 Regression or Stress Testing
Regression or stress testing is a process done in some projects to carry out a test for a longer
period of time. This type of testing is used to determine behavior of a product when used
continuously over a period of time. It can reveal some bugs in software related to memory leak-
age. In some cases developers allocate memory but forget to release it. This problem is known as
3|P ag e
Event Driven Programming
memory leakage. When a test is conducted for many days or weeks, this problem results in
allocation of all of the available memory until no memory is left. This is the point where your
software starts showing abnormal behavior.
The regression testing may be started as soon as some components are ready. This testing
process requires a very long period of time by its very nature. The process should be continued
as more components of the product are integrated. The integration process and communication
through interfaces may create new bugs in the code.
1.1.5.4 Functional Testing
Functional testing is carried out to make sure that the software is doing exactly what it is
supposed to do. This type of testing is a must before any software is released to customers.
Functional testing is done by people whose primary job is software testing, not the developers
themselves.
In addition to test cases, the tester may also need to create a certain infrastructure or environment
to test the functionality of a piece of code. For example, you may simulate a network to test
routing algorithms that may be part of a routing product.
The next important job of the tester is to create a service request if an anomaly is found.
The tester should include as much information in the service request as possible. Typical
information included in reporting bugs includes:
 Test case description
 How the test was carried out
 Expected results
 Results obtained
 If a particular environment was created for testing, a description of that environment

1.1.6 Software Releases

Before you start selling any software product, it is officially released. This means that you create
a state of the software in your repository, make sure that it has been tested for functionality and
freeze the code. A version number is assigned to release software. After releasing the software,
development may continue but it will not make any change in the released software.
The development is usually carried on in a new branch and it may contain new features of the
product. The released software is updated only if a bug fixed version is released.
Usually companies assign incremental version numbers following some scheme when the next
release of the software is sent to market. The change in version number depends on whether the
new software contains a major change to the previous version or it contains bug fixes and
enhancement to existing functionality. Releases are also important because they are typically
compiled versions of a particular version of the code, and thus provide a stable set of binaries for
testing.

1.1.7 Documentation

There are three broad categories of documentation related to software development

1. Technical documentation developed during the development process. This includes
architecture, functional and design documents.
2. Technical documentation prepared for technical support staff. This includes technical
manuals that support staff use to provide customer support.
4|P ag e
Event Driven Programming
 3. End-user manuals and guides. This is the documentation for the end user to assist the user
getting started with the product and using it.
All three types of documents are necessary for different aspects of product support.

1.1.8 Support and New Features

Your customers need support when you start selling a product. This is true regardless of the size
of the product, and even for products that are not software related. Most common support
requests from customers are related to one of the following:
 The customer needs help in installation and getting started.
 The customer finds a bug and you need to release a patch or update to the whole product.
 The product does not fulfill customer requirements and a new feature is required by the
customer.
In addition to that, you may also want to add new features to the product for the next release
because competitor products have other features. Better support will increase your customer
loyalty and will create referral business for you.

1.2 Components of a Development System

Like any other system, a development system is composed of many components that work
together to provide services to the developer for the software development task.
Typically each development platform consists of the following components:
 Hardware platform
 Operating system
 Editors
 Compilers and assemblers
 Debuggers
 Version control system
 Collaboration and bug tracking
Let us take a closer look on these components and what role they play in the development cycle.

1.2.1 Hardware Platform

This is the tangible part of the development system. A hardware platform is the choice of
Your hardware, PC or workstation, for the development system. You can choose a particular
hardware platform depending upon different factors as listed below:
Cost Depending upon budget, you may chose different types of hardware. If hardware is part of
the final product, selection of hardware platform also depends upon
Customer/market requirement.

1.2.2 Operating System

Choice of a particular operating system may be made depending upon:

 Cost
 Availability of development tools

5|P ag e
Event Driven Programming
  Hardware platform
 Native or cross compiling
 Some operating systems are cheaper than others

1.3 Software Development Approaches

The some basic approaches applied to software development methodology frameworks.

Waterfall development

The waterfall model is a sequential development approach, in which development is seen as

flowing steadily downwards (like a waterfall) through several phases, typically:

 Requirements analysis resulting in a software requirements specification

 Software design
 Implementation
 Testing
 Integration, if there are multiple subsystems
 Deployment (or Installation)
 Maintenance

6|P ag e
Event Driven Programming
Prototyping

Software prototyping is the development approach of activities during software development, the
creation of prototypes, i.e., incomplete versions of the software program being developed.

The basic principles are

 Not a standalone, complete development methodology, but rather an approach to handle

selected parts of a larger, more traditional development methodology (i.e. incremental,
spiral, or rapid application development (RAD)).
 Attempts to reduce inherent project risk by breaking a project into smaller segments and
providing more ease-of-change during the development process.
 User is involved throughout the development process, which increases the likelihood of
user acceptance of the final implementation.
 Small-scale mock-ups of the system are developed following an iterative modification
process until the prototype evolves to meet the users’ requirements.
 While most prototypes are developed with the expectation that they will be discarded, it
is possible in some cases to evolve from prototype to working system.
 A basic understanding of the fundamental business problem is necessary to avoid solving
the wrong problems.

Spiral development

software system development "spiral model," which combines some key aspect of the waterfall
model and rapid prototyping methodologies, in an effort to combine advantages of top-down and
bottom-up concepts. It provided emphasis in a key area many felt had been neglected by other
7|P ag e
Event Driven Programming
methodologies: deliberate iterative risk analysis, particularly suited to large-scale complex
systems.

The basic principles are

 Focus is on risk assessment and on minimizing project risk by breaking a project into
smaller segments and providing more ease-of-change during the development process, as
well as providing the opportunity to evaluate risks and weigh consideration of project
continuation throughout the life cycle.
 "Each cycle involves a progression through the same sequence of steps, for each part of
the product and for each of its levels of elaboration, from an overall concept-of-operation
document down to the coding of each individual program.
 Each trip around the spiral traverses four basic quadrants: (1) determine objectives,
alternatives, and constraints of the iteration; (2) evaluate alternatives; Identify and resolve
risks; (3) develop and verify deliverables from the iteration; and (4) plan the next
iteration.
 Begin each cycle with an identification of stakeholders and their "win conditions", and
end each cycle with review and commitment.

Rapid Application Development

Rapid Application Development (RAD) Model

Rapid application development (RAD) is a software development methodology, which favors

iterative development and the rapid construction of prototypes instead of large amounts of
upfront planning. The "planning" of software developed using RAD is interleaved with writing
the software itself. The lack of extensive pre-planning generally allows software to be written
much faster, and makes it easier to change requirements.

The rapid development process starts with the development of preliminary data models and
business process models using structured techniques. In the next stage, requirements are verified
using prototyping, eventually to refine the data and process models. These stages are repeated
iteratively; further development results in "a combined business requirements and technical
design statement to be used for constructing new systems".

The basic principles of rapid application development are:

8|P ag e
Event Driven Programming
  Key objective is for fast development and delivery of a high quality system at a relatively
low investment cost.
 Attempts to reduce inherent project risk by breaking a project into smaller segments and
providing more ease-of-change during the development process.
 Aims to produce high quality systems quickly, primarily via iterative Prototyping (at any
stage of development), active user involvement, and computerized development tools.
These tools may include Graphical User Interface (GUI) builders, Computer Aided
Software Engineering (CASE) tools, Database Management Systems (DBMS), fourth-
generation programming languages, code generators, and object-oriented techniques.
 Key emphasis is on fulfilling the business need, while technological or engineering
excellence is of lesser importance.
 Active user involvement is imperative.
 Iteratively produces production software, as opposed to a throwaway prototype.
 Produces documentation necessary to facilitate future development and maintenance.
 Standard systems analysis and design methods can be fitted into this framework.

Agile development

"Agile software development" refers to a group of software development methodologies based

on iterative development, where requirements and solutions evolve via collaboration between
self-organizing cross-functional teams.

Agile software development uses iterative development as a basis but advocates a lighter and
more people-centric viewpoint than traditional approaches. Agile processes fundamentally
incorporate iteration and the continuous feedback that it provides to successively refine and
deliver a software system.

1.4 Software Development Principles

Key principles to learn about software development? They are:

1. Eliminate Waste
2. Build Quality In
3. Create Knowledge
4. Defer Commitment
5. Deliver Fast
6. Respect People
7. Optimist the Whole

9|P ag e
Event Driven Programming