info 324 team process and product week 1

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