Why Is Software Difficult to Build?

1. Why Is Software Difficult to Build? • Lack of control • Lack of monitoring • Lack of traceability • Uncontrolled changes

2. Conflicts in Team Software Development • Simultaneous updates – how to prevent one person from undoing the changes of another • Shared and common code – how to notify everyone who needs to know about a change • Versions – how to make changes to all affected versions when needed

3. With a focus on: Configuration management Change management Other Software Processes Other Processes

4. Other Processes • Development Process is the central process around which others revolve • Methods for other processes often influenced by the dev process Other Processes

5. Other Processes In the context of Dev Processes Other Processes

6. Monitoring and control • Aspect of project management process • Lasts for the duration of the project and covers the development process • Monitors all key parameters like cost, schedule, risks • Takes corrective actions when needed • Needs information on the dev process – provided by metrics Other Processes

7. Communication Facilitation • Realistically no plan covers everything! • Additional decisions are made during development • Documents should be updated and communicated • Typical environment • Multiple teams • Multiple user groups • Multiple disciplines • Multiple locations • In many setting PM is center of communication hub • Planning and content meetings Other Processes

8. Meeting Types • Issues Meetings • Regularly schedule meeting (ie. open in everyone’s schedule) • Issues gathered the day before and distributed • Issue initiator indicates required attendance • QA Meetings • Planning • Discussion with business • Discussion with developers • Regular Review of open tickets Other Processes

9. Relationship with Dev Process Other Processes

10. Configuration Management Process Other Processes

11. Software Configuration Management Basics • Identification – identifying software configuration items in a baseline • Control – controlling the release of a product and changes to it throughout its lifecycle • Status Accounting – recording and reporting of the status of components and changes • Auditing and Reviewing – Validating the completeness of a product and that SCM procedures are being followed

12. SCM Definitions • Baseline – One or more software configuration items that have been formally reviewed and agreed upon and serve as a basis for further development • Software Configuration Item – A collection of software elements treated as a unit for the purposes of SCM • Configuration – A collection of all the elements of a baseline and a description of how they fit together

13. SCM Definitions (cont’d) • Configuration Control Board – Group with the responsibility for reviewing and approving changes to baselines • Software – All of the code, specifications, plans, descriptions, processes, and documents associated with a software development effort • Version – A specific instance of a baseline or configuration item

14. Background • A software project produces many items - programs, documents, data, manuals, … • All of these can be changed easily – need to keep track state of items • Software Configuration Management (SCM) • Systematically control the changes • Focus on changes during normal evolution (req changes will be handled separately) • CM requires discipline as well as tools Other Processes

15. Background • SCM often independent of dev process • Dev process looks at macro picture, but not on changes to individual items/files • As items are produced during dev they are brought under SCM • SCM controls only the products of the development process Other Processes

16. Examples of Configuration Items • Product concept specification • Software project plans • Software requirements specifications • Software design descriptions • Source code • Database descriptions • SCM procedures • Software release processes • Software test documents • User documentation • Maintenance documentation

17. SCM Process and Dev process Other Processes

18. Need for CM • CM needed to deliver product to the client • What files should comprise the product? • What versions of these files? • How to combine these to make the product? • Just for this, versioning is needed, and state of different items has to be tracked • There are other functions of CM also Other Processes

19. Functionality Needed • Capture current state of programs • Capture latest version of a program • Undo a change and revert back to a specified version • Prevent unauthorized changes • Gather all sources, documents, and other information for the current system Other Processes

20. CM Mechanisms • Configuration identification and baselining • Version control • Access control • These are the main mechanisms, there are others like • naming conventions, • directory structure,… Other Processes

21. Configuration Items • Sw consists of many items/artifacts • In CM some identified items are placed under CM control • Changes to these are then tracked • Periodically, system is built using these items and baselines are established • Baseline – logical state of the system and all its items; is a reference point Other Processes

22. Version Control • Allows different projects to use the same source files at the same time • Isolates work that is not ready to be shared by the rest of the project • Isolates work that should never be shared • Allows software engineers to continue development along a branch even when a line of development is frozen

23. Version and access control • Key issues in CM • Done primarily on source code through source code control systems, which also provide access control • Allows older versions to be preserved and hence can undo changes • Examples: • CVS – Original open source system (1986) • Subversion – Open source CVS replacement (1999) • Microsoft Visual SourceSafe (VSS) – targeted for smaller dev projects • IBM Rational ClearCase – Industrial strength solution Other Processes

24. Version and Access Control • When programmer developing code – is in private area • When code is made available to others, it goes in an access-controlled library • For making changes to an item in library, it has to be checked out • Changes made by checking-in the item – versioning is automatically done • Final system is built from the library Other Processes

25. Version/Access Control • Generally both version and access control done through CM tools • Tools limit access to specified people - formal check in, check out procedures • Automatic versioning done when a changed file is checked-in • Check-in, check-out control may • be restricted to a few people in a project • Require successful compile/build cycle Other Processes

26. CM Process • Defines the activities for controlling changes • Main phases • CM Planning • Executing the CM process • CM audits Other Processes

27. CM Planning • Identify items to be placed under CM • Define library structure for CM • Define change control procedures • Define access control, baselining, reconciliation, procedures • Define release procedure Other Processes

28. CM Audit • During project execution CM procedures have to be followed (e.g. moving items between directories, naming, following change procedures, …) • Process audit has to be done • CM audit can also check if items are where they should be Other Processes

29. Summary – CM • CM is about managing the different items in the product, and changes in them • Developing a CM plan at the start is the key to successful to CM • CM procedures have to be followed; audits have to be performed • Requires discipline and tools Other Processes

30. Requirements Change Management Process Other Processes

31. Background • Requirements change at any time during the development • Changes impact the work products and the various configuration items • Uncontrolled changes can have a huge adverse impact on project in cost/sched • Changes have to be allowed, but in a controlled manner Other Processes

32. Change Control • Proposed changes to baselines must have some level of review • The impact of proposed changes must be identified and understood. • When appropriate the approval of the CCB, key managers and project members must be obtained • Approved changes must be properly implemented • After changes are made all affected parties must be notified

33. A Change Mgmt Process • Log the changes • Perform impact analysis on the work products and items • Estimate impact on effort and schedule • Review impact with stakeholders • Rework the work products/items Other Processes

34. Changes • Change often triggered by change request • Change req log keeps a record of requests • Impact analysis for a change request involves identifying the changes needed to diff items, and the nature of change • The impact of changes on the project is reviewed to decide whether to go ahead • Cumulative changes also often tracked Other Processes

35. http://www.marinebiodiversity.ca/COINAtlantic/development-implementation-sustainability/geoconnections-coinatlantic/web-mapping-application/User%20Acceptance%20Test%20Plan%20and%20Change%20Request%20Process%20-%20Cur....pdf/viewhttp://www.marinebiodiversity.ca/COINAtlantic/development-implementation-sustainability/geoconnections-coinatlantic/web-mapping-application/User%20Acceptance%20Test%20Plan%20and%20Change%20Request%20Process%20-%20Cur....pdf/view

36. Baseline CM • Recall: • A baseline is one or more software configuration items that have been formally reviewed and agreed upon and serve as a basis for further development Other Processes

37. Baseline Management • What baselines are required to be defined and managed? • Typically aligned with major milestones • Applies to documents as well as code • How is the current software configuration defined? • A snapshot of everything the product has produced at some point in time

38. Baseline Management (cont’d) • Who must approve changes to baselines? • Usually the Change Control Board (CCB) • How and when are baselines created and physically controlled? • Through the use of document control systems, code control tools, and procedures to prevent the making of unapproved changes

39. Baseline Management (cont’d) • How are people informed of changes? • The CCB disseminates change information • How are baselines verified? • By reviews, inspections, and the testing of code • Are baselines tied to project milestones? • Many are, but during coding many may not be

40. Baseline Management (cont’d) • What information is required to process a change to a baseline? • A description of the proposed changes • Reasons for making the changes • List of other items affected by the changes • What tools, resources, and training are required to perform baseline change assessment? • File comparison tools to identify changes • Resources and training depend on size and complexity of project

41. Baseline Management (cont’d) • How are unauthorized changes to source code prevented, detected, and corrected? • No way to prevent unauthorized changes • Provide software engineers with training • A commercial available SCM systems provide adequate protection • Unauthorized changes should be caught during assessment procedures

42. Baseline Management (cont’d) • What tools, resources, and training are required to perform baseline management? • A fully featured SCM tool • On large projects a separate SCM group may be needed • SCM training is required for all involved in the process

43. For your project: • Should have a configuration management process defined • Change management procedures • Any changes to the baseline documents should be documented and include a formal change management request Other Processes

44. Examples • Collegiate Project Services http://www.collegiateproject.com/articles/PreliminaryChangeManagementPlan.pdf • Eclipse: http://www.eclipse.org/epf/process/change_request_faq.php Other Processes