Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Why Is Software Difficult to Build?  Lack of control  Lack of monitoring  Lack of traceability  Uncontrolled changes."— 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 Other Processes 3 With a focus on: Configuration management Change management

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 4

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

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 6

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 7

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 8

9 Relationship with Dev Process Other Processes 9

10 10

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 14

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 15

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 17

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 18

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 19

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 20

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 21

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 23

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 24

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 25

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

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 27

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 28

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 29

30 Other Processes 30

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 31

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 33

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 34

35 35 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 36

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 43

44 Examples  Collegiate Project Services eliminaryChangeManagementPlan.pdf eliminaryChangeManagementPlan.pdf  Eclipse: equest_faq.php equest_faq.php Other Processes 44


Download ppt "Why Is Software Difficult to Build?  Lack of control  Lack of monitoring  Lack of traceability  Uncontrolled changes."

Similar presentations


Ads by Google