SOFTWARE ENGINEERING

1
SOFTWARE ENGINEERING
2

• Objectives
• 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

3
The emergence of software engineering
The early years (50-60) Second Era (60-Mid70s) Third Era (70-mid80) Fourth Era (80's and beyond)
Batch orientation The 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 System AI Parallel Computing Software Crisis
4
The emergence of software engineering

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

5
The major problems
Correctness Efficiency Mastery of Complexity Interface specification Reliability     Flexibility Documentation Maintainability Project organization.
6
DEFINITION OF SOFTWARE

• Instructions (computer programs) on execution
  provide desired function and performance
•  Data structures that enable programs to
  adequately manipulate information
•  Documents that describes the operation and use
  of the programs

7
Software and Hardware

• When hardware is built the human creative process
  (Analysis, Design, Construction, testing) is
  ultimately transferred into a physical form
•  Software is logical rather than physical system
  element.
• Software is engineered (or developed) it is not
  manufactured.
• Software does not wear out.

8
Software Applications.

• Software may be applied in any situation for
  which a set of procedural steps (algorithm)
  has been defined.
• Information content and determinacy are important
  factions in determining the nature of software
  application.
• Content refers to the meaning and form of
  incoming and outgoing information.
• Information determinacy refers to the
  predictability of the order of timing of
  information.

9
Software Engineering paradigms.

• Software Engineering is the technological,
  managerial discipline concerned with
  systematic production and maintenance of software
  products that are developed and modified one
  time.
• The primary goals of software engineering are to
  improve the quality of software products and to
  increase the productivity and job satisfaction
  of persons involved.
• Software Engineering being labor-intensive
  activity, requires both technical and managerial
  control.

10
Software Engineering paradigms.

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

11
Software Engineering paradigms

• Software engineering is layered technology An
  approach that must rest on organizational
  commitment to quality.
• The layers are
• Tools
• Methods
• Process
• A quality focus

12

• The bedrock that supports software engineering is
  a quality focus.
• The foundation for Software Engineering is the
  process layer.
• Software Engineering methods provides the
  technical know how-to for building software.
• Software Engineering Tools provide automated or
  semi automated support for the process and
  methods.  

13
Generic Phases

• 1.     Formal technical reviews
• 2.     Software QA
• 3.     Software Configuration Management.
• 4.     Document preparation production
• 5.     Reusability management
• 6.     Measurement
• 7.     Risk Management.

14
Software Development Life Cycle

• Classic life cycle suggests a systematic ,
  sequential approach that begins at system level
  and progresses through
• Analysis
• Design
• Verification and Validation
• Support.

15
Software Development Life Cycle

• Specification Phase
• Object-Oriented Analysis Phase
• Design Phase
• Implementation Phase
• Implementation and Integration Phase
• Maintenance Phase

16
Software requirement Analysis

• Focused specially on software
• Analyst must understand the information domain to
  understand the nature of programs to be
  developed.
• The requirements for system and software are to
  be documented and reviewed by the customer.

17
Software Design

• Software Design is a multi step process focuses
  on four distinct attributes of a program.
• Data Structure
• Software architecture
• Interface representation
• Procedural logic

18
Code Generation

• Design is translated into machine readable form.
• Can be automated

19
Testing

• Code Testing
• Specification testing
• Uncovers errors

20
Support

• Software may undergo change after delivery due to
  errors.
• Software must be adaptable to new environment
• Due to functional or performance enhance
  suggested by customer

21
Project size categories

• Based on level of management control and types of
  tools and techniques

22
Trivial project

• One programmer working, sometimes part time
  for few days, for exclusive use.
•  Less than 500 statements 10 - 20 sub
  routines. 
• Eg. PC Software, a little need for analysis
  documentation
• No Extensive test planning essential. 

23
Small Projects

• 1 - 6 months effort of 1 programmer.
• 1000 - 2000 lines of code.25 - 50 sub routines
• Less interaction between programmers
• Scientific calculations for engineering on small
  
• Commercial applications
• Little interaction between customers and
  developers.

24
Medium Size Projects

• 2 - 5 Programmers team.
• 1- 2 years
• 10,000 50,000 lines
• 250 - 1000 routines
• medium project size
• Eg. Assembler, Compilers, Small MIS Inventory
  systems, Process Control Applications. 

25
Large Projects

• 5 - 20 programmers team
• 2 - 3 years duration
• 50,000 to 1,00,000 lines of code
• Package in several system
• Eg. Large compilers, DAS, RTC s

26
Very large Projects

• 100 - 1000 programmers
• 4 - 5 years
• 1 million source instructions
• Consists of several major sub systems
• 0S/360 5000 programmers worked for 5 years

27
Extremely large projects

• 2000 - 5000 Programmers
• duration up to 10 years
• 100 million lines of code
• Often distributed processing, Multitasking
• Requires high reliability
• Eg. Telecomm ,defense, air traffic control

28
Problems in Software Engineering

• Potential business problems or occurrences that
  may cause the project
• Potential project problems or occurrences that
  may cause the project
• Technical problems or occurrences that may cause
  the project
• Conform to changes in its external environment
  analysis

29
Software Productivity factors

• Individual ability
• Team communication
• Product complexity
• Appropriate notations
• Systematic approaches
• Change control
• Level of technology
• Required reliability

30
Software Productivity factors

• Available time
• Problem understanding
• Stability of requirements
• Facilities and resources
• Management skills
• Appropriate goals
• Rising expectations

31
Project Structure

• Project format.
• Use of a project format involves assembling
  a team of programmers who conduct a project from
  start to finish project team members do product
  definition, design the product, implement it,
  test it, conduct project reviews, and prepare the
  supporting documents.

32
Project Structure

• Functional format.
• In the functional approach to organization,
  a different team of programmers performs each
  phase of the project, and the work products pass
  from team to team as they evolve.

33
Project Structure

• Matrix format.
• In matrix organizations, each of the
  functions described above has its own management
  team and a group of specialist personnel who are
  concerned only with that function