Introduction (class 1)

Evolution of Software • 1950 – Mid 1960 – – – –

Batch Orientation Limited Distribution Custom Software In house development

• Mid 1960 – Mid 1980 – Multi user, multi session, multitasking – Real time processing – Database connectivity – Product software

Evolution of Software • Mid 1980 – Mid 1990 – – – –

Distributed Systems Embedded Systems Low cost hardware Consumer Impact

• Mid 1990 – Present – Powerful PCs – Internet – Client-server environment – Object oriented environment – ……

Evolution of Software Engineering • 1950 –1960 : Early days – The term coined during this period – First two international conferences sponsored by NATO in 1968 and 1969 • Developing software product is far more complex than developing standalone programs • Principles of engineering design should be applied to the task of developing large software product • Fritz Bauer : Coined the term “Software Engineering”

Evolution of Software Engineering • 1970 – Mid 1980 : Software Crisis – Cost and budget overrun – Property damage – Life and Death – Brooks (1976) • IBM 360 OS • The Mythical Man Months

– Boehm (1981) • Software Engineering Economics

Evolution of Software Engineering • Mid 1980 – Presents : No silver bullets – Software paradox • Tools, formal methods, process and professionalism

– Cost of Hardware – Process and methodology • Humprey (1989), Paulk(1991-1995) • Capability Maturity Model

– Object Oriented Analysis and Design • Rumbaugh et al. (1998)

– Emergence as a profession

Nature of Software Engineering • Mathematics • Science • Engineering – Manufacturing – Industrial Engineering – Project Management

• Computer Science • !! Finding its own identity

Changes in software development style • Early computer programming – Slow Computers, small programs, assembly level programming – Exploratory programming style

• High-level language programming – Semiconductor technology and compilers – High level languages like COBOL, FORTRAN, ALGOL

• Control flow-based design – Stress on control structures • The sequence of program instructions

– Flow charting technique – Structured programming methodology • Avoidance of goto • Single entry – single exit structures • Sequence, selection and iteration

– PASCAL, MODULA, C

Changes in software development style (Contd.) • Data structure-oriented design – ICs – More importance to data structure – Jackson’s structured programming, Warnier-Orr methodology

• Data flow-oriented design – VLSI – Complex software products – Data flow oriented techniques • Identification of major data items • Flow of data between the processes

• Object-oriented design – Objects – Relationship among the object

Software Engineering Course Content • Software design techniques • Software development processes • Project management techniques • Testing techniques • Debugging techniques • Quality Assurance techniques • Software metrics Books: Software Engg-A practitioner's approach R.S. Pressman Software Engg – Sommerville Fundamentals of SE – Prof. Rajib Mall

Defining Software • New Webster Dictionary (1981) – Software is the program and programming support necessary to put a computer through its assigned tasks, as distinguished from the actual machine

• Blum (1991): Software is the detailed instructions that control the operations of a computer System. Its functions are to – Manage the computer resources of the organization – Provide tools for human beings to take advantage of these resources. – Act as an intermediary between organizations and locate information

Levels of Software Hardware Logic System Software

1. Machine Micro logic 2. Supervisors or Executives 3. Operating Systems 4. Language Translators 5. Utility Programs

Application 6. Inquiry, File, and Database software Software 7. High level and assembly language programs End-user 8. 4GLs Software

Program Vs. Software Product • Program – – – –

Personal use Limited life a good interface No need for documentation – …….

• Software Product – – – –

Multiple developer Multiple user Longer Life span Thorough testing and careful implementation – Good user interface, user manual – Maintainable - Good documentation support

Defining Software Engineering • Fritz Bauer Software Engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines • IEEE (IEE93) Software Engineering: (1) The application of a systematic, disciplined, quantifiable approaches to the development, operation and maintenance of software; that is, the application of engineering to software. (2) The study of the approaches in (1).

• The discipline of software engineering discusses systematic and cost-effective approaches to develop good quality software.

Nature of Software Engineering • Mathematics • Science • Engineering – Manufacturing – Industrial Engineering – Project Management

• Computer Science • !! Finding its own identity

A Comparison With Traditional Engineering Discipline • Problem domain can be anything • Abstract Design to Concrete Product – Abstract Design to More Abstract Code

• Product Standardization for reduced cost – Process Standardization

• Unlimited number of domain- and application specific notions – Limited but universally accepted principle

Software Characteristics • Developed or engineered, not manufactured in a classical sense – The concept of ‘raw material’ is nonexistent here. It is better visualized as a process rather than a product. – The ‘human element’ is extremely high in software development, compared to manufacturing – The development productivity is highly uncertain, even with standard products, varying greatly with the skill of the developer. – Development tools, techniques, standards, and procedures vary widely across and within an organization. – Quality problem in software development are very different from those in manufacturing.

Software Characteristics (Contds.) • Software Development presents a job-shop environment. – Here the product is custom built hence unique. – It cannot be assembled from existing components. – All the complexities of the job shop (viz. The problem of design, estimating, and scheduling is also present here. – Human skill, the most important element in a job shop, is also the most important element here.

Software Characteristics (Contds.) • Time and effort for software development are hard to estimate. – Interesting work gets done at the expense of the dull work. • documentation, being a dull work, gets the least priority

– Doing job in a clever way tends to be more important consideration than getting it done adequately; on time, at reasonable cost. – Programmers tend to be optimistic, not realistic and their time estimate for the task completion reflects this tendency. – Programmers have trouble communicating.

Software Characteristics (Contds.) • User requirements are not often conceived well enough; therefore a piece of software undergoes many modifications, before it is implemented satisfactorily. • There is virtually no objective standards or measures by which to evaluate the progress of software development. • Testing a software is software is extremely difficult, as well as expensive.

Software Characteristics (Contds.) • Software does not wear out. – will not lose its functionality with use. – may lose its functionality due to change in user requirements. – Defects are removed by rewriting the relevant code, not by replacing with the available code. – When defects are removed it is very likely that new defects are introduced.

Software Characteristics (Contds.) • Hardware has a physical model to use in evaluating design decisions. Software design evaluations, are on the other hand, rests on judgment and intuition. • Hardware because of its physical implementation has a practical bound on complexity, software on the other hand, can be highly complex and still confirms to almost any set of needs. • There are major differences between the management of a hardware and software project. – May be counter productive. Ex: Reporting 100% completion in terms of LOC may be highly misleading.

Evolution of a Programming System Product • A program – Complete in itself – Run by the author – Run on a m/c where it is developed

• A programming product – Can be run, tested, repaired and extended by anybody. – Must be thoroughly tested, and well documented. – Costs three times as much as the corresponding program.

Evolution of a Programming System Product (Contds.) • Programming System – – – –

A collection of interacting program User interface Consistent in memory usage Must be tested with other components in all expected combinations. – Costs three times as much as a standalone program.

• A programming System Product – All the features of a programming product and a programming systems a product. – Costs three times as much as a stand-alone program of the same function

Software Crisis • Software cost outstripping hardware cost. • S/W maintenance cost has surpassed the hardware cost. • Time and cost overrun • Lack of transparency and hard to maintain • S/W is often less than adequate • Often does not satisfy the end user • Productivity of s/w people has not improved with the demand for their services. • Progress on software development is difficult to measure. • Standardization not possible due to lack of data • How a person works during software development is not yet understood

Myths that prevail in S/W industry • Management Myth – standards and procedures for building s/w, newest hardware, state-of-the-art software development tool will increase the productivity of people. – If project is running behind the people add more people.

• Customer Myth – A general statement on objective is sufficient to begin writing the program. We can fill in the details latter. – Software are flexible hence changes can be easily accommodated.

• Practitioner’s Myth – Once we write the program and get it work our job is done. – Until I get the program running, I have no way to assess its quality – Only deliverable for a successful project is a working program

System Development Life Cycles • Cycle: A succession of events repeated regularly within a given period of time • Life Cycle: A sequence of events or patterns that reveals themselves in the life cycle of an organism • System Development Life Cycles: – Pattern that is observed in the lifetime of a s/w product – Its recognition hold the key to successful software development

Software Process Models • • • • •

Code and fix model Classical waterfall model Evolutionary model Prototyping Spiral models

Classical Waterfall Model Feasibility Study Requirements Analysis Design and Specification Coding and unit testing Integration and system testing

Maintenance

Feasibility study • Systems Engineering and Information Engineering • Abstract definition of the problem • Formulation of alternative strategies • Examination of alternatives – Resources required and available – Development cost and time – Cost-benefit analysis

Requirement Analysis • Requirement Analysis – Interviews and discussions – Incomplete views – Ambiguities and contradictions

• • • •

Requirements Specification User manual System test plan End product - SRS Document

Design • Translation of SRS into a structure that is suitable for implementation • Traditional design approach – Structured Analysis – DFD – Architectural design – Detailed design

• Object oriented design – Identification of objects and relationships – Detailed design

• End product – A set of design documents

Coding and Unit Testing • Translation of designs to source code • Testing each program module • End product – a set of program modules that are individually tested.

Integration and Unit Testing • Partial integration and testing • System testing – Alpha testing – Beta testing – Acceptance testing

Maintenance • Corrective • Perfective • Adaptive

Variations of waterfall model (Royce, 1970) Requirements Analysis Design and Specification Coding and unit testing Integration and system testing

Maintenance

Variations of Waterfall Model (Boehm, 1981)

Feasibility Study Validation

Software Plans and Requirements Analysis Validation Product Design Verification Detailed Design Verification Coding unit testing Integration Product Verification

Implementation System Test Maintenance Revalidation

Waterfall Model (Pressman, 2005) Communication project initiation requirements gathering

Planning Estimating scheduling tracking

Modeling Analysis Design

Construction code test

Deployment delivery, support feedback

Assumptions of waterfall model • Unidirectional flow of control among the phases • Downward flow of primary information and developmental effort. • Work can be divided according to phases among different classes of specialists. • It is possible to associate a goal for each phase (the exit condition) • Output of one phase is used as input to the next phase after review, verification and validation (Limited iterative flow)

Assumptions of waterfall model • Output of each phase is frozen. – Baseline – check point – Configuration management

• It is possible to create different development tools suitable to the requirements of each phase • Phases provide the basis for management and control

Economic rationally Behind Waterfall Model (Boehm) • All phases and their associated goals are necessary • Any different ordering of the phases will produce a less successful software.

Usefulness of the waterfall model • Complete specification of the system before it is built • Understanding interaction of the components before coding • More accurate tracking of the project and early discovery of the schedule slippage • Documentation for ease of testing and maintenance • Reduced development and maintenance cost • More structured and manageable system.

Shortfalls of Waterfall Model • Protracted Integration and Late Design Breakage – Blocking state of developers – Working version takes long time to come up – Non-optimal-fixes, little time for redesign, late delivery of a nonmaintainable product

• Late Risk Resolution – Risk: the probability of missing cost, schedule, feature, or quality goal – High at the requirement phase

• Requirement driven Functional decomposition – customers must state all requirements explicitly – All the requirements are equally important and do not change over the SDLC – Decomposition of requirements to functions and sub functions

• Adversarial stakeholder relationship As a result Real projects rarely follow this model

A Critique of the Waterfall Model • rigid • monolithic • Heavily document driven hence bureaucratic As a result Many refinements are proposed • Incremental Model • Evolutionary Model • Spiral Model

The Incremental model • Applying linear sequence in a staggering manner • First increment is the core product • Focuses on the delivery of an operational product • Useful when staffing is inadequate • Technical risk can be handled

The Incremental model Communication

Software Functionality and Features

Planning Modeling Construction Deployment

Calendar Time

The RAD Model (Rapid application development)

• Fully functional system in a short time (60 –90 days) • Phases – Communication – Planning (for multiple teams) – Modeling (Business, Data, Process) – Construction (Use of Components, Automatic Code generation) – Deployment (Integration, Delivery, Feedback)

Team #1

Modeling

Construction Team #2

Modeling

Construction Team #n

Modeling

Construction

Deployment

– Sufficient and efficient manpower – Commitment of the team members – Appropriate modularization – Not suitable for high technical risk projects

Planning

• Shortfalls

Communication

The RAD Model contd.

Component Based Models -Software Reuse Requirements Design of Architecture

Component Specification Search for reusable components

Detail Design of the Remaining Components Coding and Unit of the Remaining Components

Integration

Delivery

Advantages of Software Reuse • Increases system reliability • Reduces overall project risk due to less uncertainty in cost estimates • Effective use of specialists in developing generic components than in a wide array of variety of products • Embodiment of organizational standards in reusable components, such as user interface and error handling procedures • Reduction of software development time.

Guideline for Software Reuse • Generalized – Names, operations, exceptions

• Documented • Availability of test cases

Common Problems of Software Reuse • Portability – Transportation – Adaptation

• Customization

Cleanroom Software Development • Suitable for the systems that have stringent safety, reliability and security requirements. • Formal specification of the requirements • Incremental development strategy • Structured programming • Static verification of the individual build using mathematically based correctness argument • Statistical testing with the help of reliability growth models

The Prototyping Model • Iterative in nature • Customers are unsure of their requirement • Developers are unsure of the development environment • Can be applied with any other paradigm • Evolutionary or throwaway

Communication

Quick Plan Deployment, delivery and feedback Modeling and quick design Construction of the Prototype

Evolutionary Vs. Throwaway Prototyping • Both types assume that at the outset some abstract, incomplete set of requirements has been specified. • Both allows user feedback • Evolutionary prototype is delivered to the customer with minimal changes. • Throwaway prototype is used just to collect user requirements. Hence the actual deliverable is developed afterwards. • Evolutionary prototype is difficult to maintain • Throwaway prototype is not suitable for testing nonfunctional requirements

Benefits of Prototyping • Resolves communication gap and misunderstanding between software developer and users. • Missing user services may be detected • Difficult to use or confusing user services may be identified and refined • Resolves inconsistencies and incompleteness in the users’ requirements • Helps in gaining user confidence • Helps in writing specifications • Correct specifications of the requirements reduces requirements-related errors and therefore overall development cost • Training user before delivering the product • Test cases developed during prototyping can be used for testing the final product.

Guidelines for developing the prototype • Objective of the prototype must be explicitly stated to the user – Validate functional requirement – Validate user interfaces

• Requires cost – – – –

Non-functional features can be ignored Need not maintain error handling routines Need not adhere to the quality and reliability standard Suitable tools or development languages may be used • • • •

Usable components Executable specification language – z specification language Forth generation language – SQL Very high-level language – Smalltalk, Prolog or Lisp

Shortfalls of Prototyping • Customers wishes to have it as the working product • Developers makes compromises to make it the working product

The Spiral Model (Boehm, 1998) • Iterative in nature • Each loop represents a phase in the software process • Each loop is broken into 4 sectors • Sophistication increases with each version • Risk analysis is a must in planning phase Shortfalls • Difficult to convince the customer • Needs Risk Assessment Expertise

Quadrant – 1: Formulation

Quadrant – 2: Analysis

Identify need, objectives, Constraints, & alterable

Identify alternatives and risks

Risk Analysis

Risk Analysis

P4 Risk Analysis

P3 P2

Risk Analysis

Operational prototype

P1 Final Dev, s/w dev plan Intgr & Test Plan

s/w Req plan

Lifecycle Control Plan

Mgmt Control Plan

Detailed Design

Reqts Validations

Code Unit Test

Design Validation and verification

Quadrant – 4: Interpretation Plan for the next phase of the spiral life cycle

Implem entation

Integrate Acceptance and Test test

Quadrant – 3: Interpretation Develop and Evaluate

Comparison of Alternative Software Development Life Cycle Models •

Waterfall Model – – – –

•

Sequence of phases Limited feedback Iteration between phases Document based

Prototype Model – Many iterations – Feedback on partial builds – User based

•

Incremental Development – Addition of functionality to the initially built kernel

•

Spiral Model – Risk based – Incremental/prototyping is followed to eliminate risk, establish user requirement, and detailed software design before taking final coding, testing and implementation

Five metric for comparison • Shortfall – A measure of how far the software is, at time t from meeting the actual user requirement.

• Lateness – a measure of the time delay between the appearance of a new requirement and its satisfaction

• Adaptability – The rate at which a s/w solution can adapt to new requirements, a measured by the slop of the solution curve

• Longevity – The time a system solution is adaptable to change and remains viable (Time from creation to replacement)

• Inappropriateness – A measure of the behavior of the shortfall over time.

Software Productivity Metrics User Need Conventional Approach

Shortfall

Inappropriateness

Lateness Adaptability

t0

t1

t2 Longevity

t3

t4

Phasewise distribution of effort • 40-20-40 rule – Analysis & Design (40%) – Coding and Debugging (20%), – Testing and Checkouts (40%)

• Wolverton (1974) Requirements Analysis Preliminary Design Interface Definition Detailed Design Code and debug Development testing Validation testing

– 8% – 18% – 4% – 16% – 20% – 21% – 13%

46%

34%

Phasewise distribution of effort • Thibodeeau and Dodson (1984) – Analysis & Design (37%) – Coding and Debugging (20%), – Testing and Checkouts (43%)

• Fagan (1986) – Snail Shaped Curve Planning Requirements Design

Coding

Testing

Lifecycle Phase Interrelationships Time Analysis

Design Person-Hour Loading

Coding and Unit Testing

Planned

Integration and unit testing

Actual Maintenance

Project Curve (Putnam, 1978) Project Curve Man-Year/ Year

Test and Validation Extensions

Design and Coding

Modification

Plan Functional Spec

Maintenance

Time

Unified Process Model • Ivar Jacobson, Grady Booch, and James Rumbaugh (1999) – Use-case driven – Architecture centric – Iterative and Incremental – Static and dynamic models

Phases of Unified Process Model Inception Phase Vision Document, initial use-case model,

Elaboration Phase Use-case model,

Initial business case,

Supplementary Requirement including nonfunctional Analysis model,

Initial risk assessment,

Software architecture description,

Integrated software increment,

Project plan – Phases and iterations

Executable architectural prototype,

test plan and procedure,

initial project glossary,

Preliminary design model, Project Plan, Preliminary user’s manual

Construction Phase Design Model , Software Components,

Test cases, Support documentation – user manual, installation manual, description of the current increment

Transition Phase Delivered software increment, Beta test reports, General user feedback

The Agile View of the Process (Beck, 2001)

• Individual and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan

Principles to Achieve Agility • Early and continuous delivery of valuable software. • Harness change for customer’s competitive advantage. • Preference to shorter timescales. • Motivated individual • Face-to-face conversation. • Working software

• Sustainable development. • Continuous attention to technical excellence and good design. • Simplicity • Self organizing teams • Introspection at regular intervals

Characteristics of agile process • Change in customer’s requirements and priorities • Interleaved design and construction • Unpredictable analysis, design and testing from planning point of view.

Agile Process Models • • • • • •

Extreme Programming (XP) Adaptive software development Dynamic system development method Scrum Crystal ….

Extreme Programming • Assumes object oriented development paradigm • Encompasses a set of rules and practices that occur within the context of four framework activities – Planning, design, coding and testing • Planning – Use stories by customer – Value (priority) by customer – Cost (developmental, in terms of development weeks) by designer – Breaking of stories if required – Project velocity (no of stories to be implemented with each increment) – Addition, modification and deletion of stories by the customer at any time

Extreme Programming • Design – – – –

Keep it simple CRC Card (class-responsibility-collaboration) Spike solution (immediate creation of an operational prototype) Refactoring

• Coding – Refactoring – Pair programming – Unit and integration testing

• Testing – integration testing – Acceptance testing

SCRUM Scrum Meeting: Progress, Obstacle, Plan

Backlog item expanded by Sprint team member Sprint Backlog

30 Days

Product Backlog

Demo

Prioritized Product Features as desired by the customer