Introduction to Software Engineering

Introduction to Software Engineering
Speaker Reference Notes This document contains the slides and associated speaker reference notes for the seminar “Introduction to Software Engineering.” Configuration Management of this presentation This version updated the last 2 slides some. Previous version:TALK5.ppt = 1 ½ hour talk that provides an introduction to some of the basic software engineering concepts. (This is a new version- where the word SEAL was deleted from the last 2 slides)

Introduction to Software Engineering Outline
Part 1 - Background and Introductory Information Software Engineering History Software Development Statistics What is Software Engineering? Part 2 - Software Engineering Concepts Software Engineering Relationships Principles Development Methods & Techniques Management Methods & Techniques Life-Cycle Methodologies Software Engineering Processes & Procedures Automated Tools Today's Training will be conducted in two parts. Part 1 provides some background and introductory information on software engineering. This part of the seminar provides: a brief history of software engineering, statistics demonstrating common problems with software development, and definitions for the term “Software Engineering.” Additional definitions for different software engineering terms will be provided throughout the presentation . A glossary of these terms is provided in the back of your handout to provide a common reference point. Part 2 presents software engineering concepts: the principles, methods & techniques, life-cycle methodologies, processes and tools. The seminar lasts about 1 1/2 hours.

Software Engineering History
Computers were invented in the 1940’s Then - computing programming languages were invented Eventually - program language training was developed However, training was unable to provide sufficient methods & techniques for developing large reliable systems on time & within budget By the late 1960’s, digital computers were less than 25 years old and already facing a software crisis Software Engineering term first emerged as title of a 1968 NATO conference [1] “The first electronic digital computer was the Electronic Numerical Integrator and Calculator (ENIAC) which was built for the U.S. Army in 1946.” [Downing, Douglas, and Michael Covington, “Dictionary of Computer Terms.” New York: Barron’s Educational Series, Inc., 1986.] High order computer programming languages started to come into being in the late 1950’s. Eventually some training on how to write programs was developed. However, the training available at the time was not advanced enough to provide the methods and techniques needed to develop large systems that were reliable, delivered on schedule and within budget. As it turned out, we were not very good at building large systems on time and without overruns. Digital computers were less than a quarter of a century old and already we were facing a "software crisis”. The crisis came about not only because the software being produced did not function properly, but because of the problems associated with how we developed software and the growing demand for more software than the industry could provide. The software crisis is characterized by many problems: the lack of defined requirements and the constant changes to requirements that are known schedule and cost estimates are often grossly inaccurate the productivity of software developers hasn’t kept pace with the demand for their services, and the quality of software is sometimes less than adequate. - continued next page -

These problems led to the software crisis which in turn led to the need for - and birth of - software engineering itself. Both the term “software crisis” and “software engineering” were invented about the same time. Software engineering first emerged as a popular title of a 1968 NATO conference held in Garmisch, Germany. [ 1] Complex software development needed a classic engineering approach: to first clearly define the problem to be solved and secondly, develop standard methods and techniques for solving it. The software engineering discipline was formed to address the overwhelming problems being encountered in the development of complex software. NOTE: Although software engineering was a popular title at the 1968 NATO conference, the term did not become widely used and recognized in the software community until the mid-1970’s

Software Development Statistics
1979 General Accounting Office Report [2] 50% + of contracts had cost overruns 60% + of contracts had schedule overruns 45% + of software contracted for could not be used 29% + of software was paid for and never delivered 22% + of software contracted for had to be reworked/modified to be used This list was extracted from a 1984 paper in the IEEE transactions on Software Engineering. A 1979 General Accounting Office report reviewed contracts for the development of custom-built business and administration systems. The projects studied represented the state of the practice in the mid-1970s. "Several factors contributed to the situation [of having software development problems]. First, the invisible nature of both the work process and its product made software projects very difficult to manage and predict. Second, the explosive growth of the use of computers created a great demand for new programmers, most of whom were self-taught on the job; and frequently, low productivity and poor quality resulted. Third, there was little idea then of how to train programmers properly. Fourth, a tradition grew that programmers were secretive craftspersons whose products, during development, were their own property. " [2]

Software Development Statistics
Other Studies Tom DeMarco 25% of large systems development projects never finished 1991 Capers Jones Study Average Management Information System* project is 1 year late and 100% over budget Software crisis stubbornly persists Tom DeMarco and Capers Jones, well-known software engineering gurus/authors, have conducted studies in recent years to further substantiate the GAO report. In 1982, Tom DeMarco pointed out that 25% of large systems development projects never finish. This "software crisis" was the rationale for the establishment of the Ada programming language by the Department of Defense. History reveals, however, that the languages and environments of the 1980’s provided some improvement but not what was expected. The effective use of emerging software technology was limited by several factors: an ill-defined process, inconsistent implementation, and poor management. A recent study by Capers Jones in 1991, documented the gloomy statistic that the average Management Information System project is 1 year late and 100% over budget . The software crisis stubbornly persists. [3] * Management Information System - a system for providing information to support organizational activities and management functions.

Summary While there has been some progress, there still are serious problems to overcome in software development schedule and cost estimates are still inaccurate productivity of developers is not keeping up with the demand quality of software is not meeting customer expectations Still a need to bring engineering discipline into the software process Some of the basic problems pointed out at the 1968 NATO Conference have continued. Progress has been spotty. Where improvements have occurred, much of them can be attributed to software engineering practices.

Software Engineering Definition
The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. [IEEE Std ] Institution of engineering discipline in the manufacturing of computer software Software engineering enables the manager to control the process of software development and provides the software developer with a foundation for building high-quality software in a productive manner.

Part 2 - Software Engineering Concepts
Part 1 - Background and Introductory Information Part 2 - Software Engineering Concepts Software Engineering Relationships Principles Development Methods & Techniques Management Methods & Techniques Life-Cycle Methodologies Software Engineering Processes & Procedures Automated Tools This part of the seminar will focus on the following software engineering concepts and how they relate to one another: the principles of software engineering the methods and techniques used to develop software the methods and techniques used to manage software development how these methods and techniques are combined into a life-cycle methodology how software engineering processes and procedures are defined for specific organizations by tailoring the above mentioned methods and techniques and finally, how these methods and techniques are supported with automated tools

Software Engineering Relationships
Principles Methods & techniques Life-cycle methodologies Processes & procedures Automated tools This figure shows the relationship between software engineering principles, methods & techniques, life-cycles, processes, and tools. Each layer in the figure is built on the layer(s) below it and the outermost layers are more susceptible to change over time. Principles are the basis of all methods, techniques, life-cycles, processes, and tools. The first three layers are in the realm of theory. The final two layers are the physical applications of the theory and concepts of software engineering.

Selected Software Engineering Principles
Rigor and Formality Modularity Abstraction Anticipation of Change Generality Incrementality Software engineering principles are more important than any particular methodology for building software--they enable the software engineer to evaluate various methodologies and apply them when they are appropriate. The following are only a few of the Software engineering principles recognized today. [NOTE: Throughout the remainder of this material, examples will be based on an automobile so that the reader may easily relate to them.] Software development is a creative activity. There is a tendency in any creative process to be neither precise nor accurate but rather to follow the inspiration of the moment. Rigor is a necessary complement to creativity in every engineering activity. It is only through a rigorous approach that we can produce more reliable products, control their costs, and increase our confidence in their reliability. Various degrees of rigor can be achieved. The highest degree is what we call formality. In every engineering field, the development process proceeds as a sequence of well-defined, precisely stated steps. In each step, the engineer follows some method or applies some mathematical technique. These well defined methods and techniques applied in a rigorous and systematic approach can be uniformly applied and taught. The amount of rigor and formality depends on the task at hand. Using road vehicles as an example, a Mercedes Benz with its center of gravity designed in the correct place (making Mercedes known for its precision handling), requires much more rigor than a go cart hacked together from a lawn mower engine and some lumber. - continued next page -

A complex system may be divided into separate and distinct pieces called modules. Modularity is an important property of most engineering processes and products. For example, in the automobile industry, the construction of cars proceeds by assembling parts that are designed and built separately. Furthermore, parts are often reused from model to model, perhaps after minor changes. Abstraction is a process in which we identify the important aspects of a problem and ignore its unimportant details. A useful abstraction for the owner of a car is the owner’s manual which describes the various features and operations of the car. For the person maintaining the car, a useful abstraction is the maintenance manual. Other abstractions include activities conducted in the factory needed to design and build the car. Anticipation of change is the process of creating software so it may be easily modified. After software is released, based on feedback from the user, the application must evolve as new requirements are discovered or old requirements are updated. If we can anticipate the changes of context in which a software component might be embedded, we may then design the component in a way that such changes may be easier to implement. For example, cars can be ordered with additional options. Power windows and air conditioning can be added to the car by the dealer. Car manufacturers have anticipated these kinds of changes and have made the cars easily modifiable. The principle of generality may be stated as follows: Every time you are asked to solve a problem, try to focus on the discovery of a more general problem that may be hidden behind the problem at hand. The success of such tools as spreadsheets, databases, and word processors is that they are general enough to cover the practical needs of most people when they wish to handle their personnel business with a computer. If the problem at hand may be restated as an instance of a problem solved by a general package, it may be convenient to adopt the package instead of implementing a specialized solution. In the early days of automobile technology, it was possible to customize cars according to the specific requirements of the customer. Nowadays, it is not possible to ask for a personal car design, unless one is ready to pay an enormous amount of money. Incrementality means that the desired application is produced as an outcome of an evolutionary process. One way of applying the incrementality principle consists of identifying useful subsets of a software application that may be developed and delivered to customers in order to get early feedback. We progressively add functions to the application being developed, starting from a kernel of functions that would still make the system useful, although incomplete. For example, with a newly designed car, the first increment may be a running car with no body (just the frame) which can undergo evaluation on a test track. The first increment can be undergoing testing while the second increment, the car body, is being developed and aerodynamically tested.

Methods & Techniques Automated tools Processes & procedures Life-cycle
methodologies We have just finished going over software engineering principles. We will now discuss software engineering methods and techniques. This has been further split into discussions of development methods & techniques and management methods & techniques. Methods & techniques Principles

Basic Problem Solving Flow
WHAT HOW DO This basic flow can be used for virtually all problem solving activities. This process flow was initially modeled for manufacturing and applied to systems engineering and then to software engineering. The first step is to decide what is to be done. Once the objectives have been determined, we next must decide how to achieve them. This is followed by a step in which we do it, whatever “it” was determined to be. Then we must test the results to see if we have accomplished our objectives. Finally, we use what we have done. The same process can be used in building anything. Using a car as an example, first we decide on what the car should look like and detail how it should be built. The car is then built, tested and used. Software engineering follows the same types of activities. TEST USE

Development Methods & Techniques
System Engineering Requirements Analysis Design Software Implementation Testing Integration Maintenance Verification & Validation Development Methods & Techniques This chart restates the basic problem solving flow to software development methods and techniques. Systems engineering and requirements analysis is the “what,” design is the “how,” implementation is the “do,” and testing and integration is the “test.” During product use, maintenance may be required. The software engineering principles reviewed earlier are incorporated into various software engineering methods and techniques. The principle of rigor and formality will require an adoption of appropriate methods to define requirements and design the system. Modularity, abstraction, and generality will be applied to tame the complexity of the design and make sure the design is understandable. Finally, anticipation of change and incrementality allow the designing of systems that can easily evolve. Software engineering methods provide the technical "how to's" for building software. Each one of these software development activities will be defined in the slides to follow with the steps in each activity specified and shown with a sample technique. Wind tunnels, aeronautic simulators, and space flight instruments are examples of types of applications that probably need to implement each of these development activities. However, your application area may only require a subset of these development activities. Project Tracking & Oversight Project Planning Configuration Management Quality Assurance Management Methods & Techniques

Verification & Validation
System Engineering Requirements Analysis Design Software Implementation Testing Integration Maintenance Verification & Validation Development Methods & Techniques Systems Engineering System Design Document User Need Requirements Definition Concept Definition System Design Systems Engineering is the application of scientific and engineering methods to transform user needs into a description of the system that will fill those needs. Software engineers need to be intimately involved in systems engineering efforts to provide software expertise and assist in evaluating design decisions. Trade studies are performed and alternatives are evaluated to determine the most appropriate system design and allocation of system requirements to hardware and software. A required function in a car, for example, may perform much faster if it is implemented in hardware instead of software. However, it may be more expensive to implement in hardware. If the car being designed is a sports car, the increase in price may be acceptable. However, if it is a family car, the need to keep the price affordable may lead the systems designers to implement the function in software. It is important for the hardware and software engineers to be involved in the systems engineering activities to help the systems analyst make these kinds of trade-offs. The above process shows how a specific car model would first be conceptually defined. Then more detailed requirements are determined and an initial design completed. Finally the systems requirements are separated and allocated to hardware related requirements and software related requirements. The software engineer helps determine what requirements are appropriate to implement in software. Items such as the digital dashboard displays, engine control systems like timing, fuel injection and emission control are all controlled by software. The software engineering process starts during the system engineering phase. Note: Circles on this chart represent processes and parallel lines represent products which can be stored and retrieved. System Requirements Concept Allocated Hardware Reqs Allocated Software Reqs

Software Requirements Analysis
Development Methods & Techniques Software Requirements Analysis System Engineering Requirements Analysis Design Software Implementation Testing Integration Maintenance Verification & Validation Allocated Software Requirements Write Software Requirements Review System Requirements Allocated to Software SW Requirements Document Software requirements analysis is the process of studying the system requirements allocated to software to arrive at a definition of the software requirements. The requirements that were allocated to software are now analyzed and expanded in the software requirements document. The software requirements are checked for clarity, completeness, consistency, testability, etc. For example, if one of the requirements for the car’s computer system was for it to be user friendly, this requirement is subjective, ambiguous, and untestable. Further investigation would be required to see how car owners define user friendly. Perhaps this would include full words on the buttons instead of acronyms or icons. Any problem discovered during the Review or Formal Inspection of the software requirements document would be recorded in a trouble report, and corrective action would be performed before the requirements are considered complete. Review/Inspect Requirements & Write Trouble Reports Perform corrective action Trouble Reports

Software Requirements Checklist
Clarity Is the terminology consistent with the user’s? Are the requirements clear and unambiguous? If assumptions that affect implementation have been made, are they stated? Completeness Have all requirements been assigned a priority? Have the criteria for assigning priority levels been defined? Have the requirements been stated for each staged implementation? Consistency Are the requirements consistent with each other? Are the requirements here consistent with the requirements in related documents? Testability Have the test methods (test, demonstration, analysis or inspection) been stated for each requirement? This list shows a small subset of questions asked during the Formal Inspection of the software requirements document.

Requirements Document - NASA-STD-2100 [4]
Table of Contents 1.0 Introduction 2.0 Related Documentation 3.0 Requirements Approach and Tradeoffs 4.0 External Interface Requirements 5.0 Requirements Specification 5.1 Process and Data Requirements 5.2 Performance and Quality Engineering Requirements 5.3 Safety Requirements 5.4 Security and Privacy Requirements 5.5 Implementation Constraints 5.6 Site Adaptation 5.7 Design Goals 6.0 Traceability to Parent’s Design 7.0 Partitioning for Phased Delivery The purpose of the Software Requirements document is to specify the functional, performance, and interface requirements for the software in written form. Requirements approach and tradeoff results are described. This also specifies the major characteristics, implementation constraints, and design goals for the software in a NASA standard format.

Object Oriented Software Design*
Development Methods & Techniques System Engineering Requirements Analysis Design Software Implementation Testing Integration Maintenance Verification & Validation Software Req. Document Create state diagram for each object Translate reqs into objects and create object model State Diagrams Object Model Design is the process of defining the architecture, subunits, interfaces, and other characteristics of a software system or component. Once the Requirements Document is completed and reviewed, the software design process is started. There are several different methods for developing the software design. The design method shown here is called object-oriented design which provides techniques for modeling software design based on real-world entities. The fundamental construct is the object, which combines the data and the operations performed on the data into a single entity. In our car example, the gas pedal, cruise control, and engine would become objects. The object model documents and describes the static structure of the objects in a system and their relationships. State diagrams describe the dynamic structure or behavior of an object. In other words, state diagrams relate events and responses to objects. Examples of events are the driver depressing the power button on the radio or the car cruise control is turned on, which causes an object to change state. For example, the state of the cruise control is either on or off, depending on the cruise control switch. A data flow diagram (DFD) can be constructed for each state to graphically depict the data flow between processes which are performed while in the state. This chart is a simplified data flow diagram showing the object oriented design process. Develop Data Flow Diagram for each state Data Flow Diagrams *This diagram is based partly on the Rumbaugh OOD technique[5]

Detailed Design Document- NASA-STD-2100 [4]
Table of Contents 1.0 Introduction 2.0 Related Documentation 3.0 Detailed Design Approach and Tradeoffs 4.0 Detailed Design Description 4.1 Compilation Unit Design and Traceability 4.2 Detailed Design of Compilation Units 5.0 External Interface Detailed Design 5.1 Interface Allocation Design 5.2 Physical Interface Design 6.0 Coding and Implementation Notes 7.0 Firmware Support Manual The Detailed Design document includes: the design approach and trade-offs, constraints, assumptions, and diagrams which are used to convey instructions on how the code should be written.

Software Implementation
Development Methods & Techniques System Engineering Requirements Analysis Design Software Implementation Testing Integration Maintenance Verification & Validation Design Document Translate design into programming language Source code Compile, link, load onto processor Software implementation is the process of translating design and data definitions into the form of a programming language. The programmer reviews the design for possible reuse components, then translates the design into programming language source code. This source code is compiled and linked into a load module. The module is loaded onto the processor and the program is run. Errors are identified and fixed. At this point, with our car, the software for a single module, let’s say for the fuel injection system, would be loaded on a test computer mounted on top of the engine and run. This software component is verified to ensure the engine will start, run, and perform as expected. corrected source code Load module Run program, identify & fix errors

Ada Code -- package specification package Simple_IO is
procedure Get (Item : out Integer); procedure Put (Item : in Integer); end Simple_IO; -- package body with Text_IO; package body Simple_IO is -- hidden declarations package Int_IO is new Text_IO.Integer_IO (Integer); -- body stubs procedure Get (Item : out Integer) is separate; procedure Put (Item : in Integer) is separate; This is a very simple example of a read/write routine coded in the Ada programming language. During the software implementation process, the programming language instructions are translated to machine-readable instructions that will control the operations of the computer.

Testing Development Methods & Techniques System Engineering Requirements Analysis Design Software Implementation Testing Integration Maintenance Verification & Validation Source Code Produce test plans and procedures Expected Results Conduct tests & Evaluate Result Test plan and procedures Testing is the process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component. Testing should be performed by someone other than the developer. Testing begins with test plans and procedures being produced. The test plan provide managers and test personnel with the necessary approach to validate that the coded modules perform correctly and that the requirements of the system have been satisfied. The test procedures document specifies the required operator actions, and the input and output for each software test. Errors found based on the testing evaluation are sent back to the programmer to debug and metrics are kept on the number and types of errors so that defect analysis can be conducted to determine the root cause of the errors so as to prevent them in the future. On our car, at this point, the fuel injection, emission control, and timing systems would be brought together, loaded onto the test computer and the complete engine component tested. Deliverable Software Debug & fix

Trouble Report [1] Program ID - TR # [2] Current Status
[3] Program Title [4] Problem Description [5] Rationale (Proposed Approach to be Taken) Disposition Information [6] Status [7] Schedule This is a sample test report used to record errors found during testing.

Test Procedures Document - NASA-STD-2100 [4]
Table of Contents 1.0 Introduction 2.0 Related Documentation 3.0 Test Identification and Objective 4.0 Procedures 5.0 Evaluation Criteria 6.0 Expected Results 7.0 Actual Results 8.0 Abbreviations and Acronyms 9.0 Glossary 10.0 Notes 11.0 Appendices The purpose of the test procedures document is to record the objectives, procedures, results, and other technical information related to a test.

Integration Development Methods & Techniques System Engineering Requirements Analysis Design Software Implementation Testing Integration Maintenance Verification & Validation Acceptance test plans and procedures Expected results Tested hardware Receive & Install Hardware/ Software Production system Run acceptance test Tested software Integration is the process of combining software and hardware components into an overall system. This phase takes the tested hardware components and software components and installs them into an integrated system. An acceptance test is conducted to validate that the system meets the user’s requirements. The same kind of trouble report used for testing can be used during the integration phase, in case problems are found. At this point the fuel injection, emission control and timing systems are loaded into the actual computer hardware box that will be installed in the car. All tested components are brought together and tested together as a system. This is the first time that engineers can physically climb into the car and test drive it. Integrated system Write trouble reports & fix errors

Maintenance Development Methods & Techniques System Engineering Requirements Analysis Design Software Implementation Testing Integration Maintenance Verification & Validation Production system Operations Change requests/trouble reports Maintenance is the process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment. Maintenance is the set of activities that are performed after the system is delivered to the customer. Basically, maintenance consists of correcting any remaining errors in the system, adapting the application to changes in the environment and improving, changing, or adding features and qualities to the application. With our car example, maintenance would be performed when the owner decides he wants additional options, to work out new car bugs or to equip cars with catalytic converters so that they meet U.S. environmental standards. Maintenance Perform Testing Software changes

Verification& Validation
Development Methods & Techniques System Engineering Requirements Analysis Design Software Implementation Testing Integration Maintenance Verification & Validation Validate Validate Validate Requirements Analysis Design Code Testing Verification and validation (V&V) is the process of determining whether the requirements for a system or component are complete and correct, the products of each development phase fulfill the requirements or conditions imposed by the previous phase, and the final system or component complies with specified requirements. Validation is the process of evaluating a software component during the development process to determine whether it satisfies specified requirements. Verification is the process of evaluating a software component to determine whether the product of a given development phase satisfies the conditions imposed at the start of that phase. Human beings are fallible, and they make mistakes even if they adopt the most sophisticated and thoughtful design techniques, erroneous results can never be avoided. Consequently, the product of any engineering activity, such as our car, must be validated against its requirements throughout its development to ensure that errors are not propagated to later phases. During the design and construction of our car, one must repeatedly verify the product in all its intermediate development stages. For instance, the first blueprints of the car are verified by using suitable equations to forecast whether the car’s frame will withstand the impact of an accident at 30 mph. Prototypes of the car are also built to further enhance confidence. And throughout the development phases the software design, code, and test would be compared to the requirements to validate that the car is being built as initially specified. For instance, can the car do 0 to 60 mph in the specified 10 seconds. Verify Verify Verify Verify

Requirements Traceability Matrix
Ref. # Paragraph # Description Module ID 1 Accelerate from 0 to 60 within 10 seconds under standard conditions. 2 Maintain cruising speed within 2 mph of set speed. One technique to help in validation is a requirements traceability matrix. This matrix ties the requirements to the design and any associated trouble reports. 3 Update speed display 10 times per second.

Management Methods & Techniques
System Engineering Requirements Analysis Design Software Implementation Testing Integration Maintenance Verification & Validation Development Methods & Techniques The highlighted activities in this chart represent the software engineering management activities that span across each phase of development. Each one of these activities will be defined in the slides to follow and shown with a sample technique. Project Tracking & Oversight Project Planning Configuration Management Quality Assurance Management Methods & Techniques

Management Plan Document NASA-STD-2100 [4]
Management Methods & Techniques Project Planning Project Tracking & Oversight Quality Assurance Configuration Management 1.0 Introduction 2.0 Related Documentation 3.0 Purpose and Description of the Software 4.0 Resources, Budgets, Schedules, and Organization 4.1 Business Practices Definition and Revision Processes 4.2 Work Breakdown Structure 4.3 Resource Estimation and Allocation to WBS 4.4 Work Authorization 5.0 Acquisition Activities Plan 6.0 Development Activities Plan 7.0 Sustaining Engineering and Operations Activities Plan 8.0 Assurance Plan 9.0 Risk Management Plan 10.0 Configuration Management Plan 11.0 Delivery and Operational Transition Plan 12.0 Abbreviations and Acronyms 13.0 Glossary 14.0 Notes 15.0 Appendices The purpose of the Management Plan is to provide the organization for all planning information. It includes planning for management, assurance, and development for the software, including maintenance. Project plans typically describe the work to be done, the resources required, the methods to be used, the procedures to be followed, the schedules to be met, and the way the project will be organized.

Project Tracking & Oversight Configuration Management
Project Planning Management Methods & Techniques Project Planning Project Tracking & Oversight Quality Assurance Configuration Management System Engineering Software Requirements Analysis Software Design Preliminary Detailed Code Test Integration Q 1 Q 2 Q 3 Q 4 Plan Actual Project schedules are one of the Management Plan components and are typically displayed in Gantt charts as shown. The tasks listed in the Gantt chart are based on the development activities described earlier in this talk. Plans (particularly project schedules) are one of the major inputs to the project tracking and oversight process shown next.

Project Tracking And Oversight
Management Methods & Techniques Project Planning Project Tracking & Oversight Quality Assurance Configuration Management System Engineering Software Requirements Analysis Software Design Preliminary Detailed Code Test Integration Q 1 Q 2 Q 3 Q 4 Plan Actual Project tracking and oversight is the management approach to provide adequate visibility into actual progress so that management can take effective actions when the project’s performance deviates significantly from the plan. Tracking and oversight includes all of the project activities associated with managing the accomplishment of work. Approved project plans provide the yardstick to objectively measure actual accomplishments. Tools like the project Gantt chart are used to communicate financial and schedule information. Other methods, like weekly software status reports and status meetings are also used for monitoring performance and identifying and controlling risk.

Project Tracking & Oversight Configuration Management
Quality Assurance Management Methods & Techniques Project Planning Project Tracking & Oversight Quality Assurance Configuration Management Procedures Products Activity being performed Standards Product Reviews Process Reviews Quality Assurance (QA) assures that the product conforms to required standards and that the proper procedures are being followed in the development of the product. Actual products, like computer code or design documents, are looked at during product reviews. The product is compared to written standards to ensure adherence to them. Errors are reported to management for resolution. Process reviews are used to review the records and other documentary evidence to verify completeness of the process and that the organization’s defined procedures were followed. Errors Errors

Configuration Management
Management Methods & Techniques Project Planning Project Tracking & Oversight Quality Assurance Configuration Management Change/Trouble Reports Change Control & Impact Analysis Approved Request Development Staff Configuration Management Library Configuration Management involves identifying work products, controlling changes, and maintaining the integrity and traceability to requirements. This diagram illustrates what that means during the maintenance phase. The change control authority (usually a Configuration Control Board) reviews the request and its impact and decides if the request will be approved or disapproved. Development staffs receive the approved request and check out products from the configuration management library. Once the development staff completes the corrections it passes the updated products to Configuration Management where the library is updated with the new versions. Corrected Products Version Controlled Products Copy of Products

Life-Cycle Methodologies
Automated tools Processes & procedures Life-cycle methodologies We will now discuss life-cycle methodologies which organize methods and techniques into an ordered sequence of events. Methods & techniques Principles

Life-cycle Models System Engineering Requirements Analysis Design Software Implementation Testing Integration Maintenance Verification & Validation Life-cycle models provide engineered approaches that can be used to structure the software development process. These models are a convenient and idealized picture of the process we followed to build, deliver, and evolve software systems. Software life-cycle models typically include phases that correspond to these development activities. The primary difference in life-cycle models is the sequence of, and emphasis on these activities. Waterfall Incremental Spiral

The Waterfall Life-cycle
Systems Engineering Req Analysis Design Code Waterfall was the first formal life-cycle. With the waterfall methodology, each phase is completed before the next is started. Each phase produces products that are used in the next phase. It was developed in the early 70’s when projects were simpler and smaller in scope. It ran into problems with larger projects where all the requirements were not known prior to design or the requirements changed frequently. This life-cycle methodology is appropriate only for small projects whose requirements are well documented and understood. Test Integration Maintenance

Incremental Life-Cycle
Systems Eng System Implementation Rqmts. Analysis Maintenance The incremental life-cycle is an adaptation of the waterfall model. This life-cycle methodology is used for more complicated systems and systems where all the requirements are not known up front. It breaks large projects into a series of smaller deliverables called builds. In the later builds, requirements can be added based on customer feedback on the earlier builds. It also provides the opportunity to deliver limited functionality early in the project. Rqmts Analysis Design Code Test Integrate Build 1 Rqmts Analysis Design Code Test Integrate Build 2 Rqmts Analysis Design Code Test Integrate Build 3

Spiral Life-cycle Risk Analysis Risk Mitigation Determine objectives,
alternatives, constraints Evaluate alternatives, identify, resolve risks Risk Analysis Risk Mitigation Concept of operation This life-cycle is driven by risk management. It recognizes there may be many uncertainties in the project and works to reduce the probability of negative impacts due to those uncertainties. Risk analysis is performed to identify, analyze, and rank risks. Risk mitigation identifies actions to be taken to reduce the amount of risk, resolving risk through planned corrective action and monitoring the situation to see if the corrective actions removed or reduced the risk as planned. The spiral life-cycle is a further refinement of the basic waterfall model and was first published in The figure shows a model that consists of a series of learning cycles that begin with defining the objectives and then performing a risk assessment to identify areas of greatest uncertainty in the project. The number of iterations through the cycle varies based on the uncertainty of the problem. Simple problems take one pass and look very much like a standard waterfall life-cycle. More complicated problems may involve several passes through the cycle to resolve uncertainty to an acceptable level. Requirements analysis Design Implementation and test Plan next phases Develop, verify next level product

Processes & Procedures
Automated tools Processes & procedures Life-cycle methodologies We will now discuss the application of principles, methods & techniques, and life-cycle methodologies into processes, procedures and automated tools. Methods & techniques Principles

Software Engineering Processes and Procedures
Responsible Group 006 Configuration Management Baseline Software Design Document Baselined Software Requirements Document Quality Assurance 004 Formal Inspection Hardware Engineering Everything we covered so far is not one size fits all. This simplified process diagram illustrates how the previously mentioned object-oriented software design might actually be done in a particular organization and for a particular type of software. The design methods and techniques would differ somewhat depending on if the system you were implementing was for processing employee paychecks versus software aboard the space shuttle versus the software used for command and control systems used during Desert Storm. This slide shows the process and procedures that would be performed for a complex software project. By drawing this picture we can communicate the major inputs and outputs, major organizational responsibilities and interactions, reviews and quality checks, and the sequence of events. Any box on this diagram would be decomposed into a lower level diagram or supported by a detailed procedure. In this example, only the design phase of the software life-cycle is diagrammed. 001 002 003 Software Engineering Translate Requirements into objects and develop object model Create state diagram for each object Develop Data Flow Diagram for each state * - the processes and procedures defined in this slide apply to the software design phase of a complex software project.

Software Engineering Processes and Procedures
Responsible Group 008 Math Library Management Baseline Routine 001 Task Monitor User Needs User 004 Formal Inspection This slide shows the process that is followed for inserting a new routine into an existing library of math routines. In this example, the complete life-cycle of the math routine development is shown. It is a much simpler set of procedures than those shown on the previous slide since the software development task at hand is not as complex. 002 003 005 006 007 Task Plan Software Requirements Data Flow Diagram For Design Code Test Local Contractor * - the processes and procedures defined in this slide show the possible phases applicable for adding a simple routine to a math library.

Tools Analysis Tools Design Tools Coding Tools Testing Tools Reverse
Engineering Tools Configuration Management Tools H O R I Z N T A L T O L S A number of automated tools exist to support software engineering methods. This chart shows some of the major areas where software tools are employed in software engineering activities. Vertical tools provide support for one specific development phase. Analysis tools usually provide drawing programs with integrated text capabilities to assist the engineer in developing software requirements. Design tools provide additional text and graphic support to translate requirements into design. Some coding tools will take information from design tools and generate executable code from the design specifications. Testing tools support the generation of test data and verification of test results. Reverse engineering tools allow software engineers to reconstruct software designs from existing code. - continued next page - Project/Process Management Tools Documentation Tools

Horizontal tools span multiple life-cycle stages
Horizontal tools span multiple life-cycle stages. They typically support management methods and techniques. Configuration management tools support the management of project products (software and documents) and their change history. Project management tools include all of the tools used to plan, estimate, schedule, track, and status the software engineering project. Documentation tools assist in the generation and maintenance of documents and manuals needed to develop and maintain the software.

Tool Examples - 1 Vertical Tools Horizontal Tools
McCabe Tools - source code analyzers that generate measures of software complexity Horizontal Tools Microsoft Project - commercial project management tool Polytron Version Control System - controls multiple versions of software, documents, procedures, etc. This chart and the next one list some of the tools used at NASA. The McCabe and tool actually “read” code and produce a set of numbers that indicate how complex the code is. They work a lot like some of the grammar checkers in word processing programs that tell you the grade level necessary to read your text. If the source code complexity is too high, you might want to consider a simpler, more appropriate, structure.

Tool Examples - 2 Computer Aided Software Engineering (CASE) Environments Tools supporting analysis, design, code (Fortran, C,C++), simulation, and reverse engineering Tools supporting vertical areas using object-oriented methods and code generation Test Beds PC Data Acquisition Hardware and Software Miscellaneous Oscilloscopes/Logic Analyzers and other test equipment Testing equipment and tools Circuit analyzers Some vendors have integrated sets of software engineering tools into Computer-Aided Software Engineering (CASE) environments. CASE environments facilitate the information sharing and transformations that occur both within life-cycle engineering phases (vertically) and between the phases (horizontally). For instance, a CASE environment might provide a tool component that allows a system engineer to graphically describe an application database, use that information in another tool component to produce a design document, while another tool component is keeping track of the changes to the design and the documents. There are CASE tools that supports large-scale developments in several programming languages and support different methods such as object-oriented.

Footnotes [1] Blum, Bruce. “Software Engineering, A Holistic View.” New York: Oxford University Press, 1992, page 11. [2] Comptroller General, “Contracting For Computer Software Development - Serious Problems Require Management Attention to Avoid Wasting Additional Millions” FGMSD-80-4, United States General Accounting Office, November 9, 1979. [3] Shepherd, Dale, “Defining the Software Development Process”, Crosstalk, Software Technology Support Center, Special Edition 1993. [4] “NASA Software Documentation Standard Software Engineering Program,” NASA-STD , Technical Standards Division Publication, Approved July 29, 1991 [5] Rumbaugh, James, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorenson, “Object-Oriented Modeling and Design.” Englewood Cliffs, NJ: Prentice-Hall, 1991. Footnotes

--Continued next page --
Glossary Software Engineering - The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. [IEEE Std ] Computer Program - A combination of computer instructions and data definitions that enable computer hardware to perform computational or control functions. [IEEE Std ] Systems Engineering - the application of scientific and engineering effort to (a) transform an operational need into a description of system performance parameters and a system configuration ..., (b) integrate related technical parameters and ensure compatibility of all physical, functional, and program interfaces ..., (c) integrate reliability, maintainability, safety, survivability, human, and other factors into a total engineering effort to meet cost, schedule, and technical performance objectives. ]MIL-STD-499A] Requirements Analysis - (1) the process of studying user needs to arrive at a definition of system, hardware, or software requirements; (2) the process of studying and refining system, hardware, or software requirements. [IEEE Std ] Design - (1) the process of defining the architecture, components, interfaces, and other characteristics of a system or component; (2) the result of the process in (1). [IEEE Std ] Code - (1) in software engineering, computer instructions and data definitions expressed in a programming language or in a form output by an assembler, compiler, or other translator; (2) to express a computer program in a programming language; (3) a character or bit pattern that is assigned a particular meaning; for example, a status code. [IEEE Std ] Testing - (1) the process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component; (2) the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features of the software items. [IEEE Std ] Integration -the process of combining software components, hardware components, or both into an overall system. [IEEE Std ] Maintenance - (1) the process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment; (2) the process of retaining a hardware system or component in, or restoring it to a state in which it can perform its required functions. [IEEE Std ] Verification and validation (V&V) - the process of determining whether the requirements for a system or component are complete and correct, the products of each development phase fulfill the requirements or conditions imposed by the previous phase, and the final system or component complies with specified requirements. [IEEE Std ] --Continued next page -- Glossary

Project Planning - the technical and management approach to be followed for a project. Typically describes the work to be done, the resources required, the methods to be used, the procedures to be followed, the schedules to be met, and the way the project will be organized. [IEEE Std ] Project Tracking and Oversight - the technical and management approach to provide adequate visibility into actual progress so that management can take effective actions when the project’s performance deviates significantly from the plans. [CMU/SEI 93-TR-25] Quality Assurance - A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements. [IEEE Std ] Configuration - (1) The arrangement of a computer system or components as defined by the number, nature, and interconnections of its constituent parts. (2) In configuration management, the functional and physical characteristics of hardware or software as set forth in technical documentation or achieved in product. [IEEE Std ] Configuration Management - Identifying the configuration of the software (i.e., selected software work products and their descriptions) at given points in time, systematically controlling changes to the configuration, and maintaining integrity and traceability of the configuration throughout the software life-cycle. The work products placed under software configuration management include the software products that are delivered to the customer (e.g. the software requirements document and the code) and the items that are identified with or required to create these software products (e.g., requirements, plans and procedures, change requests and trouble reports, design documents, etc.). [CMU/SEI-93-TR-25]

Introduction to Software Engineering

Similar presentations

Presentation on theme: "Introduction to Software Engineering"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Introduction to Software Engineering

Similar presentations

Presentation on theme: "Introduction to Software Engineering"— Presentation transcript:

Similar presentations

About project

Feedback