CSE 784 Software Studio class notes Chapter 6

CSE 784 Software Studio class notes Chapter 6 Software Development Process Models Jim Fawcett copyright (c) 1994 - 2002 Chapter 6 - Process Models

Model Definitions · Model: A representation of the most essential features of a physical object or process used as a pattern for reasoning about, analyzing, or predicting behavior · Abstract Model: A model with no concrete instances, e. g. , a metamodel, or model of a model, used to reason about models. · Software Development Model: A model of the phases, activities, products, and roles of people involved with the development of software. · Software Computation Model (Component Model): A model of the structure, behavior, and dependencies of a software component. – Logical Model (Process Model): A computational model which focuses on processing to be done and the information necessary to do it. – Physical Model (Structural Model): A computational model which focuses on structural and data dependencies of a software product, including source code which implements its design. Chapter 6 - Process Models

Software Computational Models · Computational models describe structure, behavior, and dependencies of software components. They enable us to reason about and predict the behavior of software systems and their components. · Without computational models, large-scale software development would be virtually impossible. We need the abstractions provided by computational models to understand how these large systems are supposed to work. · We use these models when we write requirements specifications and conduct design reviews. Chapter 6 - Process Models

Computational Model Views · A computational model represents the processing, data, and physical structure of a software component. Each component level - function, class, module, program, software system - can be described in different ways: Logical Model - applies to all levels – client’s view of component’s operation – capsule summary of key features and functions · Process Model - for modules, programs, systems – major partitions of processing and data flow between them, shown by DFDs, Data dictionary. – logical and requirements model for each process captured by Pspecs. · Structural Model - for modules, programs, systems – data, control, and timing dependencies on outside environment shown by context diagram, performance requirements. – major partitions captured by a module diagram. – data, processing, control, and timing dependencies between partitions shown by structure chart, class hierarchy diagram, state transition diagram, critical threads, performance requirement flow-downs. · Implementation Model - applies to all levels – brief logical model for each component in prologue – description of algorithms and data structures used to build component – list of all components in the physical software – source code for each component Chapter 6 - Process Models

SW Product Model · Architecture – defines product components and allocates processing to them – defines external product behavior · Requirements Specification – describes what constitutes correct operation – it is the basis for testing and evaluation · Product Specification – defines an architecture for the system – describes software design and implementation – specifies a software build process · Test Plan – defines procedures for unit, integration, validation, qualification, and regression testing – qualification test procedures are emphasized · Prototype Code – verifies design for critical processing, analyzes implementation problems as they arise · Product Code – Code for each component of the product, implemented as software modules. – test stub attached to each module, used to establish basic software cycling and nearly correct operation · Test Code – test drivers for unit and qualification tests · Test Report Chapter 6 - Process Models

Relating Computational models to Software Product · Architectural Model - concept document – · Requirements Model - A and B level specifications – – · process model which represents what system is obligated to do must be complete, unambiguous, and succinct strictly tied to the application domain, ignores solution domain requirements modeling is a decomposition process Design Model - C level specification – – – · logical and structural model which discloses the systems organizing principles, major processes, and critical design issues structural and implementation model shows how system works focused mostly on the solution domain design is initially a top-down decomposition followed by recomposition, that is, construction of a solution from a series of components Component Models to support Reuse – – – manual pages and design notes show each module provides its services prologues provide a flow down of process obligations which enable orderly code inspection and unit testing prologues state assumed preconditions and post conditions which result from the components activities prologues, pseudo code, and source code show the solution works at the most detailed level each component is part of a solution to an application need, tested independently and then integrated Chapter 6 - Process Models

Software Development Models • A software development model is concerned with the phases, activities, products, and roles of people involved in the development of software. • Production of large scale software is a complex endeavor: – scores of documents are produced – code is written, not only for the application, but also to prototype new ideas, support various hardware and software test phases, and for managing software builds – many reviews are held internally with the development team and for the customer – enormous amounts of data are collected, used to manage the development and keep developers and customer apprised of the program’s status • Models are an essential part of that process, used to guide developers in their day-to-day activities, keep the program focused on its principle objectives, and promote communication through the use of standardized documentation and reviews. Chapter 6 - Process Models

SW Process Model (Focus on Development Process) · Requirements Analysis – – · define what the system must do define architecture build a requirements model review requirements specifications with customer Design and Unit Test – define how the system will met requirements – define structure, e. g. , modules, classes, functions – build and test each module by populating with functions and classes · Integration – integrate modules and test – carry out performance, validation, and stress tests · Qualification – legal demonstration that developer’s obligations have been met, e. g. , the system meets customer’s require-ments · Audits – Functional Configuration Audit (FCA) showing that contracting office and contractor have been successful producing a working product – Physical Configuration Audit (PCA) showing that contractor and contracting office have supplied all purchased components to the end user Chapter 6 - Process Models

Waterfall Development Model A software development process which proceeds linearly in time through the phases: – Specification analysis: analyzing what software must do and writing contractual requirements documents to specify resulting functional behavior and performance. – Design: developing a physical structure for software by partitioning into modules, classes, and functions, and defining the processing necessary for each. Each module, class, and function has a prologue which flows down software processing requirements to that level. – Code and unit test: writing source code for functions, classes, and modules, and compilation with test drivers to verify that each component satisfies the processing requirements flowed down to it. – Integration testing: building software execution images which progressively combine more modules, providing incremental capability, until the entire product has been assembled and is functioning. When integration begins many modules are likely to have errors since only unit testing has been conducted. – Qualification testing: a step by step process of verifying that each requirement identified in the requirements specification has been met. Requirements Analysis design code and Unit Test integration test Qualification Test Chapter 6 - Process Models

Waterfall Development Roles · Software Product Manager – Responsible for software cost and schedule – Has ultimate authority on all software development decisions – Depends on Architect, Test Manager, and Team Leaders to implement his decisions. · Software Architect – Responsible for top-level software partitioning, defining user interfaces – Manages interfaces between software developed by each team – Is the source of knowledge on how the system works · Test Manager – Responsible for Test Plan and Qualification – Develops, with the test team, test descriptions and procedures, usually by assigning to the individual teams for elaboration – Conducts the Test Readiness Review and Qualification Test Chapter 6 - Process Models

Waterfall Development Roles · Team Leader – Responsible for one subsystem – may be a single module or a family of modules. – Responsible for production of B and C specifications for his team’s software. • Presents his B-specification at the SSR (see formal reviews slide). • Usually delegates C Specification development to his team members. – Reponsible, with the other team leaders, for software integration. Integration process is usually organized by the Software Architect or Test Manager. – Responsible to fully support Test Manager for the team’s part of the system, including production of Test Descriptions, Test Procedures, and test conduct. · Team Members – Responsible for their assigned part of the teams CSpecification, code, and unit test. – Usually present at the PDR and CDR (see formal reviews slide). · Quality Assurance – Responsible for continuing assessment of the software quality. – Reports to the Program Manager. Chapter 6 - Process Models

Breaking Down and Building Up · Software requirements analysis and preliminary design is a process of breaking down or decomposition in the application domain: – – – · application requirements are decomposed to processes and data flows each process is allocated part of the requirements model and may derive additional requirements necessary to complete or disambiguate its process model a design structure is developed by associating major process blocks with modules - to be composed of func-tions and classes each stage of the decomposition needs to allocate requirements to its component parts, otherwise there is no basis for deciding the correctness of the design at the lowest component level requirements are specified as preconditions assumed to hold for the component, processing the component must perform on its input data, and post conditions which the processing must guarantee. Detailed design and testing is a process of building up or recomposition in the solution domain: – – – function and class development builds a language into which the applications processing is encoded each function and class is tested for conformance to its process model. new functions and classes are added to satisfy the process model of the module in which they are embedded modules are populated in order of their dependencies and used to progressively build system capability this process continues until all system requirements are met and tested. Chapter 6 - Process Models

Breaking Down, Building Up A-Specification logical behavioral model of software system Architectural Concept organizing principles high level structure design issues decomposition in application domain B-Specification C-Specification recomposition in solution domain logical models of major processing components with data flows logical process models --> logical modules --> functions, classes --> physical modules Integration & Test physical modules --> physical programs --> physical system Qualification Test logical behavioral model of software system Chapter 6 - Process Models

Waterfall Model – Customer Reviews · Requirements Analysis: – Software Specification Review (SSR) presents - · Architecture B-Spec = DFDs + HIPOs + Data Dict + RTM derived requirements and design and issues Design: – Preliminary Design Review (PDR) presents - Module structure - Prelim C-Specs = Mod. Cht + Str. Chts + Class Structures + HIPOs - resolution of design and requirements issues - derived requirements, design and test issues – Critical Design Review (CDR) presents - C-Specs = Mod. Cht + Str. Chts + Hdrs + STDs + HIPOs + Pseudo Code - resolution of design and test issues · Code and Unit Test: – informal code walkthroughs and inspections · Integration Testing: – Test Readiness Review (TRR) presents - major test groups - test procedures - test equipment, environment Chapter 6 - Process Models

Customer Reviews (continued) · Qualification Testing: – formal, step-by-step, proof that system meets A and B level specification requirements - demonstration: run software and observe programmed responses which verify requirements - test: instrument software to develop logged data, examine off-line to verify requirements - analysis: show by models, calculation, reference to past data, or other deductive means that the implementation will satisfy requirements - inspection: examine source code, development files, documentation to show that requirements have been satisfied · Audits: – Functional Configuration Audit (FCA) an Audit of both contracting office and contractor by outside agency to verify that contractual obligations have been met. Includes specification and test report reviews. – Physical Configuration Audit (PCA) an Audit of both contracting office and contractor by outside agency to verify that all the component parts purchased by the contract are in fact the ones tested and delivered. Chapter 6 - Process Models

Waterfall Model Products · Specification analysis: – operational concept document (OCD) – B level software requirements specification (SRS) – allocated baseline · Design: – – – – · software test plan software test descriptions database design document (DDD) C level software design document (SDD) also called a C-spec software development files computer resources integrated support document (CRISD) development baseline Code and unit test: – test procedures – source code – development baseline · Integration testing: – software test procedures – test readiness review · Qualification testing: – – software test report (STR) software product specification (SRS, SDD, code, STR) version description document (VDD) computer system operators manual (CSOM) Chapter 6 - Process Models

Waterfall Model Summary · The waterfall model does a good job of capturing the essentials of a large software development process: – activities required – roles of specific project personnel – products generated · It does not do a very good job of accounting for many realities of the development process: – Need for constant change due to: • • • requirement errors design errors Implementation errors performance deficits accommodation of changes in another part of the system – Need to carefully control change. – Discovery of unforeseen risks. – Uncertainty in scheduling work that the team has not done before, e. g. , design and development using unfamiliar technology or new platforms. · This failing of the waterfall model has prompted the development of several new variations on the waterfall theme. – – – Incremental Development Spiral model Design by Contract Extreme Programming Amalgams of two or more of these. Chapter 6 - Process Models

Capability Maturity Model (CMM) · Formalized, under Do. D funding, by the Software Engineering Institute, Carnegie Mellon University, it describes software development processes in terms of five levels: – Level 1 - Initial Ad hoc process, unpredictable results. Key process areas: • none – Level 2 - Repeatable Disciplined process using standard management principles. Key Process Areas: • • • requirements management project planning project tracking and oversight configuration management quality assurance – Level 3 - Defined Standard process applied consistently across organization. – Level 4 - Managed Predictable process using metrics gathered as part of the applied process. – Level 5 - Optimizing Continuously improving process with a mandated process for defect prevention. · References: – The Capability Maturity Model, Software Engineering Institute, Addison Wesley, 1994 – Process Improvement for Small Organizations, Kelly & Culleton, IEEE Computer, October 1999 Chapter 6 - Process Models

Variations on the Development Model · Incremental Development Model – Partitions development into modules, implementing in order of dependency, so that as each is completed, we integrate only a small amount of newly developed code with an existing baseline. · Design by Contract – Espoused by Bertrand Meyers, an authority on Object Oriented Development – and creator of the Eiffel programming language. Attempts to support and enforce the use of contracts between users and suppliers of services. · Spiral Model – Attempts to control project risks by developing a series of prototypes with · Evolutionary Project Management, an Extension of the Spiral Model – Plans for frequent working deliveries to the customer with progressively increasing functionality, culminating in the final delivered product. – · · more functionality. At the end of each cycle, devise a plan, schedule, and budget for the next release. Emphasis on continuous testing. – Extreme Programming, an Extension of Evolutionary PM – Takes evolutionary programming to an extreme. – Requirements are based on user “stories”, e. g. , how I would use the product. – Customers decide when to release, but only when all tests pass. – We work until the money is gone. Microsoft Development Process – Segregate development organization into: • • • Top level product managers and system architects Project teams – each project creates a new version or a new feature. Each team consists of a project manager, developers, and testers Project manager is responsible for the specifications, schedule, and delivery. Developers are responsible for reviewing and criticizing the specification, developing product code, and fixing bugs found by the testers. Testers beat unmercifully on the developer’s code, hoping to find all visible and latent bugs. Chapter 6 - Process Models

Incremental Development Model Begins with requirements analysis and preliminary design just like the spiral model. As soon as modules are defined one is selected that has no dependencies on other modules (at least one almost always exists). This module’s development proceeds as with the spiral model, until unit test is completed. A regression (summary) level test is incorporated into the module’s source code as a test stub, and used to verify the module’s operation. Next a module is selected which depends at most on the completed module. It also is subjected to the spiral model process through integration test with the completed module. That is, detailed design, code and unit test, and integration test are all completed. This process continues until all the modules have been integrated. The development completes by carrying out qualification test to demonstrate that the software meets all its contractual obligations. Chapter 6 - Process Models

Incremental Development Requirements Analysis Preliminary Design --- Code & UT --- Design phases Integration Test correct code Code & UT partially tested code Integration Test partially tested code correct code Integration Test modules Qualification Test Chapter 6 - Process Models

Design by Contract · Design by Contract – A development process based on built-in test. – Uses assertion constructs to guarantee correctness · Pre-conditions: – Conditions which must be satisfied by the caller. These are assumptions the service supplier makes about the caller. These assumptions are EXPLICIT! – Pre-conditions are checked by the REQUIRES(bool) construct. · Post-conditions: – Conditions the service supplier guarantees to hold after delivery of the service, provided that the pre-conditions are met. – Post-conditions are checked by the ENSURE(bool) construct. · Invariants: – Invariants are conditions which must hold at the end of every service invocation. They define correctness for the module’s state. – Invariants are checked by the CHECK_INVARIANT construct. – Invariants are defined at the end of a class declaration with the syntax: INVARIANT invariant statements, e. g. : ASSERT(bool), IMPLIES(bool, bool), or BASE_INVARIANT(base class) END_INVARIANT Chapter 6 - Process Models

Spiral Model · · · The Spiral Development Model, developed by Barry Boehm of TRW, and used by that organization, and others starting in 1986. Development proceeds through several prototypes, culminating in the completed system. Each prototype is developed according to the waterfall model, e. g. through requirements analysis, code and unit test, integration, and system testing. Its intent is to deal effectively with the uncertainties and risks associated with a large new development. Chapter 6 - Process Models

Evolutionary Project Management · Plan for frequent deliveries of a production quality system that runs with growing functionality. · Goals: – budget cost and schedule for the complete project – divide the project into a series of small delivery cycles – focus on short-term, clear goals with a high expectation of meeting them – deliver fully tested, production-quality software with the right documentation at the end of each cycle – solicit feedback from customer, management at the end of every cycle – reassess objectives at the beginning of every cycle – estimate effort at the beginning of each cycle – make quality objectives part of the project requirements – conclude the project when the budgeted cost or schedule has been consumed or the customer contracts for further work. · Inspection process: – All deliverable items are inspected by the Project Manager and an inspection committee (of developers) using a walk-through process lead by the originator. – All defects are recorded. – The originator removes all defects and resubmits the item for inspection. The process repeats until the item meets or exceeds its planned levels of quality. · References: – Evolutionary Project Management, Woodward, IEEE Computer, October 1999 Chapter 6 - Process Models

Extreme Programming · Extreme Programming is a development process designed to develop high quality software using an incremental development process. – Requirements are based on User Stories, something like use cases, but developed by the customer. – Builds in small incremental stages, with each stage ending in a release of operational software to the customer. – Emphasizes a test-as-you-go process. – Software tests are designed before the production software, based on requirements. – As software is built it is continually tested. – The developer does not move on until all tests pass. – Assumes the use of a lot of automated testing. – No releases are made to the customer until all tests pass. · This process is very like the incremental development process I require of you, but with a more formal approach to testing. – Extreme Programming construction tests are close to full unit testing. Chapter 6 - Process Models

Extreme Programming · · · Planning Customers decide scope and time of releases based on estimates provided by developers. Only functionality demanded by customers is implemented in each iteration. Small Releases The system is put into production in a few months, before the whole is complete. New releases are made often, perhaps monthly. Simple Design - At every moment the design: – – · · · runs all tests communicates everything developers want to communicate contains no duplicate code has fewest possible classes and methods Tests - Developers write unit tests continuously. Tests are collected and must all run correctly. Customers write functional tests for the functionality in each release. These tests should also always run correctly. Refactoring Design of the system is evolved through transformations of the existing design that keep all tests running. Pair Programming All code is written by two people at one terminal. Just Rules Being part of the Extreme team you sign up to follow the rules. The team can change the rules at any time if there is consensus on how the effects of change will be measured References: – Embracing Change with Extreme Programming, Beck, IEEE Computer, October 1999. Chapter 6 - Process Models

Low-Level Process Models · The process models we have discussed so far attempt to describe the entire development process. – Waterfall, spiral, incremental, evolutionary · There are other important models that address smaller parts of the process, most notably the Design by Contract model. · Design by Contract addresses the detailed design and implementation phases of development. – Attempts to guarantee contracts between the user of a service and the provider of the service. – It does this by embedding assertions about preconditions and post-conditions. – A pre-condition is a condition required for the service to function correctly and users must guarantee that it holds, otherwise an exception is thrown. – A post-condition is a guarantee of delivery of some commodity in some state, provided that the precondition holds. Should the post condition fail to hold an exception is thrown. Chapter 6 - Process Models

Microsoft Development Process · Microsoft uses a process called “Synchronize and Stabilize”, developed in the late 80’s and early 90’s. – – – · · Goal is to balance almost hacker-like flexibility and speed with professional engineering discipline. Project begins with a vision of what the product is to do (jointly developed by marketing and the development team) Program manager develops a rough functional specification which the team evolves until end of the project. Schedule has a few stabilization points (milestones). Each has a list of prioritized features and represents progress after weeks of a development cycle: – · · · give designers lots of autonomy to evolve designs iteratively force the team to synchronize their work frequently periodically stabilize design changes and feature innovations design, code, usability test, daily builds Each milestone marks either an alpha (internal) or beta (external) release. Buffer time precedes each release. It is used to add new features In the final milestone the user interface is frozen. The team runs a final test, debugging, and stabilization sub-cycle and issues a final release. Only when the project is complete is the functional specification considered done. References: – Software Development on Internet Time, Cusumano & Yoffie, IEEE Computer, October 1999 Chapter 6 - Process Models

Microsoft Test Process · Testing starts with: – private builds by the individual developers – Buddy builds by the whole development team · As soon as the team releases a build, testers begin beating on build, based on: – Known bugs – Smart attempts to break code · · · Tester’s goals are to find the source of each known bug and find new bugs and their sources. They file bug reports which are assigned to the responsible developer to fix. Testers run Build Variation Tests (BVTs) continuously. – BVTs are automated, fast, but not too thorough. · · · Every night testers run stress tests Every 10 or 15 builds the testers run Functional Test suites which are much more thorough. As the product matures they run: – Long haul tests designed to find resource leaks – Performance tests – Security tests Chapter 6 - Process Models

Survival Guide – Integration Procedure Find these steps in the class text, page 203, Table 14 -1. · · · · · Developer develops a piece of code. Developer unit tests the code. Developer steps through every line of code, including all exception and error cases, in an interactive debugger. Developer integrates this preliminary code with a private version of the main build. Developer submits code for technical review. Developer informally turns code over to testing for test case preparation. Code is reviewed. Developer fixes any problems identified during the review. Fixes are reviewed. Developer integrates final code with the main build. Code is declared “complete” and can be checked off the project activity list. Chapter 6 - Process Models

Survival Guide – Daily Build Procedure · · · · The developer merges his code changes with the master source files, after checking for conflicts with recent changes made by other developers. He builds and tests a private release to ensure that the newly implemented features still works as expected. The developer runs the current smoke test against his private build to be sure the new code won’t break the build. The developer checks his private copies of the source code into the master source files. The build team generates a complete build of the software from the master sources. The build team runs the smoke test to evaluate whether the build is stable enough to be tested. If the build team discovers any errors that prevent the build from being tested (the build is broken), it notifies the developer who checked in the breaking code. That developer fixes the problem immediately. Fixing the build is the project’s top priority. Anyone who breaks the build becomes the project goat, and is put in charge of the build process until someone else breaks the build. Chapter 6 - Process Models

Configuration Management Configuration management is charged with controlling and providing access to the thousands of documents, code components, and project data items that are generated in a large software development program. Its obligations are: · Identification: Identify every version of every: – document, e. g. , specification, design , test, program memo, contract letter, . . . – product code component – support and test code component – project data Each is identified by number, date, and author or responsible individual. It then becomes a configur-ation item. · Baselining: A baseline is a snapshot of the development configuration (all the configuration items) at specific points in the development: – – – requirements baseline just before SSR design baseline just before PDR and again before CDR informal unit test baselines informal integration baselines integration test baseline just before TRR qualification test baseline just before FCA, PCA Each configuration item must be retrievable from any baseline at any time after the baseline has been constructed. Chapter 6 - Process Models

Configuration Management (continued) · Access Control: is intended to insure that all changes to a baseline are properly authorized, all builds have known components, and no baseline becomes corrupted. Access control depends on the type of baseline, e. g. : – formal baselines: The baseline created before each major review, e. g. , SSR, PDR, CDR, TRR, PCA are formal and require customer approval to change. – informal baselines: All other baselines require inter-nal approval for change, e. g. , the Software Project Manager or his agents, the librarian and team leaders. Control of the internal baseline is based on role models: – developer may have only read access – team leader has read and write access to the software components being developed by his team – librarian has read and write access to the entire internal baseline, but uses the access as directed by team leaders and the Software Project Manager – Software Project Manager has complete discretion over the internal baseline Chapter 6 - Process Models

Configuration Management (continued) · Association: The configuration management system must maintain associations between each component of a baseline for every version. The CM process must be able to answer the questions: – which components where used with any specific build of the hundreds of builds prepared during develop-ment? – which of the test data items came from any specific build? – what requirements where identified for a specific build? – what requirements, design, or implementation issues where unresolved for any specific build? – what changes in source code where made between any two builds? – what changes in a document where made between any two releases? · Build Control: The CM system must ensure that a “packing list” of software components is constructed for each build which identifies the specific versions used and test results obtained. The Software Project Manager and Customer must be confident that the version lists and result assoc-iations are accurate. Chapter 6 - Process Models

Configuration Management (continued) · CM Tools: Maintaining CM integrity requires: – use of database management tools for all but the smallest projects – build control using a testbed with: - command language batch automation - make files - structure libraries based on disk directories organized and access controlled by baseline - extensive requirements trace databases · Independent Validation and Verification (IV&V): Many contracts demand an IV&V process conducted by a third party (not customer and not developer). Its purpose is to measure and report on: – development process integrity – software quality IV&V activities are usually carried out by product sampling via inspections, participation in require-ments, design, code, and test walkthroughs, and through the evaluation of test plans and test data. Chapter 6 - Process Models

Development Model Summary The waterfall model defines all the major phases, activities, and products of any software development process. Its unilateral movement through the phases of development is not very realistic - there always cycles back to make changes and fix errors - but it serves well to define the basic development process. Some variation of the incremental model is probably the most used process in Software Engineering organizations that have a disciplined development process - not all do. The Spiral and Evolutionary Models have been used on small to medium scale programs with some success. Chapter 6 - Process Models

Development Model Summary · Waterfall Model – – assumes single pass through requirements analysis, design, code and unit test, and qualification. base on the house construction metaphor. - – – · more accurate than the waterfall, in that it recognizes the need for revision as the developer’s learn more about the system. Based on delivering a series of prototypes before a final version. Evolutionary and Extreme Programming – · brings only one partially tested component into a thoroughly tested baseline. Spiral Model – · The one pass model makes sense for building houses when the builder follows a standard process to construct a product just like millions of others already in existence. It just does not work well for “one of a kind” systems even if there is significant reuse of existing components. Incremental Model – · assumes the foundation (requirements) must be done perfectly assumes that framing (design) can only begin after the foundation is complete. that siding and interior (code and unit test) can’t be started until the frame is complete. assumes that final finish work (qualification) won’t affect any of the earlier work. There is a lot of current interest in these models. Successes have been reported on small to medium sized programs. Design by contract – as implemented with the Eiffel language, is being used in Europe, but not much use in this country. Chapter 6 - Process Models

SW Process Model · Requirements Analysis – – · define what the system must do define architecture build a requirements model review requirements specifications with customer Design and Unit Test – define how the system will met requirements – define structure, e. g. , modules, classes, functions – build and test each module by populating with functions and classes · Integration – integrate modules and test – carry out performance, validation, and stress tests · Qualification – legal demonstration that developer’s obligations have been met, e. g. , the system meets customer’s require-ments · Audits – Functional Configuration Audit (FCA) showing that contracting office and contractor have been successful producing a working product – Physical Configuration Audit (PCA) showing that contractor and contracting office have supplied all purchased components to the end user Chapter 6 - Process Models

SW Product Model · Architecture – defines product components and allocates processing to them – defines external product behavior · Requirements Specification – describes what constitutes correct operation – it is the basis for testing and evaluation · Product Specification – defines an architecture for the system – describes software design and implementation – specifies a software build process · Test Plan – defines procedures for unit, integration, validation, qualification, and regression testing – qualification test procedures are emphasized · Prototype Code – verifies design for critical processing, analyzes implementation problems as they arise · Product Code – Code for each component of the product, implemented as software modules. – test stub attached to each module, used to establish basic software cycling and nearly correct operation · Test Code – test drivers for unit and qualification tests · Test Report Chapter 6 - Process Models

Notable Quotes - Robert Martin · From Robert Martin, President of Object Mentor Inc. and former editor of the C++ Report: – “I’ve said it before, and I’ll say it again: The best process for developing software is the smallest process that we can get away with using. ” – “The best a process can hope to do is install the checkpoints and reviews needed to catch errors and stimulate project management decisions” · This overlooks the essential goals of: – establishing strong channels of communication – creating well understood allocations of responsibility – defining early all products needed to complete a project. However, I agree with his main point. Chapter 6 - Process Models

Notable Quotes - Fred Brooks · From Fred Brooks: – Former Chairman of the Computer Science Department, University of North Carolina – Former Program Manager, IBM System/360. – Former Program Manager, IBM OS/360. · “One occasionally reads newspaper accounts of how two programmers in a remodeled garage have built an important program that surpasses the best efforts of large teams. And every programmer is prepared to believe such tales, for he knows that he could build any program much faster than the 1000 statements/year reported for industrial teams. Why then have not all industrial programming teams been replaced by dedicated garage duos? One must look at what is being produced. ” · “Assuming that he has the disciplined, experienced architects and that there are many implementers, how shall the manager ensure that everyone hears, understands, and implements the architects decisions? How can a group of 10 architects maintain the conceptual integrity of a system which 1000 men are building? A whole technology for doing this was worked out for the System/360 hardware design effort, and it is equally applicable to software projects. ” Chapter 6 - Process Models