Software Engineering CS5704: First Class Instructor: Shawn A. Bohner Voice: (703) 538-8374 Email: bohner@nvc.cs.vt.edu Teaching Assistant: Sepna Georges Voice: (703) 538-8381 2001 Shawn A. Bohner Agenda Introductions Semester Schedule Guidelines and Expectations Chapter 1 The Software Product Break Chapter 2 The Software Process Survey of Interests Homework Assignment 2 1
Spring Semester Timeline Class Begins Analysis, Design, Product & Process & Architecture PM Metrics & Mid-Term Estimation Exam SW Metrics & Testing Strategies Maintenance & Evolution Final Exam Jan Feb Mar Apr May Project Management Cross-Life- Cycle Process Testing Techniques Object- Oriented Development Advanced SWE Topics 16 weeks, 13 sessions So much to do and so little time be prepared to work hard and glean the value! 3 Guidelines and Expectations Grading: Homework/Quizzes (10%) Project, Mid-Term, and Final (30% each) With the exception of today, plan to have read the assigned material before class Plan for an average of 9 hrs of work a week outside of class Once the website is up, check it regularly Handouts, when available, will be on web You may work in teams on some assignments be fair to other team members! What you learn in CS5704, you will use in most IT or software endeavors CS5704 is a good investment with ROI 4 2
2000+ Technology Headlines IT budget brakes are still on Network spending on the rise IT spending in non-it budgets IT shops undergoing radical role change Increasingly functioning as integrators, solution implementers, and sourcing managers Increasing packaged applications in IT portfolio ADM rigor eroding with demand for IT agility IT Headline News IT staff shortage inhibiting key technology delivery Source: 2000 World Wide Benchmark Following Y2K, software is critical to the success of most private and public sector organizations 5 2000+ Business Reality: Increasing IT-Intensive Initiatives Business-Triggered Technology Initiatives (CRM, ERP, E-Business, ) Event-Triggered Initiatives (Y2K, Euro, M&A, Reorgs, ) Technology Infrastructure Initiatives (Network Upgrades, Data Center Consolidation, ) Modernization Initiatives (Legacy Consolidation, Stove-Pipe Integration, ) Initiatives on the Value Stream ERP e-biz B2B Legacy CRM e-biz B2C Euro Software performance drives need to manage manifold risks induced by the growing portfolio of IT initiatives 6 3
Chapter 1 The Product 7 Purpose The purpose of this chapter is to introduce software as a product designed and built by software engineers for consumers Software is important because it is used by a great many people worldwide Businesses today cannot operate without it Objectives Outline software as a product Outline key aspects of software products Examine software engineering s role 8 4
What is Software? Software is a set of items or objects that form a configuration that includes programs documents data... That s one way to look at it 9 What is Software? Software is part of a computer system that is intended to change Business changes and its computer systems must respond Software is engineered, not manufactured Software is intangible Software is complex Software is suppose to change otherwise it would in the hardware! 10 5
Software Doesn t Wear Out Software doesn t change with age or wear out with use! However,... Software ages or becomes obsolete with a changing environment Software deteriorates or degrades with continued changes Wear versus Deterioration Failure rate increased failure rate due to side effects change actual curve idealized curve Time 12 6
Software Design Degradation The Original Software Design... Easy to Understand Components well isolated to facilitate change Isolation supports change validation...plus a few Changes Increased size and complexity...but it works (for awhile) Reliability of system degrades, errors creep in At some point, it s unmaintainable...effort to make the next change becomes prohibitive Information Lose Due to Relentless Change Baseline Change Set 1 Change Set 2 Change Set N Code Design Spec s 14 7
The Cost of Change 60-100x 1x 1.5-6x Definition Development After release 15 Software is Complex Applications Gridlock 1980s Spaghetti code became the 1990s spaghetti integration Total replacement represents enormous business risk Increasing costs for maintaining and simply reconfiguring applications 8
Software Applications Business Applications Real-Time Systems Engineering/Scientific Applications Embedded Systems AI/Knowledge-Based Systems Web applications PC/Midrange/Mainframe Applications System Software 17 Software Schizophrenia Who is the Audience for Software? The Computer Subsequent software engineers Users Software is developed or engineered, NOT manufactured Effort in creation not production 18 9
Software is an Important Asset Provides valuable service/resource Important part of most systems Embodies important domain and system knowledge Requires maintenance to remain serviceable Costly to develop Redevelopment must be amortorized Stern-wave of development often brings with it a large bow-wave of maintenance costs Software Crisis on the Horizon? U.S. Software Development Productivity Trends Productivity Index 400 350 300 250 200 150 100 50 0 Budget - Y2K Adjusted 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 Productivity Quality Application Demand IT Budget Source: 1989-2000 Worldwide Benchmark 10
Chapter 2 The Process 21 Purpose The purpose of this chapter is to introduce several software process models used to manage large-scale software projects While no software process works well for every project, every project needs to conform to some systematic process Objectives Outline software as a process Outline key aspects of software process Examine how to assess software process maturity 22 11
Business Agility is Driving Software IT Agility needed for businesses to rapidly exploit new markets and adapt to ever changing business conditions Change tolerance essential for evolving software at the pace of today s business Reduce time to: Market for new products and services Operations for internal software systems Financial break-even point Software is the cornerstone for change 70 60 50 40 30 20 10 0 Cycle Times (months) for Large Systems Development 1970's 1980's 1990's 2000's? Software Still Stuck in Construction Software Development evolved largely out of constructive engineering principles However, software was meant to change (or else it would be in the hardware!) Plus a few changes! Change is what software does not do readily unless the principles are intentionally applied 12
A Layered Technology Software Engineering tools methods process model a quality focus 25 A Common Process Framework Common Process Framework Framework activities work tasks work products milestones & deliverables QA checkpoints Umbrella Activities 26 13
Umbrella Activities (AKA Cross-Life-Cycle Activities) Software project management Formal technical reviews Software quality assurance Software configuration management Document preparation and production Reusability management Measurement Risk management 27 Process as Problem Solving problem definition status quo technical development solution integration 28 14
The Process Model: Adaptability Framework activities will always be applied on every project... BUT Tasks (and degree of rigor) for each activity will vary based on: the type of project (an entry point to the model) characteristics of the project common sense judgment; concurrence of the project team 29 Primary Goal: High Quality Remember: High quality = project timeliness Why? Less rework! 30 15
business m odeling da ta mode ling pr oce ss mode ling testing The Linear Model System/information engineering analysis design code test 31 Iterative Models listen to customer build/revise mock-up team #1 business modeling team #2 business modeling data modeling team #3 application ge ne rat ion data modeling process modeling & turnover customer test-drives mock-up process modeling application generation application generation testing & turnover Prototyping 60-90 days testing & turnover RAD 32 16
The Incremental Model System/information engineering increment 1 analysis design code test delivery of 1st increment increment 2 analysis design code test delivery of 2nd increment increment 3analysis design code test delivery of 3rd increment increment 4 analysis design code test delivery of 4th increment calendar time 33 An Evolutionary (Spiral) Model Planning Risk Analysis Customer Communication Engineering Customer Evaluation Construction & Release 34 17
Still Other Process Models Component assembly model the process to apply when reuse is a development objective Concurrent process model recognizes that different part of the project will be at different places in the process Formal methods the process to apply when a mathematical specification is to be developed Cleanroom software engineering emphasizes error detection before testing 35 SEI Process Program Background CBA IPIs and SPAs conducted since 1987 through December 1999 and returned to the SEI by January 2000 1512 assessments 1024 CBA IPIs 488 SPAs 1166 organizations 309 participating companies 283 reassessed organizations 6168 projects *Source: Software Engineering Institute 36 18
SEI s Software Process Capability Maturity Model Level Focus Key Process Areas Result 5 Optimizing 4 Managed 3 Defined 2 Repeatable 1 Initial Continuous Process Improvement Product and Process Quality Engineering Process Project Management Heroes Defect prevention Technology innovation Process change management Process measurement and analysis Quality management Organization process focus Organization process definition Peer reviews Training program Intergroup coordination Software product engineering Integrated software management Software project planning Software project tracking Software subcontract mgt. Software quality assurance Software configuration mgt. Requirements management Productivity & Quality Risk *Source: Software Engineering Institute 37 Summary of the SEI/CMM Levels 1) Initial: The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort. 2) Repeatable: Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications. 3) Defined: The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software. 4) Managed: Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled. 5) Optimizing: Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies. 38 19
Software Process Maturity Advances 90 80 70 60 50 40 30 20 10 0 79.8 75.3 72.2 64.4 58.1 48.6 23.930.6 21.7 15.416.9 15.1 12.4 9.7 7 8.7 12 15.6 3.8 0.5 0.5 1.5 0.71.4 2.3 0.8 0.5 0.6 Level 1 Level 2 Level 3 Level 4 Level 5 1987-91 1992 1994 1996 1998 1999 *Source: Software Engineering Institute 39 Summary Maturity Findings: Organizational Trends Software Quality Assurance is the least frequently satisfied level 2 KPAs among organizations assessed at level 1 Integrated Software Management, Training Program and Organization Process Definition are the least frequently satisfied level 3 KPAs among organizations assessed at level 2 Higher maturity has been reached among those organizations reporting reassessments *Source: Software Engineering Institute 40 20
Process Improvement Maturity Levels Defined Process metrics focus High predictability Process => Success Medium Risk Process Process Repeatable Project metrics focus Low variability/medium predictability PM => Success Medium-High Risk Ad hoc High variability/low predictability Heroes => Success High Risk 41 More Traction at Upper levels... Optimized (Incorporated) Value metrics High predictability Agility => Success Low Risk Managed Product and Process metrics High predictability Managed Process => Success Low-Medium Risk 42 21
Survey of Background and Interest Name Student ID Address Phone # Email Program (CS, MIS, MIT) Number of Hours Completed in Program Programming/Software Engineering Experience # of years Current position Languages/Environments Why did you take CS5704? What are your objectives for this course? Which of the following have you created? Requirements Specification Architecture Design Detailed Program Design Source Code Test Plans Test Cases Maintenance Plan Project Plan Business Case for Project Software Methodology 43 Homework Assignment for 1/26/01 Read Pressman Chapters 1.2 2.1-2.7 3.1-3.8 4.1-4.3 Email survey information to: bohner@nvc.cs.vt.edu Have a great week! 44 22