info 324 team process and product week 1
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
www.ischool.drexel.edu1
INFO 324Team Process and Product
Week 1Dr. Jennifer Booker
College of Computing and InformaticsDrexel University
Introduction
www.ischool.drexel.edu2
Agenda• About the course
– Course overview– Expectations– Grading– Resources
• Project introduction
www.ischool.drexel.edu
Course Overview
• Catalog description
• Pre-requisites and co-requisites
• Rationale
• Curriculum role
3
www.ischool.drexel.edu4
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
www.ischool.drexel.edu
Pre-requisites and Co-requisites
• Pre-requisites– INFO 153, Applied Data Management– INFO 200, Systems Analysis I
• Co-requisites– None
5
www.ischool.drexel.edu
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
6
www.ischool.drexel.edu
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
7
www.ischool.drexel.edu
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.
8
www.ischool.drexel.edu
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
9
www.ischool.drexel.edu
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
10
www.ischool.drexel.edu11
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
www.ischool.drexel.edu12
Expectations of you
• Results
• Timeliness
• Preparation
• Writing
• Attitude
• Attention
www.ischool.drexel.edu13
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
www.ischool.drexel.edu14
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
www.ischool.drexel.edu
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
15
www.ischool.drexel.edu
Class Themes
16
Tools
Teams
Technique
Free and Open Source Software
For IT development by
teams
Formation, Operation,
Communication
Learning by doing
As a practice environment
www.ischool.drexel.edu
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…
17
www.ischool.drexel.edu18
Teams
• Lecture and discussion
• Readings and reflective writing
• Focus on team– Formation– Structure or roles– Communication– Problems solving
www.ischool.drexel.edu19
Technique
• Tool assignments
• Task and project work in teams– Pairs and small teams– FOSS project environment
• Teams are not assigned but sometimes will change
www.ischool.drexel.edu
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)
20
www.ischool.drexel.edu
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 /
21
www.ischool.drexel.edu22
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
www.ischool.drexel.edu
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?
23
www.ischool.drexel.edu
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
24
www.ischool.drexel.edu
SRS-V1 - Introduction
• 1.1 Purpose– Purpose of the document, NOT the product
• 1.2 Scope– Brief overview of your product– User oriented
25
www.ischool.drexel.edu
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
26
www.ischool.drexel.edu
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.?
27
www.ischool.drexel.edu
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
28
www.ischool.drexel.edu
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
29
www.ischool.drexel.edu
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
30
www.ischool.drexel.edu
Characteristics of a Good SRS
• Correct• Unambiguous• Complete• Consistent• Ranked for importance or stability• Verifiable• Modifiable• Traceable
31
* From IEEE Std 830
www.ischool.drexel.edu
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
32 * From IEEE Std 830
www.ischool.drexel.edu
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
33 * From IEEE Std 830
www.ischool.drexel.edu
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)
34 * From IEEE Std 830
www.ischool.drexel.edu
Project OPOW: OAI-PMH Output Writer
35
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?”
www.ischool.drexel.edu
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
36
www.ischool.drexel.edu37
Functional Requirements Exercise
• SRS Exercise: Sandy’s Castle
• Goals– Practice writing action statements– Practice identifying and describing actors
www.ischool.drexel.edu38
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
www.ischool.drexel.edu
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
39
www.ischool.drexel.edu
Collaborative Editing
• Enter user roles and requirement statements here:– http://free.primarypad.com/p/GymG8bx3W8
• In-class assignment 1:– 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
40
www.ischool.drexel.edu41
In Your Future...• Next class
– Requirements workshop – using OPOW1 results
– Design specification• Introduction• Exercise using OPOW