Скачать презентацию Lecture 1 Product and Process 1 1
e5b4584aad253f6e438b79e0e91157ce.ppt
- Количество слайдов: 96
Lecture 1: Product and Process 1
1. About our Product: Software 2
A Product is… Something being created n n by nature by humans by aliens …. The result of a process Something with an associated lifetime Something with an associated lifecycle 3
Product Characteristics Purpose Origin Speciality Environment Relationship to other products Market situation 4
Product Categories “Hardware” Products n n mostly manufacturing-driven slow evolution “Software” Products n n n mostly intellect-driven rapid evolution human factor 5
The Importance of Software Today, software is virtually everywhere Consider this: A laundry machine controller n n 10 years ago: A complex electro-mechanical sequencing device Today: A pre-programmed microcontroller 6
Implications (Again laundry machine microcontroller) Is it cheaper to produce: n n Today: Maybe Tomorrow: Yes Is it cheaper to maintain: Yes Is it more reliable: Probably yes 7
What Is Software? (1) Set of programs/documentation that direct computers to perform desired functions n n System software Utility software Application software … 8
What Is Software? (2) Software is a set of items or objects that form a “configuration” that includes: n n n programs documents data. . . 9
Software Characteristics (1) Software is engineered n n n engineering is an intellectual process engineering is a human-based process engineering needs a formal process framework Software does not wear out n n although it becomes obsolete and deteriorates due to maintenance no spare parts for software maintenance 10
Software Characteristics (2) Software is complex, and complexity is constantly increasing n n more dependence on others layers distribution evolving platforms. . . 11
Software Characteristics (3) Replacing a bad part by a good part may cause problems elsewhere n n n differences in style side effects. . . Software is like an aging factory 12
Failure Models (1) Hardware n Infant mortality w material defects w processing defects n n Reliable operation Wear out w material degradation w fatigue 13
Failure Models (2) Software n Design and/or implementation errors w multiple developers w process imperfections n Maintenance induced errors w incompatible corrections w undiscovered side effects n Technology aging 14
Failure Rates for HW & SW 15
Failure Rates for Software 16
The Cost of Change (1) Changes are expensive But not changing can be even more expensive A long and thorough design and engineering phase saves cost n n early changes are comparably inexpensive In-production changes are expensive and sometimes impossible 17
The Cost of Change (2) 18
Software Life Cycle Easier to fix mistakes Harder to fix mistakes (1) Specify requirements levels 1. Functional 2. Performance (time/space) 3. Implementation 4. Use 5. Maintenance Analyze requirements Design Implement Test Maintain 19
Software Life Cycle (2) Steps are not independent; process is not "linear” Some things to ponder: n n “Software crisis“ - systems become more and more complex What can we automate? How can we verify/ test such complex systems? Hardware / Software boundary 20
Software Classification 1 System software - compiler, editor, operating system, communication Real-time software - behaves time-predictable (monitor/control systems) Business software - MIS - payroll, accnt-rcv/pay, decision-making Engineering/scientific software - numerical analysis, CAD/CAP/CAM/CAE/CA. . . Embedded software - in ROM, “intelligent” devices (micro-oven, washing-machine, . . . ) Personal computer software - personal business, word processing, spreadsheets, games, . . . Artificial intelligence software - symbolic, expert systems, theorem proving, neural nets, . . . Internet applications - Web, Email, FTP, … 21
Why Software Engineering? (1) Software is not done on time Software does not have discipline rigor of HW analog n Cannot prove absence of errors – just presence when we find them Cost estimates are inaccurate Programmers’ productivity does not increase (fast enough) 22
Why Software Engineering? (2) Software is delivered with bugs n (There is always one more bug. (Murphy’s Laws)) Cost of software maintenance = 3/4 of total SW cost Software systems are more and more complex Delivered software does not satisfy users’ needs 23
Software Poses Challenges How do we ensure the quality of the software that we produce? How do we meet growing demand still maintain budget control? How do we upgrade an aging “software plant? ” How do we avoid disastrous time delays? How do we successfully institute new software technologies? 24
SW Myths - Management A good manager can manage any project We have, and use, standards and procedures We have state-of-the-art tools (computers) We can add more programmers to speed up SW development … 25
Myths - Customer Requirement details can be filled in later Requirement changes can be accommodated easily 26
Myths - Developer Coding is the main part of software development The only way to assess SW quality is through testing (after it is written) Working program is the only deliverable 27
Software Configuration Data Structures Working Program Plan Requirements Design Listing Test 28
What Is Engineering? Engineering (Webster): n n the science concerned with putting scientific knowledge to practical uses the planning, developing, construction or management of machinery, roads, bridges, buildings, etc. 29
What Is Software Engineering? Fritz Bauer: n The establishment and use of sound engineering principles in order to obtain economic software that is reliable and works efficiently on real machines. 30 (1)
What Is Software Engineering? (2) SE = methods + tools + procedures Methods: “how to’s” for project planning / estimation, system / software requirements analysis, program design, coding, testing, maintenance, documentation Tools: computer support for the above methods (CASE - integrated tools) Procedures: guidelines for sequencing the use of methods and tools, required deliverables, quality controls and milestones 31
What Is Software Engineering? Software Engineering is a collection of - techniques - analytical and quantitative methods - tools which help - the manager - the programmer - the engineer 32 (3)
What Is Software Engineering? to develop software that - performs according to specifications - is delivered on time has relatively low cost is reliable (almost no bugs) is easy to maintain is efficient 33 (4)
2. The Process 34
Software Engineering Paradigm: pattern, example or model Software engineering paradigm: “a set of steps that encompass methods, tools and procedures. ” 35
A Layered Technology Software Engineering tools methods process model a “quality” focus 36
Process = activity(ies) Control/ Constraints Inputs Process Outputs Resources IDEF 0/ICOM Modeling 37
A Common Process Framework Common process framework Framework activities work tasks work products milestones & deliverables QA checkpoints Umbrella Activities Software project management Formal technical reviews Software quality assurance Software configuration management Document preparation and production Reusability management Measurement Risk management 38
Process as Problem Solving 39
The Process Model: Adaptability The framework activities will always be applied on every project. . . BUT The tasks (and degree of rigor) for each activity will vary based on: n n n the type of project (an “entry point” to the model) characteristics of the project common sense judgment; concurrence of the project team 40
The Linear Model 41
Waterfall Model (1) System Engineering Software Requirement Specifications Design Implementation Test Maintenance 42
Waterfall Model (2) System engineering and analysis n n n understanding of the whole system-level requirements gathering allocation of functions to humans, hardware and software 43
Waterfall Model (3) Software requirements analysis n n understanding of the information domain software requirements gathering w function w performance w interfaces n n interaction with the customer documenting requirements 44
Waterfall Model (4) Design - Translating requirements into a representation that can be assessed for quality: n n data structures software architecture procedures interfaces Coding - Translating the design into a machine-readable form. 45
Waterfall Model (5) Testing: n n functional: defined input produces required results logical: test all statements Maintenance: n n revisit the steps described above perfective: demanded by the user adaptive: due to changing environment, e. g. , OS corrective: due to discovered errors 46
Waterfall Model - Critique Real projects do not necessarily follow the sequence Requirements are not known at the beginning A working program is available quite late Boring 47
Iterative Models Prototyping RAD 48
Prototyping Iterate, iterate, …, until prototype ready What’s next? Throw it away! But now you know WHAT to build! Get started 49
The Incremental Model 50
Reasons to Use Incremental Delivery "80: 20" rule: Deliver 80% of system functionality in 20% of the overall time. Reduce the project management risks associated with the "big bang" approach of delivering all the software at the same time. Gain “buy in” from the system sponsor through the early availability of some functionality; delivery of “the juicy bits first” inspires user confidence and encourages their collaboration. 51
An Evolutionary (Spiral) Model 52
Spiral Model (1) Planning - objectives, alternatives, constraints Risk analysis - identification of risks Engineering - development of a “next-level” product Customer evaluation - assessment of results of engineering A series of repetitive steps whose iterations are intended to converge toward an operational prototype through four quadrants of activity (Plan - Determine Objectives - Evaluate Alternatives - Develop). 53
Spiral Model (2) Areas of greatest risk can be revisited through the spiral while areas which have stabilized can be developed through to implementation. Aimed clearly at addressing the iterative nature of systems development towards a more complete system. Disadvantages: n n n hard to control the project risk assessment is critical, need expertise no experience with using the model 54
The Reuse Model Requirements Define Classes Reuse Class Library Browse Library Refine Classes Build Custom Classes Refine Requirements Assemble Prototype Review Results 55
The Cleanroom Model Uses one of the other paradigm structures, but… n Quality is emphasized from the beginning n Formal methods for specification are used n Formal inspections are conducted n Proof of correctness is applied to all code that is developed n Statistically based independent testing is conducted 56
Still Other Process Models Component assembly model—the process to apply when reuse is a development objective 1 Concurrent process model—recognizes that different part of the project will be at different places in the process 1 Formal methods—the process to apply when a mathematical specification is to be developed Automated software synthesis – one level of abstraction higher – auto-generate code Recursive/parallel model 4 Fountain model 5 Cluster emphasis 6 Round-trip gestalt engineering 7 RAAD (Rapid Architected Application Development)9 57
CMM: Capability Maturity Model A framework for assessing maturity of a process Defines five maturity levels (initial, repeatable, defined, managed and optimizing) Defines “key activities” required at each level Developed at SEI (Software Engineering Institute), Carnegie-Mellon University 58
Why is programming so hard to manage? Management problems of large programming projects different in kind from small ones, due to division of labor Critical need: preserve the conceptual integrity of the product itself "I was struck by how few of the propositions asserted in it have been critiqued, proven, or disproven by ongoing software engineering research and experience" 59
What are these propositions? “Architect”: conceptual integrity of the product is paramount Except in very small projects, architect cannot also be manager (architect director, manager producer) Architecture and implementation must be separated Large systems need subsystems with subarchitects 60
Other comments (1) Process Model Don't build one to throw away--the waterfall model is (frequently) wrong” Incremental build, progressive refinement are more productive techniques 61
Other comments (2) Productivity Information hiding is the way to go Model-Driven techniques are the future The “man-month” really is mythical (Brooks' Law is “true”) People are (almost) everything in software productivity 62
3. System Engineering 63
System Webster 2: n n A set or arrangement of things so related as to form a unity or organic whole A set of facts, principles, rules, etc. , classified and arranged in an orderly form so as to show a logical plan linking the various parts System = elements + relations System is more than the sum of its elements Computer System = Software + Hardware + People + Database + Documentation + Procedures System decomposition and hierarchy 64
The Hierarchy 65
Information Engineering (IE) Uses an integrated set of procedures, methods and tools to identify how information systems can best meet the strategic goals of an enterprise Focuses first on the enterprise and then on the business area Creates enterprise models, data models and process models Creates a framework for better information management distribution and control 66
The IE Hierarchy Information Strategy Planning (ISP) n n n strategic goals defined success factors/business rules identified enterprise model created Business Area Analysis (BAA) n n processes/services modeled interrelationships of processes and data Application Engineering n n a. k. a. . . software engineering modeling applications/procedures that address (BAA) and constraints of ISP Construction and delivery n using CASE and 4 GTs, testing 67
Information Strategy Planning Management issues n n define strategic business goals/objectives isolate critical success factors conduct analysis of technology impact perform analysis of strategic systems Technical issues n n n create a top-level data model cluster by business/organizational area refine model and cluster 68
Defining Objectives and Goals Objective—general statement of direction Goal—defines measurable objective: “reduce manufactured cost of our product” n Subgoals: w decrease reject rate by 20% in first 6 months w gain 10% price concessions from suppliers w re-engineer 30% of components for ease of manufacture during first year Objectives tend to be strategic while goals tend to be tactical 69
Business Area Analysis Define “naturally cohesive groupings of business functions and data” (Martin) Perform many of the same activities as ISP, but narrow scope to individual business area Identify existing (old) information systems / determine compatibility with new ISP model n n n define systems that are problematic define systems that are incompatible with new information model begin to establish re-engineering priorities 70
The BAA Process admin. manufacturing sales QC distribution acct Process Decomp. Diagram eng’ring Process Flow Models Process Decomp. Diagram Data Model Matrices e. g. , entity/process matrix 71
Product Engineering 72
Requirements Engineering Elicitation — determining what the customer requires Analysis & negotiation — understanding the relationships among various customer requirements and shaping those relationships to achieve a successful result Requirements specification — building a tangible model of requirements System Modeling — building a representation of requirements that can be assessed for correctness, completeness, and consistency Validation — reviewing the model Management — identify, control and track requirements and the changes that will be made to them 73
Computer System Engineering Problem: Lack of methods of engineering software Computer System Engineering: n n Input: Customer-defined goals and constraints Output: Representation and allocation of: w w w function performance interfaces design constraints information structure to: software, hardware, people, databases, documentation, procedures according to some accepted criterion. 74
System Allocation Software Hardware Objects (from Table) Processes (from Table) Performance Allocation People Constraints Data Documents Procedures 75
Criteria Project-related: cost, risks, scheduling, Business-related: profitability, marketability, payoff/risk ratio Technical: implementability, functionality assurance, maintainability, availability of resources, tech. risks, availability of COTS, … Manufacturing: availability of manufacturing technology, components, quality assurance methodology, … Human factors: availability of trained personnel, political risks, simplicity, health risks, . . . Environmental interfaces: ease, prone to errors, correctness, … Legal aspects: liability risks, rights protection, . . . And more 76
Product Architecture Template 77
Architecture Flow Diagram 78
System Architecture Architecture n n n template Context Diagram (ACD) Flow Diagram (AFD) Diagram Specification (ADS) system module narrative (what processed, how interfaced) architecture dictionary (description of items in diagrams architecture interconnection diagram (AID) + interconnect description (type of link: electronic, mechanical, optical, . . . ) More detail on this in Design 79
System Specification Introduction n n Scope and Purpose of Document Overview w w Objectives Constraints Functional and Data Description n System Architecture w w Architecture Context Diagram ACD Description Subsystem Descriptions n Architecture Diagram Specification for Subsystem n w w w n n Architecture Flow Diagram System Module Narrative Performance Issues Design Constraints Allocation of system components Architecture Dictionary Architecture Interconnect Diagrams and Description System Modeling and Simulation Results n n n System Model Used for Simulation Results Special Performance Issues Project Issues n n Projected Development Costs Projected Schedule Appendices 80
4. Unified Modeling Language 81
UML - Use Case Modeling What is use case modeling? Core concepts Diagram tour When to model use cases Modeling tips Example: Online HR System 82
What is use case modeling? Use Case Model: A view of a system that emphasizes the behavior as it appears to outside users. A use case model partitions system functionality into transactions (‘use cases’) that are meaningful to users (‘actors’). 83
Use Case Modeling: Core Elements 84
Use Case Modeling: Core Relationships 85
Use Case Diagram Tour Shows use cases, actor and their relationships Use case internals can be specified by text and/or interaction diagrams Kinds n n use case diagram use case description 86
Use Case Diagram 87
Use Case Relationships 88
Actor Relationships 89
Use Case Description: Change Flight Actors: traveler, client account db, airline reservation system Preconditions: n Traveler has logged on to the system and selected ‘change flight itinerary’ option Basic course n n n System retrieves traveler’s account and flight itinerary from client account database System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment. System asks traveler for new departure and destination information; traveler provides information. If flights are available then … System displays transaction summary. Alternative courses n If no flights are available then … 90
When to model use cases Model user requirements with use cases. Model test scenarios with use cases. If you are using a use-case driven method n start with use cases and derive your structural and behavioral models from it. If you are not using a use-case driven method n make sure that your use cases are consistent with your structural and behavioral models. 91
Use Case Modeling Tips Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmers When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams Factor out common usages that are required by multiple use cases n n If the usage is required use <
Example: Online HR System 93
Online HR System: Use Case Relationships 94
Online HR System: Update Benefits Use Case Actors: employee, employee account db, healthcare plan system, insurance plan system Preconditions: n Employee has logged on to the system and selected ‘update benefits’ option Basic course n n System retrieves employee account from employee account db System asks employee to select medical plan type; include Update Medical Plan. System asks employee to select dental plan type; include Update Dental Plan. … Alternative courses n If health plan is not available in the employee’s area the employee is informed and asked to select another plan. . . 95
References 1. Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e by R. S. Pressman. Copyright © 1996, 2001 R. S. Pressman & Associates, Inc. 2. 3. Merriam-Webster http: //www. webster. com/ 4. Essays on Object Oriented Software Engineering by E. Berard, Volume 1, Prentice Hall, Englewood Cliffs, New Jersey, 1993. 5. Book Two of Object Oriented Knowledge: The Working Object by B. Henderson Sellers and J. Edwards, Prentice Hall, Australia, 1994. 6. The New Culture of Software Development by B. Meyer, Journal of Object Oriented Programming, 3(1), 76 81, Nov Dec 1990. 7. Object-Oriented Design with Applications by G. Booch, Benjamin Cummins, Redwood City CA, 1994. 8. Principles of Software Engineering Management by T. Gilb, Addison-Wesley, 1988. 9. Best Practices in AD Project Management, Part 2, SPA-650 -1293 by Gartner 96 Group, ADM Research Note, March 20, 1996. A Spiral Model for Software Development and Enhancement by B. Boehm ACM Sig. Software Engineering Notes Vol 11, no 4, pp 14 -23, 1986