1 / 41

INFO 324 Team Process and Product Week 1

INFO 324 Team Process and Product Week 1. Glenn Booker College of Information Science and Technology Drexel University. Introduction. Agenda. About the course Course overview Expectations Grading Resources Project introduction. Course Overview. Catalog description

ena
Download Presentation

INFO 324 Team Process and Product Week 1

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. INFO 324Team Process and ProductWeek 1 Glenn BookerCollege of Information Science and TechnologyDrexel University Introduction

  2. Agenda • About the course • Course overview • Expectations • Grading • Resources • Project introduction

  3. Course Overview • Catalog description • Pre-requisites and co-requisites • Rationale • Curriculum role

  4. Catalog Description • Hands-on experience in small teams • To apply processes and produce products typical of current best practices • To develop an integrated understanding of project life cycle artifacts • Examines issues of team organization, coordination, and problem solving

  5. Pre-requisites and Co-requisites • Pre-requisites • INFO 153, Applied Data Management • INFO 200, Systems Analysis I • Co-requisites • None

  6. Curriculum Role • Required for BSIS and BSIT students. It is usually taken in second or third year. • Typically taken prior to software project management, and it does not assume that knowledge • Focus is on skills and understanding needed to be a successful contributor on a project team • Provides a bridge to senior design

  7. Course Rationale • Team work that is central to information technology organizations • Addresses soft skill issues such as problem solving and communication in the context of teams • Provides an opportunity to look in detail at key project deliverables • Provides an opportunity to expand knowledge of tools that support IT project teams

  8. Course Rationale • Focus on one or more software systems, selected by the instructor, that students will review, analyze, modify, and extend • Perspective will include both software and infrastructure elements so as to better address the needs of both IS and IT majors • Project work will be done exclusively by students working in small teams.

  9. Course Outcomes • Upon successful completion of this course, a student will be able to: • Write and review requirement specifications for small systems using best practice approaches • Write and review detailed design specifications for system entities such as interfaces, databases, files, and code (functions and objects) using best practice approaches

  10. Course Outcomes • Create alternative designs for system entities and discuss tradeoffs among them • Perform routine IT project tasks such as version control, defect and feature tracking, testing, documentation and communication with a selection of mainstream tools • Create appropriate products for each phase of small team IT projects from inception through initial implementation • Describe issues and approaches for being a successful team member

  11. Expectations • Treat this course as you would a treat a contract project for a commercial client • You are the IT professional • I act as the client

  12. Expectations of you • Results • Timeliness • Preparation • Writing • Attitude • Attention

  13. Assessment and Grading • Test dates are given on the syllabus • Homework Due Dates • Work turned in late loses points • Grade on a missing submission is zero • You may not submit extra work or re-done assignments to improve grades • Submitting Work • Do so per the instructions with each assignment

  14. Participation Assessment • Considerations • Based on my observation, your documentation, and peer evaluation • Includes all course activities and products • Face-to-face and/or online meetings • Entire class and small group activities • All individual and group products • Requires rapid, honest communication about team issues

  15. Online Class Resources • Access via http://cci.drexel.edu/faculty/gbooker/ • Course Information • Syllabus • Handouts • Course Materials • Lecture slides • Assignments • For homework and quizzes as instructed

  16. Class Themes Tools For IT development by teams Formation, Operation, Communication Teams Learning by doing Technique Free and Open Source Software As a practice environment

  17. Tools • FOSS projects as globally distributed development • How do these teams manage to get work done? • Tools for • Communication • Tracking and planning • Documentation • Testing, etc…

  18. Teams • Lecture and discussion • Readings and reflective writing • Focus on team • Formation • Structure or roles • Communication • Problems solving

  19. Technique • Tool assignments • Task and project work in teams • Pairs and small teams • FOSS project environment • Teams are not assigned but sometimes will change

  20. FOSS • FOSS – Free and Open Source Software • Also called “open source” and FLOSS • Why FOSS? • Growing part of the IT world • Unparalleled opportunity for education • Especially for a course like this • Coverage for this course • Overview of free and open source software • Open source development tools and methods • Open source code base examples (perhaps) • Open source project participation (probably not)

  21. Recommended References • Fogel, Karl. “Producing Open Source Software.” O’Reilly Media. Available online at: http://producingoss.com/ • “Practical Open Source Software Exploration” by Greg DeKoenigsberg et al Available online at: • http://quaid.fedorapeople.org/TOS/Practical_Open_Source_Software_Exploration/html /

  22. Perspective on the SRS • Defines WHAT the system will do • Not HOW it will do it (that’s design) • User oriented document • Write so users could read it and understand • Not a design or project management document • Don’t make design decision or assumptions here • Represents the agreement between developers and client as to what the product will do and how well it can do it

  23. Perspective on the SRS • Will a designer be able to create a design specification from this SRS? • Will that SDS define the system the client wants?

  24. Software Requirements Specification • Template based on the IEEE standard • Template is SRS-V1 • Contains the most important sections for getting started • Other sources of information • IEEE std. 830-1998

  25. SRS-V1 - Introduction • 1.1 Purpose • Purpose of the document, NOT the product • 1.2 Scope • Brief overview of your product • User oriented

  26. SRS-V1 - Introduction • 1.3 Definitions, Acronyms, Abbreviations • Spell out acronyms • Cite sources as appropriate • Sort alphabetically! • Assume a professional audience, but not technical professionals

  27. SRS-V1 – Overall Description • 2.1 – User Characteristics • Clearly define various participants (actors) • Name them and use the role names in place of “user” throughout the document • Provide Use Cases or typical user descriptions if possible • How do actors differ in terms of training, skills, knowledge, abilities, types of functions performed, etc.?

  28. SRS-V1 – Specific Requirements • 3.1 External Interfaces • High level description • Helps establish the system boundary • 3.1.1 Data interfaces • System to system data exchange • NOT the product’s own internal data or database • 3.1.2 User interfaces • System to person interaction • Provide a general description and put details in the specific requirements

  29. SRS-V1 – Specific Requirements • 3.2 – Functional requirements • “Function” here does not mean code, but rather something the system must provide or do • This is the heart of the document • Usually the largest section • Write carefully and use complete sentences • Start with “The system shall” • Use multiple numbered sentences as needed to expand on each requirement “statement” • Match requirement label to content

  30. SRS-V1 – Specific Requirements • 3.3 Logical Data Requirements • What data capacity does the system have, in business terms (not GB!) • How many customers, inventory items, orders, etc. does it need to handle? • 3.4 Design Constraints • This is the only place any mention of design characteristics could appear in an SRS • Generally dictated by the customer

  31. Characteristics of a Good SRS • Correct • Unambiguous • Complete • Consistent • Ranked for importance or stability • Verifiable • Modifiable • Traceable * From IEEE Std 830

  32. Characteristics of a Good SRS • Correct • The SRS specifies the system the client wants • Unambiguous • Only one reasonable interpretation for each requirement • Complete • All significant requirements are included • SRS has all the document sections needed * From IEEE Std 830

  33. Characteristics of a Good SRS • Consistent • Different parts of the SRS agree • Ranked for importance or stability • Every requirement ranked by some standard scale (e.g., high, medium, low) • Verifiable • Every requirement can be tested * From IEEE Std 830

  34. Characteristics of a Good SRS • Modifiable • The SRS is well organized and requirements are not redundant so that changes are manageable • Traceable • Every requirement can be traced back to a source authority • Every requirement has an identifier to allow future referencing (e.g., from the design) * From IEEE Std 830

  35. Project OPOW: OAI-PMH Output Writer Your client has emailed this request: “I am working on a digital library project. See ensemble.org. As part of this project, we want to make collections of course materials visible on the Ensemble portal. To do that we need to harvest metadata describing each course material in a collection. To do that we are using OAI-PMH, a protocol for harvesting metadata. See http://www.openarchives.org/. We need a program that can reformat a file of metadata to match the OAI-PMH protocol. The input would be a text file with metadata extracted from one or more repositories of course materials. Can you help?”

  36. OPOW1 – Critiquing an SRS • Based on the client request, a draft SRS for OPOW has been created • You will critique the SRS from the perspective of a designer • Resolve ambiguities • Look for missing parts • Question any design decisions that seem to be implied by the requirements

  37. Functional Requirements Exercise • SRS Exercise: Sandy’s Castle • Goals • Practice writing action statements • Practice identifying and describing actors

  38. Sandy’s Castle • Sandy’s Castle is a beach kiosk catering to vacationers • Sandy rents umbrellas, chairs, surfboards, etc. • Sandy sells sunscreen, ice cream, etc. • Sandy needs to track and manage inventory, rentals, sales, and report to Sandy Castle’s corporate headquarters • Your job: • Identify actors and users • Define some functional requirements

  39. Collaborative Editing • Etherpad • Open source collaborative editor • Useful for collaborative note taking, brainstorming, collaborative writing, etc. • Code base was the starting point for Google docs • We’re using PrimaryPad, a public version of Etherpad

  40. Collaborative Editing • Enter user roles and requirement statements here: • http://free.primarypad.com/p/S3C47si2Wg • Assignment: • Form groups of 3-4 people • Identify actors and users for Sandy’s Castle • Define some functional requirements • Record your results on the Etherpad above

  41. In Your Future... • Next class • Requirements workshop – using OPOW1 results • Design specification • Introduction • Exercise using OPOW

More Related