Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Convener: Houman Younessi Convener: Houman Younessi Software Engineering Management Software Engineering Management Course # CISH-6050 Lecture 6: Software.

Similar presentations


Presentation on theme: "1 Convener: Houman Younessi Convener: Houman Younessi Software Engineering Management Software Engineering Management Course # CISH-6050 Lecture 6: Software."— Presentation transcript:

1 1 Convener: Houman Younessi Convener: Houman Younessi Software Engineering Management Software Engineering Management Course # CISH-6050 Lecture 6: Software Process Definition and Modeling 06/18/2012

2 2 CISH Software Engineering Management AGENDA SE Processes -Rational Unified Process (RUP) -Object-oriented Process Environments and Notation (OPEN) Key Process Areas for SW-CMM Level 3: Defined Peer Reviews Education and Training SE Processes -Rational Unified Process (RUP) -Object-oriented Process Environments and Notation (OPEN) Key Process Areas for SW-CMM Level 3: Defined Peer Reviews Education and Training

3 3 CISH Software Engineering Management AGENDA … Software Process Definition Software Process Models: -Waterfall -V-Model -Spiral -Evolutionary, Incremental, Concurrent -Prototype, OO -RAD -Others … Software Process Definition Software Process Models: -Waterfall -V-Model -Spiral -Evolutionary, Incremental, Concurrent -Prototype, OO -RAD -Others …

4 4 CISH Software Engineering Management Organizational Process Focus -Establish organizational responsibility for software process activities that improve org’s overall software process capability Organizational Process Definition: -Develop & maintain a usable set of software process assets that improve process performance across projects Organizational Process Focus -Establish organizational responsibility for software process activities that improve org’s overall software process capability Organizational Process Definition: -Develop & maintain a usable set of software process assets that improve process performance across projects SW-CMM Level 3 KPAs: Defined

5 5 CISH Software Engineering Management Training Program -Develop skills and knowledge of individuals so they can perform their roles effectively and efficiently Integrated Software Management: -Integrate software engineering and management activities into a coherent, defined software process, tailored from org’s standard software process Training Program -Develop skills and knowledge of individuals so they can perform their roles effectively and efficiently Integrated Software Management: -Integrate software engineering and management activities into a coherent, defined software process, tailored from org’s standard software process SW-CMM Level 3 KPAs: Defined …

6 6 CISH Software Engineering Management Software Product Engineering: -Consistently perform a well defined engineering process, integrating all software engineering activities to produce correct products consistently Intergroup Coordination: -Means for software engineering group to actively participate with other engineering groups Software Product Engineering: -Consistently perform a well defined engineering process, integrating all software engineering activities to produce correct products consistently Intergroup Coordination: -Means for software engineering group to actively participate with other engineering groups SW-CMM Level 3 KPAs: Defined …

7 7 CISH Software Engineering Management Peer Reviews: -Review defects from the software work products early and efficiently Peer Reviews: -Review defects from the software work products early and efficiently SW-CMM Level 3 KPAs: Defined …

8 8 CISH Software Engineering Management Fallacies about Education and Training from R. L. Glass Facts and Fallacies of Software Engineering -You teach people how to program by showing them how to write programs  Shown the “rules” of a programming language & then asked to write code  In learning other languages, you learn to read it first; read examples of what skilled writers have written Fallacies about Education and Training from R. L. Glass Facts and Fallacies of Software Engineering -You teach people how to program by showing them how to write programs  Shown the “rules” of a programming language & then asked to write code  In learning other languages, you learn to read it first; read examples of what skilled writers have written Education and Training

9 9 CISH Software Engineering Management -Should take a ‘read before writing’ approach to learn how write code  To teach code reading, select examples of code to be read – top notch code or flawed code  Need text books to support code reading  Standard curricula for software academic disciplines updated to teach code reading -Should take a ‘read before writing’ approach to learn how write code  To teach code reading, select examples of code to be read – top notch code or flawed code  Need text books to support code reading  Standard curricula for software academic disciplines updated to teach code reading Education and Training …

10 10 CISH Software Engineering Management Organizations are likely to expect project members to acquire new knowledge in ad-hoc manner, vs. personal development program Training has cost attached to it, which can be offset with expected benefits Training is investment in org’s major asset: its employees Organizations are likely to expect project members to acquire new knowledge in ad-hoc manner, vs. personal development program Training has cost attached to it, which can be offset with expected benefits Training is investment in org’s major asset: its employees Education and Training …

11 11 CISH Software Engineering Management Lack of training jeopardizes schedules and product quality Sufficient evidence from failed IS projects to suggest many new & inexperienced project managers struggle to cope with project -Orgs stand by & watch project managers (and projects) suffer -Net result not good – failed projects and departed resource Lack of training jeopardizes schedules and product quality Sufficient evidence from failed IS projects to suggest many new & inexperienced project managers struggle to cope with project -Orgs stand by & watch project managers (and projects) suffer -Net result not good – failed projects and departed resource Education and Training …

12 12 CISH Software Engineering Management To correct this: -Organizations place focus on education and training -Support training by providing funding & time for education -Offer mentoring or coaching schemes to project managers – both new and inexperienced To correct this: -Organizations place focus on education and training -Support training by providing funding & time for education -Offer mentoring or coaching schemes to project managers – both new and inexperienced Education and Training …

13 13 CISH Software Engineering Management Software Engineering Process Group (SEPG) should serve as focal point for organizational education & training Education and Training …

14 14 CISH Software Engineering Management Education & training generally needs to be done for a development organization on: -Project Management Methods -Software Design Methods -Quality Management -Design and Code Inspections Education & training generally needs to be done for a development organization on: -Project Management Methods -Software Design Methods -Quality Management -Design and Code Inspections Education and Training …

15 15 CISH Software Engineering Management SEPG can consult on: -Process data to be collected -Analysis & interpretation of data -Tuning standard process to unique project needs -Assisting with quality plans -Advising on priority areas for technology insertion -Serve as experienced inspection moderators SEPG can consult on: -Process data to be collected -Analysis & interpretation of data -Tuning standard process to unique project needs -Assisting with quality plans -Advising on priority areas for technology insertion -Serve as experienced inspection moderators Education and Training …

16 16 CISH Software Engineering Management Facts & Fallacies about Reviews & Inspections from R. L. Glass Facts and Fallacies of Software Engineering -Fact: Rigorous inspections can remove up to 90% of errors from software before 1 st test case is executed  Same study shows cost of inspection less than cost of testing to find same error  Effective process that is cost effective Facts & Fallacies about Reviews & Inspections from R. L. Glass Facts and Fallacies of Software Engineering -Fact: Rigorous inspections can remove up to 90% of errors from software before 1 st test case is executed  Same study shows cost of inspection less than cost of testing to find same error  Effective process that is cost effective Peer Reviews

17 17 CISH Software Engineering Management -So why aren’t given same recognition as other break through methods, such as CASE tools?  Few major vendors make money from inspections  Nothing new & marketable about inspections  Seen as part of back end of the software life cycle  Require a lot of mind-intensive hard work -So why aren’t given same recognition as other break through methods, such as CASE tools?  Few major vendors make money from inspections  Nothing new & marketable about inspections  Seen as part of back end of the software life cycle  Require a lot of mind-intensive hard work Peer Reviews …

18 18 CISH Software Engineering Management -Fact: Despite benefits of rigorous inspections, they can’t/shouldn’t replace testing  Inspections can’t remove all errors  Error removal is complex task  Software construction is complex and error prone  No silver bullet with software inspections, so testing is still needed to remove errors in code -Fact: Despite benefits of rigorous inspections, they can’t/shouldn’t replace testing  Inspections can’t remove all errors  Error removal is complex task  Software construction is complex and error prone  No silver bullet with software inspections, so testing is still needed to remove errors in code Peer Reviews …

19 19 CISH Software Engineering Management -Fact: Postdelivery reviews are important for process improvement and determining customer sat, but most orgs don’t do them  After project is complete, lessons learned (postdelivery review) should be done to understand problems, root causes, and what can be done to prevent them from happening again  Lessons learned tend to be discarded as developers move on to next project -Fact: Postdelivery reviews are important for process improvement and determining customer sat, but most orgs don’t do them  After project is complete, lessons learned (postdelivery review) should be done to understand problems, root causes, and what can be done to prevent them from happening again  Lessons learned tend to be discarded as developers move on to next project Peer Reviews …

20 20 CISH Software Engineering Management -Fact: Peer reviews are both technical and sociological – have to pay attention to both  Need to focus on the technical aspect of the review, while being sensitive to the sociological side as well  Egoless programming and no personal attacks on the developer  Don’t let managers or unprepared participants attend  Have roles and responsibilities identified -Fact: Peer reviews are both technical and sociological – have to pay attention to both  Need to focus on the technical aspect of the review, while being sensitive to the sociological side as well  Egoless programming and no personal attacks on the developer  Don’t let managers or unprepared participants attend  Have roles and responsibilities identified Peer Reviews …

21 21 CISH Software Engineering Management -Fallacy: If enough people look at your code, all bugs are found  Research shows that there is a maximum number of useful inspection participants – 2 to 4  No evidence to suggest that this fallacy is true -Fallacy: If enough people look at your code, all bugs are found  Research shows that there is a maximum number of useful inspection participants – 2 to 4  No evidence to suggest that this fallacy is true Peer Reviews …

22 22 CISH Software Engineering Management Software Inspections provide powerful method to improve quality & productivity of software: -Find/correct errors earlier in software development cycle -13:1 ROI by some orgs by correcting bugs and reducing rework costs later in cycle -Cost factor for fixing bug increases through development cycle: 1x to 200x Software Inspections provide powerful method to improve quality & productivity of software: -Find/correct errors earlier in software development cycle -13:1 ROI by some orgs by correcting bugs and reducing rework costs later in cycle -Cost factor for fixing bug increases through development cycle: 1x to 200x Peer Reviews …

23 23 CISH Software Engineering Management Inspection : -Find errors at earliest possible point -Uncover errors in function, logic, etc. -Ensure technically agree on work -Verify software meets requirements -Ensure software developed per standards -Achieve software that is developed in uniform manner -Make projects more manageable -Provide data on product & inspection process Inspection : -Find errors at earliest possible point -Uncover errors in function, logic, etc. -Ensure technically agree on work -Verify software meets requirements -Ensure software developed per standards -Achieve software that is developed in uniform manner -Make projects more manageable -Provide data on product & inspection process Peer Reviews …

24 24 CISH Software Engineering Management Not just code inspection, but also inspect: -Estimates & sizings -Project plans & schedules -Requirements document -Design documents -Unit Test Cases -System Test Cases -User Acceptance Test Cases Not just code inspection, but also inspect: -Estimates & sizings -Project plans & schedules -Requirements document -Design documents -Unit Test Cases -System Test Cases -User Acceptance Test Cases Peer Reviews …

25 25 CISH Software Engineering Management Inspection Principles: -Structured, formal process w/ defined roles -Generic checklists used for all inspections -Tailored checklists for project specific items -3 to 5 people -Advance prep needed; no more than 2 hours -Duration less than 2 hours -Data about inspection recorded & reported -Identify problems, not resolve them Inspection Principles: -Structured, formal process w/ defined roles -Generic checklists used for all inspections -Tailored checklists for project specific items -3 to 5 people -Advance prep needed; no more than 2 hours -Duration less than 2 hours -Data about inspection recorded & reported -Identify problems, not resolve them Peer Reviews …

26 26 CISH Software Engineering Management The software process is documented by a process engineering work product Software Process Definition: -Identifies a set of activities needed to develop software and supporting products -Identifies activity relationship to each other -Typically performed at 2 levels: 1.Generic organization process 2.Project specific process The software process is documented by a process engineering work product Software Process Definition: -Identifies a set of activities needed to develop software and supporting products -Identifies activity relationship to each other -Typically performed at 2 levels: 1.Generic organization process 2.Project specific process Software Process Definition

27 27 CISH Software Engineering Management Each defined activity provides: -A description -When to start and stop -Required inputs -What it accomplishes or produces -Personnel, methods, practices & tools to be used -Cost & schedule estimating mechanisms Each defined activity provides: -A description -When to start and stop -Required inputs -What it accomplishes or produces -Personnel, methods, practices & tools to be used -Cost & schedule estimating mechanisms Software Process Definition …

28 28 CISH Software Engineering Management Four fundamental process activities common to all software processes: 1.Software Specification – functionality & constraints 2.Software Development – producing software to meet specification 3.Software Validation – verification & validation 4.Software Evolution – evolves to meet changing customer needs Four fundamental process activities common to all software processes: 1.Software Specification – functionality & constraints 2.Software Development – producing software to meet specification 3.Software Validation – verification & validation 4.Software Evolution – evolves to meet changing customer needs Software Process Definition …

29 29 CISH Software Engineering Management Process Driver Constraints: -Organizational Process Drivers  Investments (equipment, methods, etc.)  Technology & business strategies  Infrastructure & culture  Government rules & regulations  Polices, procedures, & standards Process Driver Constraints: -Organizational Process Drivers  Investments (equipment, methods, etc.)  Technology & business strategies  Infrastructure & culture  Government rules & regulations  Polices, procedures, & standards Software Process Definition …

30 30 CISH Software Engineering Management Process Driver Constraints … -Project Process Drivers  Organizational process definition (or drivers)  Project objectives (follow-on work, zero defects, etc.)  Project constraints (i.e. customer requirements)  Project risks & problem areas Process Driver Constraints … -Project Process Drivers  Organizational process definition (or drivers)  Project objectives (follow-on work, zero defects, etc.)  Project constraints (i.e. customer requirements)  Project risks & problem areas Software Process Definition …

31 31 CISH Software Engineering Management There’s no right or wrong software process for an org to follow -Different software processes decompose activities differently -Timing of activities may vary as does results -Different orgs may use different processes to produce same type of product There’s no right or wrong software process for an org to follow -Different software processes decompose activities differently -Timing of activities may vary as does results -Different orgs may use different processes to produce same type of product Software Process Definition …

32 32 CISH Software Engineering Management There’s no right or wrong software process for an org to follow … -Different types of products may be produced by organization using different processes -Some processes more suitable than others for some types of application development -Chosen process model based on nature of software dev. project & application There’s no right or wrong software process for an org to follow … -Different types of products may be produced by organization using different processes -Some processes more suitable than others for some types of application development -Chosen process model based on nature of software dev. project & application Software Process Definition …

33 33 CISH Software Engineering Management Waterfall Model -First presented by Royce in Simple, transformation-based life cycle model -Depicts a sequential execution of principle stages in the development process -Also called Linear Sequential or Classic Life Cycle model Waterfall Model -First presented by Royce in Simple, transformation-based life cycle model -Depicts a sequential execution of principle stages in the development process -Also called Linear Sequential or Classic Life Cycle model Software Process Models

34 34 CISH Software Engineering Management Waterfall Model Operations / Maintenance

35 35 CISH Software Engineering Management V-Model -Variation of the Waterfall model – Waterfall is “pulled” to a ‘V’ at implementation phase -Viewed as several horizontal process layers -Each phase, except for implementation, has process checking mechanism  Detailed design validated by Unit Test  High level design validated by Component Integration Test V-Model -Variation of the Waterfall model – Waterfall is “pulled” to a ‘V’ at implementation phase -Viewed as several horizontal process layers -Each phase, except for implementation, has process checking mechanism  Detailed design validated by Unit Test  High level design validated by Component Integration Test Software Process Models …

36 36 CISH Software Engineering Management V-Model … -Each layer depicts a level of abstraction and three process partitions, each depicting a class of project activity:  Creation  Evaluation  Operation V-Model … -Each layer depicts a level of abstraction and three process partitions, each depicting a class of project activity:  Creation  Evaluation  Operation Software Process Models …

37 37 CISH Software Engineering Management System Req. Analysis Operation & Maintenance Creation Operation Evaluation V-Model

38 38 CISH Software Engineering Management Spiral Model -First introduced by Boehm in Views the software process as a series of risk management cycles -Based on notion or prototyping -As you move away from origin of spiral, levels of expended funding increase -Specific activities as you go through each quadrant Spiral Model -First introduced by Boehm in Views the software process as a series of risk management cycles -Based on notion or prototyping -As you move away from origin of spiral, levels of expended funding increase -Specific activities as you go through each quadrant Software Process Models …

39 39 CISH Software Engineering Management Spiral Model … -Goal: after sufficient number of cycles, product will be accepted -Win Win Spiral  Set of negotiation activities at the beginning of each pass around spiral  Following activities defined: 1.Identification of system stakeholders 2.Determine stakeholder’s win criteria 3.Negotiation of win criteria Spiral Model … -Goal: after sufficient number of cycles, product will be accepted -Win Win Spiral  Set of negotiation activities at the beginning of each pass around spiral  Following activities defined: 1.Identification of system stakeholders 2.Determine stakeholder’s win criteria 3.Negotiation of win criteria Software Process Models …

40 40 CISH Software Engineering Management Evolutionary, Incremental Models -Evolutionary Models are iterative:  Planned development of multiple releases of product -Incremental Models  Combines elements of Waterfall model with iterative philosophy of prototyping  Each linear sequence delivers increment of the software  Activities repeated at each increment Evolutionary, Incremental Models -Evolutionary Models are iterative:  Planned development of multiple releases of product -Incremental Models  Combines elements of Waterfall model with iterative philosophy of prototyping  Each linear sequence delivers increment of the software  Activities repeated at each increment Software Process Models …

41 41 CISH Software Engineering Management Concurrent Model -Many activities in progress concurrently for any phase of cycle -Uses state charts to represent concurrent relationships existing among activities -Driven by user needs, management decisions & review results -Can be represented schematically as a series of major technical activities, tasks, & their associated states Concurrent Model -Many activities in progress concurrently for any phase of cycle -Uses state charts to represent concurrent relationships existing among activities -Driven by user needs, management decisions & review results -Can be represented schematically as a series of major technical activities, tasks, & their associated states Software Process Models …

42 42 CISH Software Engineering Management Prototype Model -Customer identifies set of general objectives -Detailed requirements not known -Create a prototype, which is evaluated by customer -Iterations occur as prototype is tuned -Focuses on high risk function, performance, and user requirements Prototype Model -Customer identifies set of general objectives -Detailed requirements not known -Create a prototype, which is evaluated by customer -Iterations occur as prototype is tuned -Focuses on high risk function, performance, and user requirements Software Process Models …

43 43 CISH Software Engineering Management Object Oriented/Component Based Models -Creation of classes that encapsulates both data & algorithms to manipulate data -Prescribes software development in terms of synergy between abstraction, modularity, encapsulation, hierarchy, typing, concurrency & persistence -Incorporates characteristics of Spiral Model -Evolutionary in nature; software reuse Object Oriented/Component Based Models -Creation of classes that encapsulates both data & algorithms to manipulate data -Prescribes software development in terms of synergy between abstraction, modularity, encapsulation, hierarchy, typing, concurrency & persistence -Incorporates characteristics of Spiral Model -Evolutionary in nature; software reuse Software Process Models …

44 44 CISH Software Engineering Management Rapid Application Development (RAD) -Incremental software development model emphasizing extremely short cycle (60-90 days) -High speed adaptation of Waterfall, using component based design -If requirements fully understood & project scope constrained, RAD enables dev team to create fully functional system in short period of time Rapid Application Development (RAD) -Incremental software development model emphasizing extremely short cycle (60-90 days) -High speed adaptation of Waterfall, using component based design -If requirements fully understood & project scope constrained, RAD enables dev team to create fully functional system in short period of time Software Process Models …

45 45 CISH Software Engineering Management Phases encompassed by RAD: -Business Modeling – info flow between fctns -Data Modeling – business data refined into set of data objects -Process Modeling – data objects transformed to information flow -Application generation – assumes 4GL used -Testing/Turnover – with reuse, many components already tested Phases encompassed by RAD: -Business Modeling – info flow between fctns -Data Modeling – business data refined into set of data objects -Process Modeling – data objects transformed to information flow -Application generation – assumes 4GL used -Testing/Turnover – with reuse, many components already tested Software Process Models …

46 46 CISH Software Engineering Management Embedded Systems: -US DoD system life cycle model DoD-Std describes how embedded systems should be developed -Embedded System: electromechanical system governed by one or more computers (i.e. rocket guidance system) -Computers in embedded systems perform some of requirements of that system Embedded Systems: -US DoD system life cycle model DoD-Std describes how embedded systems should be developed -Embedded System: electromechanical system governed by one or more computers (i.e. rocket guidance system) -Computers in embedded systems perform some of requirements of that system Software Process Models …

47 47 CISH Software Engineering Management Formal Methods: -Encompasses activities leading to formal mathematical specifications of software -Enables software engineer to specify, develop, & verify software through rigorous mathematical notation -Ambiguity & inconsistency discovered & corrected more easily than ad hoc reviews -Concerns: time consuming, extensive training, may be difficult to use w/ customers Formal Methods: -Encompasses activities leading to formal mathematical specifications of software -Enables software engineer to specify, develop, & verify software through rigorous mathematical notation -Ambiguity & inconsistency discovered & corrected more easily than ad hoc reviews -Concerns: time consuming, extensive training, may be difficult to use w/ customers Software Process Models …

48 48 CISH Software Engineering Management Cleanroom: -Variation of Formal Methods -Cleanroom Engineering starts during software process management -Each cleanroom has ETVXM:  Entry – conditions to satisfy  Feedback – input to tasks  Task – what, who, how, & when  Verification – checking work products  Exit – termination requirements  Measurement – required task measures Cleanroom: -Variation of Formal Methods -Cleanroom Engineering starts during software process management -Each cleanroom has ETVXM:  Entry – conditions to satisfy  Feedback – input to tasks  Task – what, who, how, & when  Verification – checking work products  Exit – termination requirements  Measurement – required task measures Software Process Models …

49 49 CISH Software Engineering Management 4GT - Fourth Generation Techniques: -Encompasses software tools allowing engineer to specify software characteristics at high level -Tool automatically generates source code -Focuses on ability specify software using specialized language forms or graphics -4GT development environments use non- procedural languages for DB query, report generation, code; high level graphics, spread sheets, automated HTML, etc. 4GT - Fourth Generation Techniques: -Encompasses software tools allowing engineer to specify software characteristics at high level -Tool automatically generates source code -Focuses on ability specify software using specialized language forms or graphics -4GT development environments use non- procedural languages for DB query, report generation, code; high level graphics, spread sheets, automated HTML, etc. Software Process Models …

50 50 CISH Software Engineering Management 4GT Current State: -Using 4GT is viable approach for many application areas -Coupled with computer-aided software & code generators, 4GT offers credible sol’n -Based on data from companies using 4GT:  Reduced time in producing small apps  Reduced time for design/analysis for small apps  Using 4GT for larger effort requires more analysis, design, & testing to save time 4GT Current State: -Using 4GT is viable approach for many application areas -Coupled with computer-aided software & code generators, 4GT offers credible sol’n -Based on data from companies using 4GT:  Reduced time in producing small apps  Reduced time for design/analysis for small apps  Using 4GT for larger effort requires more analysis, design, & testing to save time Software Process Models …

51 51 CISH Software Engineering Management Lecture 6 Recap: Key Process Areas for SW-CMM Level 3: Defined Peer Reviews Education and Training Software Process Definition Software Process Models Key Process Areas for SW-CMM Level 3: Defined Peer Reviews Education and Training Software Process Definition Software Process Models

52 52 CISH Software Engineering Management References P. Jalote, Software Project Management in Practice, Addison-Wesley, Boston, MA, 2002 R. L. Glass, Facts and Fallacies of Software Engineering, Addison-Wesley, Boston, MA, 2003 D. Yardley, Successful IT Project Delivery: Learning the Lessons of Project Failure, Addison-Wesley, Boston, MA, 2002 R. S. Pressman, Software Engineering: A Practitioner's Approach, 5th ed., McGraw-Hill, New York, 2001 W. S. Humphrey, Managing the Software Process, Addison-Wesley, Reading, MA, 1989 I. Sommerville, Software Engineering, 5th ed., Addison-Wesley, Reading, MA, 1995 M. Paulk, C. V. Weber, B. Curtis, M. B. Chrissis, The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, Boston, MA, 1995 J. Peters, W. Pedrycz, Software Engineering: An Engineering Approach, John Wiley & Sons, Inc., NY, NY, 2000 P. Jalote, Software Project Management in Practice, Addison-Wesley, Boston, MA, 2002 R. L. Glass, Facts and Fallacies of Software Engineering, Addison-Wesley, Boston, MA, 2003 D. Yardley, Successful IT Project Delivery: Learning the Lessons of Project Failure, Addison-Wesley, Boston, MA, 2002 R. S. Pressman, Software Engineering: A Practitioner's Approach, 5th ed., McGraw-Hill, New York, 2001 W. S. Humphrey, Managing the Software Process, Addison-Wesley, Reading, MA, 1989 I. Sommerville, Software Engineering, 5th ed., Addison-Wesley, Reading, MA, 1995 M. Paulk, C. V. Weber, B. Curtis, M. B. Chrissis, The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, Boston, MA, 1995 J. Peters, W. Pedrycz, Software Engineering: An Engineering Approach, John Wiley & Sons, Inc., NY, NY, 2000


Download ppt "1 Convener: Houman Younessi Convener: Houman Younessi Software Engineering Management Software Engineering Management Course # CISH-6050 Lecture 6: Software."

Similar presentations


Ads by Google