software development life cycle overview

8/9/2019 Software Development Life Cycle Overview

http://slidepdf.com/reader/full/software-development-life-cycle-overview 1/6

Software Development Life Cycle OverviewWhite Paper by Bob Jones

At The Socrates Group, we are familiar with the problems and challenges of building complex

software applications, and like most good software development organizations, we use a

structured process to define and manage our development work. This type of process is called a

“Software Development Life Cycle” (SDLC).

Building custom software solutions is a complex process that can, if not well managed, easily

lead to disaster. Cost overruns and scope creep are common, but failing to solve the businessproblems effectively can cost the business more than just time and money. It can cost the

business a strategic window of opportunity. A poorly implemented solution can even drive

some businesses out of business. The purpose of a SDLC is to produce a system that will meet

the client’s business needs and allow the solution to adapt and grow as the client’s business

needs grow and evolve.

SDLC Variables

An SDLC must reflect many variables:

Technology: Development of a web based application is different from developing a fatclient app, and development using Microsoft tools is very different from using Linux,

Apache, MySQL, PHP and PERL (LAMPP).

At The Socrates Group, we make no statement about whether Microsoft or LAMP

technology is superior to the other; however, we work only with Microsoft based tools

because that is where we have chosen to focus our skill set.

Scope: Large projects present more risk, and risk is best managed by clarity. Smaller

projects can be developed with a more casual approach1, while larger projects require

more formal definition of requirements and more careful management of scope creep.

We believe that The Socrates Group team is the best “heavy lifting” software developmenthouse North of Everett. We specialize in large, business critical projects and have local

references to validate the quality of our work.

1 See “Design and Build Versus SDLC” by Bob Jones



Software Development Life Cycle Overview

Last Updated 11.30.2007 of 6

Developer Relationship: The nature of the relationship between the developer and the

client can have a massive impact on the SDLC. If the development team interacts closelywith the end user, they have a better chance of clearly understanding what the client

wants and needs than does an offshore team of developers.

The Socrates Group team is entirely local. We work closely with our clients throughout

the development process.

Contract Relationship: Software development has inherent risk that both the client and

the developers must manage. We do our work on a “Time and Material” basis. We

charge only for the hours actually worked. We do not do fixed price work unless the

requirements are extremely clear2.

The Socrates Group SDLCWe have developed an SDLC that represents a balance of client needs for cost effective solutions

that meet customer needs. Our SDLC is based around producing a specific set of “deliverables”.

Each deliverable is a specific document or collection of files that fulfill a specific purpose. The

deliverables are produced in a specific order, as outlined below.

Our process must include each of these deliverables:

Services Agreement Contract: this simple document spells out how we work together to

create value.

Project Charter: Presents an overview of the project that includes:o Project Purpose: What is the purpose of this engagement? In brief terms, why

has the client engaged The Socrates Group to do work?

o Project Justification: How will completing this engagement benefit the client? Aclearly stated justification makes it easy to determine the engagement’s cost-benefit and ROI.

o Scope: What’s in scope and what’s explicitly out of scope for this project. Thescope definition serves to put boundaries around the project and helps preventaccidental scope creep.

o Project Plan: What are the major steps we will go through to complete this

project?o Billing & Rates: How will The Socrates Group charge for its services and what is

the client’s process for paying for those services?

2 See “Managing the Risks of Custom Development” by Bob Jones





o Timeline: When will the project begin and when does the customer expect majordeliverables?

o Key Players: Who are the people who have a stake in the success of this project,who are the key people who will act as project resources and what roles will eachperson play?

Business Process Analysis: We begin our analysis with a thorough exploration of the

relevant business processes. The assumption we start with and must verify is that

business growth is impeded by the current processes. To rectify the problem, we must

understand what is currently happening and what is not working. This document takes

the form of a detailed description of how the existing processes work and what

problems they present.

System Requirements: Once we understand the nature of the current business, we canarticulate the capabilities required of the new system. This document takes the form of a

specific list of “The system must [do this]” and possibly a list of “Would be nice”

capabilities.

Security Requirements and Threat Analysis: If the system we are building will manage

sensitive data, we need to understand the requirements for protecting that data. For

example, if sales transactions must capture a customer’s credit card information, we

need to take special measures to protect that information. The Security Requirements

will define what needs to be protected, and the threat analysis will identify possible

threats to the security of that information. This information will feed into subsequent

deliverables in the life cycle.

High Level Functional Design: During our exploration of the existing process issues,

some solutions will emerge. When we have explored the various possibilities and settled

on the “best” approach, we will document our design at a high level. This document

describes how we have partitioned the solution into components and how the

components will interact. If the solution involves multiple databases (as it often does),

this document will also describe what major tables will reside in each database.

System Architecture: Technology is evolving at an amazing rate. No two systems we

build will use precisely the same architecture. As technology evolves, our team is

constantly investigating what is new on the horizon and how new technologies andapproaches can benefit our clients. We have learned the wisdom of formally including

this review in the development process for all strategic systems we build. The System

Architecture document will, on completion, reflect the architecture of the platform on

which we will build our solution set.





The System Architecture will determine whether we will use a web-based approach or a

more traditional Windows Forms (desktop application).

Development Plan: When we have a high level design and can define the major system

components, we can sequence building of those components in some meaningful way.

Usually, some components will the existence of functionality or capabilities existing in

other components, so we typically have to start with the component(s) that don’t

depend on other components. The Development Plan will lay out what will be built and

a rough timeline for the delivery of each of the major components.

Development Schedule: As we progress, we will keep a development schedule that

reflects where we are towards the completion of each deliverable. We tend to do this in a

relatively informal way because we have learned that most project management systems

are excessively cumbersome and because the development often uncovers additional

requirements and business rules that can impact the overall schedule.

Data Model: Virtually every solution we build is based on a database of some sort. We

use Microsoft SQL Server for all of our database work, and we use Visio to develop a

data model (a diagrammatic representation of the database). This data model becomes

one our most important communication tools as we drill deeper into design and

implementation. A visitor to our office will see our walls covered with data models for

work in process. This model evolves continuously during our development work, and

indeed over the lifetime of the solutions we build.

Detailed Component Design (one for each major component): Once we understandhow the system decomposes into specific parts, we drill into each part in the order they

are to be built and produce a written description of the component. We review this

document carefully with our clients to make sure we understand and agree on what we

are to build before we start coding.

Business Process Design Notes: Throughout the lifecycle, our understanding of our

client’s business gets progressively deeper. As we uncover or clarify business rules and

detailed system requirements, we document these as Business Process Design Notes. We

create separate documents rather than making revisions to the documents we produced

earlier because we have learned that doing it this way is much easier and less costly and

it allows us to focus on, document and get client feedback quickly.

Application Software: Decades of experience have taught us that software development

is best done as a formal process that divides development into these major steps:

o User Interface Mockup: We begin application development of each component

by taking the Detailed Component Design and the Data Model and mocking up





a user interface which we review with our clients before hooking it up too closely

to the database.

o Internal Release: Once we have a good approach to the user interface and we

understand the underlying database, the coding work involves hooking up the

two and implementing in code the critical business rules that the system must

enforce. The Internal Release represents the current state of the code. An internal

release may be demonstrated to a customer, but it is not ready for customer

testing.

o Customer Release: Once all critical component functionality has been

implemented, we deliver a working version to our client and ask them to test it

and give us feedback. We will take their feedback and incorporate it into our

code and then deliver another Customer Release.

o Operational Release: When the customer is satisfied with the component, we

have an operational release. We will most likely continue to make small changes

to the operational release as the customer requests and requires. Major changes

that reflect new business processes or rules will require more formality that will

include Business Process Design Notes and possibly additional Detailed

Component Design documents.

Change management is one more aspect of our SDLC that bears noting. We do only time and

materials work, so we can easily accommodate client change requests, and since we give our

clients detailed weekly bills showing everything we are doing for them, our clients haveconstant visibility into the work we are doing for them and the corresponding charges.

The process described in this document is flexible and fluid and changes to meet the needs of

each engagement. We have learned through many years of experience, the value of clearly

documenting what we need to do before we dive into code.

About Bob Jones:

Bob Jones is an Information Systems Consultant specializing in analysis, design and

development of custom software solutions for local businesses. Bob has been developingapplications to support critical business processes for over forty years. Along with Dick

DeWaard, Bob founded DeWaard & Jones Company in 2003 to provide high quality

information Systems consulting services to businesses in Whatcom County. The business name

was changed to The Socrates Group in October, 2007.





The Socrates Group is a Microsoft Certified Partner that specializes in creating business

information system solutions using Microsoft .NET and SQL Server.

Bob is also quite active in an international men’s training organization called The Mankind

Project (mkp.org) which helps men lead lives of conscious intention, accountability and service.

software development life cycle overview

Documents