Introduction to Software Engineering

Outline
Nature of software projects Engineering approaches Software process A process step Characteristics of a good process Waterfall model for development Other models Project planning
2

Software Systems
Ubiquitous, used in variety of applications
Business, engineering, scientific applications

Simple to complex, internal to public, single function to enterprise-wide, one location to distributed, batch or real-time, informational to missioncritical, .
3

Challenge in large projects

Developing large/complex software application is very challenging
Effort intensive High cost Long development time Changing needs for users High risk of failure, user acceptance, performance, maintainability,

Quite different from one-time programs where author and user are same ! 4

Successful software system

Software development projects have not always been successful When do we consider a software application successful?
Development completed It is useful It is usable, and It is used

Cost-effectiveness, maintainability implied

5

Reasons for failure

Schedule slippage Cost over-runs Does not solve users problem Poor quality of software Poor maintainability

Reasons for failure .

Ad hoc software development results in such problems
No planning of development work (e.g. no milestones defined) Deliverables to user not identified Poor understanding of user requirements No control or review Technical incompetence of developers Poor understanding of cost and effort by both developer and user
7

Engineering: other disciplines

Large projects common and successfully done
Buildings bridges, dams Power plants Aircrafts, missiles,

engineering a solution:
To design, develop (build, fabricate) an artifact that meets specifications efficiently, cost-effectively and ensuring quality Using scientific principles. 8

Engineering
Requires well-defined approach : repeatable, predictable Large projects requires managing the project itself
Manage people, money (cost), equipment, schedule Scale makes big difference: compare building a hut, 2storeyed house, or 50storeyed apartment building

Quality extremely important : relates to failures, efficiency, usability, .

People willing to pay for quality !
9

Large Projects
Involve different types of people
Large building : architect, civil engineer, electrical engineer, workers (masons, carpenters), .

Continuous supervision for quality assurance

On site supervisors (check cement/steel quality, ensuring proper mix of sand & cement, .)
10

Large projects
Many deliverables : architecture plan, model, structure diagrams, electrical cabling layouts, Standards, regulations, conventions need to be followed Steps, milestones defined and reviews are carried out; progress is visible Project planning and project management essential

11

Software projects
Software is different from other products
Cost of production concentrated in development Maintenance consists of making corrections and enhancing or adding functions Progress in development is difficult to measure
12

Apply Engineering Approach

Hence planning and control even more important in software development engineering approach:
Attempt to estimate cost/effort Plan and schedule work Involve user in defining requirements Identify stages in development Define clear milestones so that progress can be measured Schedule reviews both for control and quality 13 Define deliverables

Job of Software Developer is difficult

Dealing with users
Ill-defined requirements Concern with ease-of-use and response time

Dealing with technical people

Concerned with coding, databases, file structures, etc.

Dealing with management

Concerned with return on their investment Cost-benefit analysis

14

Software Process
Process consists of activities/steps to be carried out in a particular order Software process deals with both technical and management issues Consists of different types of process Process for software development: produces software as end-result
multiple such processes may exist a project follows a particular process
15

Process Types
Process for managing the project
defines project planning and control effort estimations made and schedule prepared resources are provided feedback taken for quality assurance monitoring done.

16

Process Types
Process for change and configuration mgmt.
Resolving requests for changes Defining versions, their compositions Release control

Process for managing the above processes themselves

Improving the processes based on new techniques, tools, etc. Standardizations and certifications (ISO, CMM)

17

Multiple processes
A large software development company may have multiple development processes
A. For client-server based conventional

applications (sales processing, payroll) B. For enterprise-level (ERP) projects based on packages and customization C. For web-based e-commerce type D. For data-warehousing/decision-support type

The company may have many projects in each category

18

Step in a Process
Each step has a well-defined objective Requires people with specific skills Takes specific inputs and produces well-defined outputs Step defines when it may begin (entry criteria) and when it ends (exit criteria) Uses specific techniques, tools, guidelines, conventions.

19

Process step
Step must be executed as per project plan that gives duration, effort, resources, constraints, etc. It must produce information for management so that corrective actions can be taken
E.g., adding more resources

A step ends in a review (V&V)

Verification: check consistency of outputs with inputs (of the step) Validation: check consistency with user

20

Process step
(entry criteria) actions to be carried out Review V&V (exit criteria)

inputs

outputs

Project Control info

info for management

21

Characteristics of a Good Process

Should be precisely defined no ambiguity about what is to be done, when, how, etc. It must be predictable can be repeated in other projects with confidence about its outcome
Predictable with respect to effort, cost:
Project A: Web-based library applications done by 3 persons in 4 months another project B (guest house bookings), similar in complexity should also take about 12 22 person months.

A Good Process
Predictable for quality: with respect to number and type of defects, performance,

Predictable process is said to be under statistical control , where actual values are close to expected values It supports testing and maintainability
Maintenance by third party Follow standards, provide necessary documentation
23

A Good Process
Facilitates early detection of and removal of defects
Defects add to project cost Late detection/correction is costly

It should facilitate monitoring and improvement

Based on feedback Permit use of new tools, technologies Permit measurements
24

Waterfall Model for Development

Here, steps (phases) are arranged in linear order

A step take inputs from previous step, gives output to next step (if any) Exit criteria of a step must match with entry criteria of the succeeding step

It follows specify, design, build sequence that is intuitively obvious and appears natural
25

Waterfall Model
Produces many intermediate deliverables, usually documents
Standard formats defined Act as baseline used as reference (for contractual obligations, for maintenance) Important for quality assurance, project management, etc.

It is widely used (with minor variations) when requirements are well understood
26

Waterfall Model
system engineering -software part of some larger system -establish requirements for all elements of the system; assign some to software -understand information domain, functions, performance Analysis Project planning and interfacing. Project plans made design -translate requirements into s/w architecture, data structures and procedural details. A detailed design step can be added -programming -test logic and function interfaces -deployment; make changes for -Errors, performance -changes in requirement

code

testing & integration

Installation & maintenance

27

Deliverables in Waterfall Model

Project plan and feasibility report Requirements document (SRS : Software Requirement Specifications) System design document Detailed design document Test plans and test reports Source code Software manuals (user manual, installation manual) Review reports
28

Cost/Effort Distribution
Total accumulated cost

Problem Feasibili Analysis System Detailed Impleme Mainten definitio ty study design design nn tation ance

Accumulated cost increases dramatically as programmers, operators, technical writers and computer time is committed. Cost of discovering and fixing errors also increases with steps

29

 Requirements may not be clearly known, especially for applications not having existing (manual) counterpart
Railway reservation: manual system existes, so SRS can be defined On-line container management for railways - new Knowledge management for a central bank new
30

Shortcomings of Waterfall Model

Shortcomings
Requirements change with time during project life cycle itself
Users may find solution of little use Better to develop in parts in smaller increments; this is common for packages, system software

Considered documentation-heavy: so much documentation may not be required for all types of projects.
31

Prototyping Model
When customer or developer is not sure
Of requirements (inputs, outputs) Of algorithms, efficiency, human-machine interaction

A throwaway prototype built from currently known user needs Working or even paper prototype

32

Prototyping
Quick design focuses on aspects visible to user; features clearly understood need not be implemented Prototype is tuned to satisfy customer needs
Many iterations may be required to incorporate changes and new requirements

Final product follows usual definedesign-build-test life cycle

33

Prototyping benefits
Misunderstandings between software users and developers are exposed Missing services may be detected and confusing services may be identified A working system is available early in the process The prototype may serve as a basis for deriving a system specification The system can support user training 34 and system testing

Types of prototyping: Throwaway prototyping Evolutionary prototyping or breadboard prototyping Incremental prototyping Extreme prototyping

35

Prototyping process
Establish p ro to ty pe o bjectives Define p ro to ty pe fun ction ality Develo p pro to ty pe Ev alu ate p ro to ty pe

Pro toty ping p lan

Ou tline d efinition

Ex ecutab le pro to ty pe

Ev alu ation repo rt

36

Prototyping
Requirements gathering Quick design

build prototype

evaluate & refine

Engineer product

37

Advantages : Reduced time and costs Improved and increased user involvement Users are actively involved in the development Quicker user feedback is available leading to better solutions. Errors can be detected much earlier as the system is mode side by side.

38

Limitations of Prototyping
Customer may want prototype itself ! Developer may continue with implementation choices made during prototyping
may not give required quality, performance, .

Good tools need to be acquired for quick development May increase project cost
39

Iterative Development
Useful for product development where developers define scope, features to serve many customers Early version with limited feature important to establish market and get customer feedback Initial version may follow any method A list of features for future versions maintained Each version is analyzed to decide 40 feature list for next iteration

 Evolutionary Development model [SE-7, Fig 4.2]

Concurr ent activities Initial version

Specification

Outline description

Development

Intermediate versions

Validation

Final version

41

Evolutionary Development..
Main characteristics:
The phases of the software construction are interleaved Feedback from the user is used throughout the entire process The software product is refined through many versions

Types of evolutionary development:

Exploratory development Throw-away prototyping
42

Evolutionary Development
Advantages:
Deals constantly with changes Provides quickly an initial version of the system Involves all development teams

Disadvantages:
Quick fixes may be involved Invisible process, not well-supported by documentation The systems structure can be corrupted by continuous change
43

Evolutionary Development
Disadvantages [contd]:
Special tools and techniques may be necessary The client may have the impression the first version is very close to the final product and thus be less patient

Applicability:
When requirements are not well understood When the client and the developer agree on a rapid prototype that will be thrown away Good for small and medium-sized software systems
44

Component-based Software Engineering

Rq i e e t e ur mns s e i ic t n p cf aio

C mo e t o p nn a a ss n ly i

Rq i e e t e ur mns m d ic t n o if aio

S s m ei n yte d sg w hr u e it e s

Dv lo mn ee p et a di te r to n n gai n

Ss m y te v li aio adt n

45

Component-based Software Engineering..

Main characteristics:
Makes intensive use of existing reusable components The focus is on integrating the components rather than on creating them from the scratch

46

Component-based Software Engineering.

Advantages:
Reduces considerably the software to be developed in-house Allows faster delivery In principle, more reliable systems, due to using previously tested components

47

Component-based Software Engineering

Disadvantages:
Compromises in requirements are needed Less control over the systems evolution

Applicability:
When there is a pool of existing components that could satisfy the requirements of the new product Emerging trend: integration of web services from a range of suppliers

48

Spiral Model
Activities are organized in a spiral having many cycles Four quadrants in each cycle
1. Determine objectives, Alternatives, constraints 2. Evaluate alternatives, identify and handle risks

4. Plan next step

3. Develop the software

49

Spiral Model
Prototyping, simulations, benchmarking may be done to resolve uncertainties/risks Development step depends on remaining risks; e.g.,
Do prototype for user interface risks Use basic waterfall model when user interface and performance issues are understood but only development risk remains

Risk driven : allows us mix of specification-oriented, prototypeoriented, simulation based or any

50

Spiral Model Description

The development spiral consists of four quadrants as shown in the figure above: Quadrant 1: Determine objectives, alternatives, and constraints. Quadrant 2: Evaluate alternatives, identify, resolve risks. Quadrant 3: Develop, verify, nextlevel product. 51 Quadrant 4: Plan next phases.

The Spiral Model

52

Spiral Model
Main characteristics:
Also a hybrid model that support process iteration The process is represented as a spiral, each loop in the spiral representing a process phase Four sectors per loop: objective setting, risk assessment and reduction, development and validation, planning Risk is explicitly taken into consideration

53

Spiral Model
Advantages:
Risk reduction mechanisms are in place Supports iteration and reflects real-world practices Systematic approach

Disadvantages:
Requires expertise in risk evaluation and reduction Complex, relatively difficult to follow strictly Applicable only to large systems

Applicability:
Internal development of large systems
54

The Rational Unified Process

P h as e i t erat i o n

In cep t i o n E l ab o rat i o n

C o n s t ru ct i o n

Tran s i t i o n

55

Major work products in UP phases

Inception phase
Vision doc, early use cases, feasibility, project plans

Elaboration phase
Detailed use cases, analysis, architecture design, detailed plan, preliminary user manual

Construction phase
Detailed design, components, test plans/cases, implementation, detailed manuals

Transition phase
56 Delivery, beta/acceptance, user feedback

Other s/w process Models :

RAD Model WIN-WIN Spiral Model Dynamic system development

57

Summary
Challenges in software development and need for engineering approach
Step-by-step methodology with specific deliverables

Types of software processes

For development, for project management,

Precise definition of a step Waterfall model : natural, widely followed in spite of its limitations Project management for planning, monitoring and control

58