What is a Functional Spec?  Defines what the functionality will be NOT how it will be implemented  Describes features of the software product product's.

Slides:



Advertisements
Similar presentations
CHAPTER 1 SOFTWARE DEVELOPMENT. 2 Goals of software development Aspects of software quality Development life cycle models Basic concepts of algorithm.
Advertisements

Project What is a project A temporary endeavor undertaken to create a unique product, service or result.
Chapter 10 Schedule Your Schedule. Copyright 2004 by Pearson Education, Inc. Identifying And Scheduling Tasks The schedule from the Software Development.
8 September Announcements  GIT Class: Friday 3-5 SN 115 (Peter Parente)  Information for Project Links PageProject Links Page  Hot Topics Teams.
8 September ProcessWithin the Steps  Put together minimal solution Start with external commitments Introduce internal milestones  Focus on the.
11 October Project Management Discipline of planning, organizing, and managing resources to bring about the successful completion of specific project.
Review 20 March. Announcements EA here today Let me know if you are looking for a job or summer internship John Smith Current Events: John BackusJohn.
Message Design and Content Creation 23 January 2007 Kathy E. Gill.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
Part 2: Requirements Days 7, 9, 11, 13 Chapter 2: How to Gather Requirements: Some Techniques to Use Chapter 3: Finding Out about the Users and the Domain.
Risk Management 25 January. What is due next week Website: Monday (send me URL as soon as you have it) Team rules: Monday Functional spec: Tuesday Project.
“80% of software projects fail”  Standish Report (1995) Standish Report 16.2% completed on-time and on-budget with all features and functions as initially.
INFO 637Lecture #31 Software Engineering Process II Launching & Strategy INFO 637 Glenn Booker.
SA Capstone Requirements and Design Week 10 SYST Winter 2013 Instructors: Jerry Kotuba & Joe Varrasso.
Copyright Course Technology 1999
Software Development Landscape
Supplementary Specifications (Chapters 20,22 - Requirements Text) Question 1 by Steve & Chandan (Along with others in the past! - See notes, below)
(from Dr. Diane Pozeksky. “80% of software projects fail” Standish Report (1995) Standish Report 16.2% completed on-time and on-budget with all features.
Resources Performance time. resources Performance time 2.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Project Tracking. Questions... Why should we track a project that is underway? What aspects of a project need tracking?
June 2005 Coral Trisko, PMP Enterprise Project Management Ltd. Project Management... a step in the right direction!
1.  Describe an overall framework for project integration management ◦ RelatIion to the other project management knowledge areas and the project life.
Software Engineering Management Lecture 1 The Software Process.
1 Project Management Introduction. 2 Chap 1 What is the impact? 1994: 16% of IT projects completed “On-Time” 2004 : 29% of IT projects “On- Time” 53%
Strong9 Consulting Services, LLC 1 PMI - SVC I-80 Breakfast Roundtable Monthly Meeting Thursday, October 12, :00 am – 9:00 am.
ISM 5316 Week 3 Learning Objectives You should be able to: u Define and list issues and steps in Project Integration u List and describe the components.
Chapter 11. Intro  What is Project Management?  Project Manager  Project Failures & Successes Managing Projects  PMBOK  SDLC Core Process 1 – Project.
1 김 수 동 Dept. of Computer Science Soongsil University Tel Fax
3 September Sources of requirements  People Stakeholders ○ Who are the stakeholders? Issues: ○ Conflicting requirements ○ Wants vs. needs Helping.
J. Scott Hawker p. 1Some material © Rational Corp. Rational Unified Process Overview See and use the RUP Browser on lab machines.
 Chapter 1: Introduction NET481: Project Management Afnan Albahli.
1 IT Project Management, Project Failure and Success  Introduction  Projects operate in a broad organizational environment.  Project managers need to.
Project Management Inspections and Reviews 1 February.
Project Management Organization Scheduling 31 January.
24 January Software Engineering Processes Risk Management.
PPTTEST 12/26/ :41 1 IT Ron Williams Information Technology Management Project Management.
Stand Up Comedy Project/Product Management
Project Management. Projects and Project Managers Project – a [temporary] sequence of unique, complex, and connected activities having one goal or purpose.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Requirements Management with Use Cases Module 2: Introduction to RMUC Requirements Management with Use Cases Module 2: Introduction to RMUC.
Project Management Strategies Hidden in the CMMI Rick Hefner, Northrop Grumman CMMI Technology Conference & User Group November.
1 Chapter 11 Planning. 2 Project Planning “establishing a predetermined course of action within a forecasted environment” “establishing a predetermined.
Welcome to Software Project Management. CONVENTIONAL SOFTWARE MANAGEMENT The BEST and WORST thing about software is its flexibility. 1.Software development.
LCG Persistency Framework Project Boundary Conditions and Overall Schedule Torre Wenaus, BNL/CERN.
Configuration Control (Aliases: change control, change management )
Chapter 25 – Configuration Management 1Chapter 25 Configuration management.
Slide 3.1 © The McGraw-Hill Companies, 2002 SOFTWARE LIFE-CYCLE MODELS.
Chapter 11 Project Management.
Software Configuration Management
Software Engineering Management
Workplace Projects.
Regression Testing with its types
Project Management Chapter 3.
Lecture 3 Prescriptive Process Models
Software Engineering and Best Practices
Martha Grabowski LeMoyne College
Software Project Management
Project Management Complexity, Risks, Failure and Technology
Chapter 1 (pages 4-9); Overview of SDLC
FOUNDATIONAL CONCEPTS
CSSSPEC6 SOFTWARE DEVELOPMENT WITH QUALITY ASSURANCE
Software Engineering: A Practitioner’s Approach, 6/e Chapter 2 Process: A Generic View copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Project Management Chapter 11.
Project Management: Inspections and Reviews Formal Specifications
Software Testing Lifecycle Practice
Chapter 3: Project Integration Management
Executive Project Kickoff
Software Reviews.
SDLC (Software Development Life Cycle) Role Play
Presentation transcript:

What is a Functional Spec?  Defines what the functionality will be NOT how it will be implemented  Describes features of the software product product's behavior as seen by external observer  Contains technical info and data needed for design  What a contractor bids on

Why a Spec?  Allows you to communicate with your client and users  Easier to change than code  Basis for schedule  Record of design decisions

What’s in a Functional Spec?  Overview: project description  Use cases and (optionally) personas  Interfaces: anything the USER sees or uses  Requirements  …as much as you know  Note: your functional spec will go through multiple iterations

Expectations of Software Engineering 1. Predetermine quantitative quality goals 2. Accumulate data for use in later projects 3. Keep all work visible 4. Design, program and test only against requirements 5. Measure and achieve quality goals Watts Humphrey

“80% of software projects fail”  Standish Report (1995) Standish Report 16.2% completed on-time and on-budget with all features and functions as initially specified. 52.7% completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified. 31.1% cancelled at some point during the development cycle.  Sauer et al (2007) Sauer et al 67% “delivered close to budget, schedule, and scope expectations” with experienced project managers

More Recent Experience  Lessons From a Decade of IT Failures Lessons From a Decade of IT Failures  And in the past year… And in the past year…

Project Management Discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives

Should we eliminate risk?  Patton: Take calculated risks. That is quite different from being rash.  Nehru: The policy of being too cautious is the greatest risk of all.  Herodotus: Great deeds are usually wrought at great risks.  The Net: No risk => no challenge

Sources of Risk 1. Top management commitment 2. User commitment 3. Misunderstood requirements 4. Inadequate user involvement 5. Mismanaged user expectations 6. Scope creep 7. Lack of knowledge or skill Keil et al, “A Framework for Identifying Software Project Risks,” CACM 41:11, November 1998A Framework for Identifying Software Project Risks

Technical Risks  New features  New technology  Developer learning curve  Changes that may affect old code  Dependencies  Complexity  Bug history  Late changes  Rushed work  Tired programmers  Slipped in “pet” features  Unbudgeted items

ProcessWithin the Steps  Put together minimal solution Start with external commitments Introduce internal milestones  Focus on the risks  Add next level of features where possible  Identify components  Identify dependencies  Estimate (guess) Prefer educated guess  Lay out assignments and time frames Scheduling

Questions project plan answers  What is Joe working on this week?  Who can help me if I run into trouble?  If I have to choose an activity to be late, which one will impact the project more?

What needs to be in the plan?  All Deliverables  Code  Design  Test  Documentation  Learning  Presentation and demo prep  Reviews

Reviews and Inspections  Why? Developer can’t correct unseen errors More eyes to catch problems Earlier is cheaper ○ Integration fix typically 3-10 times the cost at design  Difference in terms Review implies completed work, often reviewed by someone at a different level Inspection implies peer review of work in progress

Inspections  Introduced by Michael Fagan in 1976 (IBM Systems Journal)  Formalized process Specific roles and steps Heavy preparation and follow-up  Used for documents and code In 1999, survey identified 117 checklists covering requirements, design, code, testing, documentation and process