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

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 20000-2011 - IMS • CMMi Version 1.3 – Maturity Level 3 - ADM • ITIL Framework - IMS • URL: http://mygavs/

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. Projects @ GAVS • Development • Maintenance • Testing • Support

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

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 email • 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 email • 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 • 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 • 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 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 • 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 • 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