Software Engineering

1. Software Engineering Software Configuration Management

2. Objectives • To make clear the inevitability of software change. • To define the terminology of software configuration management. • To cover the issues involved in effective change control.

3. Dealing with Change • “No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle.” • Configuration management is the art of identifying, organizing, and controlling modifications to software so as to keep mistakes and confusion to a minimum. • Software Configuration Management is an umbrella activity (much like SQA) applied throughout the software process. • Tasks: • Identify change • Control change • Ensure that change is being properly implemented • Report changes to others who might have an interest

4. What Are These Changes? changes in business requirements changes in technical requirements changes in other documents user requirements software models Project Plan data Tests code

5. Software Configuration Terminology • Baseline: • A specification or product that has been formally reviewed an agreed upon. • Can only be changed through formal control procedures. • Software Configuration Items: • The objects that make up a baseline. Information created during the software engineering process. • For example: a suite of test cases, a program component, an analysis model. • May also include specific versions of editors, compilers and case tools, which need to be “frozen”. • Must also specify dependencies and relationships between SCI’s. • Once reviewed an approved they are placed in a project database (also called a project library or software repository)

6. The SCM Process • Identification: SCI must be separately named and related. • Version Control: recording different versions of an SCI. • Change Control: managing the way in which changes are carried out. • Auditing: making sure that change is properly implemented. • Reporting: ensuring accountability • A balancing act (creativity vs. control) Software Engineering SCM • identification tools • version control methods • change control procedures • auditing a TQM foundation • reporting

7. Version Control • Allows management of configurations through selection of variants or versions. • Associate attribute-tuples with each SCI. Can be as complex as a string of Boolean switches indicating functionality. • Variant: A set of SCI at the same version level with different functionality. • Version: A change in an SCI spawns a new version. Variants SCI Versions

8. Change Control Process Need for change is recognized Change request from user Developer evaluates Change report is generated Change control authority decides Change request is denied Request is queued for action User is informed Change control process proceeds

9. Change Control Process Continued Assign people to SCIs Include all changes in release Check-out SCIs Make the change Review/audit the change Review/audit the change Rebuild appropriate version Establish a “baseline” for testing Promote SCI for inclusion in next release Perform SQA and testing activities Check-in the changed SCIs

10. Check-in and Check-out Procedure Configuration Object [extracted version] Configuration Object [baseline version] Check-In Audit Info Unlock Ownership Info Software Engineer Project Database Access Control Lock Configuration Object [extracted version] Configuration Object [baseline version] Check-Out

11. Auditing and Reporting • Auditing: Considers change aspects not covered by a formal technical review. Ensures change management is being applied. • Reporting: Places in an on-line database information such as what happened, who instigated the change, when it occurred and what else was affected. Change Requests SQA Plan SCIs SCM Audit

12. Software Engineering Summary

13. The Nature of Software • Software is a set of items or objects that form a “configuration” that includes: • Programs • Documents • Data • Software Characteristics: • Software is developed or engineered, rather than being manufactured. • Although the industry is moving toward component-based assembly, most softwarecontinues to be custom built. • Software doesn’t wear out. • Software is complex.

14. The Product • Software Myths: • Managers are under pressure, tend to grasp at myths. • Myths held by customers often lead to false expectations and, ultimately, dissatisfaction. • Early attitudes to programming have become entrenched among practitioners. • Professional and ethical responsibilities: • Software engineering involves wider responsibilities than simply the application of technical skills. • Confidentiality, competence, intellectual property rights, computer misuse.

15. The Process • Software Engineering defined: • The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. • The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. • Generic Phases: • Definition (“what”): Establish what the requirements of the system are. • Development (“how”): Establish how the system is to be realized – design and build • Support: Handle changes as the software environment evolves • This process is complemented by a number of umbrella activities.

16. Process Models • A framework of tasks applied during software engineering: • Linear (Waterfall): Based on conventional engineering • Prototyping: Build a system to clarify requirements • Rapid Application Development (RAD): Well defined 60-90 day projects • Incremental: Deliver increasing functionality at each iteration • Spiral (Boehm): Similar set of tasks applied for each turn of the spiral. • Component based: Aimed at producing and reusing OO components analysis design code test

17. Analysis analysis design code test

18. Analysis Principles • begin by focusing on the essence of the problem without regard to implementation details • Examine “What” rather than “how” • Understand the problem before you begin to create the analysis model. • Develop prototypes that enable a user to understand how human-machine interaction will occur. • Record the origin of and the reason for every requirement. • Use multiple views of requirements. • Prioritize requirements. • Work to eliminate ambiguity. (Primary advantage of Formal Mathematical Specification)

19. Valuation Trader Use Case Diagrams • Graphically shows use-cases, actors and their relationships. Uses Relationship Analyze Risk <<uses>> Actor Price Deal <<uses>> Capture Deal Communication Relationship Use Case <<extends>> Extends Relationship Limits Exceeded

20. Class Responsibility Collaborator Cards • Benefits: • They are portable. No computers are required so they can be used anywhere. Even away from the office. • They allow the participants to experience first hand how the system will work. • Stages: • Identify potential classes with a grammatical parse for nouns. • Apply a set of requirement to determine acceptable classes. • Determine class types, characteristics, responsibilities (attributes and methods) and collaborators. • Do a CRC review (walkthrough) of the model.

21. Example: CRC Card class name: Sensor class type: external entity class characteristics: tangible, atomic, concurrent, guarded responsibilities: collaborators: keep sensor information assign sensor information signal sensor event

22. Class Diagrams • Descendent of Entity-Relationship Diagrams • Show the static structure of the model • the entities that exist • internal structure • relationship to other entities • Static View • Do not show temporal information • Used in both analysis (conceptual) and design (specification and implementation). • Conceptual class diagrams only require a subset of the full UML notation. • Derived from CRC Cards.

23. Example: Class Diagram Label and Navigability control panel system contains u polls u sensor 1..* 1 1 1 1 1 Multiplicity recognizes q produces q * * Association audible alarm sensor event Class

24. Object-Behavioural Modelling • CRC and object-relationship model  static • Object-behaviour model  dynamic (function of specific events and time) • Process: • Evaluate use-cases to understand the sequence of system interaction • Identify events that drive the interaction sequence and relate these to specific objects • Create an interaction diagram for each use-case • Build a state diagram for the system • Review model to verify accuracy and consistency

25. Homeowner Example: Sequence Diagram Control Panel Object System system ready enters password initiates beep ready for activation/deactivation Event Active selects stay or away activate/deactivate sensors Life Line red light on request ready for next action

26. stop Basic UML State Diagram State Ready Event Initial Pseudostate stop [user quits] /ctr := 0 Transition Done Guard Action Final State

27. Design Summary analysis design code test

28. Testing Summary analysis design code test

29. Steps in Project Planning • Scope—understand the problem and the work that must be done. • Estimation—how much effort? how much time? • Risk—what can go wrong? how can we avoid it? what can we do about it? • Schedule—how do we allocate resources along the timeline? what are the milestones? • Control strategy—how do we control quality? how do we control change? Project Scope Estimates Risks Schedule Control strategy Software Project Plan