Presentation is loading. Please wait.

Presentation is loading. Please wait.

Ch. 71 The software production process. Ch. 72 Questions What is the life cycle of a software product? Why do we need software process models? What are.

Similar presentations

Presentation on theme: "Ch. 71 The software production process. Ch. 72 Questions What is the life cycle of a software product? Why do we need software process models? What are."— Presentation transcript:

1 Ch. 71 The software production process

2 Ch. 72 Questions What is the life cycle of a software product? Why do we need software process models? What are the goals of a software process and what makes it different from other industrial processes?

3 Ch. 73 Outline Traditional answer: "waterfall" lifecycles Flexible, incremental processes Case studies –"synchronize-and-stabilize" (Microsoft) –the "open source" development model Organizing the process –software methodologies –the "Unified Process" Organizing artifacts: configuration management Standards

4 Ch. 74 Life cycle The life cycle of a software product –from inception of an idea for a product through requirements gathering and analysis architecture design and specification coding and testing delivery and deployment maintenance and evolution retirement

5 Ch. 75 Software process model Attempt to organize the software life cycle by defining activities involved in software production order of activities and their relationships Goals of a software process –standardization, predictability, productivity, high product quality, ability to plan time and budget requirements

6 Ch. 76 Code&Fix The earliest approach Write code Fix it to eliminate any errors that have been detected, to enhance existing functionality, or to add new features Source of difficulties and deficiencies –impossible to predict –impossible to manage

7 Ch. 77 Models are needed Symptoms of inadequacy: the software crisis –scheduled time and cost exceeded –user expectations not met –poor quality The size and economic value of software applications required appropriate "process models"

8 Ch. 78 Process model goals (B. Boehm 1988) "determine the order of stages involved in software development and evolution, and to establish the transition criteria for progressing from one stage to the next. These include completion criteria for the current stage plus choice criteria and entrance criteria for the next stage. Thus a process model addresses the following software project questions: What shall we do next? How long shall we continue to do it?"

9 Ch. 79 Process as a "black box"

10 Ch. 710 Problems The assumption is that requirements can be fully understood prior to development Interaction with the customer occurs only at the beginning (requirements) and end (after delivery) Unfortunately the assumption almost never holds

11 Ch. 711 Process as a "white box"

12 Ch. 712 Advantages Reduce risks by improving visibility Allow project changes as the project progresses –based on feedback from the customer

13 Ch. 713 The main activities They must be performed independently of the model The model simply affects the flow among activities

14 Ch. 714 Feasibility study Why a new project? –cost/benefits tradeoffs –buy vs make Requires to perform preliminary requirements analysis Produces a Feasibility Study Document 1.Definition of the problem 2.Alternative solutions and their expected benefits 3.Required resources, costs, and delivery dates in each proposed alternative solution

15 Ch. 715 Requirements engineering activities

16 Ch. 716 Requirements engineering Involves –eliciting –understanding –analyzing –specifying Focus on –what qualities are needed, NOT on –how to achieve them

17 Ch. 717 What is needed Understand interface between the application and the external world Understand the application domain Identify the main stakeholders and understand expectations –different stakeholders have different viewpoints –software engineer must integrate and reconcile them

18 Ch. 718 The requirements specification document (1) Provides a specification for the interface between the application and the external world –defines the qualities to be met Has its own qualities –understandable, precise, complete, consistent, unambiguous, easily modifiable

19 Ch. 719 The requirements specification document (2) Must be analyzed and confirmed by the stakeholders –may even include version 0 of user manual May be accompanied by the system test plan document

20 Ch. 720 The requirements specification document (3) As any large document, it must be modular –"vertical" modularity the usual decomposition, which may be hierarchical –"horizontal" modularity different viewpoints Defines both functional and non functional requirements

21 Ch. 721 A case study railway automation Who are the stakeholders? –management of the train company –train drivers and their unions –passengers (customers) –contractors Each has different goals

22 Ch. 722 Case study how to classify requirements Safety requirements –the probability of accidents should be less than 10 -9 per year Utility requirements –level of usefulness of the system as perceived by the various stakeholders

23 Ch. 723 Case study the produced document Introduction: the “mission” of the system Architecture: the main structure of the system Specific requirements associated with each subsystem –discussion of how the subsystems’ requirements guarantee that the overall goals are indeed achieved

24 Ch. 724 Software architecture and detailed design activity The result of this activity is a Design Specification Document Usually follows a company standard, which may include a standard notation, such as UML

25 Ch. 725 Coding and module testing activity Company wide standards often followed for coding style Module testing –based on black box/white box criteria

26 Ch. 726 Integration and system test activity These activities may be integrated with coding and module testing Integration may be done incrementally through subsystems –top down vs. bottom up The last step is system test –may be followed by alpha testing

27 Ch. 727 Delivery, deployment, and maintenance activities Delivery –real delivery may be preceded by beta testing Deployment –components allocated on physical architecture Maintenance –corrective, adaptive, perfective

28 Ch. 728 Maintenance Requirements errors are main cause of maintenance activities Late discovery of requirements errors causes increased costs

29 Ch. 729 Other software activities Documentation Verification Management They can be considered as parts of any kind of software related activity

30 Ch. 730 Overview of software process models

31 Ch. 731 Waterfall models (1) Invented in the late 1950s for large air defense systems, popularized in the 1970s They organize activities in a sequential flow Exist in many variants, all sharing sequential flow style

32 Ch. 732 A waterfall model

33 Ch. 733 Waterfall models (2) Organizations adopting them standardize the outputs of the various phases (deliverables) May also prescribe methods to follow in each phase –organization of methods in frameworks often called methodology Example: Military Standard (MIL-STD- 2167)

34 Ch. 734 Critical evaluation of the waterfall model +sw process subject to discipline, planning, and management +postpone implementation to after understanding objectives –linear, rigid, monolithic no feedback no parallelism a single delivery date

35 Ch. 735 Waterfall with feedback

36 Ch. 736 Problems with waterfall Estimates made when limited knowledge available Difficult to gather all requirements once and for all –users may not know what they want –requirements cannot be frozen

37 Ch. 737 Evolutionary models Many variants available Product development evolves through increments –"do it twice" (F. Brooks, 1995) –evolutionary prototype Evolutionary process model (B. Boehm, 1988) "model whose stages consist of expanding increments of an operational software product, with the direction of evolution being determined by operational experience"

38 Ch. 738 Incremental delivery Identify self-contained functional units that may be delivered to customers To get early feedback –According to T. Gilb, 1988: Deliver something to the real user Measure the added value to the user in all critical dimensions Adjust design and objectives

39 Ch. 739 Transformation model Guided by formal methods Specifications transformed into implementations via transformations Still a theoretical reference model

40 Ch. 740 Transformation model

41 Ch. 741 Spiral model B. Boehm, 1989

42 Ch. 742 A final model assessment(1) Waterfall –document driven Transformational –specification driven Spiral –risk driven

43 Ch. 743 A final model assessment(2) Flexibility needed to reduce risks –misunderstandings in requirements –unacceptable time to market Waterfall may be useful as a reference structure for documentation –describes the "rationale" a posteriori (Parnas and Clements, 1989)

44 Ch. 744 Legacy software

45 Ch. 745 Software evolution Existing software must evolve because requirements change Re-engineering –process through which an existing system undergoes an alteration, to be reconstituted in a new form Reverse engineering –from an existing system to its documentation, which may not exist, or may be incomplete –includes program understanding –preventive maintenance

46 Ch. 746 Case study Synchronize&Stabilize (The Microsoft Software Process)

47 Ch. 747 The process Planning phase –vision of the product, specification, schedule Development –team composed of 2 groups developers and testers (continuous testing) –process prescribes daily synchronization product stabilization

48 Ch. 748 Case study The Open Source Approach

49 Ch. 749 Open source Regulates licensed software, specifying its use, copy, modification, and distribution rights Business does not derive from selling software, but rather from other, indirect activities (services, accessories, advertisement, etc.)

50 Ch. 750 The process Highly distributed process characterized by frequent iterations –wide availability of source code –openness to contributions from a large community of developers Enabling technology –Internet (large scale and fast collaborations) –repositories with version control and configuration management

51 Ch. 751 Methodologies to organize the process

52 Ch. 752 SA/SD Structured Analysis/Structured Design 3 major conceptual tools for modeling –data flow diagrams functional specifications –data dictionaries centralized definitions –Structured English to describe transformation of terminal bubbles

53 Ch. 753 DFDs: a reminder

54 Ch. 754 Analysis of office work

55 Ch. 755 Automated portion

56 Ch. 756 From analysis to design Use of Structured Diagrams (SDs) A "method" is provided to transform DFDs into SDs; tries to –minimize coupling –maximize cohesion

57 Ch. 757 SD A DAG of functional modules (direction of arrow is implicitly downward)

58 Ch. 758 Decorated SDs M MM 12 A B C selection loop data flow X

59 Ch. 759 Decorated SDs M 1 abstract input M 2 transformation M 3 abstract output

60 Ch. 760 SD for the "order" DFD

61 Ch. 761 JSD and JSP Jackson's System Development –modeling stage analysis and modeling of the external world –entities –actions (described by process structure diagram) –network stage system modeled as a network of interconnected and communicating processes— system specification network (SSN) –implementation stage

62 Ch. 762 A DCB (a) X Y * (c) H L M o o (b) PSD (a) sequence (b) selection (c) iteration

63 Ch. 763 (a) Processes connected by data structure P Q Q' P' (b) Connection by state vector A A' Network stage (SSNs)

64 Ch. 764 Implementation stage (JSP) Input and output data structures Correspondence between nodes Program structure

65 Ch. 765 Program Generate header Generate body Generate * line by item group Process item group Output net movement line Process record * Process receipt o Process delivery o 1. open files 2. close files 3. read (item_id, movement) 4. net_item_movement := 0 5. net_movement_item := net_movement_item + movement 6. net_movement_item := net_movement_item - movement 7. write (header) 8. write (net_item_movement_line) The resulting program structure

66 Ch. 766 Annotated program structure Trivially translatable into a program

67 Ch. 767 Unified Software Development Process (UP)

68 Ch. 768 Principles Development of an OO system Uses the UML notation throughout the process Supports an iterative and incremental process Decomposes a large process into controlled iterations (mini projects)

69 Ch. 769 Cycles and phases of a cycle milestone product release Inception Elaboration Construction Transition

70 Ch. 770 Distribution of workflows over phases

71 Ch. 771 Organizing artifacts Configuration management

72 Ch. 772 CM concepts Configuration –identifies components and their versions Configuration management –discipline of coordinating software development and controlling the change and evolution of software products and components

73 Ch. 773 Key CM issues Multiple access to shared repository Handling product families –different members of the family comprise components which may have different versions

74 Ch. 774 Member 1 A B C1 Member 2 A B C2 Member 3 A D 1 2 3 A A B D E A C C 1 1 2 2 3 Component database

75 Ch. 775 Baseline and private workspaces Project baseline –central repository of reviewed and approved artifacts that represent a given stable point in system development Private workspaces –private and intermediate versions of components

76 Ch. 776 Versions Can be refined into –revisions new version supersedes the previous define a linear order –variants e.g., alternative implementations of the same specification for different machines, or access to different I/O devices

77 Ch. 777 Derived versions Further logical relations may exist among versions of components A component may be derived from another –object code component is a derived version of a source code component

78 Ch. 778 Software standards

79 Ch. 779 Why standards? They are needed to achieve quality in both software products and processes They may be imposed internally or externally –e.g., MIL-STD 2167A imposed to contractors for military applications Other examples: ISO series, IEEE

80 Ch. 780 Main benefits From the developers' viewpoint –standards enforce a uniform behavior within an organization –they facilitate communication among people, stabilizes the production process, and makes it easier to add new people to ongoing projects From the customers' viewpoint –they make it easier to assess the progress and quality of results –they reduce the strict dependency of customers on specific contractors

81 Ch. 781 Issues with standards Freezing premature standards –can inhibit acceptance of new ideas Standards proliferation De-facto standards vs. official standards

Download ppt "Ch. 71 The software production process. Ch. 72 Questions What is the life cycle of a software product? Why do we need software process models? What are."

Similar presentations

Ads by Google