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

(1)

Afiya Nusrat and Navreet Ghag CS 846 Spring 2015

A Study of RE Across Different

Software Development Lifecycle

Models

(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

(3)

(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

(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)

(7)

Operations Overview

Level 2 Global Support Lab Advocate Customer Level 3 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

● At each stage

o Qualification planning

o Requirement collection

o Testing in parallel

Customer Req. Elicitation

System Req. Development

Architectural Development

Subsystem Req. Dev.

Component Development Operation Acceptance Test System Test Integration Test Component Test

(9)

● 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

 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

Customer Requirement

Customer Req. Elicitation Architectural Development System Req. 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 Architectural Development System Req. 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 Architectural Development System Req. 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 Architectural Development System Req. Development Subsystem Req. Dev. Component Development

(13)

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

(16)

(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

(19)

(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.”

Development

Operations Requirements

(21)

(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)

(24)

The Team

● Agile Methodology ● Daily Standups

● Code pushed to production every week or sometimes twice a week

(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

(26)

My Team’s Job

(27)

My Team’s Job

● Community Management

(28)

My Team’s Job

● Community Management

● Each community has its own manager ● Create recruitment/research surveys,

Manage invitation/reminder/confirmation emails, 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

www.cocacolacommunity.com/c/aspxlksj12hjsh o12 with www.cocacolacommunity.com/c/r/join

(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)

(31)

Back end Work Analysis

● Created a design proposal - sent in email to dev

manager, team lead, software architect and a senior team member

(32)

Back end Work Analysis

● Presented the design proposal in a meeting

(33)

Back end Work Analysis

● 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

(35)

Back end Work Analysis

A lot of emails 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 email - some emails exchanged suggesting changes changes made -another meeting - -another presentation - a healthy

(37)

Back end Work Analysis

discussion

(38)

Back end Work Analysis

discussion

ACCEPTED

requirements & design decisions were finalized, story points were re-adjusted

(39)

Back end stories were

(40)

UI Story Analysis

● UI team sent us a document , highlighting the UI features

(41)

UI Story Analysis

● Created an acceptance criteria , had one official meeting with prod manager to

(42)

UI Story Analysis

● Created an acceptance criteria , had one official meeting with prod manager to

analyze requirements

(43)

(44)

(45)

UI Story Progress

(46)

UI Story Progress

● A lot of desk checks

(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

(48)

(49)

Why did that happen ?

(50)

Why did that happen ?

Incorrect time estimation OR

(51)

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

(52)

(53)

Why ME ??

● New to the way team works - can better point out defects

(54)

Story Review

(55)

Story Review

● We never had an official meeting with UI team ● We were sent the UI design far too early in the

(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

(60)

Story Review

● A lot of back and forth between different phases of SDLC

(61)

Story Review

● A lot of back and forth between stages of SDLC ● Inaccurate time estimate

(62)

Story Review

(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

(65)

(66)

(67)

(68)

(69)

What was missing?

(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

(72)

Observation 1

- 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

(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:

(78)

Observation 2

● Improper time estimates

- This created a lot of stress both on devs and QAs

(79)

Solution 3

● In agile , always try to split story into parts. Bigger stories can usually come up with

unexpected complications

(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

(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

(84)

Scope for Improvement

Behaviour Driven Development: ● Requires training

(85)

Scope for Improvement

(86)

Scope for Improvement

● How much is enough?

(87)

Scope for Improvement

Expected to come with experience

(88)

Scope for Improvement

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, 2010.

3. Link to DevOps white papers

4. John H Lopes, Evaluation of Behavior Driven Development,

(91)

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