Instances

1. tariff_1974:TariffSchedule zone2price = { {‘1’, .20},{‘2’, .40}, {‘3’, .60}} 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. CS410 – Software Engineering Lecture #5: Project Management

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

3. SimpleWatch PushButton Display Battery Time Class Diagrams • Example: Class diagram for a simple watch. 1 1 1 1 2 1 2 1 The numbers on the ends of associations indicate the number of links that each object has with an object of a given class. CS410 – Software Engineering Lecture #5: Project Management

4. Exhaust System 1 0..2 Muffler Tailpipe 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. CS410 – Software Engineering Lecture #5: Project Management

5. Button CancelButton ZoneButton 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. CS410 – Software Engineering Lecture #5: Project Management

6. Class Diagram Example MapSite Enter() Maze Wall Door Room isOpen roomNum 1..n AddRoom() RoomNo() SetSide() GetSide() CS410 – 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, • labeled arrows represent stimuli (messages) that are sent from an actor to an object or between objects. CS410 – Software Engineering Lecture #5: Project Management

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

9. Sequence Diagrams • Used during requirements analysis • to refine use case descriptions, • 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 CS410 – Software Engineering Lecture #5: Project Management

10. Sequence Diagram Observations • UML sequence diagrams represent behavior in terms of interactions. • Complement the class diagrams which represent structure. • Useful to find participating objects. • Time consuming to build but worth the investment. CS410 – 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, • 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. CS410 – Software Engineering Lecture #5: Project Management

12. button2Pressed button2Pressed button2Pressed button1&2Pressed StopBlinking BlinkSeconds BlinkMinutes IncrementMinutes BlinkHours IncrementSeconds IncrementHours button1Pressed button1&2Pressed button1&2Pressed button1Pressed Statechart Diagrams • Example: Statechart diagram for SimpleWatch. CS410 – 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. CS410 – Software Engineering Lecture #5: Project Management

14. Open Incident Allocate Resources CoordinateResources Document Incident Archive Incident Activity Diagrams • Example: Activity diagram for incident management Thick bars represent the synchronization of the control flow. CS410 – 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. CS410 – 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. CS410 – Software Engineering Lecture #5: Project Management

17. UMass Boston Department of Computer Science Department of Psychology Students Classes Faculty Systems, Models, and Views • We can use a view to visualize a subset of a model. Example: View of a subset of UMass Boston CS410 – 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 • Professor Jun Suzuki • September 5 • A concept is an abstraction describing a set of phenomena, for instance: • Classrooms • UMass professors • Dates CS410 – Software Engineering Lecture #5: Project Management

19. Concepts and Phenomena • A concept is defined as a three-tuple: • its name (identifying the concept), • 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). • Example: • University is the name of the concept. • Educating students is the purpose of a university. • UMass Boston and York University are members of the university concept. CS410 – 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. • A software project has a specific duration, consumes resources and produces work products. • Management categories to complete a software project: Tasks, Activities, Functions CS410 – Software Engineering Lecture #5: Project Management

21. Software Project Management • Software Project Management Plan (SPMP): • The controlling document for a software project. • 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. • SPMP may be part of project agreement. CS410 – 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 exact items, quantities, delivery dates, delivery location. • Can be a contract, a statement of work, a business plan, or a project charter. CS410 – 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): • Documents • Demonstrations of function • Demonstration of nonfunctional requirements • Demonstrations of subsystems CS410 – Software Engineering Lecture #5: Project Management

24. f1:Function p:Project f2:Function a1:Activity a2:Activity a3:Activity a2.1:Activity a2.2:Activity a2.3:Activity t1:Task t2:Task t3:Task t4:Task Project: Functions, Activities and Tasks CS410 – Software Engineering Lecture #5: Project Management

25. Functions f1:Function • A function is an activity or a set of activities that span the duration of the project. p:Project f2:Function a1:Activity a2:Activity a3:Activity a2.1:Activity a2.2:Activity a2.3:Activity t1:Task t2:Task t3:Task t4:Task CS410 – Software Engineering Lecture #5: Project Management

26. Functions • Examples: • Project management • Configuration management • Documentation • Quality control (verification and validation) • 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. CS410 – Software Engineering Lecture #5: Project Management

27. Tasks Smallest units of work that are subject to management f1:Function p:Project f2:Function a1:Activity a2:Activity a3:Activity a2.1:Activity a2.2:Activity a2.3:Activity t1:Task t2:Task t3:Task t4:Task CS410 – Software Engineering Lecture #5: Project Management

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

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

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

31. 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. Task Sizes CS410 – Software Engineering Lecture #5: Project Management

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

33. Activities Activities are major units of work with precise dates. f1:Function p:Project f2:Function a1:Activity a2:Activity a3:Activity a2.1:Activity a2.2:Activity a2.3:Activity t1:Task t2:Task t3:Task t4:Task CS410 – Software Engineering Lecture #5: Project Management

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

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

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

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

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

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

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

41. Assistant Chief Programmer Senior Programmer Librarian Administration Tester Junior Programmer Example: Chief Programmer Team Chief Programmer CS410 – Software Engineering Lecture #5: Project Management

42. Another Project Organization: Egoless Programming Team Analyst Tester Programmer Designer Librarian CS410 – Software Engineering Lecture #5: Project Management