Part 1 - Product and Process Final

8/14/2019 Part 1 - Product and Process Final

1/80

Innovation

Software Engineering.Software Engineering

Think Differently


2/80

Software Engineering


PART I The Product and the Process

PART II Managing Software Projects

PART III Conventional Methods for Software Engineering

PART IV Object Oriented Software Engineering

PART V Advanced Topics in Software Engineering

INTRODUCTION Class Orientation


3/80


Introduction - Course Objectives

PART I PART II PART III PART IV PART VINTRODUCTION

At the end of the semester, the students are expected to:

Define software engineering, its processes and products. Enumerate the steps to be done during software development. Enumerate available models with their functionalities useful in software

engineering. Identify each person with their roles in software development. Identify the conventional methods in software engineering. Define Object-Oriented Software Engineering and its processes involved. Design a Software Engineering guided document. Create an Information System guided by Software Engineering models and

methodologies. Develop values on critical thinking in dealing IS problems and provide

alternative solutions.


4/80


Introduction - Books/References


Books/References

Pressman, Roger S., Software Engineering, A Practitioners Approach, 5

th

Edition, McGrawHill International Edition, Computer Science Series, 2001

Shari, Lawrence, Pfleeger,Software Engineering, Theory and Practice, 2ndEdition, Low PriceEdition, Pearson Education Asia, 2001

Sommerville, I, Sofware Engineering7th ed.Pearson, 2004


5/80



Introduction Software Engineering

What is Software Engineering?

Software engineering is the application of a systematic, disciplined, quantifiableapproach to the development, operation, and maintenance of software. Software engineering is the establishment and use of sound engineering principles

in order to obtain economically software that is reliable and works efficiently on realmachines.

Why study Software Engineering?


6/80


Part I The Product and the Process


CHAPTER I The Product

Objectives:

Define Software Describe the characteristics of a software Give Examples of a software application Distinguish the facts from fictions in Software

Development Cite scenarios and identify the appropriate software to be

used.


7/80




CHAPTER I The Product /2

What is a Software?

Instructions (Computer Programs) that when executed,provide desired function and performance.

Characteristics Developed/Engineered, not manufactured Dont wear out

Most software continues to be custom built.


8/80





Software Applications

System Software collection of programs written toservice other programs. (e.g. Drivers, OS components) Real-time Software monitors/analyzes/controls real-

world events as they occur. Business Software business information processing Engineering and Scientific Software processing of

scientific information, calculation algorithms. Embedded Software reside in read-only memory and isused to control products and systems for consumer andindustrial markets. (e.g. keypad control for microwaveoven).


9/80





Software Applications

Personal Computer Software word processors,spreadsheets, graphics, multimedia, etc. Web-based Software web pages. Artificial Intelligence Software uses non-numerical

algorithms to solve complex problems that are notamenable to computation or straightforward analysis.


10/80





Software Myths

Myth -We already have a book that's full of standardsand procedures for building software, won't that providemy people with everything they need to know?

Reality The book of standards may very well exist, butis it used? Are software practitioners aware of itsexistence? Does it reflect modern software engineeringpractice? Is it complete? Is it streamlined to improve timeto delivery while still maintaining a focus on quality? Inmany cases, the answer to all of these questions is "no."


11/80





Software Myths

Myth -My people have state-of-the-art software development tools,after all, we buy them the newest computers.

Reality It takes much more than the latest model mainframe,workstation, or PC to do high-quality software development.Computer-aided software engineering (CASE) tools are moreimportant than hardware for achieving good quality and productivity,yet the majority of software developers still do not use themeffectively.


12/80





Software Myths

Myth -If we get behind schedule, we can add more programmersand catch up (sometimes called the Mongolian horde concept).

Reality Software development is not a mechanistic process likemanufacturing. In the words of Brooks [BRO75]: "adding people to alate software project makes it later." At first, this statement may seemcounterintuitive. However, as new people are added, people whowere working must spend time educating the newcomers, therebyreducing the amount of time spent on productive development effort.People can be added but only in a planned and well-coordinatedmanner.


13/80





Software Myths

Myth -If I decide to outsource the software project to a third party, Ican just relax and let that firm build it.

Reality If an organization does not understand how to manageand control software projects internally, it will invariably strugglewhen it outsources software projects.


14/80


15/80





Software Myths

Myth -Project requirements continually change, but change can beeasily accommodated because software is flexible.

Reality It is true that software requirements change, but theimpact of change varies with the time at which it is introduced.


16/80





Software Myths

Myth -Once we write the program and get it to work, our job is done. Reality Someone once said that "the sooner you begin 'writing

code', the longer it'll take you to get done." Industry data ([LIE80],[JON91], [PUT97]) indicate that between 60 and 80 percent of alleffort expended on software will be expended after it is delivered tothe customer for the first time.


17/80





Software Myths Myth -Until I get the program "running" I have no way of assessing

its quality.

Reality One of the most effective software quality assurancemechanisms can be applied from the inception of a projecttheformal technical review. Software reviews (described in Chapter 8)are a "quality filter" that have been found to be more effective thantesting for finding certain classes of software defects.


18/80





Software Myths Myth -The only deliverable work product for a successful project is

the working program.

Reality A working program is only one part of a softwareconfiguration that includes many elements. Documentation providesa foundation for successful engineering and, more important,guidance for software support.


19/80





Software Myths Myth - Software engineering will make us create voluminous and

unnecessary documentation and will invariably slow us down.

Reality Software engineering is not about creating documents. It isabout creating quality. Better quality leads to reduced rework. Andreduced rework results in faster delivery times.


20/80





Brainstorming Give examples of software applications.

Business Education Etc.


21/80





Summary

Software has become the key element in the evolution of computer-based systems and products. Over the past 50 years, software hasevolved from a specialized problem solving and information analysis toolto an industry in itself. But early programming culture and history havecreated a set of problems that persist today. Software has become thelimiting factor in the continuing evolution of computer based systems.

Software is composed of programs, data, and documents. Each of theseitems comprises a configuration that is created as part of the softwareengineering process. The intent of software engineering is to provide aframework for building software with higher quality.


22/80




CHAPTER I The Product

Review: Define Software Describe the characteristics of a software Give Examples of a software application Distinguish the facts from fictions in Software

Development Cite scenarios and identify the appropriate software to be

used.


23/80




END OF CHAPTER I The Product

Assignment: What is a Software Process? Give examples of Software Process Models


24/80



CHAPTER II The Process

Objectives: To define Software Process

To describe the importance of Software Process

To be able to list down different Software Process Models

To be able to compare and contrast the different Software ProcessModels


25/80



CHAPTER II The Process/2

What is a Software Process?

A framework for the tasks that are required to build a high-quality software.

Defines the approach that is taken as software isengineered.


26/80




Software Engineering A Layered Technology / 1

Process, Methods and Tools Software engineering is a layered technology, and like any

engineering approach, rests on an organizational commitment toquality


27/80





Process Layer

Foundation of software engineering. Defines a framework for a set of key process areas that must be

established for effective delivery of software engineeringtechnology.


28/80





Methods Layer

Provide the technical how-tos for building software. Tasks include requirements analysis, design, program

construction, testing, and support


29/80





Tools Layer

Provide automated or semi-automated support for the process andthe methods


30/80





Generic Characteristics of a Software Process:

Definition identification of key requirements of thesystem and software. Answers the question What?

Development describe the way things are done.Answers the question How?

Support Covers the steps of the Definition andDevelopment phases but in the context of a finishedproduct (existing software). Focuses on Change.


31/80



CHAPTER II - The Process


The Definition Phase: What information is to be processed? What function and performance are desired?

What system behavior can be expected?

What interfaces are to be established?

What design constraints exist?

What validation criteria are required to define a successful system?


32/80





3 Major tasks in the Definition Phase:

1. System / Information Engineering (Ch 10)

2. Software Project Planning (Ch 3,5,6,7)

3. Requirements Analysis (Ch 11,12,21)


33/80





The Development Phase: How data are to be structured? How function is to be implemented within a software architecture?

How procedural details are to be implemented?

How interfaces are to be characterized?

How the design will be translated into a programming language?

How testing will be performed?


34/80





3 Major Tasks in the Development Phase:

1. Software Design (Ch 13, 16, 22)

2. Code Generation

3. Software Testing (Ch 17,18, 23)


35/80





4 types of Changes in the Support Phase: Correction Uncover Defects

Adaptation Adjust to external environment changes

Enhancement Additional functions that provide benefit

Prevention Make Correction, Adaptation, and Enhancementeasy to do when a change occurs that might make the software

deteriorate.


36/80

P I Th P d d h P


37/80




The Software Process / 1

Common Process Framework

P t I Th P d t d th P


38/80




The Software Process / 2

Capability Maturity Model

5 Point Grading Scheme in assessing an organizations state ofprocess maturity

Level 1 Initial

Level 2 Repeatable

Level 3 Defined

Level 4 Managed

Level 5 - Optimizing



39/80




Software Process Models / 1

What is a Software Process Model?

Development Strategy that encompasses the differentlayers that make up Software Engineering (Process,Methods, Tools).



40/80





Phases of a Problem Solving Loop



41/80





Phases within phases of a Problem Solving Loop



42/80





Linear Sequential Model

Prototyping Model RAD Model

Other (Evolutionary Software Process Models) Incremental Model

Spiral Model WINWIN Spiral Model

Concurrent Development Model



43/80






Also called Classic Lifecycle/Waterfall Model Activities:

System/Information engineering and modeling Software Requirements Analysis Design

Code Generation Testing Support



44/80







45/80



46/80





Linear Sequential Model Activities

Software Requirements Analysis Requirements gathering is intensified and focused primarily on

software.

Requirements for both system and software are documented andreviewed with the customer.



47/80






Design Focuses on 4 distinct attributes of a program

Data Structure

Software Architecture

Interface representations

Procedural (Algorithmic) details Documented



48/80






Code Generation Translate design into machine readable form.



49/80






Testing Ensure all statements have been tested.

Uncover errors

Ensure that a defined input will produce actual results that agreewith required results.



50/80






Support Accommodate Change



51/80





Criticisms on Linear Sequential Model Real projects rarely follow the sequential flow that the model

proposes. Although the linear model can accommodate iteration, itdoes so indirectly. As a result, changes can cause confusion as theproject team proceeds.

It is often difficult for the customer to state all requirementsexplicitly. The linear sequential model requires this and hasdifficulty accommodating the natural uncertainty that exists at thebeginning of many projects.

The customer must have patience. A working version of theprogram(s) will not be available until late in the project time-span. Amajor blunder, if undetected until the working program is reviewed,can be disastrous.



52/80





Prototyping Model

Prototype serves as a mechanism for identifying softwarerequirements.

Activities: Requirements Gathering

Quick Design



53/80




Software Process Models /15

Prototyping Model



54/80





Criticisms on the Prototyping Model

The customer sees what appears to be a working version of thesoftware, unaware that the prototype is held together with chewinggum and baling wire, unaware that in the rush to get it working noone has considered overall software quality or long-termmaintainability. When informed that the product must be rebuilt sothat high levels of quality can be maintained, the customer criesfoul and demands that "a few fixes" be applied to make the

prototype a working product. Too often, software developmentmanagement relents.



55/80




Criticisms on the Prototyping Model

The developer often makes implementation compromises in orderto get a prototype working quickly. An inappropriate operatingsystem or programming language may be used simply because itis available and known; an inefficient algorithm may beimplemented simply to demonstrate capability. After a time, thedeveloper may become familiar with these choices and forget allthe reasons why they were inappropriate. The less-than-ideal

choice has now become an integral part of the system.



56/80




RAD (Rapid Application Development

is an incremental software development process modelthat emphasizes an extremely short development cycle.

Activities: Business Modeling

Data Modeling

Process Modeling

Application Generation

Testing and Turnover



57/80




RAD Activities

Business Modeling What information drives the business process?

What information is generated?

Who generates it?

Where does the information go?

Who processes it?



58/80




RAD Activities

Data Modeling The information flow defined as part of the business modeling

phase is refined into a set of data objects that are needed tosupport the business. The characteristics (called attributes) of eachobject are identified and the relationships between these objectsdefined.



59/80




RAD Activities

Process Modeling The data objects defined in the data modeling phase are

transformed to achieve the information flow necessary toimplement a business function. Processing descriptions arecreated for adding, modifying, deleting, or retrieving a data object.



60/80




RAD Activities

Application Generation RAD assumes the use of fourth generation techniques (Section

2.10). Rather than creating software using conventional thirdgeneration programming languages the RAD process works toreuse existing program components (when possible) or createreusable components (when necessary). In all cases, automated

tools are used to facilitate construction of the software.



61/80




RAD Activities

Testing and Turnover Since the RAD process emphasizes reuse, many of the program

components have already been tested. This reduces overall testingtime. However, new components must be tested and all interfacesmust be fully exercised.



62/80




RAD Drawbacks

For large but scalable projects, RAD requires sufficienthuman resources to create the right number of RADteams.

RAD requires developers and customers who arecommitted to the rapid-fire activities necessary to get a

system complete in a much abbreviated time frame. Ifcommitment is lacking from either constituency, RADprojects will fail.



63/80




RAD Drawbacks

Not all types of applications are appropriate for RAD. If a systemcannot be properly modularized, building the componentsnecessary for RAD will be problematic. If high performance is anissue and performance is to be achieved through tuning theinterfaces to system components, the RAD approach may notwork.

RAD is not appropriate when technical risks are high. This occurswhen a new application makes heavy use of new technology orwhen the new software requires a high degree of interoperabilitywith existing computer programs.



64/80




Incremental Model

Linear Sequential + Prototyping



65/80




Incremental Model

Focuses on delivery of an operational product with each increment.

Example: Word Processing Application

1st Increment: basic file management, editing

2nd Increment: more sophisticated editing

3rd Increment: Spelling and Grammar

Prototyping paradigm can be incorporated within each increment.

Useful when staffing is unavailable for a complete implementation by abusiness deadline that has been established for the project.



66/80




Spiral Model


67/80

Part I The Product and The Process


68/80



Software Process Models /30

Spiral Model

Addresses Customer Communication Realistic approach in large scale systems and software.

Demands a risk assessment expertise and relies on it forsuccess.

Not widely used as the other paradigms.



69/80




WINWIN Spiral Model

Elicit project requirements from the customer



70/80




WINWIN Spiral Model

Added Activities: Identification of the system or subsystems key stakeholders.

Determination of the stakeholders win conditions.

Negotiation of the stakeholders win conditions to reconcile theminto a set of win-win conditions for all concerned (including the

software project team).



71/80




WINWIN Spiral Model

Anchor Points: Life Cycle Objectives (LCO), defines a set of objectives for

each major software engineering activity. Life Cycle Architecture (LCA) establishes objectives that must

be met as the system and software architecture is defined. Initial Operational Capability (IOC) Represents a set of

objectives associated with the preparation of the software for

installation/distribution, site preparation prior to installation, andassistance required by all parties that will use or support thesoftware.



72/80




Concurrent Development Model

Sometimes called ConcurrentEngineering

is often used as the paradigm for thedevelopment of client/server applications.

is applicable to all types of softwaredevelopment and provides an accurate

picture of the current state of a project.



73/80



Component-Based Development / 1

Incorporates many of the characteristics of the spiralmodel.

model composes applications from prepackaged softwarecomponents (called classes).



74/80



Component Based Development / 2

Identification of candidate classes.

The class library is searched to determine if thesecandidate classes exist.

If candidate classes dont exist, they are engineered usingobject oriented methods.


75/80



76/80



Formal Methods Model

Enable a software engineer to specify, develop, and verifya computer-based system by applying a rigorous,

mathematical notation. Defect Prevention



77/80



Fourth Generation Techniques (4GT)

Enables the software engineer to specify somecharacteristic of software at a high level.

The tool then automatically generates source code basedon the developer's specification.

Part I - The Product and The Process

CHAPTER II Th P


78/80



Fourth Generation Techniques (4GT) / 2

Currently, a software development environment thatsupports the 4GT paradigm includes some or all of thefollowing tools: nonprocedural languages for database query, report generation, data manipulation, screen interaction and definition, code generation; high-level graphics capability; spreadsheet capability, automated generation of HTML and similar languages used for

Web-site creation using advanced software tools.


CHAPTER II Th P


79/80



Summary

Software engineering is a discipline that integratesprocess, methods, and tools for the development of

computer software. A number of different process modelsfor software engineering have been proposed, eachexhibiting strengths and weaknesses, but all having aseries of generic phases in common.


CHAPTER II Th P


80/80



Review:

Define Software Process

Describe the importance of Software Process

List down different Software Process Models

Documents

Part 1 - Product and Process Final