1. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 1 Instances An instance represents a phenomenon. The name of an instance is underlined and can contain the class of the instance. The attributes are represented with their values. zone2price = { {‘1’,.20}, {‘2’,.40}, {‘3’,.60}} tariff_1974:TariffSchedule

2. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 2 Associations Associations denote relationships between classes. The multiplicity of an association end denotes how many objects the source object can legitimately reference. 1-to-1 association 1-to-many association * draw() Polygon x:Integer y:Integer Point 1 Has-capital name:String Country name:String City 11

3. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 3 Class Diagrams Example: Class diagram for a simple watch. SimpleWatch PushButtonDisplayBatteryTime The numbers on the ends of associations indicate the number of links that each object has with an object of a given class. 2121 1111

4. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 4 Aggregation An aggregation is a special case of association denoting a “consists of” hierarchy. The aggregate is the parent class, the components are the children class. Exhaust System 1 MufflerTailpipe 0..2

5. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 5 Generalization Generalization relationships denote inheritance between classes. The child classes inherit the attributes and operations of the parent class. Generalization simplifies the model by eliminating redundancy. ButtonZoneButtonCancelButton

6. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 6 Class Diagram Example Maze AddRoom() RoomNo() MapSite Enter() Room WallDoor isOpen roomNum SetSide() GetSide() 1..n

7. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 7 Sequence Diagrams Sequence diagrams show the communication among objects. The objects involved in a use case are called participating objects. A sequence diagram represents the interactions that take place among these objects. In a sequence diagram, columns represent timelines of actors and objects, columns represent timelines of actors and objects, labeled arrows represent stimuli (messages) that are sent from an actor to an object or between objects. labeled arrows represent stimuli (messages) that are sent from an actor to an object or between objects.

8. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 8 Sequence Diagrams Example: Sequence diagram for the SetTime use case. :SimpleWatch :WatchUser :Display:Time pressButton1() blinkHours() pressButton1() blinkMinutes() pressButton2() incrementMinutes() incrementMinutes() refresh() pressButtons1And2() commitNewTime() commitNewTime() stopBlinking()

9. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 9 Sequence Diagrams Used during requirements analysis to refine use case descriptions, to refine use case descriptions, to find additional objects (“participating objects”) to find additional objects (“participating objects”) Used during system design to refine subsystem interfaces. Classes are represented by columns Messages are represented by arrows Activations are represented by narrow rectangles Lifelines are represented by dashed lines

10. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 10 Sequence Diagram Observations UML sequence diagrams represent behavior in terms of interactions. UML sequence diagrams represent behavior in terms of interactions. Complement the class diagrams which represent structure. Complement the class diagrams which represent structure. Useful to find participating objects. Useful to find participating objects. Time consuming to build but worth the investment. Time consuming to build but worth the investment.

11. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 11 Statechart Diagrams Statechart diagrams describe the behavior of an individual object like a finite state automaton, that is, a finite number of states that the object can assume, a finite number of states that the object can assume, transitions between these states. transitions between these states. Here, a state is a particular set of values for an object. States are represented by ovals. A transition represents a state change that occurs under a particular condition. Transitions are represented by arrows that are labeled with the corresponding condition.

12. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 12 Statechart Diagrams Example: Statechart diagram for SimpleWatch. BlinkHoursIncrementHours BlinkMinutesIncrementMinutes BlinkSecondsIncrementSecondsStopBlinking button2Pressed button2Pressed button2Pressed button1&2Pressed button1&2Pressed button1&2Pressed button1Pressed button1Pressed

13. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 13 Activity Diagrams An activity diagram describes a system in terms of activities. Activities are shown as states that represent the execution of a set of operations. After the completion of one or more activities, other activities are started. Activity diagrams are similar to flowchart diagrams. They represent activities as ovals and transitions between activities as arrows.

14. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 14 Activity Diagrams Example: Activity diagram for incident management Thick bars represent the synchronization of the control flow. Open Incident Allocate Resources Coordinate Resources Document Incident Archive Incident

15. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 15 Systems, Models, and Views A system is a structured set of interacting parts that serve a specific purpose. For example, a humanoid robot consists of a torso, a head, two arms and two legs. These parts can in turn be considered subsystems. For instance, the robot’s head may be composed of a metal frame, two cameras, two microphones, and a speaker. We can apply this decomposition recursively to determine the hierarchy of subsystems.

16. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 16 Systems, Models, and Views Modeling is a way of dealing with the high complexity of certain systems. Such systems are often described by multiple models, each of them representing a particular aspect of the system. In general, a model focuses on particular aspects of a system and ignores irrelevant details. We should aim at building models that are simple enough to be easily comprehensible by a single person.

17. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 17 Systems, Models, and Views We can use a view to visualize a subset of a model. Example: View of a subset of UMass Boston UMass Boston Department of Psychology Department of Computer Science Students Faculty Classes

18. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 18 Concepts and Phenomena A phenomenon is an object of the world as it is perceived, for example: Classroom M-1-409 Classroom M-1-409 Professor Jun Suzuki Professor Jun Suzuki September 5 September 5 A concept is an abstraction describing a set of phenomena, for instance: Classrooms Classrooms UMass professors UMass professors Dates Dates

19. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 19 Concepts and Phenomena A concept is defined as a three-tuple: its name (identifying the concept), its name (identifying the concept), its purpose (the properties determining if a phenomenon is part of the concept or not), its purpose (the properties determining if a phenomenon is part of the concept or not), its members (the set of phenomena that are part of the concept). its members (the set of phenomena that are part of the concept).Example: University is the name of the concept. University is the name of the concept. Educating students is the purpose of a university. Educating students is the purpose of a university. UMass Boston and York University are members of the university concept. UMass Boston and York University are members of the university concept.

20. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 20 Software Project Management Software Project: All technical and managerial activities required to deliver the deliverables to the client.All technical and managerial activities required to deliver the deliverables to the client. A software project has a specific duration, consumes resources and produces work products.A software project has a specific duration, consumes resources and produces work products. Management categories to complete a software project: Tasks, Activities, FunctionsManagement categories to complete a software project: Tasks, Activities, Functions

21. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 21 Software Project Management Software Project Management Plan (SPMP): The controlling document for a software project.The controlling document for a software project. Specifies the technical and managerial approaches to develop the software product.Specifies the technical and managerial approaches to develop the software product. Companion document to requirements analysis document: Changes in either may imply changes in the other document.Companion document to requirements analysis document: Changes in either may imply changes in the other document. SPMP may be part of project agreement.SPMP may be part of project agreement.

22. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 22 Project Agreement Document written for a client that defines the scope, duration, cost and deliverables for the project, the scope, duration, cost and deliverables for the project, the exact items, quantities, delivery dates, delivery location. the exact items, quantities, delivery dates, delivery location. Can be a contract, a statement of work, a business plan, or a project charter.

23. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 23 Project Agreement Client: Individual or organization that specifies the requirements and accepts the project deliverables. Deliverables (= Work Products that will be delivered to the client): DocumentsDocuments Demonstrations of functionDemonstrations of function Demonstration of nonfunctional requirementsDemonstration of nonfunctional requirements Demonstrations of subsystemsDemonstrations of subsystems

24. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 24 Project: Functions, Activities and Tasks p:Project f1:Function f2:Function a2.1:Activitya2.2:Activitya2.3:Activity t1:Taskt2:Taskt3:Taskt4:Task a1:Activitya2:Activitya3:Activity

25. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 25Functions p:Project f1:Function f2:Function a1:Activitya2:Activitya3:Activity a2.1:Activitya2.2:Activitya2.3:Activity t1:Taskt2:Taskt3:Taskt4:Task A function is an activity or a set of activities that span the duration of the project.

26. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 26 Functions Examples: Project management Project management Configuration management Configuration management Documentation Documentation Quality control (verification and validation) Quality control (verification and validation) Training Training Mapping of terms: Project Functions in the IEEE 1058 standard are called Integral processes in the IEEE 1074 standard. We call them cross- development processes.

27. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 27Tasks p:Project f1:Function f2:Function a1:Activitya2:Activitya3:Activity a2.1:Activitya2.2:Activitya2.3:Activity t1:Taskt2:Taskt3:Taskt4:Task Smallest units of work that are subject to management

28. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 28Tasks Tasks are the smallest units of management accountability, the smallest units of management accountability, atomic units of planning and tracking atomic units of planning and tracking They should be small enough for adequate planning and tracking, small enough for adequate planning and tracking, large enough to avoid micro management. large enough to avoid micro management. Properties of tasks: finite duration finite duration need resources need resources produce tangible results (e.g., documents or code) produce tangible results (e.g., documents or code)

29. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 29Tasks Specification of a task: Work package name, name, description of work to be done, description of work to be done, preconditions for starting, preconditions for starting, duration, duration, required resources, required resources, work product to be produced and acceptance criteria for it, work product to be produced and acceptance criteria for it, risk involved, risk involved, completion criteria completion criteria

30. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 30 Task Sizes Finding the appropriate task size is problematic, because: During initial planning a task is necessarily large. During initial planning a task is necessarily large. You may not know how to decompose the problem into tasks at first. You may not know how to decompose the problem into tasks at first. Each software development activity identifies more tasks and modifies existing ones. Each software development activity identifies more tasks and modifies existing ones.

31. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 31 Task Sizes Tasks must be decomposed into sizes that allow monitoring. Work package usually corresponds to well defined work assignment for one worker for a week or a month. Depends on nature of work and how well task is understood.

32. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 32 Examples of Tasks Unit test class “Foo” Unit test class “Foo” Test subsystem “Bar” Test subsystem “Bar” Write user manual Write user manual Write meeting minutes and post them Write meeting minutes and post them Write a memo on Windows 7 vs. Unix Write a memo on Windows 7 vs. Unix Schedule the code review Schedule the code review Develop the project plan Develop the project plan Related tasks are grouped into hierarchical sets of functions and activities.

33. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 33Activities p:Project f1:Function f2:Function a1:Activitya2:Activitya3:Activity a2.1:Activitya2.2:Activitya2.3:Activity t1:Taskt2:Taskt3:Taskt4:Task Activities are major units of work with precise dates.

34. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 34Activities An activity consists of smaller activities or tasks, consists of smaller activities or tasks, usually culminates in a major project milestone. usually culminates in a major project milestone. A milestone is An internal checkpoint that should not be externally visible, An internal checkpoint that should not be externally visible, a scheduled event used to measure progress. a scheduled event used to measure progress.

35. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 35Activities Activities may be grouped into larger activities: Establishes hierarchical structure for project (phase, step,...) Allows separation of concerns Precedence relations often exist among activities

36. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 36 Examples of Activities Major activities: Planning Planning Requirements Elicitation Requirements Elicitation Requirements Analysis Requirements Analysis System Design System Design Object Design Object Design Implementation Implementation System Testing System Testing Delivery Delivery Activities during requirements analysis: Refine scenarios Define Use Case model Define object model Define dynamic model Design User Interface

37. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 37 Project Roles Planner Planner Analyst Analyst Designer Designer Programmer Programmer Tester Tester Maintainer Maintainer Trainer Trainer Document Editor Document Editor Web Master Web Master Configuration Manager Configuration Manager Group leader Liaison Minute Taker Project Manager

38. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 38 Project Roles Management roles: Organization and execution of the project within constraints.Organization and execution of the project within constraints. Examples: project manager, team leaderExamples: project manager, team leader Development roles: Specification, design and construction of subsystems.Specification, design and construction of subsystems. Examples: Analyst, system architect, implementor.Examples: Analyst, system architect, implementor.

39. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 39 Project Roles Cross-functional roles: Coordination of more than one team.Coordination of more than one team. Examples: API Engineer, configuration manager, testerExamples: API Engineer, configuration manager, tester Consultant roles: Support in areas where the project participants lack expertise.Support in areas where the project participants lack expertise. Examples: End user, client, application domain specialist (problem domain), technical consultant (solution domain).Examples: End user, client, application domain specialist (problem domain), technical consultant (solution domain). Promoter roles: Promote change through an organization.Promote change through an organization.

40. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 40 Hierarchical Project Organization Chief Executive First Level Manager (“Front-Line Manager”) Project Members A B A wants to talk to B: complicated information flow A wants to make sure B does a certain change: complicated control flow

41. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 41 Example: Chief Programmer Team Chief Programmer Assistant Chief Programmer Senior ProgrammerLibrarian AdministrationTester Junior Programmer

42. February 11, 2014CS410 – Software Engineering Lecture #5: Project Management 42 Another Project Organization: Egoless Programming Team Analyst DesignerLibrarian TesterProgrammer