Software Development Life Cycle Methodologies Processes Tools & Techniques

ninetimesdissemblingDéveloppement de logiciels

10 nov. 2012 (il y a 5 années et 1 mois)

220 vue(s)

Aim Computer Consulting has
Implemented and used following Best
Systems and Practices.


Software Development Life Cycle
Methodologies


Processes

Tools & Techniques

Prepared By: Salman Warsi PMP IT
Project Manager

Mob:00919949128594,
email:salmanwarsi@aim
-
cc.com,salmanwarsi@gmail.com

Legal

Disclaimer
:

please

make

sure

that

the

reader

of

this

document

has

ensured

that

our

information

and

data

communication

for

RFP

is

hindered

and

concealed

as

a

result

not

used

for

any

third

party

process

maturity

and

improvement
.



Tools
-
RAD, Jdeveloper, MyEclipse, Netbeans, WSAD, TOAD (for database) and Rational.


Technology
-
J2EE


Software Products


Struts


EJB


JSP


Servlets


Beans


Tiles


Spring


Java Mail


JDBC


Hibernate


AJAX


Change Management System
-
Jira Bug Tracking System.


Testing Tools
-
J
-
Unit


Servers
-
Tomcat, Appachi, J
-
Boss, Web Logic.


Database
-

Oracle 8i, 9i and 10G Design, Implementation and Administration.


Tools and Technologies used in Aim CC Offshore Development
Center..

Technology and Tools Used in JAVA Team Approach…



Tools
-
RAD, Jdeveloper, MyEclipse, Netbeans, WSAD, TOAD (for database) and Rational.


Technology
-
J2EE


Software Products


Struts


EJB


JSP


Servlets


Beans


Tiles


Spring


Java Mail


JDBC


Hibernate


AJAX


Change Management System
-
Jira Bug Tracking System.


Testing Tools
-
J
-
Unit


Servers
-
Tomcat, Appachi, J
-
Boss, Web Logic.


Database
-

Oracle 8i, 9i and 10G Design, Implementation and Administration.


Tools and Technologies used in Aim CC Offshore Development
Center..

Technology and Tools Used in JAVA Team Approach…

SDLC Processes
we use….



IBM RUP Process Framework



Waterfall Model



Agile Model



Linear Sequential Model



ADCT Model




This

ADCT

model

focus

on

Analysis

Design

Code

and

Test,

it

is

straight

forward

analysis

and

coding

model

which

can

be

used

for

very

small

or

small

typical

projects

or

tasks,

their

wont

be

enough

management

or

environment

work

done

here,

and

also

the

requirements

are

likely

to

change

as

the

system

progresses

as

a

result

there

is

no

mapping

or

tracking

for

scope

change

in

this

model,

never

the

less

the

kind

of

documentation

prepared

for

this

model

is

immature

glossy

system,

no

line

of

business

and

project

organization

defined
.

the

impact

of

change

here

is

on

single

entity

of

the

system,

here

one

person

has

to

do

many

tasks

or

he/she

has

to

wear

many

hats

during

the

software

development,

and

ends

up

with

messy

code,

fair

chances

of

application

might

crash

though

not

source

code,

but

thought

from

user

point

of

view

is

not

incorporated

up
-
front
.


ADCT Model


This

model

is

more

or

less

same

like

ADCT

there

hasn't

been

enough

iterations

done

here

only

sequence

of

tasks

and

tracking

those

tasks

monitoring

and

controlling

them,

here

also

the

kind

of

documentation

or

planning

is

limited

to

100
-
120

pages,

project

organization

defined

no

Work

break

down

structure

defined,

no

estimation

on

effort

and

cost,

no

strategic

policies

and

process

in

place,

in

fact

entire

process

is

more

or

less

like

manual

data

collection

not

by

following

any

special

tools

and

techniques,

here

triple

constraint

Time,

Cost

and

Quality

are

flexible,

doesn’t

really

matters

of

one

of

these

triple

constraint

changes,

impact

is

on

single

functionality

or

department

or

entity
.


Linear Sequential Model


This

model

has

phases

predefined,

preliminary

investigation,

system

analysis,

system

design,

system

coding,

system

implementation,

system

assessment,

system

deployment

and

maintenance
.

One

of

major

defector

with

this

model

is

its

still

not

iterative

even

after

defined

phases,

the

WBS

is

up

to

first

level

only

with

100
-
200

pages

documentation

some

defined

roles

and

responsibilities,

some

project

and

organization

hierarchy,

here

either

one

or

two

constraints

needs

to

be

controlled,

the

impact

of

change

is

either

on

single

department

or

a

business

unit
.




Waterfall Model


This

model

is

launched

specifically

for

sun

compatible

systems,

this

is

an

iterative

process

model

similar

to

IBM

RUP

framework,

this

model

has

strong

business

analysis

strategies,

focus

on

what

we

have

to

do,

where

we

are

and

where

we

will

be

in

future,

here

the

level

of

work

break

down

structure

is

up

to

third

level,

it

is

a

full

iterative

process

model

most

of

the

IT

companies

using

this

as

mature

process

model,

its

accredited

from

CMM

level

3
,
4
,
5
,

here

strong

&

mature

management,

environment,

requirement

and

solution

assessment

is

practiced
.

Impact

of

change

is

on

one

or

more

business

units
.

Triple

constraints

needs

to

be

controlled

and

balanced
.


Agile Model


This

model

is

designed

by

IBM

way

back

in

1970
-
80
’s

it

passed

quality

standard

levels

from

Capability

Maturity

Model

1
,
2
,
3
,
4
,
5

and

Latest

CMMI

and

Six

Sigma

green

belt,

black

belt

and

master

black

belt

approved

from

SEI

(

Software

Engineering

Institute)
.

Popularly

called

as

SEI

CMM
.

Very

matured

process,

matured

project

and

organization

structure,

CCB

Change

Control

Board

in

place,

tight

Balance

and

control

over

Triple

Constraints
.

Impact

of

change

is

on

whole

Enterprise
.


The

following

are

the

process

Phases
.



Management

Inception


Environment




Engineering

Stage


Requirement

Elaboration


Design


Implementation

Construction


Assessment


Deployment

Transition

Production

Stage




RUP Framework Model


A.
Management

a.
Inception phase management


Business case development


Elaboration phase release specifications


Elaboration phase work break down structure base lining


Software development plan


Inception phase project control and status assessments

b.
Elaboration phase management


Construction phase release specifications


Construction phase WBS base lining


Elaboration phase project control and status assessments

c.
Construction phase management


Deployment phase planning


Deployment phase WBS base lining


Construction phase project control and status assessments

d.
Transition phase management


Next generation planning


Transition phase project control and status assessments

Management


B.
Environment

a.
Inception phase environment specification

b.
Elaboration phase environment base lining


Development environment installation and administration


Development environment integration and custom tool smiting


SCO database formulation

c.
Construction phase environment maintenance


Development environment installation and administration


SCO database maintenance

d.
Transition phase environment maintenance


Development environment maintenance and administration


SCO database maintenance


Maintenance environment packaging and transition

Environment

C.
Requirements

a.
Inception phase requirements development


Vision specification


Use case modeling

b.
Elaboration phase requirements base lining


Vision base lining


Use case model base lining

c.
Construction phase requirements maintenance

d.
Transition phase requirement maintenance

Requirements

D.
Design

a.
Inception phase architecture prototyping

b.
Elaboration phase architecture base lining


Architecture design modeling


Design demonstration planning and conduct


Software architecture description

c.
construction phase design modeling


Architecture design model maintenance


Component design modeling

d.
Transition phase design maintenance

Design

E.
Implementation

a.
Inception phase component prototyping

b.
Elaboration phase component implementation


Critical component coding demonstration integration

c.
construction phase component implementation


Initial release) component coding and stand
-
alone testing


Alpha release component coding and stand
-
alone testing


Beta release component coding and stand
-
alone testing


Component maintenance

d.
Transition phase component maintenance

Implementation

F.
Assessment

a.
Inception phase assessment planning

b.
Elaboration phase assessment


Test modeling


Architecture test scenario implementation


Demonstration assessment and release descriptions

c.
Construction phase assessment


Initial release assessment and release description


Alpha release assessment and release description


Beta release assessment and release description

d.
Transition phase assessment


Product release assessment and release descriptions

Assessment

G.
Deployment

a.
Inception phase deployment planning

b.
Elaboration phase deployment planning

c.
Construction phase deployment


User manual base lining

d.
Transition phase deployment


Product transition to user

Deployment

INCEPTION
ELABORATION
TRANSITION
CONSTRUCTION
WBS Element
Fidelity
Management
Implementation
Design
Requirements
Environment
Assessment
Deployment
High
Moderate
High
Moderate
Low
Low
Low
WBS Element
Fidelity
Management
Implementation
Design
Requirements
Environment
Assessment
Deployment
High
HIgh
High
High
Moderate
Moderate
Low
WBS Element
Fidelity
Management
Implementation
Design
Requirements
Environment
Assessment
Deployment
High
High
Low
Moderate
High
High
Moderate
WBS Element
Fidelity
Management
Implementation
Design
Requirements
Environment
Assessment
Deployment
High
High
Low
Low
Moderate
High
High
Work Break down Structure base lining


Inception
Elaboration
Construction
Software
Architecture
20
%
Software
Development
20
%
Software
Assessment
10
%
Software
Management
50
%
Software
Architecture
50
%
Software
Development
20
%
Software
Assessment
20
%
Software
Management
10
%
Software
Architecture
10
%
Software
Development
50
%
Software
Assessment
30
%
Software
Management
10
%
Software
Architecture
5
%
Software
Development
35
%
Software
Assessment
50
%
Software
Management
10
%
Transition
Software development Plan


Project Management
Chief Engineer
Software Development
Administration
Software Test
Software Engineering
FSD Project Organization and Responsibilities
Software specifications
System engineering coordination
Stakeholder interface
Work breakdown structure
Cost and schedule statusing
Quality assurance
Software process definition
Software tool development
Metrics definition and analysis
Architecture maintenance
Design walkthroughs
HRMS component development
Payroll component development
Man
-
hours and cost component development
Build integration testing
Engineeering string testing
Formal qualification testing
CV track component development
Performance management system
Configuration baseline control
Reliability testing
Environment maintenance
Component development
Demonstration plan and integration
Travel management system
Access Control system
Test software development
Requirements verification
Technical status assessments
Call accounting management system
Project Organization and
Responsibilities

Inception
Elaboration
Construction
Transition
Prototype
0
.
1
Architecture
0
.
2
Architecture
0
.
3
0
.
3
.
1
0
.
3
.
2
Internal test release
1
.
0
1
.
0
.
1
2
.
0
.
1
2
.
0
.
2
Alpha test release
2
.
0
IOC beta release
3
.
0
3
.
1
.
1
Beta release
3
.
1
Product Release
4
.
0
4
.
0
.
1
Upgrade Release
4
.
1
Typical Project release sequence for a large
-
scale
,
one
-
of
-
a kind project
Inception
Elaboration
Construction
Transition
Prototype
0
.
1
Architecture
0
.
2
Architecture
0
.
3
Internal test release
1
.
0
Alpha test release
2
.
0
IOC beta release
3
.
0
3
.
1
.
1
Beta release
3
.
1
Product Release
4
.
0
3
.
1
.
2
Upgrade Release
4
.
1
Typical Project release sequence for a small commercial project
4
.
0
.
1
4
.
1
.
2
Upgrade Release
4
.
2
Typical Release Sequences

Design Set
UML Models
Implementation Set
Source Code
Requirements Set
UML Models
Deployment Set
Executable Code
Portability among platforms and network topologies
Automated distribution links
Automated Build Management
Forward engineering
(
source generation from models
)
Reverse engineering
(
models generation from source
)
Round Trip Engineering

UML

2
.
1

advances

the

successful

UML

2
.
0

specification,

and

is

quickly

becoming

the

accepted

standard

for

specifying,

documenting

and

visualizing

software

systems
.

The

Unified

Modeling

Language

(UML)

is

also

used

for

the

modeling

of

non
-
software

systems,

and

is

extensively

implemented

in

most

industry

sectors

including

finance,

military

and

engineering
.


If

you

are

new

to

the

Unified

Modeling

Language,

our

Introduction

to

UML

is

a

recommended

starting

point
.



UML

2

defines

thirteen

basic

diagram

types,

divided

into

two

general

sets
:

UML 2.1

1
.

Structural

Modeling

Diagrams

Structure

diagrams

define

the

static

architecture

of

a

model
.


They

are

used

to

model

the

'things'

that

make

up

a

model

-

the

classes,

objects,

interfaces

and

physical

components
.


In

addition,

they

are

used

to

model

the

relationships

and

dependencies

between

elements
.


-
Package

diagrams

are

used

to

divide

the

model

into

logical

containers,

or

'packages',

and

describe

the

interactions

between

them

at

a

high

level
.

-
Class

or

Structural

diagrams


define

the

basic

building

blocks

of

a

model
:

the

types,

classes

and

general

materials

used

to

construct

a

full

model
.

-
Object

diagrams

show

how

instances

of

structural

elements

are

related

and

used

at

run
-
time
.


-
Composite

Structure

diagrams

provide

a

means

of

layering

an

element's

structure

and

focusing

on

inner

detail,

construction

and

relationships
.

-
Component

diagrams

are

used

to

model

higher

level

or

more

complex

structures,

usually

built

up

from

one

or

more

classes,

and

providing

a

well

defined

interface
.

-
Deployment

diagrams

show

the

physical

disposition

of

significant

artifacts

within

a

real
-
world

setting
.

1. Structural Modeling Diagrams

2
.

Behavioral

Modeling

Diagrams

Behavior

diagrams

capture

the

varieties

of

interaction

and

instantaneous

states

within

a

model

as

it

'executes'

over

time
;

tracking

how

the

system

will

act

in

a

real
-
world

environment,

and

observing

the

effects

of

an

operation

or

event,

including

its

results
.

-
Use

Case

diagrams


are

used

to

model

user/system

interactions
.

They

define

behavior,

requirements

and

constraints

in

the

form

of

scripts

or

scenarios
.

-
Activity

diagrams


have

a

wide

number

of

uses,

from

defining

basic

program

flow,

to

capturing

the

decision

points

and

actions

within

any

generalized

process
.

-
State

Machine

diagrams

are

essential

to

understanding

the

instant

to

instant

condition,

or

"run

state"

of

a

model

when

it

executes
.

-
Communication

diagrams

show

the

network,

and

sequence,

of

messages

or

communications

between

objects

at

run
-
time,

during

a

collaboration

instance
.

-
Sequence

diagrams


are

closely

related

to

communication

diagrams

and

show

the

sequence

of

messages

passed

between

objects

using

a

vertical

timeline
.

-
Timing

diagrams

fuse

sequence

and

state

diagrams

to

provide

a

view

of

an

object's

state

over

time,

and

messages

which

modify

that

state
.


-
Interaction

Overview

diagrams

fuse

activity

and

sequence

diagrams

to

allow

interaction

fragments

to

be

easily

combined

with

decision

points

and

flows
.


2. Behavioral Modeling Diagrams

Package Diagram

Class Diagram

Class and Object Diagram

Component Diagram

Deployment Diagram

Use Case Diagram

Activity Diagram

State Machine Diagram

Sequence Diagram

Interaction Diagram

BABOK accredited from IIBA ( International Institute of
Business Analysis)



Enterprise Analysis



Requirements Planning and Management



Requirements Elicitation



Requirements Analysis and Documentation



Requirements Communication



Solution Assessment and Validation

Business Analysis Body of Knowledge

Project

Management

Professional

accredited

from

PMI

(

Project

Management

Institute
-
New

Jersey

USA

Website
:

www
.
pmi
.
org
)

PMBOK

is

a

Guide

to

PMP
.


It

has

five

process

groups

and

nine

knowledge

areas,

popularly

called

as

or

acronym

as


IPECC’

Process

Group
.



Initiation



Planning



Executing



Monitoring

and

Controlling



Closing


Project Management Body of Knowledge

Developing

Project

Integration

Management

Plan
,

and

also

develop

project

charter,

preliminary

project

scope

statement,

project

plan

and

closing

project

process
.


Developing

Project

Scope

Management

definition

and

plan

the

scope,

created

the

scope

definition,

created

the

work

breakdown

structure,

verified

the

project

scope

and

protected

the

scope

from

change
.



Developing

Project

Time

Management

plan
,

defined

the

project

activities,

activity

mapping,

examining

the

sequence

outputs,

estimating

activity

durations,

designed

and

developed

the

project

schedule

in

MS
-
Projects

and

controlling

the

project

schedule

outputs

and

schedule

development
.


Designing

Cost

Management

Plan

also

analyzed

cost

estimating

and

budgeting

cost

results,

implemented

cost

controls

and

project

performance

measurement,

cost

control

results

consideration
.

Nine Knowledge Areas

Designing

and

developing


Project

Human

Resource

Management

plan’
,

prepared

and

completed

human

resource

and

organization

planning

and

examined

the

results,

managed

staff

acquisition

and

acquired

the

needed

staff,

assembled,

developed

and

managed

the

project

team,

lead

the

project

team

development

and

examined

the

results
.


Designing

a

big

quality

picture

using

Project

Quality

Management

planning

process,

planned

and

prepared

for

quality,

created

the

quality

management

plan,

quality

assurance,

implemented

the

quality

control

and

examined

the

results

of

quality

control
.


Implementing

and

recommending

Project

Management

Information

Distribution

Systems

by

creating

Project

Communication

Management

Plan,

creating

communications

plan,

prepared

for

information

distribution,

reported

project

performance

and

managed

project

stakeholders
.

Nine Knowledge Areas

Come

up

Project

Risk

Management

Plan
,

created

the

risk

management

plan,

identified

risks,

prepared

for

risk

identification,

identified

the

project

risks,

created

a

risk

register,

used

and

completed

qualitative

risk

analysis,

examined

the

results

of

qualitative

risk

analysis,

prepared

quantitative

risk

analysis,

examined

the

results

of

quantitative

risk

analysis,

planned

for

risk

responses,

created

risk

responses,

examined

the

results

of

risk

response

planning,

implemented

risk

monitoring

and

control,

prepared

for

risk

monitoring

and

control,

completed

risk

monitoring

and

control

and

examined

the

results

of

risk

monitoring

and

control
.


Planning

for

purchases

using

Project

Procurement

Management

Plan
,

completed

procurement

planning,

examined

the

results

of

procurement

planning,

prepared

for

contracting,

examined

the

results

of

contracting

planning,

creating

evaluation

criteria,

prepared

for

contracting,

completed

contracting,

examined

the

results

of

contracting,

performed

contract

administration

and

contract

closure
.

Nine Knowledge Areas

Tools and Techniques Snapshots

Microsoft Office Visio

Drawing Microsoft Visio

Microsoft Projects 2007

Microsoft Project Startup

Microsoft Project Plan

Microsoft Project Schedule View