SOFTWARE ENGINEERING
(Session 1)
AGENDA
· Evolution, Challenges and Issues
· Understanding Software as a Product
· Characteristics, Components and Applications
· Problems Causes and Myths
· Software Process – The development Roadmap
· Software Engineering Models
Just to Begin with
· Software Differentiates Between Organisations (Makers/Users).
· Evolved from batch jobs of 1960 à Multi-user real-time of 1970 à Distributed System of 80 à Object Oriented of 90 à AI based, Parallel systems and now everything on Web based systems.
· Programming has developed from an art form to a systematic engineering approach.
· Challenges : (Typical 3 Es Inclusive – Efficiency, Economy and Error Free)
§ Speed of development
§ Cost
§ Errors
§ Monitoring Difficulties.
· Issues
§ Ageing Softwares. (No One Knows Entire Design, Small changes can foil everything)
§ Un-economic re-engineering.
§ Competition from New Technologies.
§ Managing Grey Matter HR and multiple teams.
· Understanding as a Product
o A product in itself and vehicle for delivering other products (Most important is Information).
o Definition as product with following main assemblies
§ Instruction (code) for desired function and performance
§ Data structure and sets for information manipulation
§ Documents describing operation and usage.
Characteristics, Components and Application Types
· Characteristics:
§ Developed, not manufactured
§ Doesn’t wear out (May deteriorate due to changes)
§ Not assembled at site with components
· Components:
§ Non Machine Executable (Configuration, Data, Graphics)
§ Machine Executable
REUSABILITY OF BOTH ABOVE DESIRED.
E.g. Windows
· Applications: (Classified on the basis of contents and determinacy)
Ø Content: Usage Domain
Ø Determinacy: Predefinition level of inputs and outputs (For e.g. application software is more determinate than operating system)
§ System Software
§ Real Time Software
§ Business Software
§ Engineering and Scientific Software
§ Embedded Software
§ PC software
§ Web Based Software
§ AI software
Problems, Causes & Myths
· Problems:
§ Inaccurate cost and schedule estimates
§ Productivity of Developers
§ Quality (Consistency ?) inadequate
§ Estimation required before collecting data
§ Customer always seems to be dis-satisfied
§ Missing systematic approaches to quality
§ Maintainability not really an acceptance criteria
· Causes:
§ Human beings are involved
§ Experience not very long
§ Defect correction is not like spare part replacement but design modifications are required.
§ Communication with machine made by third party.
§ Project Management not in hands of specialised people only.
§ Programming is derived from past experience and not really training.
§ Opposition to change.
· Myths (For Managers, Developers and Customer):
§ (M) Book of standards and procedures is enough.
§ (M) Best Dev. Tools and Hardware is enough.
§ (M) We can catch-up in time by adding more people.
§ (C, D) Objective definition is sufficient to begin programming, details can be worked later.
§ (C ) Software is flexible, so changes can be continually accommodated. (Only the cost may vary)
§ (D) Only deliverable is a working program.
§ (D) Program quality can be best judged by running it.
Software Process – The development Roadmap
· Engineering = Way to approach problem
· Process = definable in terms of procedure – methods and tools.
· Definition – Development – Support phases generic to whole process.
· Correction – Adaptation – Enhancement & Prevention (Software re-engineering) are applied during support.
· Process Framework ( Directly related Activities – Task Sets – Umbrella Activities )
· CMM – Capability Maturity Model defined by SEI of CM univ. defines 5 levels of processes.
o 1 – Initial – Adhoc definitions
o 2 – Repeatable – Cost, Scheduling and Functionality
o 3 – Defined – Documented and Standardised
o 4 – Managed – Measurements established and controlled
o 5 – Optimise – Continuous improvement with new innovations
· KPA (Key Process Areas) are defined at each level with specific
§ Goals
§ Commitment
§ Abilities
§ Activities
§ Monitoring Methods
§ Verification Methods
Software Engineering Process Models - I
· Objectives of Modeling:
§ Obtain economically, a reliable and efficient software for real machines.
§ Define methods, tools and procedures.
· Linear Sequential/ Life Cycle / Waterfall model
§ STAGES: System Engineering (Analysis & Design), Coding, Testing and Maintenance.
§ Limitations: Not Real, Not all requirements predefined, wait till end.
· Prototyping:
§ Usage of paper prototyping, partly functional module writing or modification of existing.
§ STAGES: Requirement gathering, Quick Design, Build Proto, Evaluation, Refining Prototype, Engineering Product.
§ Limitations: Quality and maintainability ignored, Compromises for quickness.
· RAD (Rapid Application Development):
§ Incremental development of multiple components together to achieve speed.
§ STAGES: Business Modeling, Data Modeling, Process Modeling, Application generation (Using reusable components & 4GL), testing and turnover.
§ Limitations: High HR needs, High Commitment of large set of people desired, Only Modular projects can be done with this, Not suitable for High technical Risk Projects.
Software Engineering Process Models - II
· Incremental / Iterative Enhancement:
§ Stages:
Design 1 à Implementation 1 à Analysis 1 …..
Design n à Implementation n à Analysis n à
Final Product
§ Client Can be involved smoothly, functionality added in increment, Project control list is involved.
§ Limitations: Schedule Over-run, Cost Over-run, Poor Initial Estimation.
· Spiral Model:
§ Spiral of activities move from Customer communication, Planning, Risk Analysis, Engineering, Construction and release, Customer Evaluation In several layers.
§ Model supported well for concept development, new product, enhancement or maintenance projects.
§ Limitations: Often difficult to convince customer, requires continuous assessment expertise.
§ Win-Win Spiral is a variation of above with Win situation is negotiated between every pass of spiral.
· Concurrent Development Model:
§ Activities under review and changes are identified in each process stage (Can be stage of spiral model).
§ More near to event driven programming concept.
§ Used in client/server Development.
§ Limitations: Implemented by highly organized teams.
Software Engineering Process Models - III
· Component Based Model:
§ The engineering and construction stages of spiral model package either pre-development components or new classes are planned and developed building-up the library.
§ Limitations: Limited to certain project types only. Component version issues may also crop-up.
· Formal Methods Model:
§ Formal Mathematical Specs of Software Activities are developed in this.
§ Also called clean-room software engineering.
§ Aims at providing defect free software.
§ Limitations: time consuming and expensive. Specially trained programmers for formal methods are required. Difficult to establish communication with customers.
· Fourth Generation Techniques:
§ Generate source code based on Developer Specs.
§ Currently used for Database Query, Report/form Design etc.
§ Stages: Req. collection, Design Strategy, 4GL implementation, Testing
§ Limitations: Limited usage domain, OK for moderate size only.
· Mixed Techniques:
§ Best of all worlds can be used per need.
§ Prototyping, 4GL, Spiral can often give a good mix.