1. Role Based Training
Role : SE,SSE
Module 1,2: Development , Maintenance Project Life cycle

2. Module 1: Development project life cycle

3. Objective
The objective of this section is to introduce you the overview of software process – a coherent set of activities for software production. When you have read this section you will:
understand the concept of a software process and a software process model;
understand a number of different software process models such as waterfall, spiral and iterative models.

4. Business Management System (BMS)
Business management system documents all the processes followed in GAVS
Is an integration framework
ISO 9001:2008 – All functions
ISO 27001:2013 – All functions
ISO IMS
CMMi Version 1.3 – Maturity Level 3 - ADM
ITIL Framework - IMS
URL:

5. Why SDLC
In the earlier days, projects were developed without proper specification or any attempt in design and were just built, and reworked as many times needed to satisfy the customer.
This is not possible for complex projects since
There is no control on quality assurance.
There is no risk analysis.
There is no estimation of time and cost of the project.
There is no proper plan.
Hence,
The project may lead to a huge financial loss for both the customer as well as the developer.
The project may fail.
The project may not be delivered in time with the satisfaction of the customer.

6. GAVS
Development
Maintenance
Testing
Support

7. SDLC
SDLC: A framework that describes the activities performed at each stage of a software development project
Waterfall
Iterative Model
Spiral Model
V-Model
Big-Bang model
Agile model
Refer BMS : Guideline SDLC models

8. Life Cycle for development Project
Requirements
Design
Coding
Testing
Deployment
Implementation & Support

9. Requirements Functional Requirements
– Requirements that specify mandatory behaviors.
– They are typically specified using normal narrative text, specification languages, use case
models, functional models, state models, and/or object models.
Data (or Informational) Requirements
– Requirements that specify some mandatory property of a data type or value.
– They are typically specified using logical data models, object models, or data dictionaries.

10. Requirements Quality (or Non-Functional) Requirements
– Requirements that specify mandatory levels of quality factors
– Can be either developer-oriented (e.g., extensibility, installability, maintainability, portability, reusability, scalability, testability) or
– Can be user-oriented (e.g., accessibility, auditability, configurability including personalization and internationalization, correctness, efficiency, interoperability, look and feel including banding, operational availability, operational environments, performance, reliability, robustness, safety, security, and usability)
– They are typically specified using normal narrative text, either separately as a group of related requirements or else individually with the relevant functional and data requirements
Interface (or External API) Requirements
– Requirements that specify mandatory application programmer interfaces to external systems, typically either the customer organization’s legacy systems or systems not owned by the customer organization.
– They are typically specified using interface and protocol specifications.

11. Requirements Techniques
There are a variety of methods and techniques for uncovering, discovering, and communicating functional and non-functional requirements and constraints:
– Interviews
Face to face interaction with client representatives/subject
matter experts (SME) to elicit information . Usually supported with a set of
pre-defined topics or questions to be covered
– Questionnaires
A set of focused questions, preferably framed objectively sent out to client representatives
– Requirements Prototyping
– etc

12. Requirements Specification
Requirements specification will be in any form of below list
Business requirements
Functional Requirements
Software Requirements specification
Non –Functional requirements
Use case documents
User stories
Requirements review and approval:
Review the requirements documents and close the review comments
Clarification tracker : To understand/raise the quries about the requirements
Refer : BMS for templates and guidelines

13. Exercise How the requirement queries are resolved & track
Through requirement clarification tracker
Through
Through requirement walkthrough
Through PM plan
Through Risk
2. Select Various method of understand the requirements
Refer the requirements in SVN
PM/TL Circulate the requirements to team through
Walkthrough the requirements in a meeting
None of the above
3. List down 2 requirements elicitation techniques
4. Select Non-Functional Requirements in the below list?
Support additional Language (from multi-lingual language aspect)
100 + simultaneous users can access the application
Any reports should undergo 3 level of approval
First Name should have 20 characters length
Preview of report with quick response time
5.Select the Functional requirements in the below list
Need to establish an Online Sales Portal
Portal Should List the products with category
Portal Should allow seller to register a product
Portal should allow 5 product in each category for registration
Portal Needs a login feature
User credential must have special characters

14. Design HLD is prepared based on the User requirements
High Level Design
Low Level Design
HLD is prepared based on the User requirements
The High Level Design (HLD) process converts the User Requirements Specification (URS) into high level architectural design
Contents of HLD :
Scope of the Project
CTQ - Design Mapping
Alternate design (By Applying Decision Analysis Resolution method)
System architecture
Function Description
Identification of business components and reusable components
Security Requirements

15. Design - HLD Contents of HLD: System Interfaces which include
Interface with Screens and Reports
Interface with Modules
Interface with External Systems
Database Design
System Diagrams (Class Diagram, Sequence Diagram, Process flow diagram, Data flow diagram)

16. Design – HLD Preparation
High Level Design (HLD) shall be prepared using the HLD template
Update Traceability matrix
Traceability from Requirements to HLD
Traceability from HLD to Requirements
Review & Approve Design
Design shall be reviewed for correctness and adequacy
Review comments shall be logged and tracked to closure

17. Design - LLD
Low Level Design (LLD) shall be prepared using the LLD template
Objective: Identify software components / programs that need to be developed for functional and non-functional requirements.
Understanding the Requirements from High Level Design aspect
Establishing detailed module specification,
functions,
screens,
reports,
user interface design,
error message strategy,
coding standards,
integration test plan and cases
program specification
Acceptance criteria
Traceability matrix to be updated
Traceability from HLD to LLD
Traceability from LLD to HLD
Review & Approve Design
Design shall be reviewed for correctness and adequacy
Review comments shall be logged and tracked to closure

18. Exercise Select the details captured in High levels designs
A.Architecture design
B.DB Design
C.Schema
D.Code
E.Test case

19. Coding Converts LLD into operational code
Follow Coding standards and methods
Refer User specification , Functional and design documents
Construct code
Assigned units shall be constructed based on the approved design
code shall be mapped to design and requirements
Developers shall do a self review
Checklist /coding standard can be used for the self review
Compile Code
constructed unit shall be compiled and debugged before submitting for peer review.

20. Code Review Code Review Update Requirement Traceability Matrix
Code to be reviewed by Peer
Defects detected during reviews to be logged
All defects to be tracked to closure
Using coding Standards
Java
.Net
Security Standard
Update Requirement Traceability Matrix
Requirements - > Design - > Code
Refer BMS for coding standard guidelines

21. Coding - UT Unit test cases are designed for Equivalence partitioning
Unit Test cases to be prepared prior to coding
Contains the plan to uncover maximum defects in an Unit
Unit test cases are designed for
Equivalence partitioning
Boundary Value testing
Decision Table
GUI testing
Batch Processing Testing
Report Testing
Exception Testing
Cross Platform Testing
Coverage Based Testing

22. Coding - UT
Use Test case template for test case preparation ( Script: Junit / Nunits )
Execute the Unit Test cases/scripts
Records the Unit testing defects
Close the gaps in program units as a fix
Check-in the code in to version control / project repository
Update the traceability matrix

23. Build & Release Creating build mechanism options
Get approval PM on the build mechanism
Create build list
Configure the build mechanism
Schedule build
Compile and troubleshoot
To be inline with <Buils & Relase>

24. Exercise

25. Testing Validates the product against requirements
Objective : Detect and eliminate defects
Early
Effectively
Before delivering the products to the customer
Levels of Testing

26. Levels of Testing Integration Testing (IT ) Follows Unit Testing
After integrating tested units
Focuses on the interaction between units
System Testing (ST)
Focuses on a complete integrated system
Ensures that all system elements perform allocated function
Done in an environment as close as that of the customer
Follows Integration Testing
Acceptance Testing (AT)
Formal Testing before Acceptance of product
Update the traceability matrix

27. Deployment Identifying the features/modules/software to be delivered
Identifying and documenting issues, known defects, risks in release note
Releasing using a formal release note providing all the details including installation instructions, Scripts, parameters or configuration data that needs to be updated in configuration file or any table in a database.
Releasing project through Software release note.
Identifying the client environment- hw/software
Install as per installation plan
setting up application into the client environment successfully

28. Support Preparing plan for warranty support
Perform fixes, record and track problems/bug reporting channel/tool

29. Exercise

30. Module 2 : Maintenance project life cycle

31. Maintenance Life Cycle
Knowledge Transition - Planning
Knowledge Transition - Acquisition
Knowledge Transition – Shadow and Share
Knowledge Transition- Execution Phase
Maintenance Task- Bug Fix
Maintenance Task- Minor Enhancement/Change Request

32. Knowledge Transition Planning Acquisition
Objective : Validating the application inventory to set the scope of the engagement
Plan to understand application details
Prepare the KT Plan
Prepare & Finalize the KT documents
Acquisition
Objective : Understand the application
Prepare the application understanding documents
Use requirement elicitation techniques
Understand the core, peripheral system and interfaces.
Understand Applications Details, Functions, Business Process Flow, User. Characteristics, GUI, Activity Approaches, service requests, Governance Model Etc.
Understand operating environment and platforms.
Understand functionality for various applications and modules.
Understand problem areas.
Understand the business process and domain areas
Familiarize with development and testing environment

33. Knowledge Transition Shadow & Share phase Execution
Objective : provide knowledge transition to offshore team by Business analyst
Plan to understand application details
Prepare the KT Plan
Prepare & Finalize the KT documents
Execution
Objective : Responsibilities and ownership are clearly defined and tasks are managed effectively
Develop, enhance and install tools required to support maintenance process
Understand the core, peripheral system and interfaces.
Understand Applications Details, Functions, Business Process Flow, User. Characteristics, GUI, Activity Approaches, service requests, Governance Model Etc.
Understand operating environment and platforms.
Understand functionality for various applications and modules.
Understand problem areas.
Understand the business process and domain areas
Familiarize with development and testing environment

34. Maint - Requirements
Requirements will be received in the form of Maintenance request
Maintenance requests can be
Raised in request tracking system like AMO Log
Received in a mail

35. Maint - Design
The scope of the design will be restricted to the maintenance requests
The design document template can be tailored based on the nature of the request.
Ensure traceability
From request to design
From design to request

36. Maint- Work handling Receive the MR Log the Request
Use tools like AMO log
Analyze the requirements and ensure that adequate details are available
Estimate the effort required
Ensure that SLAs can be met
Impact Analysis
Feasibility
Classification
CIs to be changed
Cost/effort impact
Schedule impact
Risks
Quality

37. Thank You