1 / 48

CS 551 Development Process

CS 551 Development Process. Revision 1. Organizational Structure. SYSTEM BASELINE REQUIREMENTS ALGORITHMS. FEATURE ENGINEERING. SOFTWARE DEVELOPMENT. SOFTWARE MANUFACTURING. ARCHITECTURE ENGINEERING. INTEGRATION. HUMAN FACTORS DEVELOPMENT. TO SITES. TRAFFIC ENGINEERING.

maura
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 Revision 1

  2. 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

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

  4. 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

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

  6. 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

  7. As of 18 Oct 07 MeasurableOperational Value

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

  9. CS SENIOR DESIGN CITIGROUP PROJECT

  10. CS SENIOR DESIGN CITIGROUP PHASES

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

  12. <<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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

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

  19. Development Plan-an evolving document • Name of Project (issue 1 due November 23) • Purpose and MOV • Team members, their roles, management plan, QA, ease of use, coding standards • Gantt Chart • Current Estimate Table • QFD • ICED-T

  20. 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

  21. Role of Testers • Restates Requirements quantitatively and from a test view-see PDF “In Other Words” • Creates test bed for developers • Designs and executes: • Scenario Tests from Use Cases • Integration Tests • Reliability Tests • Stress Tests

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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

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

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

  29. 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

  30. 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.

  31. 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.

  32. 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

  33. 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.

  34. 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.

  35. 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

  36. 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 .

  37. 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.

  38. 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.

  39. Testing in XP • Test-first development. • Incremental test development from scenarios. • User involvement in test development and validation. • Automated test harnesses are used to run all component tests each time that a new release is built.

  40. Pair programming • In XP, programmers work in pairs, sitting together to develop code. • This helps develop common ownership of code and spreads knowledge across the team. • It serves as an informal review process as each line of code is looked at by more than 1 person. • It encourages refactoring as the whole team can benefit from this. • Measurements suggest that development productivity with pair programming is similar to that of two people working independently.

  41. Agile Practices for Distributed Teams • Cohesive components with interface structures • XP for small development teams • Scrum as management structure • Frequent builds • Inter-team trust and work hour overlap • Experienced staff • Leverage collaborative tools – wikis, PM,… Ref: SD Times 15Oct07 pg 41

  42. COTS reuse • An effective approach to rapid development is to configure and link existing off the shelf systems. • For example, a requirements management system could be built by using: • A database to store requirements; • A word processor to capture requirements and format reports; • A spreadsheet for traceability management;

  43. Back-to-back testing Test data T System Application prototype system Results comparator Difference report

  44. - CODE - DOCUMENT - FIX BUGS Release Archives Base Libraries Software Factory DESIGNERS CONTROL PROGRAMS & PROCEDURES Reports Support Programs Change Management Tracking System Source Control Modification Requests Doc. Library Source Lib. Change Requests Released Product To Test Team Build System Shipping Utilities Released Product Application Files Middleware, Tools and Operating System To Sites

  45. Source Code Management • Store, update and retrieve all versions • Manage code ownership • Control updating privileges • Identify accurate version of retrieved source • Track changes • Maintain build database, tools and machine

  46. Release Flow DEVELOPMENT ENVIRONMENT EXECUTION ENVIRONMENT DEVELOPMENT SHOPS COMPONENT TEST MODULE A MODULE B MODULE C MODULE D • CODE • PROCEDURES • DOCUMENTATION SYSTEM INTEG. TEST SOFTWARE MANUFACTURING RELEASE PACKAGES SOFTWARE MANUFACTURING SITES COOPERATIVE TESTING N - 1 N MODIFICATION REQUEST (MR)

  47. Purpose of Release Documents • Describe features • Describe corrections to troubles • Cross reference software dependencies • Specify limitations or deficiencies • Provide special installation instructions and • provide data conversion instructions • Specify training • Identify new, changed or deleted documents • Provide software source code • Maintain product lists

  48. Software Change Cultural Technical Innovation & Investment Business

More Related