A Study of RE Across Different Software Development Lifecycle Models. Afiya Nusrat and Navreet Ghag CS 846 Spring 2015

Transcription

1 A Study of RE Across Different Software Development Lifecycle Models Afiya Nusrat and Navreet Ghag CS 846 Spring 2015

2 Motivation In-depth look at the SDL process and requirements gathering in two companies Experiental details, personal observations, not a comparative study! Discuss differences in : SDL process Product Team organization

3 Case Study A

4 Case Studies Company A o Fortune 500 MNC headquartered in NY o Manufactures and markets computer hardware and software, and offers infrastructure, hosting and consulting services o Market cap of B

5 The Team Worked in the L3 Continuing Engineering team in the Software Group for leading RDBMS The team owns code bases for the database server products over a variety of platforms Responsible for product maintenance and bugs Identify and drive new product features to improve functionality, performance and customer satisfaction

6 The Team

7 Operations Overview Level 3 Global Support Lab Advocate Customer Level 2 Global Support Technical Sales Level 1 Local Support

8 Development Lifecycle SDL - loosely based on classic V model Each phase corresponded to a stage in the V model Customer Req. Elicitation System Req. Development Architectural Development Operation Acceptance Test System Test At each stage o Qualification planning o Requirement collection o Testing in parallel Subsystem Req. Dev. Component Development Integration Test Component Test

9 Customer Requirement All code changes are customer driven Customer issues are usually abstract and performance related CE takes the abstract problem descriptions and formalize requirements Issues could be categorized into: o Code Bugs Customer Req. Elicitation APAR - Authorized Program Analysis Report Documented, fixed, tested and delivered o Request For Enhancement Line Items - New feature development Go through the entire software cycle System Req. Development Architectural Development Subsystem Req. Dev. Component Development

10 Planning and System Req. Formation of Planning Team Stakeholders: Architects, Legal team, Project managers, Sales Negotiations to decide on best course of action Customer requirements are elicited Planning phase consists of commiting customer specifications to development plan Customer Req. Elicitation System Req. Development Architectural Development Subsystem Req. Dev. Component Development

11 Architectural Development All architectural, system and subsystem requirements are gathered through regular meetings with the architects and developers Functional, Non-functional and Domain requirements charted out The team comes up with two main documents: o High Level Document (HLD) - functional design o Low Level Document (LLD) - code level design Customer Req. Elicitation System Req. Development Architectural Development Subsystem Req. Dev. Component Development

12 Component Development Coding Stage Based on type of work, developer specialization and availability, the project was assigned to one or more developers At each stage of development, code is reviewed for efficiency and serviceability Developer is also responsible for code unit testing Customer Req. Elicitation System Req. Development Architectural Development Subsystem Req. Dev. Component Development

13 Testing Testing Along with the system requirement collection phase, testing requirements are collected in parallel QA members of the planning team develop two different plans: o Functional Verification Testing (FVT) o System Verification Testing (SVT) o PQA Goal was to test early and trace to the requirements Requirements driven testing Operation Acceptance Test System Test Integration Test Component Test

14 Observations Every stage of the process involved reviews and feedbacks Requirements were modified based on these reviews It is to be noted that the customer only gave functional requirements The developers come up with all other requirements Inflexible and linear nature of the entire process led to problems on encountering changes!

15 Observations (contd) Lot of work was left for future extensions o Fragmentation and reduced modularity of code o Technical debt Insufficient testing - lack of resources, skills and looming deadlines Test plans did not account for integration testing During unit testing, I found static SQL testing to be very slow. Felt the need for alternate testing models V-model process cycle was generally slow, APARs took 3-6 months to release and line items took around 1 year Organization wide shift towards a cloud based model...

16 The New Approach

17 DevOps DevOps = Developers + Operations Extends the goals of agile movement to operations Promotes cross-functionality, shared responsibilities and trust Encourages automation of change, configuration and release process

18 What Changed.. Incorporated agile model in both development and product release odivide large items into short stories ocreate squads to handle stories in each sprint Opted for shorter delivery times owork with test and production team Frequent revisit of initial requirements o Consideration for both development and operations o Faster failure recovery times

19 The Squad

20 How did this new model effect the requirements? In DevOps, requirements are not only shaped by development feedback but also by operations monitoring. This means requirements affect development, development affects operations and operations affect requirements. Requirements Operations Development

21 Case Study B

22 Case Studies Company B o MNC headquartered in Vancouver o Provides a cloud-based customer intelligence platform o One of the Top 500 Fastest Growing Companies in Canada

23 The Team

24 The Team Agile Methodology Daily Standups Code pushed to production every week or sometimes twice a week Weekly scrums

25 The Team Feature development - Analysis - divide feature into smaller stories - analyse + requirements gathering + time estimates + rounds of design proposals + change in requirements + meetings + requirements finalized + start development - changes in requirements can still pop in

26 My Team s Job Community Management

27 My Team s Job Community Management Each community has its own manager

28 My Team s Job Community Management Each community has its own manager Create recruitment/research surveys, Manage invitation/reminder/confirmation s, create participation stats, export member/participation data, upload member information, etc.,

29 The New Feature: Custom URLs The ability to replace system generated anonymous survey + recruitment links with cleaner labels, i.e. replace o12 with

30 Feature Analysis Design and implement a restful API: 8 story points (3 sprints) Design and implement a redirect controller: 2 story points (1 sprint ) Design and implement a UI: 2 story points (1 sprint) Defined an acceptance Criteria for each

31 Back end Work Analysis Created a design proposal - sent in to dev manager, team lead, software architect and a senior team member Presented the design proposal in a meeting

32 Back end Work Analysis Created a design proposal - sent in to dev manager, team lead, software architect and a senior team member Presented the design proposal in a meeting REJECTED

33 Back end Work Analysis Created a design proposal - sent in to dev manager, team lead, software architect and a senior team member Presented the design proposal in a meeting REJECTED Missed requirements, lack of requirement understanding, identified better implementation ways, compromised on some requirements, etc.

34 Back end Work Analysis A lot of s were exchanged back and forth

35 Back end Work Analysis A lot of s were exchanged back and forth That brought us: clarity + better vision of future requirements of the same feature

36 Back end Work Analysis Created second design proposal - sent in - some s exchanged suggesting changes - changes made - another meeting - another presentation - a healthy discussion

37 Back end Work Analysis Created second design proposal - sent in - some s exchanged suggesting changes - changes made - another meeting - another presentation - a healthy discussion ACCEPTED

38 Back end Work Analysis Created second design proposal - sent in - some s exchanged suggesting changes - changes made - another meeting - another presentation - a healthy discussion ACCEPTED requirements & design decisions were finalized, story points were re-adjusted

39 Back end stories were completed nicely and in time!!

40 UI Story Analysis UI team sent us a document, highlighting the UI features

41 UI Story Analysis UI team sent us a document, highlighting the UI features Created an acceptance criteria, had one official meeting with prod manager to analyze requirements

42 UI Story Analysis UI team sent us a document, highlighting the UI features Created an acceptance criteria, had one official meeting with prod manager to analyze requirements Minimal changes were requested

43 Previous UI

44 Revised UI

45 UI Story Progress A lot of desk checks

46 UI Story Progress A lot of desk checks A lot of changes popped in

47 UI Story Progress A lot of desk checks A lot of changes popped in Back and forth between analysis + development + desk check -- back to requirements gathering and so on TIME TAKEN = 3 * (ESTIMATED TIME )

48 Why did that happen?

49 Why did that happen? Incorrect time estimation

50 Why did that happen? Incorrect time estimation OR New to UI development + New unit test Framework

51 My manager asked me to analyse, observe, talk and make suggestions

52 My manager asked me to analyse, observe, talk and make suggestions Why ME??

53 My manager asked me to analyse, observe, talk and make suggestions Why ME?? New to the way team works - can better point out defects I faced it first hand

54 Story Review We never had an official meeting with UI team

55 Story Review We never had an official meeting with UI team We were sent the UI design far too early in the process

56 Story Review We never had an official meeting with UI team We were sent the UI design far too early in the process Failed to identify the impossible requirements early on in the process

57

58 Story Review Underestimated the changes required in old implementation

59 Story Review Underestimated the changes required in old implementation A lot of back and forth between stages of SDLC

60 Story Review Underestimated the changes required in old implementation A lot of back and forth between different phases of SDLC Inaccurate time estimate

61 Story Review Underestimated the changes required in old implementation A lot of back and forth between stages of SDLC Inaccurate time estimate Did not divide UI work into smaller stories

62 Story Review A lot of test-rewrite

63 Story Review A lot of test-rewrite UI teams never sent us any docs with revised UI designs

64 Story Review A lot of test-rewrite UI teams never sent us any docs with revised UI designs Missed scenarios

65

66 Talked to other Team Members

67 Researched and Observed

68 What was missing?

69 What was missing? Improper Requirements Gathering

70 Observation 1 Not enough requirement analysis with the product manager and ui team as it was done amongst the technical team

71 Observation 1 Not enough requirement analysis with the product manager and ui team as it was done amongst the technical team - Gap between their understanding

72 Observation 1 Not enough requirement analysis with the product manager and ui team as it was done amongst the technical team - Gap between their understanding - Emotional issues: hesitant to ask too many questions too many times (6/10)

73 Solution 1 Thorough analysis should be done with product managers and UI team in early stages

74 Solution 1 Thorough analysis should be done with product managers and UI team in early stages UI designs should be sent in after a proper story analysis

75 Solution 2 Behaviour Driven Development

76 Solution 2 Behaviour Driven Development - A recent addition to the family of Agile software engineering methods [4] - Combines ideas from TDD and DDD - Use of domain language throughout the process

77 Solution 2 BDD relies on use of very specific (and small) vocabulary to minimise miscommunication Four primary clauses are used to define scenarios: Given, When, Then, And

78 Observation 2 Improper time estimates - This created a lot of stress both on devs and QAs - Reduced productivity

79 Solution 3 In agile, always try to split story into parts. Bigger stories can usually come up with unexpected complications Smaller stories can be thoroughly analysed

80 Observation 3 Not enough QA involvement in Analysis phase

81 Observation 3 Not enough QA involvement in Analysis phase - A good QA is the best thing to happen to a team. - During manual testing, QAs came up with many missed scenarios

82 Solution 4 QAs should be kept in loop from requirement gathering till testing They act as a bridge between technical and non technical teams Identify maximum test cases before starting development - this aids understanding of requirements

83 Observation 4 Jumping between stories - Too many stories in progress at once - Devs tend to jump to new stories while QA on current story is not yet completed - Too much back and forth between stories leads to improper understanding of requirements of new story

84 Scope for Improvement Behaviour Driven Development: Requires training

85 Scope for Improvement Behaviour Driven Development: Requires training How much is enough?

86 Scope for Improvement Behaviour Driven Development: Requires training How much is enough? Expected to come with experience

87 Scope for Improvement Behaviour Driven Development: Requires training How much is enough? Expected to come with experience Should BDD be adopted completely?

88 Scope for Improvement Behaviour Driven Development: Requires training How much is enough? Expected to come with experience Should BDD be adopted completely? Exhaustive test case identification

89 Discussion Adaptability More analysis and communication required between participating technical and non technical teams. BDD helps improve understanding and avoids miscommunication

90 References 1. An integrated approach to requirements and quality management, (White Paper), June 2009 ftp://public.dhe.ibm.com/software/emea/de/rational/neu/an_integrat ed_approach_to_requirements_and_quality_management_en_200 9.pdf 2. Hull, Elizabeth, Ken Jackson, and Jeremy Dick. Requirements engineering. Springer Science & Business Media, Link to DevOps white papers 4. John H Lopes, Evaluation of Behavior Driven Development, TUDelft, August 2014

91 Thank You! Any Questions?