1_an overview to software processes, software development

8/3/2019 1_An Overview to Software Processes, Software Development

1/42

C M C Limited

C M C Limited

Software Engineering and Live Project

1


2/42

An Overview to Software Processes

2


3/42

Its over budget!

ts uggy

Customers were not satisfied!

3


4/42

systematic, disciplined, quantifiable

approach to the development, operation

and maintenance of software, that is, the

.

4


5/42

System Engineering Phase

Interview CustomersStakeholders

Study systemdocumentation

Interview the System Analysts

FEEDBACK

ReviewwithinProject

User Requirements

Final set ofUser Requirements

Interview end users FEEDBACK

5

Study Existing Software


6/42

Activities performed in this phase

Interview customers end users

,

Collect and study the documentation of the existingsoftware, if any

Collect existing documents from the customer

Interview the customers software developers for moredetails on the project, and the standards the project has to

follow

ent y t e ar ware p at orm, so tware mo e s,programming language and tools that are needed in the

6

.


7/42

User Requirements Gathering

Sample Project Abstract and URS Template

Project and URS templete.doc

7


8/42

8


9/42

Project Manager: Initiates, plans, tracks and

manages resources of an entire project.

9


10/42

Roles in a typical software project(Contd)

leads the team working on a particular module of the

so ware pro ec . e mo u e ea er w con uc

reviews and has to ensure the proper functionality ofthe module.

10


11/42


Analyst: A software engineer who analyzes

the requirements gathered. Analysis of the

understanding of the requirements.

11


12/42

Domain Consultant: An expert who knows

.

This would involve the technical knowledgeof how the entities of the domain interface

.

12


13/42


Reviewer: A software engineer who reviews

artifacts like project documents or code. The

scrutinizes the technical details of the artifact.It could be a review where the reviewer

ascertains whether or not the artifact adheres

to a prescribed standard.

13


14/42

Architect: A software engineer involved in

has clearly specified the businessrequirements.

14


15/42

Deve oper: A so tware engineer, w o writes

15


16/42

Tester: A software engineer who conducts

es s on e comp e e so ware or a un o

the software. If an defects are found these

defects are logged and a report is sent to

the owner of the tested unit.

16


17/42

Requirement Analysis

17


18/42

In a broader sense a re uirement is1. A condition or a capability needed by a user

which will help the user to solve a problem or

to achieve an ob ective.

2. A condition or a capability that must be met

by a system to satisfy a contract, standard or

specification.

18


19/42

Functional Requirements

system, the outputs from the system and the behavioral

relationship between them.

Examples:

The software should calculate and display the cumulative

interest at the rate of 12% on all fixed deposits until maturity.

The software should display a separate web page, giving

details o all the ounder members o the com an .

The software is required to generate a monthly report on the

19

num er o ou s an ng oan amoun s


20/42

In a broader sense a re uirement is1. A condition or a capability needed by a user

which will help the user to solve a problem or

to achieve an ob ective.

2. A condition or a capability that must be met

by a system to satisfy a contract, standard or

specification.

20


21/42

on- unct ona equ rements

attributes of the system.

Examples: Good User Interface, High Performance,

Modular software and Scalable Model

21


22/42

Requirement Analysis PhaseFEEDBACK

Requirements

Process Model

withinProject

SoftwareRequirementsSpecificationTable

Data

GatheredANALYSIS

Data Model

22

FEEDBACK


23/42

Process and Data Model

Process model is used to understand the different

businesses processes that will make up the system

Data models to define and understand the design of data

that is to be used.

These models and the gathered requirements are part of

the Software Requirements Specification (SRS)

23


24/42

Levels of Testing

24


25/42

Create Test Plan

System testing

n para e o equ rement na ys s ase

System testing is the process of testing the completed

.

It is done to ensure that all the requirements specified by

the customer are met.

System testing involves functional testing and

performance testing.

25


26/42

Create Test Plan

System testing

n para e o equ rement na ys s ase

Functional testing traps errors in implementation of the

.

Performance testing looks at the way the functions are

performed, that is, considerations of speed and response

time.

26


27/42

Create Test Plann para e o equ rement na ys s ase

Acceptance testing

27


28/42

Create Test Plann para e o equ rement na ys s ase

28


29/42

Create Test Plan (Contd)

boundary of a software engineer and into

the boundary of a domain consultant,

the software interacts with the various

entities of the system.

29


30/42


System test plan and Acceptance test

meets both functional and non-functional

requirements.

testing, Acceptance testing (done after

the System testing) is done by thecustomer

30


31/42


The artifacts that need to be ready

a ter t s p ase are:

SRS which has the Process model

Process specification, Data model and

e a a c onary

System Test Plan

Acceptance Test Plan

31


32/42

Design Phase

n e es gn p ase e requ remen s are

translated into an actual representation

for software construction.

procedural detail

a a es n interface design

32


33/42

Design Phase

Design of

existing

Standarddocuments

FEEDBACKFEEDBACK

High LevelDesign

Document

project

SoftwareRequirements

Specification

Write HighLevel Design

ReviewWrite

DetailedDesign

Review

Detailed Design

Document

WriteIntegrationTest Plan

Write UnitTest Plan

IntegrationTest Plan

FEEDBACKFEEDBACK

DESIGNPHASE

REQUIREMENTSGATHERING

PHASE

Unit TestPlan

ev ew ev ew

33


34/42

Design Phase

The High Level Design (HLD) describes the

logical view of the solution. It views the

34


35/42

The Detailed Design (DD) takes the HLD as

input and goes one step further in giving a

modules. This could be algorithms whichgives a solution to a problem in a finite

35


36/42

Unit testing

Individual components are tested

Module testing

Related collections of dependent components

are tested Integration testing

Modules are inte rated into sub-s stems and

tested. The focus here should be on interfacetesting

36


37/42

ITP is created after all the modules

modules are identified. The UTP is created after details of the

.

37


38/42

Design Phase

The four documents below form theout ut of the desi n hase:

High Level Design

Integration Test Plan

Unit Test Plan

38


39/42

Build Phase

39


40/42

Test Script

It is a program which automates the steps

identified for a test

40

T i Ph


41/42

Testing Phase

41

Deployment Phase


42/42

Deployment Phase

A number of points need to be kept in mind for the

deployment of final software.

The complete delivery package needs to be assembled and

tested

Ensure that the plan for the support of the software is

ready

Early communication to customers about the changes that

the software will bring about. For example, reports might

oo erent or ocat on o n ormat on m g t avechanged

42

1_an overview to software processes, software development

Documents