1 / 22

What is Software Engineering Historical Aspects

What is Software Engineering Historical Aspects NATO group coined the phrase during a 1968 meeting in Garmisch, Germany ( a very pretty place). They believed the development of software should be an engineering discipline to solve what has been termed a “software crisis.

germaine-puckett
Télécharger la présentation

What is Software Engineering Historical Aspects

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. What is Software Engineering • Historical Aspects • NATO group coined the phrase during a 1968 meeting in Garmisch, Germany ( a very pretty place). • They believed the development of software should be an engineering discipline to solve what has been termed a “software crisis. • The crisis continues. • Goals of Software Engineering • Software is fault Free (Bugs) • Software is delivered on-time • Software is delivered within budget • Satisfies users needs. • Can be maintained and modified with the same properties.

  2. Different Phases of the Software Life Cycle • Requirements Phase: Concept is explored and customers requirements are elicited. • Specification (Analysis ) Phase: Requirements are analyzed and a specification document is produced. Customer signs off on specification. • Planning Phase: A plan is drawn up. Cost, Schedule, Resources, Risks, Assumptions, etc. • Design Phase: Requirements are translated one-to-one to a design of how to solve them. • Implementation (Coding) Phase: Do the design. • Alpha Test: Internal test with real data. • Beta Test: External test with a real customer, usually involves parallel running with old system. • Maintenance Phase: First version is released and modifications are coming back, • Retirement Phase: System is no longer used or is no longer maintained by a software organization.

  3. Module Coding/Testing 12% Integration 8% Design 6% Planning 1% Specification 4% Requirements 2% Maintenance 67% Approximate relative costs of the phases of the software life cycle

  4. Approximate relative cost to detect and correct a fault

  5. Economic Aspects of Software Engineering • Does the resulting system, after development perform one or more of the following functions: • Simplify a process • Make a process more accurate • Decrease the cost of operations • Increase productivity • Increase the quality of the product • Provide a new and useful capability • and Eventually through the features above, recoup the cost of the development of the system. • Ensure the resulting system does not do the following; • Increase maintenance and operation costs • Increase work complexity • Create work • Perform a negative aspect of what a system should do.

  6. Specification and Design • The relative costs of fixing and correcting faults within a system increase at each of the various phases. Why? • All phases that have been accomplished to date must be re-accomplished for the fault and all modules affecting the fault. • How do you avoid this: • Detailed requirements analysis • Hire quality and experienced personnel • Detailed and documented design reviews • Automate the process as much as possible • Attention to detail is of the utmost importance.

  7. Team Programming • A single programmer acting as analyst, coder, configuration manager, tester, documentation specialist, and help desk is the most efficient use of a programmer. • Almost all commercial products are a result of a team programming effort, however this has it’s own share of problems: • Doubling the number of personnel does not double the productivity • Each additional person complicates communication requirements • Management needed to control resources does not increase productivity, just merely makes sure it is completed. • Meetings and conferences use time otherwise would have been dedicated to development and testing.

  8. Object Oriented Paradigm • Consist both of the action and data views • A more realistic abstraction of the “Real World” • What is it? • “ Superficially the term object oriented means that we organize software as s collection of discrete objects that incorporate both data structure and behavior” • Four basic aspects of OOP • Identity • classification • polymorphism • inheritance

  9. IDENTITY OF OOP • The data is quantified into discrete, distinguishable entities called objects. Examples; • Paragraph in document • A window on a work station, • A white queen on a chess board • Each object can be uniquely identified • Each object has characteristics • An object can be concrete in the physical world sense or conceptual such as a scheduling routine inside a computer.

  10. CLASSIFICATION OF OOP • Objects with the same data structure (attributes) and behavior (operations) are grouped into a class. • Paragraphs • Windows on a work station • Pieces on a chess board • Each object is said to be an instance of that class. • Each object can be uniquely identified • Each object has characteristics • An object can be concrete in the physical world sense or conceptual such as a scheduling routine inside a computer.

  11. POLYMORHPISM • OF OOP • Means the same operation may behave differently on different classes. • Multiplication is different in basic arithmetic then it is in matrix algebra. • The move operation is different in Windows and Chess. • Adding two records is different then adding two numbers. • The point is to use the appropriate operation for the data and scenario.

  12. Inheritance OF OOP • Is the sharing of attributes and operations among classes based on a hierarchical relationship. • A class can be defined broadly and then refined into successively finer subclasses. • Each subclass incorporates, or inherits, all of the properties of the superclass. • Scrolling Window and Fixed Window are all subclasses of Windows and inherit its properties.

  13. Structured Paradigm Operations - Move_Dot_left - Move_Dot_Right - Move_Dot_Up - Move_Dot-Down

  14. Object Oriented Paradigm Operation - Move_Dot( direction) This has a few advantages. If we want to create a new direction such as diagonal directions, we do not have to create a new routine for the programmer but allow a new parameter and just modify the basic moves to the class.

  15. Build 1st Version Modify Until User is satisfied Build and Fix Model Operations Mode Retirement

  16. Specification Verify Integration Test Planning Verify Design Verify Implementations Test Change Requirement Verify Rapid Prototype Verify The basic Waterfall Model Operations

  17. Requirements Verify Specification Verify Integration Test Planning Verify Design Verify Implementations Test Change Requirement Verify Rapid Prototype Model Operations

  18. Requirements Verify Specification Verify Planning Verify Architectural Design Verify For each build: Do a detailed design, implementation, integration, and test Incremental Model Operations Mode Retirement Operations

  19. Risk Analysis Rapid Prototype Verify Risk Analysis Specification Verify Risk Analysis Planning Verify Risk Analysis Design Verify Risk Analysis Implementation Verify Risk Analysis Integration Verify Risk Analysis Change Req. Verify Operations Retirement

  20. Capability Maturity Model (CMM) Ref: 1986 by Watts Humphrey of the Software Engineering Institute at Carnegie-Mellon University. The Model incorporates both technical and managerial aspects of software production. CMM Level 1: Lowest level. There are essentially no sound software engineering practices. Success of projects is entirely dependent upon competent staff. Usual pattern is time and cost overruns. Most all organizations fall into this category. CMM Level 2: Basic software management practices are in place. Measurements are used to spot problems and avoid crisis. Planning and management are based upon experience with previous products. (Repeatable processes) CMM Level 3: Software production is fully documented. Management and technical aspects are clearly defined. Training both management and technical staff is of equal importance. CASE tools are used to improve the quality and efficiency. Level 3 is the highest an organization has reached to date.

  21. Capability Maturity Model (CMM) CMM Level 4: Organizations set quality and productivity goals for each product. The two quantities are continually measured and corrective action taken. A simple example of statistical quality is the number of faults per 1000 lines of code. The goal is to continually reduce this. CMM Level 5: The highest level means there are controls in place to have continuous process improvement. The knowledge gained from each product is used in all future products. The process thus incorporates a positive feedback loop, resulting in a steady improvement in productivity and quality over time. Chart from Schach Page 75 CMM Level Months Man Months Faults Faults Cost Found left 1 29.8 593.5 1,348 61 $5,440K 2 18.5 143.0 328 12 $1,311K 3 15.2 79.5 182 7 $ 728K 4 12.5 42.8 97 5 $ 392K 5 9.0 37.0 37 1 $ 146K

More Related