Software Engineering
Software Engineering
Process models : The waterfall model, Incremental process models, Evolutionary process models, The Unified process. Software Requirements : Functional and non-functional requirements, User requirements, System requirements, Interface specification, the software requirements document.
1
S.No Topic
1 2 3
PPTSlides
4 8 14
Process Models:Waterfall Model The incremental Model The RAD Model Evolutionary Process Models: prototype
4
5 6 7
L4
L5 L6 L7
19
25 28 30
8 9
L8 L9
38 40
PROCESS MODELS
Help in the software development Guide the software team through a set of framework activities Process Models may be linear, incremental or evolutionary
3
Modeling
Analysis design
Construction
Code test
Deployment
Delivery Support 5 feedback
Increment # n
Communication Planning
Modeling
Analysis design
Construction
Code test
Deployment
Delivery Support feedback
Communication Planning
Modeling
Analysis design
Increment # 1
Communication Planning
Construction
Code test
Deployment
Delivery Support feedback
Modeling
Analysis design
Construction
Code test
Deployment
Delivery Support feedback
Construction
Construction
Planning
Team # 1 Modeling
Business modeling Data modeling Process modeling
Deployment
integration delivery feedback
Construction
Component reuse automatic code generation testing
11
PROTOTYPING
Mock up or model( throw away version) of a software product Used when customer defines a set of objective but does not identify input,output,or processing requirements Developer is not sure of:
efficiency of an algorithm
Construction of prototype
15
STEPS IN PROTOTYPING
Begins with requirement gathering Identify whatever requirements are known Outline areas where further definition is mandatory A quick design occur Quick design leads to the construction of prototype Prototype is evaluated by the customer Requirements are refined Prototype is turned to satisfy the needs of customer
16
LIMITATION OF PROTOTYPING
In a rush to get it working, overall software quality or long term maintainability are generally overlooked Use of inappropriate OS or PL
19
Event generated at one point in the process trigger transitions among the states
22
24
26
SOFTWARE REQUIREMENTS
IEEE defines Requirement as : 1. A condition or capability needed by a user to solve a problem or achieve an objective 2. A condition or capability that must be met or possessed by a system or a system component to satisfy constract,standard, specification or formally imposed document
SOFTWARE REQUIREMENTS
Encompasses both the Users view of the requirements( the external view ) and the Developers view( inside characteristics) Users Requirements --Statements in a natural language plus diagram, describing the services the system is expected to provide and the constraints System Requirements --Describe the systems function, services and operational condition
30
SOFTWARE REQUIREMENTS
System Functional Requirements --Statement of services the system should provide --Describe the behavior in particular situations --Defines the system reaction to particular inputs Nonfunctional Requirements - Constraints on the services or functions offered by the system --Include timing constraints, constraints on the development process and standards --Apply to system as a whole Domain Requirements --Requirements relate to specific application of the system --Reflect characteristics and constraints of that system
31
FUNCTIONAL REQUIREMENTS
Should be both complete and consistent Completeness -- All services required by the user should be defined Consistent -- Requirements should not have contradictory definition Difficult to achieve completeness and consistency for large system
32
Types of Non-functional Requirements 1.Product Requirements -Specify product behavior -Include the following Usability Efficiency Reliability Portability 2.Organisational Requirements --Derived from policies and procedures --Include the following: Delivery Implementation Standard
NON-FUNCTIONAL REQUIREMENTS
3.External Requirements -- Derived from factors external to the system and its development process --Includes the following
33
34
Interface Specification
Working of new system must match with the existing system Interface provides this capability and precisely specified Three types of interfaces 1.Procedural interface -- Used for calling the existing programs by the new programs 2.Data structures --Provide data passing from one sub-system to another 3.Representations of Data -- Ordering of bits to match with the existing system --Most common in real-time and embedded system
38
39
Purpose of SRS
communication between the Customer, Analyst,system developers, maintainers, .. firm foundation for the design phase support system testing activities Support project management and control controlling the evolution of the system
41
IEEE requirements standard Defines a generic structure for a requirements document that must be instantiated for each specific system.
Introduction. General description. Specific requirements. Appendices. Index.
42
43
2. General description 2.1 Product perspective 2.2 Product function summary 2.3 User characteristics 2.4 General constraints 2.5 Assumptions and dependencies 3. Specific Requirements - Functional requirements -External interface requirements - Performance requirements - Design constraints - Attributes eg. security, availability,maintainability, transferability/conversion - Other requirements
44
Appendices Index
45