1 / 58

CS 551 Development Process

CS 551 Development Process. Engineering via Lambda Protocol. Prospectus Measurable Operational Value Prototyping then Modeling Quality Function Deployment Schedule & Staffing Estimates ICED-T Trade-off Analysis. Universal Software Engineering Equation. Reliability (t) = ℮ -a  t

baker-orr
Download Presentation

CS 551 Development Process

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS 551 Development Process

  2. Engineering via Lambda Protocol • Prospectus • Measurable Operational Value • Prototyping then Modeling • Quality Function Deployment • Schedule & Staffing Estimates • ICED-T • Trade-off Analysis

  3. Universal Software Engineering Equation Reliability (t) = ℮-a t for constant error rate

  4. Universal Software Engineering Equation Reliability (t) = ℮-a t for constant error rate ais a productivity constant • = complexity/ [effectiveness x staffing] • ≡ 1/ MTTF effectiveness ≡ code expansion t ≡ isthe time the software is running

  5. Boundary Conditions Reliability (0) = 1 Reliability (T) = ℮- aT Reliability (∞) = 0

  6. Top Ten Software Risk Items From Boehm (1988), p. 6

  7. Risk Analysis • Risk ≡ Probability that an event will happen = 1- Prob (event happens) = 1- event/number of events possible Business cost = the cost of recovering from the event or avoiding the event Risk Exposure = Prob( event) x Business Cost

  8. How Soon to Define Interfaces? -Loss due to rework with ill defined & validated architecture Many interface defects: high P(L) Critical IF defects: high C(L) Risk Exposure (RE )= P(L) * C(L) Few IF defects: low P(L) Minor IF defects: low C(L) Time spent defining & validating architecture

  9. How Soon to Define Interfaces? -Loss due to rework with ill defined & validated architecture-Loss due to delayed implementation start Many interface defects: high P(L) Critical IF defects: high C(L) Many delays: high P(L) Long delays: high C(L) RE = P(L) * C(L) Few delays: low P(L) Short Delays: low C(L) Few IF defects: low P(L) Minor IF defects: low C(L) Time spent defining & validating architecture

  10. How Soon to Define Interfaces? - Sum of Risk Exposures Many interface defects: high P(L) Critical IF defects: high C(L) Many delays: high P(L) Long delays: high C(L) RE = P(L) * C(L) Sweet Spot Few delays: low P(L) Short delays: low C(L) Few IF defects: low P(L) Minor IF defects: low C(L) Time spent defining & validating architecture

  11. Organizational Structure SYSTEM BASELINE REQUIREMENTS ALGORITHMS FEATURE ENGINEERING SOFTWARE DEVELOPMENT SOFTWARE MANUFACTURING ARCHITECTURE ENGINEERING INTEGRATION HUMAN FACTORS DEVELOPMENT TO SITES TRAFFIC ENGINEERING TRAFFIC PROJECTIONS ENGINNERING REPORTS SUPPORT AND OPERATIONS - COMPUTER CENTER - DEVELOPMENT MACHINE - TEST MACHINE

  12. Development Cycle with Feedback MANUFACTURE & DELIVER DEFINE DESIGN DEVELOP TEST TO SITES OPERATE, MAINTAIN & EVALUATE

  13. Project Trouble Indicators • No periodic project meetings • No project manager • No active problem list • No software architect • Testing starts after development • No risk assessment • No independent test team

  14. System Performance Resulting from Robust Requirements Performance Discrete Specifications Ideal Robust Requirements Dynamic Range

  15. Requirements Specification Spec • Project Title, Revision Number and Author • Scope and Purpose of the system • Measurable Organization Value • Description • Feature List including ICED T and Simplified QFD analysis • Interfaces • Constraints • Change Log and Expected Changes • Responses to the unexpected • Measurements • Glossary • References

  16. MeasurableOperational Value

  17. GANTT Chart see http://www.mne.psu.edu/me415/resources/docs/gantt%20chart.pdf

  18. CS SENIOR DESIGN CITIGROUP PROJECT

  19. CS SENIOR DESIGN CITIGROUP PHASES

  20. Software Requirements Process • Requirements Elicitation • Requirements Analysis • Use Cases • Requirements Specification • Prototype • Requirements Management

  21. <<actor>> Account System View Status Create & Submit Orders <<actor>> Inventory • Develop Use Cases • Focus on Goals • Identify Actors • Identify Main Tasks • Use Case Concept • Complete, orthogonal, externally visible functionality • Initiated by an actor • Identifiable value to the actor Ordering System

  22. Role of Software Architect • Assures that the Requirements are valid- use Prototypes in Requirements Stage • Assures that Requirements are quantitative • Defines Non Functional Requirements and Software Trustworthiness. • Defines 4+1 views • Defines Components and Interface Structures

  23. Kruchten’s “4 + 1”Model for Developing Software Architecture View 1 View 2 Process: System Integrators Logical: End Users View + 1 Business Scenarios: Customers All Stakeholders View 4 View 3 Execution: Programmers Physical: Engineers

  24. Role of Project Manager • Defines and documents Development Process • Makes trade-offs among features, schedule, development cost and quality • Chairs Project Meetings • Assigns and tracks action items • Communicates to Project Members

  25. Waterfall Model System feasibility Focus: Control Emphasis: Documentation Validation Software plans & Requirements Validation Product design Verification Detailed design Verification Code Unit test Integration Quality assurance Implementation Certification Operations & maintenance Operational Reviews

  26. Figure 2: Boehm’s Spiral Model of the Software Process Cumulative Cost Progress through steps Determines Objectives Alternatives, Constraints Evaluate Alternatives: Identify, Resolve Risks Focus: Risk Emphasis: Contingency Planning Risk Analysis Risk Analysis Risk Analysis Operational Prototype Rqts Anal. Proto- Type 1 Proto- type 3 Proto- Type 2 Commitment Partition Concept of Operation Rqts. Plan Life Cycle Plan Software Rqts Detailed Design Develop- ment Plan Requirements Validation Software Product Design Unit Test Code Design Validation and Verification Integration and Test Integra- tion & Test Acceptance Test Implemen- tation Plan Next Phases Develop & Verify Next - Level Product

  27. Role of Software Developers • Designs Software Components • Implements Software • Documents with code commentary prefaces and in-line narratives. • Unit Tests • Checks Interfaces

  28. Development Plan-an evolving document • Name of Project (issue 1 due 6Nov) • Purpose and MOV • Team members & their roles, • Feature Packages • Gantt Chart • Current Estimate Table • QFD • ICED-T

  29. Making a System Tools Source Library JAVA SOURCE LIBRARIES 4GL FORTRAN, ADA C Level Production Computer Development Computer Assembler Binary Application … Middleware APPLICATION DATA BASE Computer Hardware UNIX PRODUCT BUILDING BLOCKS EXECUTABLE LIBRARIES …. DEVELOPERS, PROGRAM ADMINISTRATORS & SOFTWARE MANUFACTURERS USERS

  30. Role of Testers • Restates requirements quantitatively and from a tester’s view • Creates test bed for developers • Designs and executes: • Scenario Tests from Use Cases • Integration Tests • Reliability Tests • Stress Tests

  31. Factors Affecting ProductivityCirca 1975 • Competent Management • Quality of people • Level of testing before shipping • Consistency of requirements • Sophistication of programming tools • Modularity of design • Reasonableness of commitments

  32. Development Cycle Circa 1970 Design Programs, Data Base & User Documentation Define Requirements Code and Test Modules Integration Test System Test Verify System Operation Install Software Target Site Live Operation

  33. Development Cycle for Multiple Sites Circa 1975-80 Site Peculiar Tests Design Programs, Data Base & User Documentation Define Requirements Code and Test Modules Integration Test System Test Verify System Operation Install Software Site 1 Live Operation . . . . . . . . . Verify System Operation Install Software Live Operation Site N

  34. Development Cycle with Software Manufacturing Circa 1980-90 Site Peculiar Tests Design Programs, Data Base & User Documentation Software Manufacture Controls & Builds Define Requirements Code and Test Modules Integration Test System Test Verify System Operation Install Software Live Operation Site 1 . . . . . . . . . Software Manufacture Builds and Ships Verify System Operation Install Software Live Operation Site N

  35. Development Cycle with Software Manufacturing Circa 1990-2000 Agile ‘Test then Code’ Approach Daily Software Builds Quality Assurance Define Requirements Verify System Operation Install Software Live Operation Site 1 Software Manufacture Builds and Loads Server . . . . . . . . . Verify System Operation Install Software Live Operation Site N

  36. Agile Software Development • Agile methods • Extreme programming • Agile application development • Software prototyping Focus: Time-to-Market Emphasis: Minimum Appropriate Process, a Humanistic Approach

  37. Technologies used in agile development • .NET and J2EE • Web Design • Visual Basic • Databases

  38. Define system deliverables Define system deliverables Specify system increment Build system increment Validate increment No Validate system Integrate increment Yes Deliver system Done? An iterative development process

  39. Advantages of incremental development • Accelerated delivery of customer services. Each increment delivers the highest priority functionality to the customer. • User engagement with the system. Users have to be involved in the development which means the system is more likely to meet their requirements and the users are more committed to the system.

  40. Agile methods • Dissatisfaction with the overheads involved in design methods led to the creation of agile methods. These methods: • Focus on the code rather than the design; • Are based on an iterative approach to software development; • Are intended to deliver working software quickly and evolve this quickly to meet changing requirements. • Agile methods are probably best suited to small/medium-sized business systems or PC products.

  41. Principle Description Customer involvement The customer should be closely involved throughout the development process. Their role is provide and priorities new system requirements and to evaluate the iterations of the system. Incremental delivery The so ftware is developed in increments with the customer specifying the requirements to be included in each increment. People not process The skills of the development team should be recognized and exploited. The team should be left to develop their own ways o f working without prescriptive processes. Embrace change Expect the system requirements to change and design the system so that it can accommodate these changes. Maintain simplicity Focus on simplicity in both the software being developed and in the deve lopment process used. Wherever possible, actively work to eliminate complexity from the system. Principles of agile methods

  42. Problems with agile methods • It can be difficult to keep the interest of customers who are involved in the process. • Team members may be unsuited to the intense involvement that characterises agile methods. • Prioritising changes can be difficult where there are multiple stakeholders. • Maintaining simplicity requires extra work. • Contracts may be a problem as with other approaches to iterative development.

  43. Extreme programming • Perhaps the best-known and most widely used agile method. • Extreme Programming (XP) takes an ‘extreme’ approach to iterative development. • New versions may be built several times per day; • Increments are delivered to customers every 2 weeks; • All tests must be run for every build and the build is only accepted if tests run successfully.

  44. The XP release cycle Select user Break down stories for this Plan release stories to tasks release Evaluate Release Develop/integrate system software test software

  45. Extreme programming practices I incr em en t a l p l ann i ng R e qui r e m en ts a r e r e cord e d on S t o r y C a r ds and t he St or i e s t o be i nc l uded i n a r e l e as e a r e de t er mi ned by t h e tim e a va il ab l e a nd t he ir r e l a ti ve pr i o rit y. The deve l ope r s br e ak t he s e s t o ri es i n t o deve l op m en t tasks . Sm a ll R e l eas e s T he mi n im a l u s e f u l s e t o f f unc ti ona lit y t ha t prov i de s bu si nes s va l ue i s deve l oped f ir s t. R el eas e s of t he s ys t e m a r e fr equen t and i nc r e m en t a ll y a dd f unc ti ona lit y t o t h e fi r st r e l ea s e. Sim pl e De si gn E nough de si gn i s ca rri ed ou t to m ee t t he cu rr en t r equ ir e m en t s and no m o r e. T es t f ir s t deve l op m en t An au t o m a t ed un it t es t f r a m ewo r k is u s ed t o w r i te t e s t s f o r a new p i ece o f f unc ti ona lit y be f o r e t ha t fun ct ion a l it y it se lf is im p l e m en t ed . R e fa c to ri ng A ll d e ve l ope r s a r e expe c t e d t o re f ac t o r t h e code con ti nuous l y as soon a s po s s i b l e code im p r ove m en t s a r e f ound . T h i s keeps t he code s im p l e and m a i n t a i n a bl e .

  46. Extreme programming practices P a ir Pr ogra mmi ng Deve l op e r s wo r k i n pa ir s , che c king ea c h o t he r Õ s w ork and p r ov i ding t he suppo rt t o a l w ays do a good j ob . Co ll e c t i ve Owne rs hip T he pa ir s o f deve l op e r s wo r k on a ll a re a s of t he s ys t e m, s o t ha t no i sl ands o f expe rti s e deve l op and al l t he deve l ope r s own a ll t he code . Anyon e c a n chang e any t h i ng . Con ti nuou s I n t egr at ion A s s oon a s wo r k on a t ask i s co m pl et e it i s i n t eg r a t ed i n t o t he who l e sy st e m . Af t e r any s uch i n t eg r a ti on , a ll t h e un it t e st s i n t he sy st e m m u st pa s s . S us t a i nab le pac e L arg e a m oun ts o f ove r-t i me a r e not con s id e r e d ac c ep t ab l e a s t he ne t ef f ec t i s of t en t o r educ e code qua lit y a nd m ed i u m t e rm p r oduc ti v i ty On - s it e Cu s to m e r A rep r e s en t a ti ve of t he end - u s er o f t he sy s t em (t he C us t o m e r ) shou l d be ava il ab l e f u ll tim e fo r th e u s e o f t h e X P te a m . In an ex tr e m e prog r a mmi ng p r oce s s , t he cus t o m e r is a m e m be r o f th e deve l op m en t t ea m a nd i s r espon si b l e f or b ri nging sy st e m r equ i r e m e n t s to t he te a m f or im p l e m en t a ti on.

  47. XP and agile principles • Incremental development is supported through small, frequent system releases. • Customer involvement means full-time customer engagement with the team. • People not process through pair programming, collective ownership and a process that avoids long working hours. • Change supported through regular system releases. • Maintaining simplicity through constant refactoring of code.

More Related