1. PowerPoint Presentation for IS-207 Copyright 2006 © Michael W. Schaffer. All rights reserved. Slide 1 Systems Analysis & Design A People-centered approach to Technology and Process Class One: Software Development Process 6/21/2015 11:55:53 PM

2. Slide 2 Who are we? Yale Braunstein: Professor at School of Information, UC Berkeley

3. Slide 3 Who are you? Your Name, Year, where from? Recent school or job What do you want out of this course?

4. Slide 4 Back in the old days … Tools were crude, machines were limited … short distance between concept and implementation. Applications were simple automations of well-defined processes (like bookkeeping).

5. Slide 5 But now … Software is pervasive: “user” is just about anyone or anything. Wide range of skills needed to design and specify requirements. New products are much more diverse, so teams are more diverse. Systems Development is not sterile … we need a people-based model.

6. Slide 6 Work and Meta-work Work is what we do to deliver elements of the project: design, coding, testing, etc. Meta-work, “work about the work”, is the organization and management of the tasks and deliverables to maximize the effectiveness of the work itself. Meta-Meta work: process definition … design of the meta-work of all your projects (process and procedures).

7. Slide 7 Systems Analysis and Product Development Process (PDP) Understanding the complete Product Development Process is required to deliver the right product at the right cost. This course will teach Systems Analysis and Design within the context of the Product Development Process Process modeling, data flow design, etc. Other skills too: Project Management, Statistical Analysis, Planning and Budgeting, ……. Process aligned to People and their Role

8. Slide 8 Product Development Process Process through which a lot of people contribute to the design, development, validation, and roll-out of a technology solution So many people involved, so many agendas – need to ensure clarity in every communication. Formal understanding of roles and responsibilities for the key people. Expensive : retrograde motion kills.

9. Slide 9 Product Development Process Applicable to all projects: not only “shrink- wrap”: any technology deliverable needs a development process. Once understood, elements of the process can be scaled & morphed. “shrink-wrap” techniques can provide useful lessons for web-based development RAD, eXtreme … understand the waterfall, then get more creative to fit the project Core communication needs are the same, regardless of platform and context.

10. Slide 10 PDP: The Waterfall A million flavors, but all the same Know why each deliverable is developed, and for whom – lots of documents! Author vs. audience Size matters: the longer the document, the less valuable (except Reference Docs) Move toward standard templates for your organization -- Reduce cognitive friction in consuming documents throughout the project cycle

11. Slide 11 PDP at Alibris

12. Slide 12 PDP at Alibris

13. Slide 13 PDP: Discovery “Why” is this project being considered? Who: Business Owner, Strategy guys, Architects, Resource “Estimators” Generate questions, then collect facts. Focus on cost vs. benefit, ROI … Justify the project, or kill it early. Identify risks and unknowns.

14. Slide 14 PDP: Requirements “What does it do?” and “For whom does it do it?” Who: Product Manager, Tech Lead, QA Lead, Project Manager, plus Define what the system does, and for whom. Develop cost assessment and baseline schedule, bottom-up Address risks early: prototype to test feasibility and platform/tools as needed.

15. Slide 15 Prototypes Maggie Law (SIMS Alumna): “Prototypes are useful as a communication vehicle” Between users and designers Between designers and developers Between developers and management (to prove technology, & reduce risk)

16. Slide 16 Good Prototype Examples Develop user interface with dummy functionality to get early feedback from users. Develop sample application to learn new toolset & estimate productivity. Build a sample interface between two entities (business partners) to ensure interoperability (connectivity and data flow)

17. Slide 17 PDP: More on Requirements Product Functionality Platform & Compatibility Servers, network bandwidth, connectivity, O/S, etc. Performance Marketing and Sales Channels, Pricing and Licensing Maturity of product: SDK, integration points & hooks Product Support Requirements

18. Slide 18 PDP: Specifications “How will we build it?”, “What will it cost?” Who: Architects and Designers, QA, PM Design data architecture, component interfaces, internals of interesting elements QA is key player, to audit and align specifications to requirements. Brevity helps. Ensure review with a formal feedback processes. Refine schedule and costs, bottom-up schedule definition and buy-in.

19. Slide 19 PDP: Development “Can we build it?” Who: Rank and File, Team Mgmt Development and Unit testing Refining system test plans and tools Control schedule and costs: measure drift and creep.  Smaller deliverables limit damage  Get bad news as early as possible.  Look for systemic schedule issues.

20. Slide 20 PDP: Integration and Validation “What defects?” QA can only measure quality, classify issues, and alignment to requirements. QA costs can match development costs. Do not get cheap. External integrations are always slower than you expect.

21. Slide 21 PDP: Launch and Maintenance “1.0” products are easy: everything else takes effort: Legacy user interfaces, data migration and compatibility, patch mechanism & upgrade hooks Plan for the “morning after” On-going maintenance tasks, to monitor the new system, manage user issues, manage legacy “turn-down” and End- of-life.

22. Slide 22 PDP: Working with Externals (Suppliers, Partners, etc.) Ensure process alignment: nomenclature, roles, etc. Develop formal and informal communication channels Write it down! Whoever documents it, drives it. Drive formal sign-off, int. & ext. Demonstrate “good habits” early.

23. Slide 23 PDP: Outsourcing Use process to delineate elements that could be “broken out” to an external team Visual design and branding Development / Testing Need formal process wrapping to ensure clean communication

24. Slide 24 Broadly Applicable & Flexible Process must work for web site, shrink-wrapped product, enterprise, or embedded system. Process should allow growth in variability of design documents and deliverables. Process clarifies the purpose and structure for any deliverable.

25. Slide 25 Questions? Discussion?