SE 325/425 Principles and Practices of Software Engineering Autumn 2008

1. SE 325/425Principles and Practices of Software EngineeringAutumn 2008 James Nowotarski 23 October 2008

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

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

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

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

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

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

8. Use Case Diagram

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

10. Context Diagram Example

11. Level 1 DFD for SafeHome security function Configuresystem Controlpanel Configuration data User commands & data Configurerequest Configuration information Interactwithuser Start /stop Configuration data Activate/deactivatesystem Password A/dmsg Controlpaneldisplay Displayinform-ation Processpassword Displaymessages& status Valid ID msg Alarm Configurationdata Configurationdata Alarmtype Alarmtype Sensorinformation Sensorinformation Monitorsensors Monitorsensors Telephoneline Sensors Sensorstatus Sensorstatus Telephone number tones Telephone number tones

12. Transform mapping

13. Transaction Mapping Data flow model f e a mapping d b x1 t i g program structure h l k t b j m a x2 x4 x3 n n l x3.1 m g f h d e j i k

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. Today’s Agenda Topic Duration • Guest speaker 45 minutes • Assignment 2 recap 15 minutes *** Break • Current events 15 minutes • Software development environments 90 minutes

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

17. Anatomy of the technology in a software development environment • Environment mgmt • System mgmt • Change & configuration mgmt • Service mgmt • Program/project mgmt • Plan/Estimate • Schedule • Track • Report • Personal productivity • Teamware • Training/eLearning • Process management • Information management (repository) • Quality management • QFD • Statistical process ctl • Continuous improvmnt • System development • Analysis & Design • Construction • Testing

18. 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.

19. 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

20. 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

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

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

24. 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

25. Layered behavioral model

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

27. The SCM Process

28. Software configuration items (SCIs) SRS SRS SRS SRS SRS SRS SRS SRS SRS SRS SRS SRS Change creates complexity because we have multiple versions of each SCI. SRS SRS SRS SRS SRS SRS DesignDocuments Code Testcases SRS SystemSpec Projectplan WBS RMMM

29. Baselined SCI’s modified Project database SCIs approved SCIs SCIs Softwareengineeringtasks Formaltechnicalreviews stored SCIs extracted SCM controls SCIs

30. 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.

31. Change requests • Change drivers • Users • Business • Environment • Technology • Impact analysis • Where-Used • Requirements traceability

32. 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.

33. Why traceability?

34. Why traceability? • Requirements validationValidating that all requirements have been fulfilled. • Impact analysisAssessing the impact of a proposed change(Existing or new requirements) • Regression testingTest selection following a change. • Requirements MonitoringMeasuring system’s ongoing ability to meet systemic requirements. • Recording RationalesProviding a history

35. Traceability matrix

36. Traceability matrix • An alternate and probably more common representation.

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

38. COLOR KEY:Green = Activities that occur each time a trace query is issued. Yellow = Batch activities to maintain term frequencies in Poirot Blue = Project setup activities. 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 concreteMR class will interface with the API of the 3rd party tool to actually obtain the data. 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 non-supported 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 WorkFlow System ProcessQuery()UpdateTerms() UpdateRoutine()UpdateMR(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 WebClient. 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) Poirotdata ResourceMgr MR(ManagedResource) RegisterMR()RemoveMR() GetHierarchy()GetModuleTerms()DisplayArtifact() ConcreteMR(Ex: DOORS) ConcreteMR(Ex: Rat Rose) ConcreteMR(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 ResourceMgr so that they become managed resources of the project.

39. Control the Change 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. Rebuild & distribute. • 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: • Proceed • Deny request.

40. Sample RFC form from: http://www.nws.noaa.gov/oso/oso1/oso11/oso112/drg/drgrc.htm

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

42. Obj1.3 Obj1.4 Obj1.0 Obj1.1 Obj1.2 Obj2.0 Obj2.1 Obj1.1.1 Obj1.1.2 Version control • Before and after baselining an object may change many times. • These changes can be represented in an evolution graph. 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?

43. 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

44. 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

45. 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 http://www.cmcrossroads.com/bradapp/acme/branching/branch-intro.html

46. 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

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