Скачать презентацию The software production process Ch 7 1 Скачать презентацию The software production process Ch 7 1

2d50ac636ba41128070bbd7f89fc3f7d.ppt

  • Количество слайдов: 81

The software production process Ch. 7 1 The software production process Ch. 7 1

Questions • What is the life cycle of a software product? • Why do 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? Ch. 7 2

Outline • Traditional answer: 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 Ch. 7 3

Life cycle • The life cycle of a software product – from inception of 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 Ch. 7 4

Software process model • Attempt to organize the software life cycle by • defining 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 Ch. 7 5

Code&Fix The earliest approach • Write code • Fix it to eliminate any errors 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 Ch. 7 6

Models are needed • Symptoms of inadequacy: the software crisis – scheduled time and 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" Ch. 7 7

Process model goals (B. Boehm 1988) 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? " Ch. 7 8

Process as a Process as a "black box" Ch. 7 9

Problems • The assumption is that requirements can be fully understood prior to development 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 Ch. 7 10

Process as a Process as a "white box" Ch. 7 11

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

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

Feasibility study • Why a new project? – cost/benefits tradeoffs – buy vs make 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 Ch. 7 14

Requirements engineering activities Ch. 7 15 Requirements engineering activities Ch. 7 15

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

What is needed • Understand interface between the application and the external world • 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 Ch. 7 17

The requirements specification document (1) • Provides a specification for the interface between the 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 Ch. 7 18

The requirements specification document (2) • Must be analyzed and confirmed by the stakeholders 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 Ch. 7 19

The requirements specification document (3) • As any large document, it must be modular 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 Ch. 7 20

A case study railway automation • Who are the stakeholders? – management of the 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 Ch. 7 21

Case study how to classify requirements • Safety requirements – the probability of accidents 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 Ch. 7 22

Case study the produced document • Introduction: the “mission” of the system • Architecture: 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 Ch. 7 23

Software architecture and detailed design activity • The result of this activity is a 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 Ch. 7 24

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

Integration and system test activity • These activities may be integrated with coding and 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 Ch. 7 26

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

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

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

Overview of software process models Ch. 7 30 Overview of software process models Ch. 7 30

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

A waterfall model Ch. 7 32 A waterfall model Ch. 7 32

Waterfall models (2) • Organizations adopting them standardize the outputs of the various phases 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) Ch. 7 33

Critical evaluation of the waterfall model + sw process subject to discipline, planning, and 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 Ch. 7 34

Waterfall with feedback Ch. 7 35 Waterfall with feedback Ch. 7 35

Problems with waterfall • Estimates made when limited knowledge available • Difficult to gather 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 Ch. 7 36

Evolutionary models • Many variants available • Product development evolves through increments – 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" Ch. 7 37

Incremental delivery • Identify self-contained functional units that may be delivered to customers • 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 Ch. 7 38

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

Transformation model Ch. 7 40 Transformation model Ch. 7 40

Spiral model B. Boehm, 1989 Ch. 7 41 Spiral model B. Boehm, 1989 Ch. 7 41

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

A final model assessment(2) • Flexibility needed to reduce risks – misunderstandings in requirements 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) Ch. 7 43

Legacy software Ch. 7 44 Legacy software Ch. 7 44

Software evolution • Existing software must evolve because requirements change • Re-engineering – process 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 Ch. 7 45

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

The process • Planning phase – vision of the product, specification, schedule • Development 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 Ch. 7 47

Case study The Open Source Approach Ch. 7 48 Case study The Open Source Approach Ch. 7 48

Open source • Regulates licensed software, specifying its use, copy, modification, and distribution rights 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. ) Ch. 7 49

The process • Highly distributed process characterized by frequent iterations – wide availability of 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 Ch. 7 50

Methodologies to organize the process Ch. 7 51 Methodologies to organize the process Ch. 7 51

SA/SD • Structured Analysis/Structured Design • 3 major conceptual tools for modeling – data 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 Ch. 7 52

DFDs: a reminder Ch. 7 53 DFDs: a reminder Ch. 7 53

Analysis of office work Ch. 7 54 Analysis of office work Ch. 7 54

Automated portion Ch. 7 55 Automated portion Ch. 7 55

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

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

Decorated SDs selection loop data flow M X B C A M 1 M Decorated SDs selection loop data flow M X B C A M 1 M 2 Ch. 7 58

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

SD for the SD for the "order" DFD Ch. 7 60

JSD and JSP • Jackson's System Development – modeling stage • analysis and modeling 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 Ch. 7 61

A B PSD (a) sequence (b) selection (c) iteration C D (a) X H A B PSD (a) sequence (b) selection (c) iteration C D (a) X H * Y o o M L (c) (b) Ch. 7 62

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

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

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

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

Unified Software Development Process (UP) Ch. 7 67 Unified Software Development Process (UP) Ch. 7 67

Principles • Development of an OO system • Uses the UML notation throughout the 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) Ch. 7 68

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

Distribution of workflows over phases Ch. 7 70 Distribution of workflows over phases Ch. 7 70

Organizing artifacts Configuration management Ch. 7 71 Organizing artifacts Configuration management Ch. 7 71

CM concepts • Configuration – identifies components and their versions • Configuration management – 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 Ch. 7 72

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

Component database Member 1 A C 1 D B E A 2 A C Component database Member 1 A C 1 D B E A 2 A C 1 1 C B 3 2 Member 2 A 2 Member 3 B C 2 A 3 D Ch. 7 74

Baseline and private workspaces • Project baseline – central repository of reviewed and approved 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 Ch. 7 75

Versions • Can be refined into – revisions • new version supersedes the previous 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 Ch. 7 76

Derived versions • Further logical relations may exist among versions of components • A 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 Ch. 7 77

Software standards Ch. 7 78 Software standards Ch. 7 78

Why standards? • They are needed to achieve quality in both software products and 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 2167 A imposed to contractors for military applications • Other examples: ISO series, IEEE Ch. 7 79

Main benefits • From the developers' viewpoint – standards enforce a uniform behavior within 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 Ch. 7 80

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