Software Engineering 8 SR 2 Unit III Project

Software Engineering ( 8 SR 2 ) Unit III Project Scheduling: Concepts. Peoples Efforts. Task set, Task network. Scheduling. EV analysis, Project Plan. Software quality concepts. SQ Assurance, Software reviews, technical reviews, software reliability, ISO 900 L, SQA Plan. SCM process. Version control. SCM standard Book Recommended U 1 -1, 2, 3 U 2 -4, 5, 6 U 3 -7, 8, 9 Software Engineering, A Practitioner’s Approach U 4 -10, 11, 13 - Pressman Roger. S. TMH. (Strictly 5 th Ed) Reference Books R 1 Software Engineering Somerville R 2 Software Engineering Fairly R R 3 Principles of Software Development Davis A R 4 Software Engineering Shooman, M. L U 5 -14, 15, 16 U 6 -17, 18, 19 Addison-Wesley (5/e) Mc. Graw Hill

Software Engineering ( 8 SR 2 ) Chapter 7 Project Scheduling and Tracking

Software Engineering ( 8 SR 2 ) Why Are Projects Late? • an unrealistic deadline established by someone outside the software development group • changing customer requirements that are not reflected in schedule changes; • an honest underestimate of the amount of effort and/or the number of resources that will be required to do the job; • predictable and/or unpredictable risks that were not considered when the project commenced; • technical difficulties that could not have been foreseen in advance; • human difficulties that could not have been foreseen in advance; • miscommunication among project staff that results in delays; • a failure by project management to recognize that the project is falling behind schedule and a lack of action to correct the problem

Software Engineering ( 8 SR 2 ) Scheduling Principles • compartmentalization—define distinct tasks • interdependency—indicate task interrelationshipsffort validation—be sure resources are available • defined responsibilities—people must be assigned • defined outcomes—each task must have an output • defined milestones—review for quality

Defining Task Sets • determine type of project • assess the degree of rigor required – identify adaptation criteria – compute task set selector (TSS) value – interpret TSS to determine degree of rigor • select appropriate software engineering tasks

Example

Define a Task Network

Effort Allocation 40 -50% 15 -20% • “front end” activities – – customer communication analysis design review and modification • construction activities – coding or code generation • testing and installation 30 -40% – unit, integration – white-box, black box – regression

Use Automated Tools to Derive a Timeline Chart

Why SQA Activities Pay Off? cost to find and fix a defect 100 60. 00 -100. 00 log scale 10 1 10. 00 1. 00 0. 75 Req. 1. 50 Design 3. 00 test system field use code test

Quality Concepts • general objective: reduce the “variation between samples”. . . but how does this apply to software? • quality control: a series of inspections, reviews, tests • quality assurance: analysis, auditing and reporting activities • cost of quality – appraisal costs – failure costs – external failure costs

Software Quality Assurance SQA Process Definition & Standards Formal Technical Reviews Analysis & Reporting Measurement Test Planning & Review

Reviews & Inspections. . . there is no particular reason why your friend and colleague cannot also be your sternest critic. Jerry Weinberg

What Are Reviews? • a meeting conducted by technical people for technical people • a technical assessment of a work product created during the software engineering process • a software quality assurance mechanism • a training ground

What Reviews Are Not! They are not: a project budget summary a scheduling assessment an overall progress report a mechanism for reprisal or political intrigue!!

The Players review leader standards bearer (SQA) producer maintenance oracle reviewer recorder user rep

Conducting the Review 1. be prepared—evaluate product before the review 2. review the product, not the producer 3. keep your tone mild, ask questions instead of making accusations 4. stick to the review agenda 5. raise issues, don't resolve them 6. avoid discussions of style—stick to technical correctness 7. schedule reviews as project tasks 8. record and report all review results

Review Options Matrix trained leader agenda established reviewers prepare in advance producer presents product “reader” presents product recorder takes notes checklists used to find errors categorized as found issues list created team must sign-off on result IPR * WT IN no maybe no no yes yes no no yes yes yes IPR—informal peer review WT—Walkthrough *IN—Inspection RRR—round robin review RRR yes yes no no yes maybe

Metrics Derived from Reviews inspection time per page of documentation inspection time per KLOC or FP inspection effort per KLOC or FP errors uncovered per reviewer hour errors uncovered per preparation hour errors uncovered per SE task (e. g. , design) number of minor errors (e. g. , typos) number of major errors (e. g. , nonconformance to req. ) number of errors found during preparation

Statistical SQA Product & Process • collect information on all defects • find the causes of the defects • move to provide fixes for the process measurement. . . an understanding of how to improve quality. . .

The “First Law” No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle. Bersoff, et al, 1980

What Are These Changes? changes in business requirements changes in technical requirements changes in user requirements Project Plan other documents software models data Test code

The Software Configuration programs The pieces documents data

Change & SCM Software Engineering tools methods procedures a TQM foundation SCM • • • identification version control change control auditing reporting construction

Change Control STOP

Change Control Process—I need for change is recognized change request from user developer evaluates change report is generated change control authority decides request is queued for action change request is denied user is informed change control process—II

Change Control Process-II assign people to SCIs check-out SCIs make the change review/audit the change establish a “baseline” for testing change control process—III

Change Control Process-III perform SQA and testing activities check-in the changed SCIs promote SCI for inclusion in next release rebuild appropriate version review/audit the change include all changes in release

Auditing Change Requests SCIs SQA Plan SCM Audit

Status Accounting Change Reports Requests ECOs SCIs Status Accounting Reporting