SOFTWARE SOFTWARE ENGINEERINGENGINEERING

SOFTWARE SOFTWARE ENGINEERINGENGINEERING

ObjectivesObjectives

• Have a basic understanding of the origins of Software development, in particular the problems faced in the Software Crisis

• Knowledge of the concepts of Software Engineering• Definition of Software Engineering, and the desired

Software Characteristics• The paradigms. For each paradigm, know the

associated diagram, description of the steps involved in it

• Ability to read a given scenario and recommend with justification the paradigm for it

• Ability to identify the continually changing nature of software development

The early years(50-60)

Second Era(60-Mid70s)

Third Era(70-mid80)

Fourth Era(80's and

beyond)

Batch orientationThe system

handles the job at once in sequence

Multiprogramming and Multi - User Systems.

Personal Computers came to be widely used.

Increased use of desktop systems

Limited Distribution

Computers were not widely used.

Software become distributed - this was the start of the software crisis.

Micro Computers also were used in other products

 Object Oriented

Technologies

They were highly customized - they were produced only to meet specific needs.

  Therefore there was a greater need for software

Expert SystemAIParallel

Computing

Software Crisis

The emergence of software engineeringThe emergence of software engineering

The emergence of software engineeringThe emergence of software engineering

The task description and the The task description and the requirements frequently change even requirements frequently change even during the program design phase, during the program design phase, and continue to change even after the and continue to change even after the software system has long since been software system has long since been in use. in use.

The major problemsThe major problems

CorrectnessCorrectnessEfficiencyEfficiencyMastery of ComplexityMastery of ComplexityInterface specificationInterface specification

Reliability    Reliability    FlexibilityFlexibilityDocumentationDocumentationMaintainabilityMaintainabilityProject organization.Project organization.

DEFINITION OF SOFTWAREDEFINITION OF SOFTWARE

Instructions (computer programs) on Instructions (computer programs) on execution provide desired function and execution provide desired function and performanceperformance

  Data structures that enable programs to Data structures that enable programs to adequately manipulate informationadequately manipulate information

  Documents that describes the operation and Documents that describes the operation and use of the programs use of the programs

Software and HardwareSoftware and Hardware

When hardware is built the human creative When hardware is built the human creative process (Analysis, Design, Construction, process (Analysis, Design, Construction, testing) is ultimately transferred into a physical testing) is ultimately transferred into a physical formform

  Software is logical rather than physical Software is logical rather than physical system element.system element.

Software is engineered (or developed) – it is Software is engineered (or developed) – it is not manufactured.not manufactured.

Software does not wear out.Software does not wear out.

Software Applications.Software Applications. Software may be applied in any situation for Software may be applied in any situation for

which a set of procedural – steps (algorithm) which a set of procedural – steps (algorithm) has been defined.has been defined.

Information content and determinacy are Information content and determinacy are important factions in determining the nature of important factions in determining the nature of software application.software application.

Content refers to the meaning and form of Content refers to the meaning and form of incoming and outgoing information. incoming and outgoing information.

Information determinacy refers to the Information determinacy refers to the predictability of the order of timing of information.predictability of the order of timing of information.

Software Engineering paradigms.Software Engineering paradigms.

Software Engineering is the technological, Software Engineering is the technological, managerial discipline concerned with managerial discipline concerned with systematic production and maintenance of systematic production and maintenance of software products that are developed and software products that are developed and modified one time.modified one time.

The primary goals of software engineering are The primary goals of software engineering are to improve the quality of software products and to improve the quality of software products and to increase the productivity and job to increase the productivity and job satisfaction of persons involved.satisfaction of persons involved.

Software Engineering being labor-intensive Software Engineering being labor-intensive activity, requires both technical and activity, requires both technical and managerial control.managerial control.

Software Engineering paradigms.Software Engineering paradigms. In very real sense , the software In very real sense , the software

engineer creates models of physical engineer creates models of physical situation in software. The mapping situation in software. The mapping between model and reality being between model and reality being modeled – has been called intellectual modeled – has been called intellectual distance between problem and distance between problem and computerized solution. The fundamental computerized solution. The fundamental principle of software engineering is to principle of software engineering is to design software products that minimize design software products that minimize the intellectual distance between the intellectual distance between problem and solution.problem and solution.

Software Engineering paradigmsSoftware Engineering paradigms

Software engineering is layered Software engineering is layered technology – An approach that must rest technology – An approach that must rest on organizational commitment to quality.on organizational commitment to quality.

The layers are The layers are ToolsTools MethodsMethods ProcessProcess A quality focusA quality focus

The bedrock that supports software engineering is a The bedrock that supports software engineering is a

quality focus.quality focus.

The foundation for Software Engineering is the The foundation for Software Engineering is the

process layer. process layer.

Software Engineering methods provides the technical Software Engineering methods provides the technical

know how-to for building software. know how-to for building software.

Software Engineering Tools provide automated or Software Engineering Tools provide automated or

semi automated support for the – process and semi automated support for the – process and

methods.  methods.  

Generic PhasesGeneric Phases

1.     1.     Formal technical reviewsFormal technical reviews

2.     Software QA2.     Software QA

3.     Software Configuration Management.3.     Software Configuration Management.

4.     Document preparation & production4.     Document preparation & production

5.     Reusability management5.     Reusability management

6.     Measurement6.     Measurement

7.     Risk Management.7.     Risk Management.

Software Development Life CycleSoftware Development Life Cycle

Classic life cycle suggests a systematic , Classic life cycle suggests a systematic , sequential approach that begins at sequential approach that begins at system level and progresses through system level and progresses through

Analysis Analysis DesignDesign Verification and ValidationVerification and Validation Support. Support.

Software Development Life CycleSoftware Development Life Cycle

Specification PhaseSpecification Phase Object-Oriented Analysis PhaseObject-Oriented Analysis Phase Design PhaseDesign Phase Implementation PhaseImplementation Phase Implementation and Integration Implementation and Integration

Phase Phase Maintenance PhaseMaintenance Phase

Software requirement AnalysisSoftware requirement Analysis

Focused specially on softwareFocused specially on software

Analyst must understand the information domain to Analyst must understand the information domain to

understand the nature of programs to be developed.understand the nature of programs to be developed.

The requirements for system and software are to be The requirements for system and software are to be

documented and reviewed by the customer.documented and reviewed by the customer.

Software DesignSoftware Design

Software Design is a multi step process Software Design is a multi step process

focuses on four distinct attributes of a program.focuses on four distinct attributes of a program.

Data StructureData Structure

Software architectureSoftware architecture

Interface representationInterface representation

Procedural logicProcedural logic

Code GenerationCode Generation

Design is translated into machine readable Design is translated into machine readable

form.form.

Can be automatedCan be automated

TestingTesting

Code TestingCode Testing Specification testingSpecification testing Uncovers errorsUncovers errors

SupportSupport Software may undergo change after Software may undergo change after

delivery due to errors.delivery due to errors.

Software must be adaptable to new Software must be adaptable to new environmentenvironment

Due to functional or performance enhance Due to functional or performance enhance suggested by customersuggested by customer

Project size categoriesProject size categories

Based on level of management Based on level of management control and types of tools and control and types of tools and techniquestechniques

Trivial projectTrivial project

One programmer working, sometimes part One programmer working, sometimes part time for few days, for exclusive use.time for few days, for exclusive use.

  Less than 500 statements & 10 - 20 sub Less than 500 statements & 10 - 20 sub routines. routines. 

Eg. PC Software, a little need for analysis Eg. PC Software, a little need for analysis documentation documentation

No No Extensive test planning essential. Extensive test planning essential. 

Small ProjectsSmall Projects

1 - 6 months effort of 1 programmer.1 - 6 months effort of 1 programmer.

1000 - 2000 lines of code.25 - 50 sub routines1000 - 2000 lines of code.25 - 50 sub routines

Less interaction between programmersLess interaction between programmers

Scientific calculations for engineering on small Scientific calculations for engineering on small

Commercial applicationsCommercial applications

Little interaction between customers and developers.Little interaction between customers and developers.

Medium Size ProjectsMedium Size Projects

2 - 5 Programmer’s team.2 - 5 Programmer’s team. 1- 2 years1- 2 years 10,000 – 50,000 lines10,000 – 50,000 lines 250 - 1000 routines250 - 1000 routines medium project sizemedium project size

Large ProjectsLarge Projects

5 - 20 programmer’s team5 - 20 programmer’s team 2 - 3 years duration2 - 3 years duration 50,000 to 1,00,000 lines of code50,000 to 1,00,000 lines of code Package in several systemPackage in several system

Eg. Large compilersEg. Large compilers

Very large ProjectsVery large Projects

100 - 1000 programmers100 - 1000 programmers 4 - 5 years4 - 5 years 1 million source instructions1 million source instructions Consists of several major sub systemsConsists of several major sub systems 0S/360 – 5000 programmers worked for 5 years0S/360 – 5000 programmers worked for 5 years

Extremely large projectsExtremely large projects

2000 - 5000 Programmers2000 - 5000 Programmers duration duration up to 10 yearsup to 10 years 100 million lines of code100 million lines of code Often distributed processing, MultitaskingOften distributed processing, Multitasking Requires high reliabilityRequires high reliability

Eg. Telecomm ,defense, air traffic controlEg. Telecomm ,defense, air traffic control

Problems in Software EngineeringProblems in Software Engineering

Potential Potential business problemsbusiness problems or occurrences that or occurrences that may cause the projectmay cause the project

Potential Potential project problemsproject problems or occurrences that may or occurrences that may cause the projectcause the project

Technical problemsTechnical problems or occurrences that may cause or occurrences that may cause the projectthe project

Conform to Conform to changeschanges in its external environment in its external environment analysisanalysis

Software Productivity factorsSoftware Productivity factors Individual abilityIndividual ability

Team communicationTeam communication

Product complexityProduct complexity

Appropriate notationsAppropriate notations

Systematic approachesSystematic approaches

Change controlChange control

Level of technologyLevel of technology

Required reliabilityRequired reliability

Software Productivity factorsSoftware Productivity factors Available timeAvailable time

Problem understandingProblem understanding

Stability of requirementsStability of requirements

Facilities and resourcesFacilities and resources

Management skillsManagement skills

Appropriate goalsAppropriate goals

Rising expectationsRising expectations

Project StructureProject Structure Project format. Project format.

Use of a project format involves Use of a project format involves

assembling a team of programmers who conduct a assembling a team of programmers who conduct a

project from start to finish; project team members project from start to finish; project team members

do product definition, design the product, do product definition, design the product,

implement it, test it, conduct project reviews, and implement it, test it, conduct project reviews, and

prepare the supporting documents. prepare the supporting documents.

Project StructureProject Structure

Functional format. Functional format.

In the functional approach to In the functional approach to

organization, a different team of organization, a different team of

programmers performs each phase of the programmers performs each phase of the

project, and the work products pass from project, and the work products pass from

team to team as they evolve. team to team as they evolve.

Project StructureProject Structure

Matrix format.Matrix format.

In matrix organizations, each of In matrix organizations, each of

the functions described above has its own the functions described above has its own

management team and a group of management team and a group of

specialist personnel who are concerned specialist personnel who are concerned

only with that functiononly with that function