1 / 44

Why Is Software Difficult to Build?

Why Is Software Difficult to Build?. Lack of control Lack of monitoring Lack of traceability Uncontrolled changes. Conflicts in Team Software Development. Simultaneous updates – how to prevent one person from undoing the changes of another

milton
Download Presentation

Why Is Software Difficult to Build?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related