• No results found

SA4 Software Developer Survey Survey Specification v2.2

N/A
N/A
Protected

Academic year: 2021

Share "SA4 Software Developer Survey Survey Specification v2.2"

Copied!
10
0
0

Loading.... (view fulltext now)

Full text

(1)

SA4 Software Developer Survey

Survey Specification v2.2

Last updated: 30-06-2009

Activity: SA4 Dissemination Level: PP (Project Participants) Document Code: GN3-09-134

(2)

Table of Contents

1 Introduction 1

2 Software Developer Survey Contents 2 2.1 Instructions for Responders (at the Start of the Survey) 2

2.2 Project Demographics 3

2.3 Management and IPR 4

2.3.1 Project Management 4

2.3.2 IPR and Licensing 4

2.4 Development 5

2.4.1 Coding 5

2.4.2 Version Control Management and Bug Tracking 6 2.4.3 Building and Integration 6 2.4.4 Quality Assurance and Testing 6

2.4.5 Documentation 7

2.5 Rollout and User Support 7

2.5.1 Deployment 7

2.5.2 Maintenance and User Support 8

(3)

1

Introduction

This document describes the proposed contents of the SA4 (Software Governance) Software Developer Survey which targets software developers participating in other GN3 SA and JRA activities. The data gathered through this questionnaire will be used by SA4 tasks, primarily Task 1 (Best Practices) and Task 3 (Software Development Infrastructure).

The purpose of the SA4 Software Developer Survey is to investigate developer perspective and needs in areas related to software governance, and to identify practices and tools that are already used in software development and maintenance within GN3. It will provide information about developers' experiences, practices, used tools, identified issues, plans and proposals related to SA4.

The survey is to be performed in all SA and JRA activities and tasks that will use the recommendations and software development infrastructure developed by SA4. It is expected to be conducted by the primary technical contact or coordinator, or by a single competent representative for each software development or developer group that encompasses a single development or maintenance practise. One completion of this survey may cover a single or several closely related applications, as long as all of them apply a uniform set of software project management practises.

The survey is to be implemented by using the Unit Command Climate Assessment and Survey System (UCCASS) software (http://www.bigredspark.com/survey.html) hosted by AMRES-RCUB at

http://questionnaire.rcub.bg.ac.rs/. Its results will be available at the same address.

SA4 Software Developer Survey Survey Specification v2.2

(4)

2

Software Developer Survey Contents

2.1

Instructions for Responders (at the Start of the Survey)

The purpose of this survey is to investigate developer perspective and needs in areas related to software governance, and to identify practices and tools that are already used in software development and maintenance within GN3.

The survey is to be performed in all SA and JRA activities and tasks that will use the recommendations and software development infrastructure developed by SA4, and should be filled in for each software development or developer group within GN3 that encompasses a uniform set of software project management practises. It should be conducted by the primary technical contact or coordinator, or by a single competent representative, for example, a senior developer familiar with actual development and software management procedure, requirements, and issues.

The data gathered by the questionnaire will be used mostly by SA4 Tasks 1 (Best Practices) and 3 (Software Development Infrastructure).

You do not have to answer questions regarding topics that are outside your interests or expertise, and you can skip sections that are not relevant to your application(s). However, if some subject is of your particular interest, please provide details about your needs, as well as additional information that you may have on the topic. This survey consists of 62 questions grouped into 12 pages. No input will be saved unless you click "Finish" on the last page. Further corrections are not possible after this point, but you can repeat the submission process (marking this in answer to the first question), or report correction to gn3-sa4-taskleaders@geant at net domain. To access the questions more easily you may decide to read the static version of SA4 Software Developer Survey, prepare detailed inputs off-line, and then fill in the web forms. The static version of the questionnaire is available at:

http://wiki.geant.net/pub/SA4/Admin/DocumentsMain/GN3-09-134-SA4-Software-Developer-Survey-Specification.pdf

(5)

2.2

Project Demographics

1. *What is the acronym or name of your main project, development or tool? (For example perfSONAR, AMPS, AutoBAHN, cNIS, I-SHARe)

2. *If different, what is the name of your primary software component?

(For example. perfSONAR components are: RRD Measurement Archive, SQL Measurement Archive, SSH/Telnet Measurement Point, AS (Authentication and Authorization Service), E2Emon Measurement Point, CNM, perfsonarUI…)

3. *What is the aim of your software project?

(For example: proof of concept, prototype, pilot deployment, deployed operating solution, supporting tool (testing / measuring, library, plugin), integration tool…)

4. *What is your GN3 activity? ○ JRA1 ○ JRA2 ○ JRA3 ○ NA2 ○ NA3 ○ NA4 ○ SA1 ○ SA2 ○ SA3 ○ SA4

5. *What is your task in the above GN3 activity? ○ T1 ○ T2 ○ T3 ○ T4 ○ T5 ○ T6 ○ T7

SA4 Software Developer Survey Survey Specification v2.2

(6)

Software Developer Survey Contents

2.3

Management and IPR

2.3.1

Project Management

6. Is there any overall strategy for your software development? If so, describe it briefly. 7. List any project management or software development methodology you use.

(Names or URLs, for example OpenUP, RUP, Extreme Programming (XP), Scrum… If only some elements of some methodology are used, please describe briefly!)

8. Describe the overall software architecture of your development. (Description or URLs)

9. *Does your project design involve clear decomposition of components, modules or units and also clear specification of their responsibilities and interfaces?

○ Yes ○ No ○ Partially ○ Do not know

10. Is there a development roadmap plan or overall planning management procedure? (Description or URLs)

11. List any collaboration tools you use: wikis, forums, mailing lists, video conferencing platforms… (Description or URLs)

12. Do you have any internal documentation with directions or recommendations related to best practices that could be offered to others?

(Description or URLs)

13. Are there any apparent problems or possible solutions related to current project management practices?

2.3.2

IPR and Licensing

14. Describe your IPR policy and how it is coordinated with Geant/GN3, if in place. (Description or URLs)

(7)

and any other licensing or license-compatibility problem affecting the results of your development? (This is not related to the licensing status of internally used tools.)

○ Other software is used, but there are no licensing issues ○ Other software is used, there may be some licensing issues ○ No

○ Do not know

18. Describe any other potential issues regarding the license compatibility between your software and other software, library or component.

(You may wish to describe the situation in terms of licenses without actually naming any particular software.)

19. Are there any other problems related to IPR and licensing and possible solutions? For example, can you describe in which areas clarifications are needed or recommend resources and tools that may help address IPR and licensing issues (like FOSSology software)?

2.4

Development

2.4.1

Coding

20. *List the programming languages you use.

(Names or URLs, for example Java, C++, Python…)

21. List any other key technologies related to making, design or execution of code that require attention in terms of best practices.

(Names or URLs, in relation to modelling, database management, code generation, GUI creation, or underlying platform your code is interacting with…)

22. Describe any coding rules, formatting, commenting and naming conventions you use. (Description or URLs)

23. List any procedures and tools you use for code quality checking and enforcement.

(Names or URLs, for example Checkstyle, FindBugs, PMD/CPD, Glean, QALab, XRadar…) 24. *List any IDEs or build environments you use.

(Names or URLs, for example Eclipse, NetBeans, JBuilder, Visual C, command line and build tools as make, CMake, Ant, Maven…)

SA4 Software Developer Survey Survey Specification v2.2

(8)

Software Developer Survey Contents

25. Describe any security-related coding procedures or guidelines targeting checking and avoidance of vulnerabilities, access control, data validation and authentication.

(Description or URLs)

26. Describe any means you use for the configuration management of development tools and infrastructure.

2.4.2

Version Control Management and Bug Tracking

27. *List the revision control (version control, source control, SCM) software you use.

(Names or URLs, for example Subversion (SVN), CVS, SourceSafe, Mercurial, Bazaar, Git… Also mention Web front-end, if any, as WebSVN, FishEye…)

28. Describe any commit procedures you use.

(Description or URLs, in relation to frequency, branching, passing of builds, tests and other checks) 29. *List issue, bug, task reporting, tracking and management tools you use.

(Names or URLs, for example Bugzilla, Jira, Trac, Mantis, spreadsheets, text documents…)

30. Describe current or desired operational parameters of revision control service, in terms of backup frequency, reliability, and need for failover.

(Description or URLs)

31. Describe any problems related to current source control management practices and possible solutions.

2.4.3

Building and Integration

32. *Describe what aspects of the building and integration process are involved in your practice.

(Building of executables, libraries, installations and documentation, dependency management, automatic deployment and testing, publishing, release management…)

33. List any build management and publishing tools you use. (Names or URLs, for example Maven, Ant, Ivy…)

34. List any continuous integration tools you use.

(Names or URLs, for example Hudson, CruiseControl, Continuum, Bamboo…)

35. Describe any problems related to your current building and integration practices and possible solutions?

(9)

38. List any test tools you use.

(Names or URLs, for example JUnit, TestNG, Selenium, soapUI, Cobertura, jcoverage…) 39. Describe any code metrics you use.

(Description or URLs)

40. Describe your usage of dedicated testing infrastructure or servers. (Description)

41. Describe any problems related to current quality assurance practices and possible solutions.

2.4.5

Documentation

42. *Describe your approach and policies towards documentation, including any existing technical and user documentation guidelines.

(Description or URLs)

43. List any documentation templates you use and describe good examples of technical and user documentation.

(Description or URLs)

44. List any source code documentation tools or documentation generators you use. (Names or URLs, for example Doxygen, ROBODoc, Natural Docs…)

45. To what extent do you use UML and other type of modeling languages?

(For example at conceptual level, within the whole lifecycle… Also mention what software tools and types of diagrams are being used…)

46. List any user documentation, help authoring tools and formats you currently use.

(Names or URLs, for example DocBook XML, wiki, MS Word, OpenOffice Writer, JavaHelp, RoboHelp, KeyTools, HelpSetMaker…)

47. Describe any problems related to current documentation practices and possible solutions.

2.5

Rollout and User Support

2.5.1

Deployment

48. *Describe any deployment management policies and procedures you use.

(For example in relation to verification, piloting (use of alphas, betas, release candidates…), release management, naming of packages)

SA4 Software Developer Survey Survey Specification v2.2

(10)

Software Developer Survey Contents

49. Describe any tool or processes you use for software packaging, installation, distribution and usage. (Description or URLs)

50. Describe your usage of code signing.

(For example creation and usage of signatures, checksums and certificates, relation with AAA infrastructure)

51. Is there a need for configuration management for instances of deployed software? List any tools you use.

(Description, names or URLs)

52. Describe any problems related to current deployment practices and possible solutions.

2.5.2

Maintenance and User Support

53. Describe any existing procedure and guidelines for release management. (Description or URLs)

54. Describe any installation and upgrade procedures you have. (Description or URLs)

55. Describe your issue prioritisation and user support procedures. (Description or URLs)

56. Describe any change management and feature request adoption process you have. (Description or URLs)

57. Describe any documentation dissemination procedures and distribution channels you use. (Description or URLs)

58. Describe your user training approach – means and practices. (Description or URLs)

59. Describe your user support approach, as well as used tools and infrastructure as helpdesk, contact person, issue and request tracking or CRM software, support web site or information page, blog, forum, mailing list...

(Names, description or URLs)

References

Related documents

(c) Column water vapor binned by aerosol optical depth for all co-located warm cloud retrievals with cloud fractions less than 0.5. (d) Cloud fraction binned by aerosol optical

Many of the rituals that people perform for Chinese weddings in Singapore are seen as “traditional” and understood as rites that have been passed on through

Rezultati, ki smo jih pridobili s preuˇ cevanjem zelo redkih kart, predvsem pa tistih bolj priljubljenih, pa nam lahko v praksi z dovolj visoko toˇ cnostjo napovedi pripomorejo

, 2014 ( 13 ) SCZ (41) and HC (42) Dynamic causal model ( 100 ) derived from fMRI data Gaussian mixture 3 [Bayesian model evidence ( 101 )] Subgroups characterized in terms of DCM

The Chief Executive Officer and the ITF Committee voted on January 26, 2009, to recommend funding in the amount of $2,400,000 to support the acquisition and implementation of

It shows that by using EVMDDs, the structure functions can be represented more compactly than existing methods using ordinary MDDs, and systems can be analyzed with

Among other things, we show that regions may subsidize or tax the mobile factor, there may be a positive or negative correlation between regional tax rates and the ratio of mobile

Component Architecture of Packet Decoder describes its interaction with other components and the interface it implements to offer its service (Section 3.2).. Pass