We Are Here!

We Are Here!

PART I CLASSICAL SOFTWARE ENGINEERING 1 Building a System Moving from writing a program to building a system. Whats the difference?! Complexity, size, Complexity, size ------ Complexity Breadth of Complexity Depth of Complexity 2

Complexity (Breadth) More functionalities More features within each functionality More varieties of interfaces (internal & external) More users and varieties of users More data, varieties of data, data structures

3 Complexity (Depth) More linkages and connections Data sharing among the functionalities & logic Control passing among functionalities 4 Handling Complexities (A) Via simplification Decomposition of the problem and of the solution Modularization of solution Separation of concerns of problem and of solution

Incrementally resolve problems *** Not advertised but a sometimes used technique is: REDUCE the problem. 5 Handling Complexities (B) Via improving technology and tools Database to handle information and structures of information Programming and dev. platforms Computing network Multi-developer configuration management Modeling techniques of problem and solution

Automated testing Note: the first time you use these, it will actually be more complex. 6 Task Breakdown (Macro) Example (Handling Complexity) 1. Who performs what task? 2. How is the task completed with what technique or tool? 3. When should which task start and end? 4. Who should coordinate the people and the tasks? 7

Iterative Process Example (Handling Complexity) 8 Handling the Details Separately Seemingly simple test/fix and integrate steps:

Should there be separate and independent test group? How should problem be reported and to whom? How much information must accompany a problem report? Who decides on the priority of the problem? How is the problem fix returned? Should all problems be fixed? What should we do with non-fixed problem? How are fixes integrated back to the system? 9 With the increase in system complexity, there is a corresponding

increase in the manpower or human resources. For n people, number of potential communications paths = (n1) = [n*(n1)] / 2 Increase in amount of communications as # of people increases. Also, an increase in the number of communications errors committed. 10 A Large, Complex System Building mission-critical or business- critical system (e.g., payroll in textbook) requires (1) several separate activities performed by (2) more than one person (e.g., 50 ~ 100):

Requirements: gathering, analysis, specification, and agreement Design: abstraction, decomposition, cohesion, interaction, and coupling analysis Implementation: coding and unit testing Integration and tracking of pieces and parts Separate testing: functional testing, component testing, system testing, and performance testing Packaging and releasing the system 11 Coordination Efforts Required in Systems Development and Support

Because there are (i) more parts, (ii) more developers, and (iii) more users to consider in large systems than a single program developed by a single person for a limited number of users, there is the need for coordination of (3Ps): Processes and methodologies to be used Final product and intermediate artifacts People (developers, support personnel, and users) The previous diagram on people increase and potential communication paths increase provides a clue to the importance of coordination efforts. 12 Effort vs. Software Product Quality

13 Complexity vs. Software Product Quality? Complexity vs. Software Dev. Effort? What type of relationship can we expect? Complexity Complexity ? Software Product Quality

? Software Development Effort 14 Software costs Software costs often dominate system costs. The costs of software on a PC are often greater than the hardware cost Software costs more to maintain than it does to develop. For systems with a long life,

maintenance costs may be several times development costs Software engineering is concerned with costeffective software development 15 Engineering Software As size and complexity of software projects increased, so did the number of failed projects. Engineering software was thought to be the cure: 1. Put some discipline into programming. 2. Do more than just coding/programming. 3. Study (model/measure), Understand (analyze), and Improve (change) this field!

16 Chaos Report and Software Project Success/Failures Chaos Report (1995) sampled some 300 software projects and reported that only about 16% of those projects completed, on time, and within budget! That is 84% of projects failed! Chaos Report (2009) stated that software projects have improved with 32% completed, on time, and within budget. That is still 68% of projectsfailure!

17 Chaos 2014 Report 39% successful software projects 43% challenged software projects (late, over budget, or less functionality) 18% failed software projects (cancelled or never used) This means we still have 61% project failures. 18 Software Project Success & Failure Factors

(Chaos Report) Profiling attributes for projects that succeeded User involvement Executive management support Clear requirements Proper planning Profiling attributes for challenged (completed & operational but

over budget and over time estimate) Lack of user input Incomplete user requirements and specification Changing requirements and specifications Profiling attributes for impaired and ultimately cancelled Incomplete requirements Lack of user involvement Lack of resources 19 Software Product Failures (Capers Jones Study)

Code errors : Design errors : Documentation errors : Requirements errors : Bad-fix errors :

38.33% 24.17% 13.33% 12.50% 11.67% All errors can be serious and very costly but Should we worry about coding more or requirements more Why? Requirements errors are very costly if not detected & left in the product Why? 20 Coordination & Non-Technical Concerns

As software projects grew in size and complexity, problems went beyond just code and software. Other non-technical issues became apparent: 1. Executive commitment and leadership 2. Thorough planning of both business and technical processes 3. Skilled and experienced work force 4. Management focus and project monitoring 5. Willingness to make changes and adjustments 21 US General Accounting Office Report

to US Senate (2004) 3 key strategies to ensuring delivery of: (a) High-quality software (b) On time and (c) Within budget 1. Focused attention on software development environment (people/tools/management/etc.) 2. Disciplined development process 3. Methodical use of metrics to gauge cost, schedule, and functional performance targets 22 Birth of Software Engineering The early experiences of writing difficult but small

programs did NOT provide us with the road map when we started to build large operating system, database, commercial system, etc. What is needed to develop large and complex software products and what is needed to control such projects? More discipline is needed in this field. SOFTWARE ENGINEERING!!! (NATO conference 1968) 23 Software engineering

The economies of ALL nations are dependent on software More and more systems are software controlled Software engineering is concerned with theories, methods and tools for professional software development Software engineering expenditure represents a significant fraction of GNP in all developed countries 24 What Is Software Engineering? David Parnas multi-person construction of multi-version software.

Sommerville an engineering discipline whose focus is the cost-effective development of high-quality software system. Pfleeger application of computing tools to solving problems. CMU/SEI-90-TR-003 form of engineering that applies the principles of What are these? computer science and mathematics to achieving cost-effective solutions to software problems. IEEE std 610-1990 application of a systematic, disciplined, quantifiable approach to the i) development of, ii) operation of, and iii) maintenance of software.

Curriculum Guideline: creating high quality software in a systematic, controlled, and efficient manner. CMU/SEI = Carnegie Mellon University/Software Engineering Institute 25 Software Engineering (Tsui and Karam) Software engineering is a broad field that touches upon all aspects of (a) developing and (b) supporting a software system, spanning across the following key areas: 1. Technical and business processes

2. Specific methodologies and techniques 3. Product characterization and metrics for measurements 4. People skills and team work 5. Project coordination and management 26 Difference between SE and computer science? Computer science is concerned with theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software

Computer science theories are currently insufficient to act as a complete underpinning for software engineering 27 Relevancy of Software Engineering Software is a serious business. Reached $180 billion in 2000. It is ubiquitous across multiple industries. Software is a commodity of increasing value. The business of software has graduated from a garage operation to an enterprise profession including

recent Facebook. We need to treat software engineering as an engineering profession. 15 universities have received accreditation (2009) from accreditation board of engineering and technology. 28 Software Engineering Professionals There is no equivalent professional engineer (PE) designation for software engineers, yet. Except in Texas where the board of professional engineers adopted software engineering as a specific discipline under which an engineering license may be issued.

29 Updated Information 1. Software industry in 2013 is $407 billion business (Gartner report). 2. We now (2014) have 22 US universities with accredited software engineering programs (ABET report). 30 A Simpler Set of Behavioral Rules Respect others.

Strive for fairness. Perform to ones best capability. Follow the law. 31 General Principles Different from other engineering disciplines such as civil or mechanical, there is no one set of universal principles in software engineering that is agreed upon by everyone. Neither is there any law of software engineering such as Newtons law of motion in physics. There are, however, several that are well received and respected.

Daviss Principles Royces Principles Wassermans Concepts 32 These Principles Address the Earlier Mentioned 3 key strategies to ensuring delivery of: (a) High-quality software (b) On time and (c) Within budget

1. Focused attention on software development environment (people/tools/management/etc.) 2. Disciplined development processes 3. Methodical use of metrics to gauge cost, schedule, and functional performance targets 33 Software Engineering Most Challenging Two Goals Software MUST BE on time! One of the most challenging elements of quality complex software development and therefore of software engineering is to deliver

it on schedule. Software MUST BE in budget! The other most challenging aspect of quality complex software development and therefore of software engineering is to deliver the software within budget. 34 Software Process Models 35

What Is a Process Model? It is a description of i) what tasks need to be performed in ii) what sequence under iii) what conditions by iv) whom to achieve the desired results. 36 Why Have a Process Model? Provide guidance for a systematic coordination and controlling of a) the tasks and

b) the personnel who perform the tasks Note the key words: coordination/control, tasks, people. 37 A Simple and Familiar Process 1. Most people perform and follow this simple process, but unfortunately some skip unit testing or debugging. 2. Also, some proceed without thoroughly considering & understanding the problem statementwhich is the requirement. 38

Extending the Simple Process As projects get larger and more complex: Needed to clarify and stabilize the requirements Needed to test more functionalities Needed to design more carefully Needed to use more existing software and tools Database Network

Code control Needed more people to be involved Resulting in more tasks and more people 39 With More People and More Tasks We now need to define: the set of tasks that need to be performed the sequence of flow of the tasks the input and the output from these tasks the pre-condition and post-conditions for each task

The people and skills needed to perform the tasks 40 Some Traditional Software Development Processes The earlier simple process was employed by many for years without formally embracing other important development activities such as requirements analysis, design, formal testing, or packaging. The recognition of the need for formal processes was initially driven by failures in developing large complex software.

Waterfall: earliest process and coping with no process Incremental: coping with decomposing the large systems Spiral: coping with risk management Rational Unified Process: coping with multiple development and management issues 41 Waterfall Model 1. Requirements must be specified.

2. Four main tasks must be completed in sequence: requirements, design, code, and test, followed by integration. 3. Output of one stage feeds into the next stage in sequence, and thus is easily tracked (controlled) by management.

42 The Waterfall Model: Another Version There are many representations of the waterfall model with several stages (more than 5) but for our practical purposes we will use 4 stages. Notice that coding occurs during the implementation stage. Requirements Definition System and Software Design Implementation and unit testing

Integration and system testing Operation and maintenance 43 1. Each major requirement/item is developed separately through the same sequence of: requirement, design, code, and unit test. 2. As the developed pieces are completed, they are continuously merged and integrated into a common bucket for integrated system test.

Incremental Model (A) Continuous Integration 44 Each small set of requirements is developed, packaged, and released in a multiple release fashion. Incremental Model (B) Multiple Releases 45 Spiral Model

Software development activities are cycled through four phases. A risk-averse process first proposed by Barry Boehm. 46 Every software development activity is addressed in the four phases of inception, elaboration, construction, and transition. Rational Unified Process (RUP)

47 Assessment of Software Organizations Software development and software support may be done with very little process or with very sophisticated, well-defined, wellorganized, and well-executed processes. How mature is your software engineering organization and do you need to improve? ISO (ISO 9000 series) and SEI (Software Engineering Institute at Carnegie Mellon) are two leading organizations that help in the process assessment. Matured Process No Process

Where are you in this wide spectrum? 48 SEIs Five Levels of Original Capability Maturity Model (CMM) Total of 18 processes need to be mastered to achieve optimized level. See page 7778 of your text for the 18 key processes. 49 SEIs CMMI In 2001, CMM was upgraded to CMMI (CMM

Integrated). Started with multiple, major aspects to CMMI: Systems engineering Software engineering Integrated product and process development Supplier sourcing 50 READ AT HOME: 25 Processes of CMMI There are 25 processes covering 4 major categories: Process Management (has 5 processes):

Organization process focus Organizational process definition Organizational training Organizational process performance Organizational innovation and deployment Project Management (has 8 processes):

Project planning Project monitoring and control Supplier agreement management Integrated project management Risk management Integrated teaming Integrated supplier management Quantitative project management

51 READ AT HOME: 25 Processes of CMMI (cont.) Engineering (has 6 processes) Requirements development Requirements management

Technical solution Product integration Verification Validation Support (has 6 processes) Configuration management

Process and product quality assurance Measurement and analysis Organizational environment for integration Decision analysis and resolution Causal analysis and resolution 52 READ AT HOME: Two Representations of CMMI The software engineering portion of CMMI has two representations: Staged: similar to the CMM assessment of organization Continuous: better for assessing maturity of each

process 53 READ AT HOME: Levels for Continuous versus Staged Models in CMMI 54 READ AT HOME: Continuous versus Staged Models In Continuous Representation, each process starts at capability level 0 and moves up the capability levels based on achieving generic goals and specific sub-goals.

Allows the organization to choose and pick the process to focus on based on the needs of the organization. Allows comparison of process area by process area between organizations. Allows easier migration from other standards. In Staged Representation, the organization starts at maturity level 1 and moves up the levels based on mastering sets of processes. Allows easy migration from the earlier CMM model. Provides a guidance of sequence of maturity by process areas. Allows easier comparison of organizations by maturity levels. 55

READ AT HOME: Achieving the Capability Levels by Each Process Area in the Continuous Representation Model 56 READ AT HOME: Five Generic Goals Goal 1 Achieve all the specific goals of the specific process. Goal 2 Institutionalize the managing of consistency of that process across organization. Goal 3 Institutionalize the defining of that process across the organization. Goal 4 Institutionalize quantitatively managing that process across the organization.

Goal 5 Institutionalize continuous optimizing/improving that process across the organization. 57 READ AT HOME: Achieving Maturity Level (ML) in the Staged Representation model ML1 (0 process): no process

ML2 (7 processes): 1) requirements management, 2) project planning, 3) project monitoring, 4) supplier agreement management, 5) measurement and analysis, 6) process and product quality assurance, 7) configuration management ML3 (14 processes): 1) requirements development, 2) technical solution, 3) product integration, 4) verification, 5) validation, 6) organizational process focus, 7) organizational process definition, 8) organizational training, 9) integrated project management, 10) risk management, 11) integrated teaming, 12) integrated supplier management, 13) decision analysis and resolution, 14) organizational environment for integration

ML4 (2 processes): 1) organizational process performance, 2) quantitative project management ML5 (2 processes): 1) organizational innovation and deployment, 2) causal analysis and resolution 58 Process Definition & Communication Two Main Components of Process Definition: Major activities

Sequencing of activities Most of the organizations need to modify an existing process to better fit their needs thus they must define in more detail and communicate the modified process definitions (a major endeavor). Expanding process definition to more refined level: Detailed description of the activities Control needed for entrance and exit of each activity and the ordering of the activities Artifacts that result from the activities Human resources required to perform the activities Tools that may be needed to aid the performance of the activities 59

Product and Process If the process is weak, the end product will undoubtedly suffer. Read Margaret Davis brief essay: Process and Product: Dichotomy or Duality. Software Engineering Notes, ACM Press, Vol. 20, No. 2, April, 1995, pp. 17-18. 60 OUR OWN SOFTWARE DEVELOPMENT MODEL AND ITS COST ??% Requirements

??% Design ??% Coding/Implementation ??% Testing 61 DO HERE SAMPLE PROBLEM # 1! 62 WE ARE HERE! 63

Recently Viewed Presentations

  • Acids and Bases

    Acids and Bases

    Applications of Aqueous Equilibria- ch. 8 . Buffers⇒ Solutions that can resist change in pH. Composed of a weak acid and it's conjugate base. 3 ways to make a buffer: 1. Mix a weak acid and it's conjugate base
  • Poetry Analytic Strategies

    Poetry Analytic Strategies

    After reading a poem are you left lost & confused? Never fear! Here are some strategies out there to help you out. While there are many more out there than just these, (Which I will call "The Big Four of...
  • Towards a cost-effective housing policy

    Towards a cost-effective housing policy

    Towards Cost-effective Housing Policies . Katleen Van den Broeck, Marietta Haffner, Sien Winters. 20/06/2016. Final event of the PROGRESS programme, Brussels
  • The Skeletal System - Bio Resource Site

    The Skeletal System - Bio Resource Site

    The Skeletal System Functions Framework for support Transmits movement Maintains shape Protects internal organs from mechanical injury Contains and protects the red bone marrow, one of the hemopoietic (blood-forming) tissues Mineral reservoir - storage site for excess calcium and phosphorus...
  • AMWG Report - Electric Reliability Council of Texas

    AMWG Report - Electric Reliability Council of Texas

    The Usage Report is a FANTASTIC piece of software to navigate in determining one's kWh usage. When I run the Report Type using "Daily Meter Reads" in the dropdown with a specified Start and End Date (beginning with the start...
  • New Opportunities for Direct Investment: Life ... - Tel Aviv

    New Opportunities for Direct Investment: Life ... - Tel Aviv

    & Aviv . Ratzman. Indigo, major global force in digital printing; HP acquisition ~$800M. Serial Entrepreneurs/Strong Backgrounds. Richard . Demb. Founded GC Zone, Founded Popcorn Indiana (acquired by Goldman Sachs) Eitan. Bauch & Avi. Yehuda.
  • Pédopsychiatrie - @formapsy

    Pédopsychiatrie - @formapsy

    L'enfant. D'une culture à l'autre, la place donnée à l'enfant dans la famille va être très différente. Par exemple : dans une famille x un enfant actif sera qualifié d'intelligent alors que dans une famille y il sera perçu comme...
  • Diapositive 1 - rbnj.unine.ch

    Diapositive 1 - rbnj.unine.ch

    Nouveau Avant: toujours sous la forme développée compactée : MacDonnell Après: la vedette peut être Mc Donnell ou Mac Donnell ou McDonnell, etc., suivant la forme trouvée dans le premier document catalogué + renvoi Jeu d'exemples 18 Saint, St., …