1

SOFTWARE ENGINEERING

CHAPTER-1 INTRODUCTION TO SOFTWARE ENGINEERING

WHAT IS SOFTWARE ?

Computer programs and associated documentation

3

Software products may be developed for a particular customer or may be developed for a general market

Software products may beGeneric - developed to be sold to a range of

different customersBespoke (custom) - developed for a single

customer according to their specification

4

What is software engineering?

Software engineering is an engineering discipline which is concerned with all aspects of software production.

Software engineers should adopt a systematic and organised approach to their

work use appropriate tools and techniques depending on

the problem to be solved, the development constraints and the resources available

5

What is the difference between software engineering and computer science?

Computer Science Software Engineeringis concerned with

Computer science theories are currently insufficient to act as a complete base for software engineering,

BUT it is a foundation for practical aspects of software engineering

theory fundamentals

the practicalities of developing delivering useful software

6

What is the difference between software engineering and system engineering? Software engineering is part of System

engineering System engineering is concerned with all aspects

of computer-based systems development including hardware, software and process engineering

System engineers are involved in system specification, architectural design, integration and deployment

7

What Is Software?

Computer software is the product that

software professionals design and build.

It encompassesProgramsContentDocuments

8

Who Does It? Software engineers build it.Virtually everyone in the industrialized world usesit either directly or indirectly.

Why Is It Important? Software affects nearly every aspect of our lives.

What Are The Steps? You build software like you build any successfulproduct, by applying a process that leads to a high-quality result.

9

What Is the Work Product?

From the view point of a software engineer, the

work product is the programs, documents, and

content (data).

From the user’s viewpoint, the work product is the

resultant information that somehow makes the

user’s world better.

10

1.1 The Evolving Role of Software

Software takes on a dual role: A productDelivers the computing potential embodied bycomputer hardware

The vehicle for delivering a productActs as the basis for the control of the computer

(OS), the communication of information (networks), and the creation and control of other programs (software tools and environments)

The most important product: Information.

11

Software-Related Problems

Scenario: The widespread use of computers has made society increasingly dependent on reliable operation of software.

Consequence: Enormous economic damage and potential human suffering can occur when software fails.

Our Objective: build computer software that has high reliability and quality.

Threats: Our ability to support and enhance existing programs is threatened by poor design and inadequate resources.

12

An Industry Perspective

In the early days of computing, computer-based

system were developed using hardware-oriented

management.

Project managers focused on hardware.

Project managers applied the controls, methods,

and tools that we recognize as hardware

engineering.

13

In the early days ...

In the early days, programming was viewed as

an “art form.”

The programmer often learned his/her craft by

trial and error.

The software world was virtually undisciplined.

14

Today ...

Today, the distribution of costs for the

development of computer-based systems has

changed dramatically.

Software, rather than hardware, is the largest single cost item.

15

Questions

For almost two decades managers and many technical practitioners have asked the following

questions: Why does it take so long to get programs finished ? Why are development costs so high ? Why can’t we find all errors before we give the

software to our customers? Why do we continue to have difficulty in measuring

progress as software is being developed?

16

SOFTWARE:-

Definition of Software may take the following form:

(1) Instructions (computer programs) that

when executed provide desired function

and performance,

(2) Data (contents) that enable the programs to

Adequately manipulate information, and

(3) Documents that describe the operation and use

of the programs.

17

Software Characteristics:

Software does not wear out.

Useful life phase

Wear out

phase

Burn-inphase

Fai

lure

Int

ensi

ty

Time

18

Software is not manufactured but developed or engineered

Software Characteristics:

Reusability of components

Software is flexible

19

Comparison of constructing a bridge vis-à-vis writing a program.

Sr.No

Constructing a bridge Writing a program

1.

2.

3.

4.

5.

6.

7.

Software Characteristics:

The problem is well understood Only some parts of the problem are understood, others are not

There are many existing bridges

The requirement for a bridge typically do not change much during constructionThe strength and stability of a bridge can be calculated with reasonable precisionWhen a bridge collapses, there is a detailed investigation and report

Engineers have been constructing bridges for thousands of years

Materials (wood, stone,iron, steel) and techniques (making joints in wood, carving stone, casting iron) change slowly.

Every program is different and designed for special applications.Requirements typically change during all phases of development.Not possible to calculate correctness of a program with existing methods.

When a program fails, the reasons are often unavailable or even deliberately concealed.Developers have been writing programs for 50 years or so.

Hardware and software changes rapidly.

20

SystemSoftware

Real Time Software

Embedded Software

Engineering and Scientific

Software

Web basedSoftware

Artificial Intelligence

SoftwarePersonal

Computer Software

BusinessSoftware

1.3 The Changing Nature of Software

21

The Changing Nature of Software

Trend has emerged to provide source code to the customer and organizations.

Software where source codes are available are known as open source software.

Examples

Open source software: LINUX, MySQL, PHP, Open office, Apache webserver etc.

22

The Change Nature of SW

New Challenges Ubiquitous computing- information processing has been

thoroughly integrated into everyday objects and activities.

Netsourcing- Outsourcing applications that run on the Web. Since the browser provides universal access to Web content and applications, an application can run on a third-party Web server as

easily as it can on an internal Web server (intranet)

Opensource

23

Software Myths

Unlike ancient myths, software myths

propagates misinformation and confusion

that have caused serious problems for

managers, technical people, and customers.

24

Management Myths :-

Myth:-We already have a book that’s full of standardsand procedures for building software. Won’t that provide my people with everything they need to know?

Reality:-The book of standards may very well exist, but is it used? Is it complete? In many cases, the answer is no.

25

Myth:-

If we get behind schedule, we can add more

Programmers and catch up.

Reality:-

Software development is not a mechanistic

Process like manufacturing. “Adding people to a

late software project makes it later.”

26

Myth:-If I decide to outsource the software project to a third party, I can just relax and let thatfirm build it.

Reality:-If an organization does not understand how to manage and control software projectsInternally, it will invariably struggle when itout-sources software projects.

27

A general statement of objectives is sufficient to get started with the development of software. Missing/vague requirements can easily be incorporated/detailed out as they get concretized.

If we do so, we are heading towards a disaster.

Software Myths (Customer Perspectives)

28

Myth:-

Project requirements continually change,

but change can be easily accommodated

because software is flexible.

Reality:-

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

29

Practitioner’s (Developer’s) Myths:-

Myth:-Once we write the program and get it to work, our job is

done.

Reality:-“The sooner you begin writing code, the longer it’ll take

you to get done.”

Industry data indicate that between 60 and 80% of all effort expended on software will be expended after it is delivered to the customer for the first time.

30

Myth:-Until I get the program running, I have no way of a

assessing its quality.

Reality:-

One of the most effective software quality

assurance mechanisms can be applied from the

Inception of a project- the formal technical reviews.

31

Myth:-The only deliverable work product for a successful project is the working program.

Reality:-A working program is only one part of a software configuration that includes many elements.

Documentation provides a foundation for successful engineering and, more importantly, guidance for software support.

32

Myth:-Software engineering will make us createvoluminous and unnecessary documentationand will invariably slow us down.

Reality:-Software engineering is not about creating

documents. It is about creating quality. Better quality leads to reduced network. And reduced rework results in faster delivery times.

CHAPTER-2

A GENERIC VIEW OF PROCESS

Chapter Overview

• What? A software process – a series of predictable steps that leads to a timely, high-quality product.

• Who? Managers, software engineers, and customers.

• Why? Provides stability, control, and organization to an otherwise chaotic activity.

• Steps? A handful of activities are common to all software processes, details vary.

• Work product? Programs, documents, and data.• Correct process? Assessment, quality deliverable.

2.1 Software Engineering-A Layered Technology

a “quality” focusa “quality” focus

process modelprocess model

methodsmethods

toolstools

QUALITY:-

Any engineering approach must rest on an

Organizational commitment to quality.

The bedrock that supports software engineering is

a quality focus.

PROCESS:- It defines a frame work that must be established for effective

delivery of software engineering technology.

This framework is for a set of key process areas (KPAs)

It forms the basis for management control of software projects and establishes the context in which (tmwqc) technical methods are applied, milestones are established, work products (documents, models, data, reports, forms,

etc.) are produced, quality is ensured and change is properly managed.

Process defines “what to” establish in a context.

METHODS:-

S/W engineering methods provide the technical “how to’ s” for building s/w.

Methods encompass a broad array of tasks

that include communication, requirements analysis, design modeling, program construction, testing and support.

Methods defines “how to” establish the “what to’s” stated in the process.

Tools:-

Software technology tools provide automated or semi-automated support for the process and the methods.

When tools are integrated so that information created by one tool can be used by another, a system for the software development, called Computer-Aided Software Engineering (CASE) is

established.

2.2 A Process Frame Work

It’s a set of guidelines, concepts and best practices that describes high level processes in SE.

A Process framework establishes the foundation

for a complete software process identifying a small

number of framework activities that are applicable

to all software projects, regardless of their size or

complexity.

Ex: Eclipse Process Framework, Microsoft Solutions Framework.

A Common Process Framework

The process framework encompasses a set of Umbrella activities that are applicable across the entire software process (irrespective of SDLC stages)

The following generic (common) process framework activities are applicable to the vast majority of software projects:

Activity Objective

Communication customer collaboration and requirements gathering

Planning establishes engineering work plan, describes technical risks, lists resource requirements, work products produced, and defines work schedule

Modeling creation of models to help developers and customers understand the requirements and software design

Construction code generation and testing

Deployment software delivered for customer evaluation and feedback

Umbrella Activities

1. Software project management (SPM)

2. Formal technical reviews (FTR)

3. Software quality assurance (SQA)

4. Software configuration management (SCM)

5. Document preparation and production

6. Reusability management (Ru.M)

7. Measurement

8. Risk management (RM)

Attributes for Comparing Process Models

1.Overall flow of activities and tasks.

2.Degree to which works tasks are defined within each frame work.

3.Degree to which work product identified and required.

4.Manner of applying quality assurance.

5.Process description degree.

6.Level of autonomy (uncentralization) given to the software project team.

7.Degree of involving customer and stakeholders in project.

8.Degree to which team organization &roles are prescribed.

2.3 Capability Maturity Model Integration

(CMMI)

Definition : Capability Maturity Model Integration (CMMI) is a process improvement approach that helps organizations improve their performance.

Capability levels

1. Level 0: Incomplete (Ad-hoc)

2. Level 1: Performed (Repeatable)

3. Level 2: Managed

4. Level 3: Defined

5. Level 4: Quantitatively managed

6. Level 5: Optimized

CMMI Staged Representation - 5 Maturity Levels

Level 5

Initial

Level 1

Processes are unpredictable, poorly controlled, reactive.

Managed

Level 2

Processes are planned, documented, performed, monitored, and controlled at the project level. Often reactive.

Defined

Level 3 Processes are well characterized and understood. Processes, standards, procedures, tools, etc. are defined at the organizational (Organization X ) level. Proactive.

Quantitatively Managed

Level 4

Processes are controlled using statistical and other quantitative techniques.

Optimizing

Proce

ss M

atur

ity

Process performance continually improved through incremental and innovative technological improvements.

Key Process Areas (KPAs) for Development Model

Maturity Level 2 - Managed CM - Configuration Management MA - Measurement and Analysis PMC - Project Monitoring and

Control PP - Project Planning PPQA - Process and Product Quality

Assurance REQM - Requirements Management SAM - Supplier Agreement

Management

Maturity Level 3 - Defined DAR - Decision Analysis and

Resolution IPM - Integrated Project

Management OPD - Organizational Process

Definition OPF - Organizational Process Focus OT - Organizational Training

Management

6. PI - Product Integration 7. RD - Requirements

Development 8. RSKM - Risk Management 9. TS - Technical Solution 10. VAL - Validation 11. VER - Verification

Maturity Level 4 - Quantitatively Managed

OPP - Organizational Process Performance

QPM - Quantitative Project Management

Maturity Level 5 - Optimizing CAR - Causal Analysis and

Resolution OPM - Organizational

Performance Management

Capability levels:-

Level 0: Incomplete.

The Process area is either not performed or does not achieve all goals and objectives defined by the CMMI for level 1 capability.

Level 1: Performed. (Initial=Incomplete + Performed)

All of the specific goals of the process area have been satisfied. Work tasks required to produce defined work production are being conducted.

Level 2: Managed.1. All work associated with the process area conforms to

an organizationally defined policy;

2. All people doing the work have access to adequate

resources to get the job done;

3. Stakeholders are actively involved in the process

area as required;

4. All work tasks and work products are “monitored, controlled, and reviewed;

Level 3: Defined.

The process is “tailored from the organization’s set

of standard processes according to the

organization’s tailoring guidelines, and contributes

work products, measures, and other

process-improvement information to the

organizational process assets” .

Level 4: Quantitatively managed.

“Quantitative objectives for quality and

process performance are established and

used as criteria in managing the process”.

Level 5: Optimized.

The process area is adapted and optimized using

quantitative means to meet changing customer

needs and to continually improve the efficacy of

the process area under consideration.

Behaviors at the Five Levels

Initial

Managed

Defined

QuantitativelyManaged

Optimizing

Process is unpredictable,poorly controlled, and reactive

Process is characterized for projects and is oftenreactive

Process is characterizedfor the organization andis proactive

Process is measuredand controlled

Focus is on continuousquantitative improvement

Maturity Level Process Characteristics Behaviors

Focus on "fire prevention";improvement anticipated anddesired, and impacts assessed.

Greater sense of teamwork and inter-dependencies

Reliance on defined process. People understand, support and follow the process.

Over reliance on experience of goodpeople – when they go, the processgoes. “Heroics.”

Focus on "fire fighting";effectiveness low – frustration high.

Key Process Areas (KPAs)

The SEI has associated KPAs with each maturity levels.

The CMMI defines each process area in terms of “specific goals” and the “specific practices” required to achieve these goals.

Specific goals establish the characteristics that must exist if the activities implied by a process area are to be effective.

Specific practices refine a goal into a set of process-related activities.

CMMI Terminology & Structure

Maturity Levels (1 - 5)

GenericPractices

GenericGoals

Process Area 2

Common Features

Process Area 1 Process Area n

VerifyingImplementation

SpecificGoals

SpecificPractices

Abilityto Perform

DirectingImplementation

RequiredRequired

Sub practices, typical work products, discipline amplifications, generic practice elaborations, goal and

practice titles, goal and practice notes, and references

Commitmentto Perform

Sub practices, typical work products, discipline amplifications, generic practice elaborations, goal and

practice titles, goal and practice notes, and references

Informativ

eInformative

Required. Specific for each process area.

Required. Common across all process areas.

CMMI Components Within each of the 5 Maturity Levels, there are basic

functions that need to be performed – these are called Process Areas (PAs). For Maturity Level 2 there are 7 Process Areas that must be

completely satisfied. For Maturity Level 3 there are 11 Process Areas that must be

completely satisfied. Given the interactions and overlap, it becomes more efficient to

work the Maturity Level 2 and 3 issues concurrently. Within each PA there are Goals to be achieved and within each

Goal there are Practices, work products, etc. to be followed that will support each of the Goals.

The specific goals (SG) and specific practices (SP)

defined for project planning are:-

SG 1: Establish estimates

SP: 1. Estimate the scope of the project

2.Establish estimates of work product and

task attributes.

3. Define project life cycle.

4. Determine estimates of effort and cost.

SG 2: Develop a project plan

SP: 1. Establish the budget and schedule

2. Identify project risks

3. Plan for data management.

4. Plan for project resources.

5. Plan for needed knowledge and

skills.

6. Plane stakeholder involvement.

7. Establish the project plan.

SG 3: Obtain commitment to the plan

SP: 1. Review plans that affect the

project.

2. Reconcile work and resource levels.

3. Obtain plan commitment.

The Generic goals (GG) and practices (GP) for the

project planning process area are:

GG 1: Achieve specific goals

GP: 1. Perform base practices.

GG 2: Institutionalize a managed process

GP: 1. Establish an organizational policy

2. Plan the process.

3. Provide resources.

4. Assign responsibility.

5. Train people.

6. Manage configurations.

7. Identify and involve relevant

stakeholders.

8. Monitor and control the process.

9. Objectively evaluate adherence.

10. Review status with higher level

management.

GG 3: Institutionalize a defined process

GP: 1. Establish a defined process.

2. Collect improvement information.

GG 4: Institutionalize a quantitatively managed process.

GP: 1. Establish quantitative objectives for the

project.

2. Stabilize subprocess performance.

GG 5: Institutionalize a Optimizing process.

GP: 1. Ensure continuous process

improvement.

2. Correct root cause of problems.

2.4 Process Patterns Process Patterns define a set of activities, actions, work

task , work products and /or related behaviours.

Templates or methods for describing important characteristics of software processes .

Examples:- Customer Communication( Process activity ) Analysis( An action ) Requirement gathering( Process task ) Design model ( Work Product ) Software teams can combine software patterns to

construct processes that best meet the needs of specific projects

Generic software pattern elements :-Pattern Name Intent (objective of pattern) Type

Task pattern (defines engineering action or work task)

Stage pattern (defines framework activity for the process)

Phase pattern (defines sequence or flow of framework activities that occur within process

Initial context (describes conditions that must be present prior to using pattern)

Problem (The Problem to be solved by the pattern is described).

Solution (describes how to implement pattern correctly)

Resulting context (describes conditions that result when pattern has been implemented successfully)

Related patterns (links to patterns directly related)

Known uses/examples (instances in which pattern is applicable)

2.5 Process Assessment

The Process should be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for a successful software engineering. Many different assessment option are available.-SCAMPI-CBA IPI-SPICE-ISO 9001:2000

Standard CMMI Assessment Method for

Process Improvement (SCAMPI):-It provides a five-step process assessment model

that incorporates initiating, diagnosing, acting,

establishing learning.

CMM-Based Appraisal for Internal Process

Improvement (CBA IPI):-Provides a diagnostic technique for assessing the

relative maturity of a software organization.

SPICE (ISO/IE15504):-SPICE (ISO/IE15504) standard defines a set of

requirements for process assessment

ISO 9001:2000:-ISO 9001:2000 for Software defines

requirements for a quality management system that will produce higher quality products and improve customer satisfaction

Assessment and Improvement

Software Process

Software ProcessAssessment

Software ProcessImprovement

CapabilityDetermination

Is examined by

Identifies capabilities and risk of

Leads toLeads to

Motivates

Identifies

Modifications to

2.6 Personal and Team Process Models

1. Personal Software Process (PSP):-

The Personal Software Process (PSP)

emphasizes personal measurement of both the

work product that is produced and the resultant

Quality of the work product .

What is PSP?The Personal Software Process shows engineers how to

1. Manage the quality of their projects. 2. Make commitments they can meet. 3. Improve Estimating and Planning. 4. Reduce defects in their products.

The PSP can be used by engineers as a guide to a disciplined and structured approach to developing software.

The PSP can be applied to many parts of the

software development process, including small-program development requirement definition document writing systems tests systems maintenance

enhancement of large software systems

The PSP process model defines the five

framework activities:

1. Planning:- This activity isolates requirements.

2. High-Level Design:-External Specifications.

3. High-Level Design Review:-Formal verification.

4. Development:- The component level design.

5. Postmortem:- The effectiveness of the process is determined.

2. Team Software Process (TSP):-

The goal of TSP is to build a “Self-Directed”

Project team that organizes itself to produce high-

quality software.

What is TSP?The Team Software Process (TSP), along

with the Personal Software Process (PSP),

helps the high-performance engineer to Ensure quality software products Create secure software products Improve process management in an

organization

Objectives of TSP:- Build self-directed teams that plan and track their work,

establish goals, and own their processes and plans

Show managers how to coach and motivate their teams and maintain peak performance

Accelerate software process improvement by making Level 5 behavior normal and expected

Provide improvement guidance to high-maturity organizations

Facilitate university teaching of industrial team skills

TSP defines the following framework activities: 1. Launch

2. High-Level Design

3. Implementation

4. Integration and test

5. Postmortem.

Each project is “launched” using a sequence of tasks

To establish a solid basis for starting the project.

Review project objectives with management and agree on and document team goals.

Establish team roles. Define the team’s development process. Make a quality plan and set quality targets. Plan for the needed support facilities. Make a development plan for the entire project.

Make detailed plans for each engineer for the next phase.

Merge the individual plans into a team plan. Rebalance team workload to achieve a minimum

overall schedule. Assess project risks and assign tracking

responsibility for each key risk.

PROCESS MODELS

Overview

Prescriptive process models prescribe a distinct set of activities, actions, tasks, milestones, and work products required to engineer high quality software.

Prescriptive software process models are adapted to meet the needs of software engineers and managers for a specific project.

Prescriptive software models provide stability, control, and organization to a process that if not managed can easily get out of control.

Framework activities for a particular process model may be organized into a process flow that may be linear, incremental, or evolutionary.

The software engineer's work products (programs, documentation, data) are produced as a consequence of the activities defined by the software process.

The best indicators of how well a software process has worked are the quality, timeliness, and long-term viability of the resulting software product.

Prescriptive Models

Originally proposed to bring order to the chaos of software development.

They provide reasonable guidance to software teams.

Yet, they have not provided a definitive answer to the problems of software development in an ever changing computing environment.

The Waterfall Model

When the requirements of a problem are reasonably well understood- when work flows are reasonably linear fashion.

It may also occur in a limited number of new development efforts, but only when requirements are well defined and reasonably stable.

The Waterfall model, is also called the Classic life cycle, a systematic sequential approach to s/w developments that begins with customer specification of requirements and progresses through planning, modeling, construction, and deployment.

The Waterfall model is the oldest paradigm for s/w engineering.

The Waterfall Model:-

Communication

Planning

Modeling

Construction

Deployment

Advantages of Waterfall Model

1. Easy to understand and implement.2. Widely used and known (in theory!).3. Reinforces good habits: define-before- design, design-before- code.4. Identifies deliverables and milestones5. Works well on mature products and weak teams.6.Testing is inherent to every phase of the waterfall model.7. It is an enforced disciplined approach8. It is documentation driven, that is, documentation is produced at every stage.

Problems or Disadvantages of Waterfall Model

1. Real projects rarely follow the sequential flow that the model proposes.

2. It is often difficult for the customer to state all requirements explicitly.

3. The customer must have patience. A working version of the programs will not be available until

late in the project time-span.

The linear nature of the waterfall model leads to “blocking states” .

Incremental Process Model

The Incremental Model

The RAD Model (Rapid Application Development)

The Incremental Model

COM

PLMOD

CONDEP

COM

PL

MOD

CON

DEP

COM

PL

MOD

CON

DEP

INCREMENT-1

INCREMENT-2

INCREMENT-N

The Incremental Model

The Incremental model combines elements of the waterfall model applied in an iterative fashion.

Each Linear sequences produces deliverable “increments” of the software.

The incremental process model is iterative in nature.

Early increments are “Stripped down” versions of the final product.

Incremental development is particularly useful when Staffing is unavailable.

Early increments can be implemented with fewer people.

Rapid Application Development

Similar to waterfall but uses a very short development cycle (60 to 90 days to completion).

Uses component-based construction and emphasises reuse and code generation.

Use multiple teams.

Requires heavy resources.

Requires developers and customers who are heavily committed.

Rapid Application Development

com

Plan

Mod

Con

Mod

Con

Mod

Con

Dep

60-90 days

Team# 1

Team # 2

Team #n

The RAD approach maps into the generic framework activities:-

Communication

- The business problem

- information characteristicsPlanningModeling

-Business Modeling

-Data Modeling

-Process Modeling

Construction

-Component reuse

-Automatic Code generation

-TestingDeployment

-Integration

-Delivery

-Feedback

Drawbacks of RAD Model:-

1. For large, but scalable projects.2. If Developers and customers are not

committed , project fails.3. If a system cannot be properly modularized, building the components necessary for RAD

will be problematic.4. If high performance is an issue, RAD approach

may not work.5. RAD may not be appropriate when technical risks are high.

3.4 Evolutionary Process Model

S/w engineers need a process model that has been explicitly designed to accommodate a product that evolves over time.

Evolutionary models are Iterative.

They are characterized in a manner that enables software engineers to develop increasingly more complete versions of the software.

1. Prototyping:-

Specifying requirements is often very difficult. Users don’t know exactly what they want until

they see it. Prototyping involves building a mock-up of the

system and using to obtain for user feedback. Mechanism for identifying requirements. Users like the method, get a feeling for the

actual system.

Prototyping:-

Quick Plan

Communication ModelingQuick Design

Deployment Delivery& Feedback

Construction of prototype

2. The Spiral Model :-

A different approach born of the evolution of the waterfall model.

The Spiral model, originally proposed by Boehm , is an evolutionary s/w process model that couples the iterative nature of prototyping.

More complete versions of the s/w. S/w is developed in a series of evolutionary

releases.

During early iterations- a paper model or prototype.

During later iterations - complete versions are produced.

Spiral Model :-

communication

planning

modeling

constructiondeployment delivery feedback

start

analysis design

code test

estimation scheduling risk analysis

A Spiral model is divided into a set of frame work activities defined by the s/w engineering team.

Risk is considered as each revolution is made.

Process is represented as a spiral rather than as a sequence of activities with Backtracking.

Anchor point milestones- are noted for each revolutionary pass.

Unlike other process model , the spiral model can be adapted to apply throughout the life of the computer s/w.

The first circuit around the spiral might represents a “Concept development project” at core of the spiral.

In later iterations- “new product development project” commences.

Still later iterations – “product enhancement project”.

Whenever a change is initiated, the process starts at that appropriate entry point. Example: product enhancement.

Realistic approach to the development of large-scale system.

Difficult to convince customer.

3. Concurrent Development Model

The concurrent development model, sometimes called concurrent engineering, can be represented schematically as a series of frame work activities.

The activity-modeling- may be in any one of the states noted at any given time. Similarly, other activities or tasks can be represented in an analogous manner.

Example: Communication or construction All activities exist concurrently but reside in

different states.

Concurrent Development Model

Under review

Baselined

Done

Under

revision

Awaiting

changes

Under

development

none

Modeling activity

represents the stateof a software engineeringactivity or task

The Concurrent process model is applicable to all types of s/w development and provides an accurate picture of the current state of the project.

3.5 Specialized Process Models

Special Process models take on many of the characteristics of one or more of the conventional models.

1. Component – Based Development

2. Formal Method Model

3. Aspect – Oriented Software Development

1. Component – Based Development

Commercial off-the shelf (COTS) s/w components, can be used when s/w is to be built.

The Component – based development model incorporates many of the characteristics of the spiral model.

It is evolutionary in nature , iterative approach to the creation of s/w.

Modeling and construction activities begin with the identification of candidate components.

The component – based development model incorporates the following steps:-

Available component-based products are researched and evaluated for the application domain in question.

1. Component integration issues are considered.2. A Software architecture is designed to

accommodate the components. 3. Component are integrated into the architecture.4. Comprehensive testing is conducted to ensure

proper functionality.

The Component – based development models leads to software reuse and a number of measurable benefits.

2. The Formal Methods Model

The formal methods model encompasses a set of activities that leads to formal mathematical specifications of computer s/w.

Formal methods model provide a mechanism, for eliminating many of the problems that are difficult to overcome using other s/w engineering paradigms.

Ambiguity, incompleteness and inconsistency can be discovered and corrected more easily.

Offers Defect-free software.

The formal methods model are not widely used due to :-

1. The development of formal model is currently quite time-consuming and expensive.

2. Because few s/w developers have the necessary background to apply formal methods, extensive training is required.

3. It is difficult to use the models as a communication mechanism for technically

unsophisticated customers.

3.6 The Unified Process

Unified Process —a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)

Phases of the Unified Process

software increment

Release

Inception

Elaboration

construction

transition

production

The Inception Phase of the UP encompasses both customer communication and planning activities.

Business requirements, rough architecture, plan for the iteration, incremental nature of the ensuring projects is developed by using Use-cases

Use-cases help to identify the scope and basis for the project planning.

Planning identifies resources, assesses major risks, defines a schedule and establishes a basis for the phases.

The Elaboration phase encompasses the customer communication and modeling activities of the generic process model.

Elaboration refines and expands the preliminary use-cases and expands the architectural representation to include five different views of the s/w –

the use-case model, the analysis model, the design model, the implementation model, the deployment model.

Elaboration creates an “executable architectural baseline”.

The Construction phase of the Unified Process-

Using the architectural model as input, the construction phase develops or acquires the software components that will make each use-case operational for end-user.

Tests are conducted.

The Transition Phase of the Unified Process- Software is given to end-users for beta testing,

and user feedback reports both the defects and necessary changes.

The s/w team creates necessary support information.

Example: User manuals, trouble shooting guides and installation procedures.

The five UP phases do not occur in a sequence, but rather with staggered concurrency.

Unified Process Work Products

Inception phase Vision document Initial use-case model Initial project glossary Initial business case Initial risk assessment Project plan (phases and iterations) Business model Prototypes

Elaboration phase Use-case model Functional and non-functional requirements Analysis model Software architecture description Executable architectural prototype Preliminary design model Revise risk list Project plan (iteration plan, workflow,

milestones) Preliminary user manual

Construction phase Design model Software components Integrated software increment Test plan Test cases Support documentation (user, installation,

increment)

Transition phase Delivered software increment Beta test reports User feedback

Software Engineering Why should we take a course on that?

Motivation

Software can have a hugeimpact in any aspect of society.

Importance of software

Where can you find software?

Some popular ones…

Some popular ones…

Some popular ones…

And even in…

Conclusion

Software is Almost Everywhere.

Problems in software development

•The final Software doesn´t fulfill the needs of the customer.

•Hard to extend and improve: if you want to add a functionality later is mission impossible.

•Bad documentation.

•Bad quality: frequent errors, hard to use, ...

•More time and costs than expected

Common issues

But

That never happens,

right?

Wrong!

Ariane 5 Flight 501

Cause: design errors in the software

Chaos Report

It is not enough to do your best: you must Know what to do, and THEN do your best.-- W. Edwards Deming

Conclusion

Programming is NOT enough!

And Since…

A clever person solves a problem. A wise person avoids it.- Albert Einstein

Solution

Software Engineering

The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software. -Wikipedia

What is it?

???

Software Engineering

The study and application of methodologies to develop quality software that fulfill customer needs.

What is it?

Software EngineeringObjetive

To produce software that is:

• On time: is deliver at the established date.

• Reliable: doesn´t crash.

• Complete: good documentation, fulfill customer needs.

The team

Stages for software development

Requirements Analysis

Software Design

Implementation

Testing

Maintenance

1. Requirements Analysis

Find out what the client want the software to do

2. Design

Planning the software solution

3. Implementation

Code!!!

4. Testing

Executing the application trying to find software bugs

5. Maintenance

Any activity oriented to change an existing software product.

References

•http://upload.wikimedia.org/wikipedia/commons/thumb/a/a2/Avianca_767-200_at_El_Dorado.JPG/800px-Avianca_767-200_at_El_Dorado.JPG •http://www.nosoloviajeros.com/imagenes/colombia/transmilenio.jpg •http://files.nireblog.com/blogs1/keniecita/files/celular-2.jpg •http://www.fayerwayer.com/up/2008/06/iphone3g.jpg •http://www.slideshare.net/soreygarcia/ingenieria-de-software-para-dummies •http://www.projectsmart.co.uk/docs/chaos-report.pdf •http://www.evilaliens.com/images/software_engineering_explained.gif•http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html•http://stackoverflow.com/questions/84556/whats-your-favorite-programmer-cartoon •http://stuffthathappens.com/blog/2008/03/05/simplicity/•http://www.troyangrignon.com/dilbertsoftwarerequirements.jpg•http://www.phdcomics.com/comics/archive/phd120804s.gif•http://www.phdcomics.com/comics/archive/phd011406s.gif