CPSC 372: Systems Analysis

1. CPSC 372: Systems Analysis J. Yates Monteith, Substitute for John D. McGregor Clemson University, Fall, 2014

2. Schedule • Getting Started Stuff • Who Am I? • Why am I here? • Eclipse Process Framework Composer • Overview, Processes, Process Engineering • Getting Started • Creating Method Content and Method Plug-Ins • Creating Standard Content • Creating Processes • Creating Custom Categories • Publishing • Importing and Exporting

3. Who am I? • [J.] Yates Monteith • Ph.D. Candidate, Expected Graduation 2015 • Dissertation Title: Strategic Software Platform Adoption as Successive Iterations of Real Options Valuation • M.S. Computer Science, Clemson University, 2010 • B.S. Computer Science, Clemson University, 2008 • Research Interests • Software Ecosystems • Software Architecture • Software Metrics and Measurement • Software and Systems Modeling • Personal Interests • Education and Instruction • Music and Radio Broadcasting

4. Why am I here? • Dr. McGregor is in Vienna, Austria presenting a paper at the International Conference on Software Oriented Business. • Well, he did yesterday. • Why am I here? • Super Senior Ph.D. Student in the Strategic Software Engineering Research Group • Lots of Experience • CPSC 1110L TA – 3 Sections • CPSC 1200L TA -- 3 Sections • CPSC 215L TA – 3 Sections • CPSC 1110 Instructor – 1 Section • CPSC 2150 Instructor – 2 Sections across 2 Semesters • CPSC 8620 / 8750 / 1110 Grader • CPSC 372, 871, 871 Substitute – More times than I can count…

5. Eclipse Process Framework Composer • Eclipsed Process Framework Composer (EPF) is a tool for composing documentation about a process. • What is a process? • Stupid. A process is how you do something. • Let’s try a real definition: • A process explains the steps you take in order to create a finished process… • What inputs are required for each step of the process… • What outputs are generated at each step of the process… • Who is responsible for what inputs, outputs and activities in each step of the process. • Makes sense

6. EPF Process • The EPF is used to create documentation about or a model of a software development process. • However, the EPF is based off of a meta-model, so we could use it to describe other processes. • Dr. McGregor also uses it as a textbook in his course [1]. • He’ll be dessiminating additional information to you in the form of an EPF plug-in that contains additional information. • He’ll be expecting / encouraging you to extend his plug-in by incorporating additional materials from reading, in-class notes and discussion. • Hopefully, the extended plug-in you create will serve as a customized textbook and study guide. • Today I’ll be showing you how to use the EPF just a little bit.

7. EPF: Getting Started • Step 1: Download and Install the Eclipse Process Framework Composer • Located at: http://www.eclipse.org/epf/downloads/tool/epf1.5.0_downloads.php • Current version: 1.5.1.6 Released 1/22/2014 • Available for Linux/GTK and Windows. Should also work on Mac, because Eclipse  Java and Mac  GTK • Step 2: Unzip into the C:\ directory or another ‘short’ base directory (/opt would work well). • Using another base directory might result in path names that are too long, especially on Windows. • Step 3: Install JDK 6u35. • You could also install JDK 7u* or perhaps 8u*. I have not used / tested it with JDK 7 or 8. • Step 4: Open the folder at the extraction point and launch the epf application.

8. EPF: Getting Started – Method Libraries • Method libraries are the top level libraries for EPF. • Method libraries contain Plug-Ins and Method Configurations. • Plug-Ins define different entities within the Method Library and how they are related. • Configurations define how those entities are displayed and composed into a set of documentation. • We need a Method Library, a Plug-In and a Method Configuration. • Start by creating a Method Library. Call it CPSC371 Library • This Method Library will hold our Plug-Ins and Method Configurations. • Nota Bene: Uncheck the ‘use auto synchronization for all processes’ option.

9. EPF: Getting Started – Plug-Ins • Create a Plug-In. Call it CPSC 371 • Method Content • Content Packages • Standard Categories • Disciplines • Domains • Work Product Kinds • Role Sets • Tools • Custom Categories • Processes • Capability Patterns • Delivery Processes • Configurations

10. EPF Method Content – Content Packages • A Content Package encodes a set of entities that may be project or domain specific. • Quick aside, what is a domain? • A domain is a realm that exists within a certain context or subject matter. • Medical, Aviation, Software Tooling, Networking, Video Games, etc, etc • Includes: • Roles – Who does what? • Tasks – Things and activities to do. • Work Products – Things that are generated from tasks. • Guidance – Documents that provide insight into… anything. • We should create a content package.

11. EPF Content Packages -- Roles • Roles represent people who work on the project • Could be development people: programmer, tester, architect, etc. • Could be business people: manager, lawyer, business analyst, marketer, etc. • Could be technical people: system administrator, etc. • We can give them descriptive information. • We can give them work products for which they are responsible. • We can give them relationships to guidance entities. • We can put them into a custom category.

12. EPF Method Content – Tasks • Tasks represent activities that are done during development. • We can give them descriptive elements. • We can define a number of steps in the task. • We can assign roles to perform the task. • We can define work products that are inputs and outputs of tasks. • We can provide relations to guidance entities. • We can assign tasks to a custom category.

13. EPF Method Content – Work Products • Work Products are ‘things’ that are created by roles and used in or produced from tasks • Three Types: Artifacts, Deliverables, Outcomes • Artifact is a thing used in or produced from development. • Test plan, source code, etc. • Deliverable is a thing that is delivered to another entity. • Could be a test plan delivered to the test team. • Software model to the development team. • Outcome is a result of some task or activity. • Could be a test log. • Each Work Product can b… • Given a custom category. • Assigned guidance • Can be categorized by Work Product Kind (More later…) • Provided a state. • Deliverables can also be divided into deliverable parts.

14. EPF Method Content – Guidance • Guidance represents an entity that augments information on another entity. • Guidance provides additional information about another specific entity. • For example… • Say we have a discipline called

15. EPF Method Content – Guidance • Guidance represents an entity that augments information on another entity. • There are tons of different types of Guidance entities: • Checklist • Concept • Example • Guideline • Estimation Considerations • Practices • Reports • Reusable Assets • Roadmaps • Supporting Materials • Templates • Term Definitions • Tool Mentors • White Papers • Mostt different Guidance entities can be attached to any other entities. However, some are entity specific. • For instance, a Tool Mentor can only be attached to a Tool. • Guidance entities are not required to have a working EPF documentation, but may be helpful.

16. EPF Standard Categories • Standard Categories include sets of elements that don’t fit into Content Libraries, or may aggregate content from Content Libraries. • Disciplines – Activities we engage in during development. • Agile Development, Test Driven Development, etc. • Domains – Information about the “domain” or market we are developing in, and how it affects the project. • Medical, Aviation, Telemetry, etc. • Work Product Kinds – Groupings of work products for organization of, well, work products. • Legal Dox, Validation Dox, Development Artifacts, Testing Artifacts • Role Sets – Groupings of Roles for organization of personnel. • Development Personnel, Project Personnel, Teams, etc • Tools – Entities that describe tools that are used during development. • Eclipse, SonarQube, OSATE, Visual Studio, etc.

17. Standard Categories – Disciplines • A Discipline represents something structured we do during development. • Requirements engineering, integration testing, etc. • Contains fields for… • Descriptions • Tasks that the discipline composes • Referenced workflows or other processes • Guidance, as always. • Also, groupings of other disciplines • Agile practices, XP Practices, MDD Practices

18. Standard Categories – Domains • A domain represents the market segment in which we are developing software. • The domain dictates rules, standards and regulations that may apply to our software. • In the medical domain, security and privacy are incredibly important aspects. • In the aviation domain, correctness, fault tolerance and redundancy are incredibly important. • Domains are fairly simple in the EPF. • Domains can be given a description. • Work products can be associated with a domain. • Domains can have attached guidance.

19. Standard Categories–Work Product Kinds • Work Product kinds are an organizational entity for logical groupings of work products. • Could be things like requirements documents. • Would contain requirements elicitation questions, analysis data or specification documents. • Could be things like models and diagrams • Requirements models, Use Case models, class diagrams, etc. • Work product kinds can contain other Work Product Kinds and Work Products. • Work Product Kinds can have guidance attached.

20. Standard Categories – Role Sets • Role Sets are an organizational grouping for different roles. • Could be roles based on the types of responsibilities • Development roles might include programmer, tester, architect. • Management roles might include Project Lead, Project Manager, etc. • Roles could also define teams • A team has a programmer, a tester, a domain expert and a manager. • Roles sets group together roles and role sets. • Roles sets can have guidance attached to them.

21. Standard Categories – Tools • A Tool is an entity that represents a tool we use during the development process. • A tool could be a compiler like GCC/G++, could be an IDE like Eclipse, or static analyzer like gconf/gprof. • Tools have a special kind of guidance specifically for them, tool mentors. • Tools can also have other types of guidance associated with them

22. Processes • So now that we’ve defined our Content Library and our Standard Category, we can actually define some processes. • Capability Patterns show how we do something. • Like develop a software project. • Delivery patterns show we go from something we’ve got to something that can be delivered. • For example, like taking source and turning it into an application. • A process package contains multiple capability patterns and delivery patterns. • But first we need a configuration.

23. Configurations • A configuration describes a publishing configuration. • A configuration is published into a cohesive set of documentation. The end result is a webpage with linkages between different elements. • The configuration specifies a view of the different elements in the plug-in. • Different configurations could be used to produce different sets o documentation for different types of people. • A business analyst doesn’t need the same process documentation as a software developer. • For now, go ahead and create a Method Configuration through the File menu. Give it a name, and leave it blank.

24. Capability Patterns • Capability patterns represent a document that describe how we go about doing something. • What we’re capable of. • We can provide descriptive text. • We can describe a work breakdown structure. • Divided into phases, iterations, activities an milestones. Provides rhythm for how we perform a process. • We can create a team allocation. • Says what roles are used during each component of the work breakdown structure. • We can create a work product usage. • Describes the which work products are used in work breakdown.

25. Delivery Patterns • Same as capability patterns, but for a deliverable. • For the purposes of this class, we’re more interested in capability patterns as a vehicle for process than delivery patterns.

26. Finishing Up: Custom Categories • So now that we have everything defined, we can create a custom category that aggregates the entities we’ve defined. • A custom category provides a view of the information we have assembled. • A view provides a perspective on some data or model from a given point of view. • Like developer or business person or technical person or managerial person. • Create a new custom category and assign every entity you would like to be directly viewable to that custom category. • Provide a description of the view so that we know what we’re looking at.

27. Finishing Up: Publishing • Finally, we need to configure our Method Configuration. • The method configuration states which parts of our Plug-In, or other Plug-Ins, we would like to be accessible in published (webpage) form. • They also state which views (Custom Categories) we would like to include. • Once we have all of this defined, we can publish our process documentation into a webpage. • Go to Tools  Publish • Select your configuration. • Select to publish part of or the entire configuration. • Select Static webpage, say where it should be saved. • Click finish and look at the pretty webpage.

28. Finishing Up: Importing Plug-Ins • Dr. McGregor will probably distribute a plug-in to you as a baseline source of information. This will need to be imported, and then you can extend the entities contained in that plug-in. • For extending entities, see the variability mechanisms at the bottom of the description on any entity. • To Import a Method Plug-In • File-> Import • Method Plug-In • Navigate to the directory. • EPF will automatically scan the directory and present all plug-ins found. • Select which one you would like to import.

29. Finishing Up: Exporting Plug-ins • Potentially, maybe, from time to time, Dr. McGregor may want you to export your plug-in and submit it to him so he can see what your notes are like. • To export a plugin… • File  Export • Select Method Plug-In • Check the checkbox for any plug-in you would like to export. • NB: You should include any plug-ins from which you are linking or extending entities. • Select the location of the exported plug-in and click finish.

30. EPF: Resources and Stuff • Here’s a link to a sample EPF Documentation I did. • http://people.cs.clemson.edu/~jymonte/docs/epf/index.htm • Here’s a link to an EPF Documentation on making EPF Documentations • It’s so Meta • http://people.cs.clemson.edu/~jymonte/docs/epfTutorial/index.htm • Here’s a few links to different EPF Documentations and other articles on Process Eng. • http://epf.eclipse.org/wikis/epfpractices/ • http://epf.eclipse.org/wikis/openup/ • Here’s a link to the paper McGregor and I wrote on using EPF Documentation as a textbook. • Not a bad read if I do say so myself. 8 pages? • http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=5876099