C M C Limited C M C Limited

INDUSTRIAL /PROJECT TRAINING

Software Engineering and Live Project

1

An Overview to Software Processes

Problem in Software Development

It s Its always late! Its over budget! Its buggy! It b ! Customers were not satisfied!

Software Engineering
Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software, that is, the application of engineering to software software.

System Engineering Phase

User Requirements Gathering

Interview Customers Stakeholders

Study system documentation

FEEDBACK

Interview the System Analysts

User Requirements

Review within Project

Final set of User Requirements

Interview end users

FEEDBACK

Study Existing Software

Activities performed in this phase

Interview the customer to understand requirements Interview customers end users Study the existing software if any software, Collect and study the documentation of the existing software, if any Collect existing documents from the customer Interview the customers software developers for more details on the project, and the standards the project has to follow Id tif Identify th the h d hardware platform, software models, l tf ft d l programming language and tools that are needed in the project. project
6

User Requirements Gathering

Sample Project Abstract and URS Template Project and URS templete.doc

Roles in a typical software project

Roles in a typical software project

Project Manager: Initiates, plans, tracks and manages resources of an entire project.

Roles in a typical software project(Contd)

Module Leader: A software engineer who manages and leads the team working on a particular module of the software project The module leader will conduct project. reviews and has to ensure the proper functionality of the module. h d l

10

Roles in a typical software project(Contd)

Analyst: A software engineer who analyzes the requirements gathered. Analysis of the requirements is done to get a clear understanding of the requirements.

11

Roles in a typical software project(Contd) project(Cont d)

Domain Consultant: An expert who knows the system of which the software is a part part. This would involve the technical knowledge of how the entities of the domain interface with the software being developed developed.

12

Roles in a typical software project(Contd)

Reviewer: A software engineer who reviews artifacts like project documents or code. The review can be a technical review which 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

Roles in a typical software project(Contd) project(Cont d)

Architect: A software engineer involved in the design of the solution after the analyst has clearly specified the business requirements.

14

Roles in a typical software project(Contd) project(Cont d) Developer: A software engineer, who writes l f h the code, tests it and delivers it error free.

15

Roles in a typical software project(Contd) project(Cont d) Tester: A software engineer who conducts tests t t on th completed software or a unit of the l t d ft it f the software. If any defects are found these y defects are logged and a report is sent to the owner of the tested unit.
16

Requirement Analysis & Create Test Plan

17

In a broader sense a requirement is q 1. A condition or a capability needed by a user which will help the user to solve a problem or to achieve an objective. j 2. A condition or a capability that must be met by a system to satisfy a contract, standard or specification.

18

Functional Requirements
These are the requirements that specify the inputs to the system, the outputs from the system and the behavioral relationship between them. l i hi b h 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 of all the founder members of the company. The software is required to generate a monthly report on the number of outstanding loan amounts
19

In a broader sense a requirement is q 1. A condition or a capability needed by a user which will help the user to solve a problem or to achieve an objective. j 2. A condition or a capability that must be met by a system to satisfy a contract, standard or specification.

20

Non-Functional Requirements N F ti lR i t
These are requirements that describe the overall attributes of the system. Examples: Good User Interface, High Performance, Modular software and Scalable Model

21

Requirement Analysis Phase

FEEDBACK

Process Model

Requirements Gathered ANALYSIS

Table

Review within Project

Software Requirements Specification

Data

Data Model

FEEDBACK

22

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

Levels of Testing

24

Create Test Plan

In I parallel of Requirement A l i Ph ll l f R i t Analysis Phase

System testing
System testing is the process of testing the completed software as a part of the environment it was created for for. It is done to ensure that all the requirements specified by the customer are met. System testing involves functional testing and performance testing.

25

Create Test Plan

In I parallel of Requirement A l i Ph ll l f R i t Analysis Phase

System testing
Functional testing traps errors in implementation of the business requirements. requirements Performance testing looks at the way the functions are performed, that is, considerations of speed and response time.

26

Create Test Plan

In I parallel of Requirement A l i Ph ll l f R i t Analysis Phase

Testing stages
Acceptance testing
Testing with customer data to check that it is acceptable

27

Create Test Plan

In I parallel of Requirement A l i Ph ll l f R i t Analysis Phase

28

Create Test Plan (Contd)

System testing usually falls outside the boundary of a software engineer and into the boundary of a domain consultant, who knows the complete system and how the software interacts with the various entities of the system.
29

Create Test Plan (Contd)

System test plan and Acceptance test plan are used to ensure that the software meets both functional and non-functional requirements. The difference is that unlike System testing, Acceptance testing (done after the System testing) is done by the customer
30

Create Test Plan (Contd)

The artifacts that need to be ready after this phase are: f hi h
SRS which has the Process model, S S w c as t e ocess odel, Process specification, Data model and the Data Dictionary th D t Di ti System Test Plan Acceptance Test Plan
31

Design Phase h
In the design h I th d i phase th requirements are the i t translated into an actual representation for software construction.
software architecture procedural detail data design interface design
32

Design Phase
Design of existing project Standard documents High Level Design Document

FEEDBACK

FEEDBACK

Software Requirements Specification

Write High Level Design

Review

Write Wi Detailed Design

Review Detailed Design Document

Integration Test Plan Write Integration Test Plan REQUIREMENTS GATHERING PHASE Write Unit Test Plan

Review R i

Review R i Unit Test Plan

FEEDBACK

FEEDBACK

DESIGN PHASE

33

Design Phase h
The High Level Design (HLD) describes the logical view of the solution. It views the solution at a higher level of abstraction.

34

Design Phase (Contd) (Cont d)

The Detailed Design (DD) takes the HLD as input and goes one step further in giving a detailed view of each of the defined modules. This could be algorithms which gives a solution to a problem in a finite number of steps or pseudocode

35

Testing stages
Unit testing
Individual components are tested

Module testing
Related collections of dependent components are tested

Integration testing
Modules are integrated into sub-systems and g y tested. The focus here should be on interface testing
36

Design Phase (Contd)

ITP is created after all the modules and the interfaces between the modules are identified. The UTP is created after details of the module are clearly understood understood.

37

Design Phase h
The four documents below form the output of the design phase: p g p High Level Design Detailed Design Integration Test Plan Unit Test Plan

38

Build Phase

39

Test Script
It is a program which automates the steps identified for a test

40

Testing Phase

41

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 look different or l l k diff location of i f i f information might h i i h have changed
42