What is Software? Instructions that when executed provide desired function and performance.

. Data structures that enable the programs to adequately manipulate the information Documents that describe the operation and use of the program. What is Software? An engineer is able to build a high quality product using off-the-shelf components and integrating them under time and budget constraints. The engineer is always faced with ill-defined problems, partial solutions and has to rely upon empirical methods to evolve solutions. What is Software? It is concerned with software systems built by teams rather than individuals, uses engineering principles in the development of these systems and includes both technical and non-technical aspects. From Programming to Software Programming is placing a sequence of instructions together to get the computer to do something useful. The problems being programmed were well understood; e.g. how to solve differential equation. The Software Crisis With introduction of the third generation computers there was a wide cost-gap between hardware and software. Hardware costs were tumbling down and software costs were soaring high. That was the crisis. The Software Crisis The crisis still remains unresolved The Software Crisis The costs are high per-se. The costs are high due to failures. The failures is the main crisis The failures Developers did not anticipate seldom occurring situations. Developers did not anticipate user actively misusing the system. The failures Reasons of failures: 1. Complexity: Difficult to understand Even during the development the problem is not understood. These softwares are called as Vaporware 2. Disagreement 3. Lack of standards and regulations 4. Poorly defined goals 5. Poor management 6. Poor communication

The failures Many solutions were proposed and tried. Better management techniques Different team organizations. Better programming languages and tools. Organization wide standards such as coding conventions. 5.Mathematical and formal approaches Software Engineering The consensus was reached to the view that the software should be built in the same way that engineers had built other large complex systems such as bridges, refineries, factories, ships and airplanes. The point of view was to build the software system as an engineering job. Thus, the term Software Engineering was born. Software Engineering Definition as per IEEE Std. 610.12-1990 Standard Glossary of Software Engineering Terminology. The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software. Parnas(1978) defined it as Multi-person construction of multi-version software. Software Engineering In conclusion, Software Engineering is concerned with software systems built by teams rather than individuals. uses Engineering principles in the development of these systems. includes both technical and non-technical aspects. Activities of Software Engg Modeling activity Problem solving activity Knowledge Acquisition activity Rationale-driven activity Activities of Software Engg Modeling activity S/w Engg deals with the complexity through modeling. A model is an abstract representation of a system that enables us to answer questions about the system. Activities of Software Engg Models of Problem domain and Solution Domain S/W Engineers need to learn the problem domain concepts that are relevant to the system. Hence they build a model of the problem domain.

 S/W Engineers try to provide different solutions and trade-offs. The representation is the model of Solution Domain. Activities of Software Engg Problem Solving activity Activities of Software Engg Knowledge-driven activity Activities of Software Engg Rationale-driven activity References Software Engineering, A practitioners Approach - Pressman Fundamentals of Software Engineering- Carlo Ghezzi et al PHI edition Object-oriented Software Engineering, Conquering Complex and Changing Systems- Bruegge and Dutoit- Prentice Hall No Silver Bullet: Essence and Accidents of Software Engineering. Paper by- Brooks F.P. - IEEE Software Engineering- Sommerville-Addison Wesley Software Engineering By Prashant Pund

Chapter 2 Requirements Engineering The Rock Problem The customer says, Bring me a rock. A rock is delivered. Customer: Yes, but actually I wanted a small blue rock. A small blue rock is delivered. Customer: Can you make it spherical? The Rock Problem Impression in the customers mind, No, you didnt understand what I meant. This is what I asked for but not what I wanted. Impression in the developers mind, For Gods sake, please decide what you really want and dont change it. Software Requirements Fundamentals Requirements Engineering has two basic steps: Requirement Elicitation Requirement Analysis

Software Requirements Fundamentals Requirement Elicitation: In this step, the client and the developer define the purpose of the system. They decide about the functional and non-functional requirements. Software Requirements Fundamentals Requirement Analysis : In this, the developers aim to produce an object model of the system from the use cases produced during the elicitation step. Requirement Elicitation The client , the developer and the users identify a problem area and define a system that addresses the problem. Such a definition is called as System Specification and serves as a contract between the client and the developer. Requirement Elicitation Requirement Elicitation The system specification is structured and formalized during analysis to produce an analysis model. Both System Specification and Analysis Model represent the same information. They differ only in the language and notation they use. Requirement Elicitation The system specification is written in natural language whereas the analysis model is usually expressed in a formal or semiformal notation. The system specification supports the communication with the clients and the users while the analysis model supports the communication among the developers. Requirement Elicitation Requirements Elicitation includes the following activities. Identifying the actors. Identifying scenarios. Identifying use cases. Refining use cases. Identifying relationships among the use cases. Identifying nonfunctional requirements Requirement Elicitation Identifying Non-functional Requirements User interface and human factors: What kind of interface should the system provide? What is the level of expertise of the users? Documentation: What level of document is required? Should only user document be provided? Should there be technical documentation for maintainers? Should the development process be documented? Requirement Elicitation 3. Hardware Considerations: Are there hardware compatibility requirements? Will the system interact with the other hardware systems? 4. Performance Characteristics: How responsive should the system be? How many concurrent users should the system support? What is the typical and extreme load?

Requirement Elicitation 5. Error Handling and extreme conditions: How should the system handle exceptions? Which exceptions should the system handle? What is the worst environment in which the system is expected to perform? Are there safety requirements on the systems? 6. Quality Issues: How reliable/available/robust should the system be? What is the clients involvement in assessing the quality of the system or the development process? Requirement Elicitation 7. System modifications: What is the anticipated scope of future changes?Who will perform the changes? 8. Physical environment: Where will the system be deployed? Are there external factors such as weather conditions that the system should withstand? 9. Security Issues: Should the system be protected against external intrusions or against malicious users? To what level? 10. Resource Issues: What are the constraints on the resources consumed by the system? Types of requirements Functional requirements Describe the interactions between the system and its environment independent of its implementation. Types of requirements Nonfunctional requirements Describe user-visible aspects of the system that are not directly related to the functional behavior of the system. These include quantitative constraints such as response time or accuracy etc. Types of requirements Pseudo Requirements Are requirements imposed by the client that restrict the implementation of the system. e.g. implementation language , platform etc. Analysis Principles The information domain of problem must be represented and understood. Analysis Principles The functions that the software is to perform must be defined. Analysis Principles The behavior of the software(as a consequence of external events) must be represented. Analysis Principles The models that depict information,function and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion. Analysis Principles The analysis process should move from essential information toward implementation detail. Prototyping Prototyping is an alternative to RA. A model of the software is constructed for customer and developer assessment.

Prototyping Scenario for Software Prototyping Evaluate the software request and determine whether the software to be developed is a good candidate for prototyping . Prototyping 2. Given an acceptable candidate project, develop an abbreviated representation of requirements. Prototyping 3. After the requirement model has been reviewed, an abbreviated design specification is created for prototype. Prototyping 4. Prototype software is created , tested and refined. Prototyping 5. Prototype is presented to the customer who may suggest modifications. Prototyping 6. Repeat steps 4 and 5 until all requirements are formalized. Software Requirements Specification(SRS) Properties of specification Correctness Completeness Clarity Consistency Realism Verifiability Traceability Software Requirements Specification(SRS) Correct: if it represents the clients view of the system. Complete:if all possible scenarios through the system are described, including exceptional behavior. Consistent: if it does not contradict itself. Unambiguous: not more than one interpretations. Software Requirements Specification(SRS) Realistic: if the system can be implemented within constraints. Verifiable: if a repeatable test can be designed to demonstrate that the system fulfills the requirement. Traceable: if each system function can be traced to its corresponding set of requirements. Requirement Analysis Analysis focuses on creating a system model, called the analysis model which is correct, consistent, complete, and verifiable. The analysis model may not be understandable to the client and the users but it helps developers verify the system specifications produced during the elicitation. Requirement Analysis

The analysis model is composed of three individual models. The functional model The analysis object model The dynamic model Requirement Analysis The functional model is represented by use cases and scenarios. The analysis object model is represented by class and object diagrams. The dynamic model is represented by statechart and sequence diagrams. Requirement Analysis Activities in Analysis: Identifying entity objects Identifying boundary objects Identifying control objects Mapping use cases to objects Identifying associations among objects Requirement Analysis Identifying object attributes Modeling non-trivial behavior with statecharts Modeling generalization relationships Reviewing the analysis model Requirement Analysis Advantages of categorizing the objects It provides developers with simple heuristics to distinguish different but , but related concepts. The three object approach results in smaller and more specialized objects. The three object type approach leads to model that are more resilient to change Requirement Analysis Reviewing the analysis model Software Requirements Specification(SRS) Principles Separate functionality from implementation. Select a process oriented language. A specification must encompass a system of which the software is a component. Software Requirements Specification(SRS) 4. A specification must encompass the environment in which the system operates. 5. A specification must be a cognitive model. 6. A specification must be operational. 7. A specification must be augmentable. 8. A specification must be loosely coupled. Specification Reviews Review at macroscopic level: Do stated goals and objectives for software remain consistent with system goals and objectives?

 Is information flow and structure adequately defined for the problem? Do major functions remain within the scope and had been adequately described? Are design constraints realistic? What is the technological risk of development? Specification Reviews Review at the microscopic level Watch out for vague terms Be sure that all items are understood Be sure stated ranges do not contain unstated assumptions. Look for statements that imply certainty. Format for SRS (IEEE 830-1984) 1. Introduction a. System reference b. Overall description c. Software Project constraints 2. Information description a. Information flow representation -data flow -control flow Format for SRS (IEEE 830-1984) 2. b. Information content representation c. System interface description 3. Functional Description a. functional partitioning b. functional description -Processing narrative -restrictions/limitations -performance requirements -design constraints -supporting diagrams Format for SRS (IEEE 830-1984) 3. c. Control Description -control description -design constraints 4. Behavioral Description a. System states b. events and actions 5. Validation criteria a. Performance bounds b. classes of tests c. expected software response d. special consideration 6. Bibliography

7. Appendix Format for Requirement Analysis Document (OO / UML based) 1. Introduction 2. Current System 3. Proposed System 3.1 Overview 3.2 Functional Requirements 3.3 Nonfunctional Requirements 3.4 Pseudo Requirements 3.5 System models Format for Requirement Analysis Document (OO / UML based) 3.5.1 Scenarios 3.5.2 Use case model 3.5.3 Object Model 3.5.3.1 Data dictionary 3.5.3.2 Class Diagrams 3.5.4 Dynamic models 3.5.5 User Interface-navigational paths and screen mock-ups 4. Glossary References Software Engineering, A practitioners Approach - Pressman Object-oriented Software Engineering, Conquering Complex and Changing Systems- Bruegge and Dutoit- Prentice Hall Software Engineering- Sommerville-Addison Wesley Managing Software Requirements, a unified approach- Dean Leffingwell, Don Widrig- Addison Wesley

What is design ?
A meaningful representation of something that is to be built Baseline and foundation for coding Should be traced to a customers requirements Should be assessed for quality against a predefined set of criteria

Importance of Design Success or failure of software application depend heavily on software design. The mistakes in any previous or subsequent stage can be rectified, but the mistakes related to design cannot be rectified. This is the process which requires Maximum decision making Lots of skill

 How to ensure that the design is full proof ? Mapping Requirements to Design Activities Software Design - Steps Translating the analysis model into a software design Software Design Concepts abstraction, refinement, modularity, information hiding Software Architectural Design Data Design User Interface Design Component-level Design flowchart, decision table, PDL What is Software Architecture? A working definition of Software Architecture: A software architecture is a description of the sub-systems and components of a software system along with its inter-relationships. Traditional terminology System (System) Product (Sub-System) Component (Module) Module (Unit) (Algorithm / function) Design Concepts Abstraction - generalization procedural, data, control Refinement - top-down elaboration Architecture Modularity Control hierarchy Structural partitioning Information hiding Functional Independence Abstraction Allows designers to focus on solving a problem without being concerned about irrelevant lower level details Procedural abstraction Data abstraction

Control abstraction . Modularity Software is divided into separately named and addressable components, called modules, which are integrated to satisfy the requirements. The single attribute of software that allows a program to be intellectually manageable. Benefits consistent with stepwise refinement (top-down design) a self contained unit. ease of use and understanding reuse and portability Control Terminology Span of control - maximum horizontal width ( can be at any level.) Depth (distance between the top and bottom modules in program control structure) Fan-out (number of modules directly controlled by a particular module). No. of modules used by the given module. Fan-in (number of modules that control a particular module) . No. of modules using the given module. Software Architecture Styles Various types of Architectural Styles 1. Data centered (Repositories) 2. Pipes and Filters ( Data flow Architectures). 3. Object Oriented. 4. Layered Systems. Data Centered (Repositories) Architecture Data Centered style systems have two distinct components: a central data structure which represents the current state, and a collection of independent components which operate on the datastore. Examples : Knowledge repositories on internet. Data warehousing applications CASE toolset architecture Pipes and Filters ( Data flow Architectures). Each component has a set of inputs and outputs. A component reads a stream of data on its input and produces a stream of data on its outputs. Components are called filters. Connectors serve as conduits for the information streams and are termed pipes. Not really suitable for interactive systems

Examples : Batch processing applications Unix shell programmes. Components are represented as Unix processes and pipes are created through the file system. Other examples include compilers, signal-processing systems etc.. Batch Processing Compiler model Layered Software Architecture A layered system is organized hierarchically with each layer providing service to the layer above it and serving as a client to the layer below. In some systems inner layers are hidden from all except the adjacent outer layer. Connectors are defined by the protocols that determine how layers will interact. Constraints include limiting interactions to adjacent layers. Examples : Internet Commerce applications developed using n-tiers TCP/IP architecture An Internet Banking System Why Partitioned Architecture? Results in software that is easier to test Leads to software that is easier to maintain Results in propagation of fewer side effects Results in software that is easier to extend Building the Structure Chart Processes in the DFD tend to represent one module on the structure chart The DFD levelling can correspond to the structure chart hierarchy Steps in Building the Structure Chart 1. Identify top level modules and decompose them into lower levels 2. Add control connections 3. Add couples 4. Review and revise again and again until complete Typical Structures Transaction structures Control modules that send work to subordinates for various processing work Often one inflow and several outflows on DFD Transform structure Modules that work together to perform a task Often one inflow that is changed into another sort of outflow on DFD

Functional Independence Functional independence Each module has a specific function and a simple interface with respect to the program structure. High quality structure charts result in programs that are modular, reusable and easy to implement. Why ? easier to develop as functions are grouped and separated and interfaces are simplified easier to maintain as error propagation is reduced and modules may be reusable Measured by Cohesion - measure of functional strength of module Coupling - measure of relative independence among modules Cohesion and Coupling Cohesion a cohesive module performs a single task, requiring little interaction with other modules/procedures strive for high functional cohesion in program structure Coupling measure of connectivity between modules data coupling - passing data between modules control coupling - passing signal or flag environment coupling - using same memory areas strive for low coupling Cohesion The measure of the strength of functional relatedness of the elements within a module. The extent to which all instructions in a module relate to performing a single unified task Goal: maximize cohesiveness Types of cohesion Functional Sequential Communicational Procedural Temporal

 Logical Coincidental Types of Cohesion Functional All elements in a module contribute to the execution of one and only one problem related task Usually easy to name with strong imperative names No time orientation - first, second, next, initialize No unnecessary calls to data or functions Examples: compute percentage of marks calculate interest amount Read record Sequential The module performs multiple processing functions on the same data items and these functions perform successive transformations on the data; the output of one instruction serves as the input to another instruction But the module operations don't constitute a single function. e.g. decide pass-fail status in an exam., decide eligibility of a student for a course. Types of Cohesion (cont) Communicational Elements of a module contribute to activities using the same input or output data Similar to sequential cohesion because the activities are related to each other by the data the module uses, but sequence is not important here. Usually maintainable. examples calculate average and max salary Procedural The elements within a module are grouped together based on flow of control in the program; Unrelated activities grouped together. The modules don't share data. Related by execution order and not purpose. Instructions must be carried out in the specified order, so sequence is important. Often based on a flowchart, causes maintenance problems. Types of Cohesion (cont) Temporal Elements of a module are related in time; instructions are executed in the same limited period of time during the execution of the system. Related through flow of control, but sequence is not important. Example: Initialize: module to initialize all variables, counters, switches, etc. End of job functions.

Logical The instructions are hardly related Elements contribute to activities of the same general category Several sets of instructions within the module, but the set that is executed is determined outside the module (usually via a incoming flag) Usually only one set of instructions in invoked during an execution of the module. Better to create a low level module and invoke from higher level modules Example : if device = x then do .. else if device = y then do Coincidencial Instructions within a module are not related. Generally requires an incoming flag to direct processing. Not related to the problem being solved. Very difficult to maintain. Requires re-engineering. Coupling Refers to the degree of interdependence between two modules Goal: minimize coupling. By: eliminating unnecessary relationships. reducing the number of necessary relationships. easing the tightness of necessary relationships. Why: the fewer the connections between modules the less the chances of ripple effects when the system is modified. Types of coupling Normal Data Stamp Control Common External Content