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


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


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


Pre-requisites and Co-requisites

• Pre-requisites– INFO 153, Applied Data Management– INFO 200, Systems Analysis I

• Co-requisites– None

5


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


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


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


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


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


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


Expectations of you

• Results

• Timeliness

• Preparation

• Writing

• Attitude

• Attention


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


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


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


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


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


Teams

• Lecture and discussion

• Readings and reflective writing

• Focus on team– Formation– Structure or roles– Communication– Problems solving


Technique

• Tool assignments

• Task and project work in teams– Pairs and small teams– FOSS project environment

• Teams are not assigned but sometimes will change


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


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


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


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


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


SRS-V1 - Introduction

• 1.1 Purpose– Purpose of the document, NOT the product

• 1.2 Scope– Brief overview of your product– User oriented

25


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


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


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



• 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



• 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


Characteristics of a Good SRS

• Correct• Unambiguous• Complete• Consistent• Ranked for importance or stability• Verifiable• Modifiable• Traceable

31

* From IEEE Std 830



• 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



• 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




• 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)



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?”


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


Functional Requirements Exercise

• SRS Exercise: Sandy’s Castle

• Goals– Practice writing action statements– Practice identifying and describing actors


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


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


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


In Your Future...• Next class

– Requirements workshop – using OPOW1 results

– Design specification• Introduction• Exercise using OPOW

INFO 324 Team Process and Product Week 1

Documents