Introduction to Software Engineering

Download Report

Transcript Introduction to Software Engineering

CS 3141: Team Software Project – Introduction to Software Engineering

Ali Ebnenasir Department of Computer Science Michigan Technological University

Acknowledgement

   Evelyn Stiller Cathie LeBlanc Betty H.C. Cheng

What is Software Engineering?

 Systematic approach for developing software  Methods and techniques to develop and maintain quality software to solve problems. (Software Engineering: Methods and Management, Pfleeger, 1990)  Study of the principles and methodologies developing and maintaining software systems. for (``Perspectives on Software Engineering,'' Zelkowitz, 1978)

What is Software Engineering?

 Practical the design and construction of computer programs and the associated required to develop, operate, and maintain them. application of scientific knowledge in documentation (``Software Engineering,'' Boehm, 1976)  Deals with establishment of to sound engineering principles and methods in order economically obtain software that is reliable and works on real machines. (``Software Engineering,'' Bauer, 1972)

Why Engineer Software?

    Air traffic control case study – $2.3 Billion spent without any usable deliverable Enormous social cost of NOT engineering software Too many large-scale software development failures for too many decades Software development initiatives fail for many different reasons, most of which are addressed by good software engineering practices

Sources of Complexity in Software Development

    Technical staff lacks expertise in the complex application domain Difficulty in interpersonal communications Ambiguity of natural language, used to express user needs Difficulty of mentally grasping and coordinating the details of a large-scale development project

How Software Development Projects Fail

     No functioning software results The resulting software does not adequately address the need of the users Software contains incorrect computations The software is too difficult to use correctly The system response time is too slow to be used without frustration

Why Inter-personal Communication is Difficult

    Technical staff and end users have different background knowledge Technical staff often do not possess the vocabulary used in the application domain End users frequently do not understand how to effectively express their needs in terms that are clear to systems developers.

Ambiguity of natural language

Maintaining Software Systems

     Maintenance is an inevitable aspect of software development It allows software to evolve with an organization Too often too many resources are directed to maintenance and away from new development Software requires excessive maintenance efforts if it is poorly structured It is better to invest in well-structured software up front than to invest excessively in maintenance later

Elements of a Software Development Paradigm

   Conceptualization – What elements are instrumental in how the developers think about the software system?

Representation – Must convey what the software project is all about – Most effectively done with a software modeling notation Implementation – Addresses how the source code is structured

A Brief History of Software Engineering Techniques

   Structured Programming – No gotos Functional Decomposition – Top-down organization of subprograms Structured Analysis – – Recognition that analyzing the problem statement has critical influence on the success of the overall project Formal modeling of subprogram interaction with dataflow diagrams

More History of SE Techniques

  Data-centered analysis – Uses techniques developed in structured analysis – Data modeling occurs using entity relationship diagrams before functional modeling Object-oriented analysis – No longer segregates the modeling of functions and data – Objects aggregate data with functions that operate on the data

Sample Dataflow Diagram

Check for overdue books Patron ID True/false Patron ID Patron record or null Read Patron record Check-out books Book ID, out Change book status Book ID Book record Book record Write book record Read book record

Sample Entity Relationship Diagram

Library Patron Has-a 1:M Checks out Requests 1:M Book Has-a Address Has-a Publisher

Principles of the Object Oriented Paradigm

      Abstraction Modularity Modeling Shared by other paradigms Inheritance Encapsulation(covered later) Polymorphism(covered later)

Abstraction

   Expressing the user requirements in abstract terms, suppressing details so that a comprehensive portrayal can be made The abstract representation must then be connected to more detailed expressions, so that no information is lost in modeling the system This allows us to reason about the breadth of functionality of the developing system

Modularity

    Breaking a complex software system into smaller modules allows reduces its overall complexity Modules should aggregate some coherent aspect of the system Modules should present a simple interface Classes, functions, and abstract data types are examples of modules.

Abstract Data Type Example

S T A C K

Accesses

Interface

POP() PUSH(item) ISEMPTY() 12 24 98 33 13 13 98 24 Implementation Option: Array Implementation Option: Linked list

Modeling

   Modeling is the process of use a graphic notation to express requirements and properties of the software system Models express how the system is built out of modules and how these modules interact One objective of modeling is to express characteristics of the software system in an unambiguous manner, which is very difficult!

Inheritance

 A property distinguishing classes from abstract data types  Allows characteristics from one class to be passed on its subclasses  Subclasses may override inherited characteristics

Cost of not Engineering Software

        Need to restructure code High maintenance costs Software is unacceptable to end users Unreliable code Need to rewrite code Difficulty integrating system modules Difficult project management Budget and time overruns

Why Software Engineering is not Universal

    Understanding software development as programming only without recognition of importance of analysis and design Short-sighted technical management Pressure of deadlines Poor project estimation, thus unreasonable deadlines

Software Engineering Phases and Process Models

Software Engineering Phases

 Definition: What?

 Development: How?

 Maintenance: Managing change  Umbrella Activities: Throughout lifecycle

Definition

 Requirements definition and analysis – Developer must understand  Application domain  Required functionality  Required performance  User interface

Definition (cont.)

 Project planning – – – – Allocate resources Estimate costs Define work tasks Define schedule  System analysis – Allocate system resources to  Hardware  Software  Users

Development

 Software design – User interface design – High-level design  Define modular components  Define major data structures – Detailed design  Define algorithms and procedural detail

Development (cont.)

 Coding – Develop code for each module – Unit testing  Integration – Combine modules – System testing

Maintenance

 Correction - Fix software defects  Adaptation - Accommodate changes – New hardware – New company policies  Enhancement - Add functionality  Prevention - make more maintainable

Umbrella Activities

 Reviews - assure quality  Documentation - improve maintainability  Version control - track changes  Configuration management - integrity of collection of components

Development Process

  Step-by-step procedure to develop software Typically involves the major phases: – – – – analysis design coding testing

Process Model / Methodology

      Set of activities, notations, tools, in defined sequence Goal: Order, predicitability, quality, cost control Follows requirements=>design=>coding, etc. sequence (usually) Usually defines phases or steps Often has notations Sometimes has tools

Waterfall Process Model

Requirements Design Coding Testing Maintenance

Prototyping Process Model

Requirements Quick Design Prototype Evaluate Design

When to use prototyping?

   Help the customer pin down the requirements – – Concrete model to “test out” Often done via the user interface Explore alternative solutions to a troublesome component – e.g., determine if an approach gives acceptable performance Improve morale – Partially running system provides visibility into a project Never press down a prototype to final product!

Spiral Process Model

Planning Risk Analysis Customer Evaluation Engineering

Process Models

 Idealized view of the development process  Different models are often used for different subprocesses – may use spiral model for overall development  prototyping for a particularly complex component  waterfall model for other components

CMM: Capability Maturity Model

 Level 1: Initial – – ad hoc success depends on people  Level 2: Repeatable – track cost, schedule, functionality  Level 3: Defined – use standardized processes  Level 4: Managed – collect detailed metrics  Level 5: Optimizing – – continuous process improvement “built-in” process improvement Software Engineering Institute: http://www.sei.cmu.edu/cmm/

Why is software development so difficult

?

 Communication – – Between customer and developer  Poor problem definition is largest cause of failed software projects Within development team   More people = more communication New programmers need training  Project characteristics – Novelty – – – Changing requirements   5 x cost during development up to 100 x cost during maintenance Hardware/software configuration Real time requirements

Why is software development difficult

?

(cont.)  Personnel characteristics – Ability – Prior experience – – – Communication skills Team cooperation Training  Facilities and resources – – Identification Acquisition   Management issues – Realistic goals – Cost estimation – – – – – Scheduling Resource allocation Quality assurance Version control Contracts Crosscutting concerns – Availability requirements – – – Security requirements Reliability requirements Correctness/High assurance

Summary

   Software lifecycle consists of – – – Definition (what) Development (how) Maintenance (change) Different process models concentrate on different aspects – Waterfall model: maintainability – – Prototype model: clarifying requirements Spiral model: identifying risk Maintenance costs much more than development

Bottom Line

 U.S. software is a major part of our societal infrastructure – Costs upwards of $200 billion/year  Need to – – Improve software quality Reduce software costs/risks 42

Impact of SE Research

   Impact of research is measured over time and utility Who do you think has had the most impact on the field of software engineering? Why?

People you should know…

David Parnas

: modularity, reuse, abstraction 

Edsger Dijkstra

: structured programming 

Harlan Mills

: clean room programming 

Mark Weiser

: ubiquitous computing

Software vs. Hardware Engineering

Hardware and Hardware Engineering

  Characteristics: – – – – Components are packaged as individual building blocks Standardized interfaces among components Large number of off-the-shelf components Performance, cost, and availability easily determined/measured Hardware configuration built from a hierarchy of "building blocks"

Hardware Engineering

 Phases to system engineering of hardware: – Development Planning and requirements analysis: –     best classes of hardware for problem availability of hardware type of interface required identification of what needs to be designed and built Establish a Plan or "road map" for design implementation     May involve a hardware specification – Use Hardware Description Languages (HDL) Use CAE/CAD to develop a prototype (breadboard) Develop printed circuit (PC) boards Manufacturing of boards

  

Software and Software Engineering

Function may be the implementation of a sequential procedure for data manipulation Performance may not be explicitly defined (exception in real-time systems) Software element of computer-based system consists of two classes of programs, data, and documentation – Application Software: –  implements the procedure that is required to accommodate information processing functions System Software:  implements control functions that enable application software to interface with other system elements

Three high-level phases of Software Engineering

 Definition phase: – Software planning step  – Software Project Plan     scope of project risk resource identification cost and schedule estimates Software Requirements Analysis  Specification Requirements –     System element allocated to software is defined in detail Formal information domain analysis to establish models of information flow and structure (expand to produce specification) Prototype of software is built and evaluated by customer Performance requirements or resource limits defined in terms of software characteristics Definition and Requirements must be performed in cooperation

Development Phase

  Development Phase: – Translate set of requirements into an operational system element –   Design  Design Specification Coding (appropriate programming language or CASE tool) Should be able to directly trace detail design descriptions from code.; i.e., traceability Verification, release, and maintenance phase: – Testing software  Testing Plan – –   to find maximum number of errors before shipping Testing shows software has errors, it does not show the lack of errors!

Prepare software for release  Quality Assurance Maintain software throughout its lifetime

Working in Teams

    Be conscientious about due dates Meet regularly with your team Always create an agenda for every team meeting Rotate responsibility for chairing team meetings