SE 325425 Principles and Practices of Software Engineering

SE 325/425 Principles and Practices of Software Engineering Autumn 2008 James Nowotarski 23 October 2008

Today’s Agenda Topic Duration ¢ Guest speaker 45 minutes ¢ Assignment 2 recap 15 minutes *** Break ¢ Current events 15 minutes ¢ Software development environments 90 minutes 2

Pothole Tracking and Repair System (PHTRS) Analysis Modeling Exercise Assignment 2

Use case description – narrative Use-case: Activate the system “If I’m at a remote location, I can use any PC with appropriate browser software to log on to the Safe. Home Products Web site. . . “ 4

Use case description – ordered sequence Use-case: Activate the system 1. 2. 3. 4. The homeowner observes. . . The homeowner uses the keypad. . The homeowner selects and keys in stay or away. . . When activation occurs. . . 5

Use case description – additional elements Should be primarily for users’ benefit (secondarily for developers’) ¢ Elements of a use case ¢ l l l Name (Potential process on L 1 DFD; should relate to users’ goal) Description Trigger (external, temporal) Major inputs & outputs (Potential data flows) Major steps (Potential processes on L 2 DFD) Pre- and post-conditions (no post-condition for 6 an inquiry)

Use Case Diagram Identify actors Model their interactions with the system. Through elicitation fully explore all the ways each actor may interact with the system. Banking Software Product Withdraw Money Customer Teller 7

Use Case Diagram 8

Level 0 DFD ¢ L 0 DFD (aka “Context” diagram) Shows the context into which the business process fits l Shows the overall process as just one process l Shows all “external entities” that contribute information to or receive information from the system l No data stores (unless external) l 9

Context Diagram Example

Level 1 DFD for Safe. Home security function Control panel Configure system User commands & data Configure request Interact with user Password Configuration information Start / stop Activate/ deactivate system Process password Sensors Configuration data Sensor status Valid ID msg Configuration data Monitor sensors Configuration data A/d msg Display information Display messages & status Alarm Sensor information type Telephone number tones Control panel display Alarm Telephone line 11

Transform mapping 12

Transaction Mapping Data flow model f e a d b mapping t x 1 program structure i g h l k j m t b a n d x 2 e x 4 x 3 f g l x 3. 1 h m n j i k 13

Today’s Agenda Topic Duration ¢ Guest speaker 45 minutes ¢ Assignment 2 recap 15 minutes *** Break ¢ Current events 15 minutes ¢ Software development environments 90 minutes 14

Today’s Agenda Topic Duration ¢ Guest speaker 45 minutes ¢ Assignment 2 recap 15 minutes *** Break ¢ Current events 15 minutes ¢ Software development environments 90 minutes 15

What is SE? Software Engineering Body of Knowledge Software requirements Software design Software construction Software testing Software maintenance Software configuration management Software engineering process Software engineering tools and methods Software quality tonight Source: Guide to the Software Engineering Body of Knowledge. (2004). IEEE. www. swebok. org 16

Anatomy of the technology in a software development environment 1. 2. 3. Process management Information management (repository) Quality management l l l 4. 5. l l l 6. QFD Statistical process ctl Continuous improvmnt l l Analysis & Design Construction Testing l l l 7. 8. 9. System mgmt Change & configuration mgmt Service mgmt Program/project mgmt l System development l Environment mgmt Plan/Estimate Schedule Track Report Personal productivity Teamware Training/e. Learning 17

Three critical factors in development environments when designing large software systems ¢ Thin spread of application domain knowledge ¢ Fluctuating and conflicting requirements ¢ Communication and coordination breakdowns Source: Kurtis, B. , Krasner, H. , & Iscoe, N. (1988, November). A field study of the software design process for large projects. Communications of the ACM, 31(11), 1268 -1287. 18

Experience is the best way to acquire application domain expertise “CIOs are shifting their emphasis from technical knowledge to business knowledge, from specialization to versatility, from IT expertise centralized in the IT organization to IT expertise diffused throughout business areas and regions. ” -- Gartner Group, April 2008 19

Three characteristics distinguish exceptional designers ¢ Extremely familiar with the application domain ¢ Skilled at communicating their vision to their colleagues ¢ Consumed with the performance of their projects 20

An exceptional designer represents a crucial depth and integration of knowledge domains Knowledge domains involved in systems building Crucial 21

Three critical factors in development environments when designing large software systems ¢ Thin spread of application domain knowledge ¢ Fluctuating and conflicting requirements ¢ Communication and coordination breakdowns 22

Three critical factors in development environments when designing large software systems ¢ Thin spread of application domain knowledge ¢ Fluctuating and conflicting requirements ¢ Communication and coordination breakdowns 23

Three critical factors in development environments when designing large software systems ¢ Thin spread of application domain knowledge ¢ Fluctuating and conflicting requirements ¢ Communication and coordination breakdowns Closely related 24

Layered behavioral model 25

Software configuration management (SCM) ¢ The art of coordinating software changes to minimize confusion ¢ SCM activities: l Identification l Change control l Version control l Configuration auditing l Reporting 26

The SCM Process 27

Software configuration items (SCIs) SRS SRS SRS Design Documents SRS System Spec Project plan WBS SRS SRS SRS Code SRS SRS SRS Test cases Change creates complexity because we have multiple versions of each SCI. RMMM 28

Baselined SCI’s modified Project database SCIs approved Software engineering tasks SCIs Formal technical reviews SCIs stored SCIs SCM controls extracted SCIs 29

Baselines ¢ IEEE Std. 610. 12 -1990 defines a baseline as: A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. 30

Change requests ¢ Change drivers Users l Business l Environment l Technology l ¢ Impact analysis Where-Used l Requirements traceability l 31

Requirements traceability “Requirements traceability is the ability to describe and follow the life of a requirement, in both a forward and backward direction, i. e. , from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases. ” Gotel and Finkelstein, 1994. 32

Why traceability? 33

Why traceability? Requirements validation Validating that all requirements have been fulfilled. Impact analysis Assessing the impact of a proposed change (Existing or new requirements) Regression testing Test selection following a change. Requirements Monitoring Measuring system’s ongoing ability to meet systemic requirements. Recording Rationales Providing a history 34

Traceability matrix Req No. Description Traces To U 2 Users shall be able to process retirement claims S 10, S 11, S 12 U 3 Users shall be able to process survivor claims S 13 S 10 The system shall accept retirement data U 2 S 11 The system shall calculate the amount of retirement U 2 S 12 The system shall calculate point-to-point travel time U 2 S 13 The system shall calculate the amount of survivor annuity. U 3 Entities U 2 U 3 S 10 U 2 X U 3 X S 12 S 13 X X S 10 X S 11 X S 12 X S 13 S 11 X 35

Traceability matrix An alternate and probably more common representation. 36

http: //castalia. cstcis. cti. depaul. edu: 8080/Poirot

COLOR KEY: Green = Activities that occur each time a trace query is issued. Yellow = Batch activities to maintain term frequencies in Poirot 2. When a user is evaluating a query, they have the option of asking for more information about the artifact. If this occurs then we need to ask the MR (Managed Resource) to display the artifact. If this function is nonsupported by the MR, we need to retrieve the additional data and display it ourselves. This is why we have a link from Client to WMS. The WMS will get the data through the Resource Manager. Poirot Engine Blue = Project setup activities. Process. Query() Update. Terms() For Version 1. 0 of Poirot+ we will update terms on a batch basis (nightly or upon request). The Workflow Manager will check which of the managed resources have changed. It will then update hierarchical data and term frequency data in Poirot. It will call upon the services of the resource manager to locate MR. The concrete. MR class will interface with the API of the 3 rd party tool to actually obtain the data. Work. Flow System Update. Routine() Update. MR(MRName) Poirot Web Client 1. Poirot Web Client is the interface for the user to issue trace queries. The user issues a query, the query is sent to Poirot Engine where it is serviced and results are returned to Poirot Web. Client. Currently the webclient talks directly to the Poirot Engine, however maybe it should talk to the WMS instead and have the WMS forward requests. (This is an additional complication though) MR Resource. Mgr Poirot data (Managed. Resource) Register. MR() Remove. MR() Get. Hierarchy() Get. Module. Terms() Display. Artifact() Concrete. MR (Ex: DOORS) Concrete. MR (Ex: Rat Rose) Concrete. MR (Ex: Java Code) DOORS Rational Rose Java Code The idea is that this is the part of Poirot+ that will be change. We want to be able to add managed resources dynamically at runtime, or change their location. We have considered a broker architecture – but that may be a bit of an overkill because we have a specific ‘service’ that will manage each resource. We may need each Concrete MR to have a local and distributed part. Anyway MRs will register themselves with the Resource. Mgr so that they become managed resources of the project.

Control the Change 1. 2. 3. 4. 5. Need for change is recognized Change request is submitted as a “request for change” (RFC) Developer evaluates Change report is generated Change control authority makes a decision to either: l l Proceed Deny request. 6. 7. 8. 9. 10. 11. 12. Request if queued for action. ECO is generated (Engineering Change Order). Individuals assigned to configuration objects. Objects checked out and change made. Change audited. Objects checked in. Baseline established. SQA activities performed. 39 Rebuild & distribute.

Sample RFC form from: http: //www. nws. noaa. gov/oso 1/oso 112/drgrc. htm 40

Basic version control techniques ¢ Maintain ONLY the most recent version and a history of changes. l ¢ Earlier versions are recreated through “subtractions” from the recent version Maintain full copies of ALL versions. l More space required 41

Version control ¢ ¢ Before and after baselining an object may change many times. These changes can be represented in an evolution graph. Obj 1. 0 Obj 1. 1 Obj 1. 3 Obj 1. 4 Obj 2. 0 Obj 2. 1 Obj 1. 2 Obj 1. 1. 1 Obj 1. 1. 2 How does the developer reference all modules, documents, and test cases for version 1. 4? How does the marketing department know what customers currently have version 2. 1? How can we ensure that changes to 2. 1 source code are properly reflected in corresponding documentation? 42

Check-in/Check-out ¢ Most version control tools in widespread use employ the checkout-edit-checkin model to manage the evolution of version-controlled files in a repository or codebase. http: //www. cmcrossroads. com/bradapp/acme/branching/branch-intro. html 43

Serial development with exclusive checkouts. ¢ ¢ ¢ In a strictly sequential development model, when a developer checks-out a file, the file is write-locked: No one may checkout the file if another developer has it checked-out. Instead, they must wait for the file to be checked-in (which releases or removes the write-lock). This is considered a pessimistic concurrency scheme which forces all work to take place on a single line of development. http: //www. cmcrossroads. com/bradapp/acme/branching/branch-intro. html 44

Concurrent development using branches ¢ ¢ ¢ Branching is a common mechanism to support concurrent software development. Allows development to take place along more than one path for a particular file or directory. When the revision on the new branch is modified and checked-in, the two lines of development will have different contents and will evolve separately 45 http: //www. cmcrossroads. com/bradapp/acme/branching/branch-intro. html

Synchronizing using merges ¢ ¢ Merging is the means by which one development line synchronizes its contents with another development line. The contents of the latest version on a child branch are reconciled against the contents of the latest version on the parent branch (preferably using a 2 -way or 3 -way file differencing or comparison tool). http: //www. cmcrossroads. com/bradapp/acme/branching/branch-intro. html 46

For October 30 ¢ ¢ Read Pressman Chapters 21, 25 Current event reports 47