1 / 40

Hierarchical Project Organization

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. Example: Chief Programmer Team. Assistant

agalia
Télécharger la présentation

Hierarchical Project Organization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  2. Example: Chief Programmer Team Assistant Chief Programmer Senior Programmer Librarian Administration Tester Junior Programmer Chief Programmer CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  3. Another Project Organization: Egoless Programming Team Analyst Tester Programmer Designer Librarian CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  4. Another Variant:Project-Based Project Organization Subsystem Teams Project Leader Coaches Team Members A B A wants to talk to B: simple information flow A wants to make sure B does a certain change: simple control flow CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  5. Observations on Management Structures • Hierarchical structures: • “Reports”, “Decides” and “Communicates-With” all mapped on the same association • Do not work well with iterative and incremental software development process • Manager is not necessarily always right • Project-based structures: • “Reports”, “Decides” and “Communicates-With” are different associations • Cut-down on bureaucracy reduces development time • Decisions are expected to be made at each level • Hard to manage CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  6. Hierarchical Structure • High degree of certainty, stability, uniformity and repetition • Requires little communication • Role definitions are clear • When should we use a hierarchical structure? • The more people on the project, the more need for a formal structure • Customer might insist that the test team be independent from the design team • Project manager might insist on a previously successful structure CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  7. Project-Based Structure • Project with degree of uncertainty • Open communication needed among members • Roles are defined on project basis • When should we use a project-based structure? • If requirements change during development • If new technology develops during project CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  8. Team Formation • Team Formation is done after the top level design of the project is complete. • Heuristics: • one team for each subsystem, • one cross-functional task per team, • 5-7 members per team • Be prepared to iterate the team formation after system design and subsystem decomposition. CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  9. How do you become a good project planner? • Establish a project plan • Start with the plan based on your experience with the last project(s) • Keep track of activities and their duration • Determine difference between planned and actual performance • Make sure to do a post-mortem • Lessons learned • Ask developers for feedback • Write a document about what could have been improved CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  10. Communication • In large system development efforts, you will spend more time communicating than coding. • A software engineer needs to learn the so-called soft skills: • technical writing, • reading documentation, • communication, • collaboration, • management, • presentations. CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  11. Software Lifecycle Activities Requirements Elicitation Requirements Analysis System Design Object Design Implemen- tation Verified By Implemented By Expressed in Terms Of Structured By Realized By class... class... class... ? ? Application Domain Objects Implementation Domain Objects Use Case Model Source Code SubSystems Test Cases class.... Testing CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  12. Requirements Elicitation Activities • Identify actors • Identify scenarios • Identify use cases • Identify relationships among use cases • Refine use cases • Identify nonfunctional requirements • Identify participating objects CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  13. System Identification • Definition of the system boundary: • What is inside, what is outside? • Requirements Process: • Requirements Elicitation: Definition of the system in terms understood by the customer • Analysis: Technical specification of the system in terms understood by the developer. CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  14. Requirements Elicitation • Challenging activity • Requires collaboration of people with different backgrounds: • Users with application domain knowledge • Developers with implementation domain knowledge • Bridging the gap between user and developer: • Scenarios: Example of the use of the system in terms of a series of interactions between the user and the system • Use cases: Abstraction that describes a class of scenarios CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  15. Types of Requirements • Functional requirements: • Describe the interactions between the system and its environment independent from implementation • Example: The watch system must display the time based on its location. CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  16. Types of Requirements • Nonfunctional requirements: User-visible aspects of the system not directly related to functional behavior. • Examples: • The response time must be less than 1 second. • The accuracy must be within a second. • The watch must be available 24 hours a day except from 2:00am-2:01am CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  17. Types of Requirements Constraints (“Pseudo requirements”): Imposed by the client or the environment in which the system will operate Examples: • The implementation language must be COBOL. • Must interface to the dispatcher system written in 1956. CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  18. What is usually not in the Requirements? • System structure, implementation technology • Development methodology • Development environment • Implementation language • Reusability • It is desirable that none of these above are constrained by the client. Fight for it! • However, in this course, you will implement your project in C++. • Resistance is futile. CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  19. Requirements Validation • Critical step in the development process. • Usually after requirements engineering (= requirements elicitation + analysis) • Also at delivery CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  20. Requirements Validation • Requirements validation criteria: • Correctness: The requirements represent the client’s view. • Completeness: All possible scenarios through the system are described, including exceptional behavior by the user or the system • Consistency: There are no functional or nonfunctional requirements that contradict each other • Clarity: There are no ambiguities in the requirements. CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  21. Requirements Validation • Realism: Requirements can be implemented and delivered • Traceability: Each system function can be traced to a corresponding set of functional requirements CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  22. Types of Requirements Elicitation • Greenfield Engineering: • Development starts from scratch, no prior system exists, the requirements are extracted from the end users and the client • Triggered by user needs • Re-engineering: • Re-design and/or re-implementation of an existing system using newer technology • Triggered by technology enabler • Interface Engineering: • Provides the services of an existing system in a new environment • Triggered by technology enabler or new market needs CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  23. Software Lifecycle Activities Requirements Elicitation Requirements Analysis System Design Object Design Implemen- tation Verified By Implemented By Expressed in Terms Of Structured By Realized By class... class... class... ? ? Application Domain Objects Implementation Domain Objects Use Case Model Source Code SubSystems Test Cases class.... Testing CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  24. Analysis: Object Modeling • From use cases to objects • Object modeling • Class vs instance diagrams • Attributes • Operations and methods • Links and associations • Examples of associations • Two special associations • Aggregation • Inheritance CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  25. From Use Cases to Objects Le v el 1 Le v el 2 Le v el 2 Le v el 3 Le v el 3 Le v el 3 Le v el 4 Le v el 4 A B Level 1 Use Case Level 2 Use Cases Level 3 Use Cases Operations Participating Objects CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  26. Definition: Object Modeling • Main goal: Find the important abstractions • What happens if we find the wrong abstractions? • Iterate and correct the model • Steps during object modeling: • 1. Class identification (based on the fundamental assumption that we can find abstractions) • 2. Find the attributes • 3. Find the methods • 4. Find the associations between classes • (Order of steps is secondary, only a heuristic) CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  27. Do UML associations have direction? A B An association between two classes is by default a bi-directional mapping. • Class A can access class B and class B can access class A • Both classes play the agent role. CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  28. Do UML associations have direction? A B • access  • If you want to to make A a client, and B a server, you can make the association unidirectional. The arrowhead points to the server role: • Class A ( the “client”) accesses class B (“the server”). • B is also called navigable CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  29. Aggregation • Models "part of" hierarchy • Useful for modeling the breakdown of a product into its component parts (sometimes called bill of materials (BOM) by manufacturers) • UML notation: Like an association but with a small diamond indicating the assembly end of the relationship. CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  30. Aggregation Automobile Engine serial number year horsepower manufacturer volume model on color off weight drive purchase 3,4 2 2,4 Brakelight Door Wheel Battery amps diameter open volts number of bolts on close off charge discharge CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  31. Inheritance Cell BloodCell MuscleCell NerveCell Pyramidal Red Smooth White Striate Cortical • Models "kind of" hierarchy • Powerful notation for sharing similarities among classes while preserving their differences • UML Notation: An arrow with a triangle CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  32. Aggregation vs. Inheritance • Both associations describe trees (hierarchies). • Aggregation tree describes “part-of” relationships (also called and-relationship) • Inheritance tree describes "kind-of" relationships (also called or-relationship) • Aggregation relates instances (involves two or more different objects) • Inheritance relates classes (a way to structure the description of a single object) CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  33. Other Associations • “Uses”: • A subsystem uses another subsystem (System Design) • “Contains”: • Sometimes called “spatial aggregation” • ... contains ... • Example: A UML package contains another UML package • Parent/child relationship: • ... is father of ... • ... is mother of ... • Seniority: • ... is older than ... • ... is more experienced than ... CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  34. Object Types • Entity Objects: • Represent the persistent information tracked by the system (Application domain objects, “Business objects”) • Boundary Objects: • Represent the interaction between the user and the system • Control Objects: • Represent the control tasks performed by the system CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  35. Example: 2BWatch Objects <<entity>> <<control>> <<boundary>> Year ChangeDateControl ButtonBoundary <<entity>> <<boundary>> Month LCDDisplayBoundary <<entity>> Day • UML provides several mechanisms to extend the language • UML provides the stereotype mechanism to present new modeling elements CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  36. Roles • A role name is the name that uniquely identifies one end of an association. • A role name is written next to the association line near the class that plays the role. CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  37. Roles • When do you use role names? • Necessary for associations between two objects of the same class • Also useful to distinguish between two associations between the same pair of classes • When do you not use role names? • If there is only a single association between a pair of distinct classes, the names of the classes serve as good role names CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  38. Example of Role Person Creates Workorders Person • Problem Statement: • A person assumes the role of repairer with respect to another person, who assumes the role of inspector with respect to the first person. inspector repairperson CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  39. Roles in Associations • Client Role: • An object that can operate upon other objects but that is never operated upon by other objects. • Server Role: • An object that never operates upon other objects. It is only operated upon by other objects. • Agent Role: • An object that can both operate upon other objects and be operated upon by other objects. An agent is usually created to do some work on behalf of an actor or another agent. CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

  40. Qualification File Directory filename 0..1 1 Directory File filename • The qualifier improves the information about the multiplicity of the association between the classes. • It is used for reducing 1-to-many multiplicity to 1-1 multiplicity. • Example: Without qualification, a directory has many files. A file belongs to only one directory. 1 * With qualification: A directory has many files, each with a unique name. CS410 – Software Engineering Lecture #6: Requirement Elicitation & Analysis

More Related