Software Engineering Notes

Software Engineering
SOFTWARE ENGINEERING
Chapter I Overview
Definition of Software: Software is i) instructions (computer programs that when executed provide desired function and performance, ii) data structures that enable the programs to adequately manipulate information, and iii) documents that describe the operation and use of programs. Definition of Software Engineering (SE): The definition given by IEEE: Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. The definition of SE given by Boehm: Software Engineering involves the practical application of scientific knowledge to the design and construction of computer programs and the associated documentation required to develop, operate and maintain them. Software Engineering can also be defined as The systematic approach to the development, operation, maintenance, and retirement of software, where software is defined as: Computer programs, procedures, rules and associated documentation and data pertaining to the operation of a computer system.
FAQs (Frequently Asked Questions) about Software Engineering:

Difference between software engineering and computer science Computer Science Software Engineering 1 Concerned with theories and methods Concerned with practical problems of which involve computers and software producing software systems 2. Fully theoretical and fundamental Though s/w engineering involves theories of computer science, it is not fully theoretical. Practicalities are involved in developing solutions. 3. Solutions for complex problems are Adhoc approaches are used to develop a stated theoretically. software solution to solve real, complex problems. Theories of computer science cannot always be applied. Aparna K, Dept. of MCA, BMSIT 1
Difference between software engineering and system engineering. Software Engineering Software engineering is a part of system engineering System Engineering Concerned with all aspects of the development and evolution of complex systems where software plays a major role.
Software Process A software process is a set of activities and associated results which produce a software product. These activities are carried out by software engineers. Four fundamental process activities which are common to all software processes are : 1. Software specification: The functionality of the software and the constraints on its operation must be defined. 2. Software development: The software to meet the specification must be produced. 3. Software Validation: The software must be validated to ensure that it does what the customer wants. 4. Software Evolution: The software must evolve to meet changing customer needs. There is no such thing as a right or a wrong software process. Different software processes decompose (organize) theses activities in different ways. Different organizations use different processes to produce the same type of product. The timing and result of each activity also varies. Some processes are more suitable than others for some types of applications. If a wrong process is used, it may reduce the quality and the usefulness of the product to be developed. Software Process Model: Models, in general, can be defined as specifications of any given entity or a simplified description of any given entity. Hence, a software process model is a simplified description of a software process. In other words, a software process model is an abstraction of the actual process which is being described. Process models include: - activities, which are part of software process - software products - roles of people involved in software engineering.
Types of software process model: Aparna K, Dept. of MCA, BMSIT 2
Software Engineering Some examples of the types of S/W process model: 1. A Workflow model: This model basically represents the sequence of activities involved in the process along with their inputs, outputs and dependencies. The activities are represented by the human actions. 2. A data-flow or activity model: In this type of model, the process is basically represented as a set of activities which carries out some data transformation. For instance, it shows how the input to the process such as specification is transformed to an output as a design. The activities in this model are at a lower level than activities involved in the workflow model. The transformations can either be carried out by people or by computer. 3. A role / action model: This model represents the roles of the people involved in the software process and the activities for which they are responsible. General Process Models / Paradigms of Software development: 1. The Waterfall model: In this approach, each of the activities that are involved, are represented as separate phases such as requirements specification, software design, implementation, testing and so on. After each stage is defined, it is frozen and development goes on to the following stage. 2. Evolutionary Development: In this approach, the activities of different phases such as specification, development, validation etc, are interlinked. An initial system is rapidly developed from very abstract specifications. This is then refined / enhanced several times to produce the final system that satisfies the customers needs. 3. Formal transformation: This approach is based on producing a mathematical specification of the system and then transforming this specification into a program using mathematical methods. This method assures the correctness of the specification. 4. System assembly from reusable components: This approach is based on the assumption that parts of the system already exists. Hence, this approach mainly focuses on integration of these parts rather than developing them from scratch. Costs involved in Software Engineering: Distribution of costs across the software process depends on the process used and the type of software which is being developed. Assuming that the total cost of developing software, is 100 cost units, a general distribution across the various phases can be shown as below:
Aparna K, Dept. of MCA, BMSIT
It is clear from the above figure, that system integration and testing is the most expensive activity. It is about 40% of the total development cost. If the software is developed using an evolutionary approach, then the distribution of costs can be shown as below:
Here, the specification costs are reduced because only a high-level specification is produced before development. Specification, design, implementation, integration and testing are carried out in parallel within a development activity. But a separate testing activity is needed once the initial implementation is complete. Apart from development costs, costs are also incurred in changing the software after it has gone into use. For many software systems which have a long lifetime, these costs are likely to exceed the development costs as shown below:
All the above cost distribution holds for customized software which is specified by a customer and developed by a contractor. For software products which are mostly sold for PCs, the cost profile is likely to be different. As these products are developed using an evolutionary approach, the specification costs are relatively low. But, because they are used on a range of different configurations, they must be extensively tested. Hence, the testing costs are high as shown below: Software Engineering Methods A software engineering method is a structured approach to software development whose aim is to produce high-quality software in a cost-effective way. Some of the methods are: 1. Structured Analysis and JSD (Jackson System Development): These methods were developed in 1970s and they attempted to identify the basic functional components of a system. These are basically function-oriented methods. 2. Object-oriented methods: Function-oriented methods were supplemented by object-oriented methods proposed by Booch and Rumbaugh. 3. Unified Modeling Language (UML): All the above different approaches were integrated into a single unified approach called the UML. All the above methods are based on the idea of developing models of a system which may be represented graphically. These models can in turn be used as a system specification or design. Methods include the following components: 1. System model descriptions: This includes the descriptions of the system models which should be developed and the notation used to define these models. 2. Rules: This component involves the constraints that apply to the system models. 3. Recommendations: This includes a set of recommendations which if followed should lead to a well-organized system model. 4. Process guidance: This includes the descriptions of the different activities and the organization of these activities which are used to develop the system models.
Software Engineering There is no ideal method and different methods have different areas where they are applicable. Attributes / Characteristics of a good software Software products have a number of attributes which reflect the quality of that software. These attributes are not directly concerned with what the software does, but they reflect its behaviour while it is executing and the structure and organization of the source program and associated documentation. Some of the essential attributes are: a) Maintainability: Software should be written in a flexible manner so that it may be evolved to meet the changing needs of customers. This attribute is essential since software change is inevitable. b) Dependability: This attribute includes reliability, security and safety. Dependable software should not cause any damage in the event of system failure. c) Efficiency: This attribute includes responsiveness, processing time, memory utilization etc. This attribute should ensure that the system resources are used in a cost-effective way. d) Usability: Software must be usable by the user for whom it is designed without any extra effort from his side. This means that it should have an appropriate user interface and adequate documentation. Challenges facing Software Engineering The three key challenges facing software engineering are: i) The Legacy Challenge: The legacy challenge is the challenge of maintaining and updating software in such a way that excessive costs are avoided and essential business services continue to be delivered. This challenge is essential for software systems which were developed many years ago and which are in use even today. The Heterogeneity Challenge: The heterogeneity challenge is the challenge of developing techniques to build dependable software which is flexible enough to cope with heterogeneity. This challenge is required for systems that are required to operate as distributed systems across networks that include different types of computer and with different kinds of support systems. The Delivery Challenge: The delivery challenge is the challenge of shortening delivery times for large and complex systems without compromising system quality. This challenge is essential, since many 6
ii)
iii)
Software Engineering software engineering techniques are time consuming. In other words, the time taken to achieve good quality is more.
Professional and Ethical Responsibility The work of software engineers is carried out within a legal and social framework. Software engineering is bounded by local, national and international laws. Software engineers must behave in an ethical and morally responsible way if they are to be respected as professionals. Engineers should uphold normal standards of honesty and integrity. They should not use their skills and abilities to behave in a dishonest way or in a way that will bring disrepute to the software engineering profession. Some of the ethics which needs to be followed: 1. Confidentiality: Engineers should normally respect the confidentiality of their employers or clients irrespective of whether it is formal or not. 2. Competence: Engineers should not misrepresent their level of competence. They should not knowingly accept work which is beyond their competence. 3. Intellectual property rights: Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright etc. Engineers should ensure that they are protected. 4. Computer Misuse: Software engineers should not use their technical skills to misuse other peoples computers to any extent.
Socio-Technical Systems
Emergent system properties Systems engineering Organizations, people and computer systems Legacy systems
What is a System? A system is a purposeful collection of interrelated components that work together to achieve some objective. System includes software, hardware, system interactions with users and its environment. Properties and behavior of system components influence each other. E.g. Traffic control system hardware, software, human users who make decisions based on system information. Successful functionality of each system component depends on the functioning of some other components. Types of System Technical computer-based systems Includes hardware, software components and not the procedures and processes. Socio-technical systems Includes hardware, software components and also includes procedures and processes. Users are inherent part of the system. Operational policies are governed by organizational policies and government regulations. Characteristics of Socio-Technical Systems Emergent Properties Properties of these system as a whole (not due to individual component) but due to relationship among the components. These properties can be evaluated once the system is assembled. Non-deterministic Property These system may not produce specific output when a specific input is given. Systems behaviour depends on the way operator use the system. Complex Relationship with Organizational Objective Success of these systems in supporting the organizational objectives depends on the stability of these objectives. E.g. new management may reinterpret the organizational objective that a system is designed to support and a successful system may then become a failure. Emergent Properties Properties of the system as a whole rather than properties that can be derived from the properties of components of a system. Emergent properties are the consequences of the relationships between system components. They can therefore only be assessed and measured once the components have been integrated into a system.
Software Engineering Examples of Emergent Properties Volume Physical space occupied by the system Depends on the method of assembling the components Reliability This depends on the reliability of system components and the relationships between the components. Security This is a complex property and can not be easily evaluated. Built-in safe guards may not give security to system. Reparability Repairabit:: Repairability: If system defect can be fixed easily, system is reparable, thus depends on designers ability to diagnose the problem and faulty component The usability of a system This is a complex property which is not simply dependent on the system hardware and software but also depends on the system operators knowledge and the environment where it is used.
Types of Emergent Properties Functional Emergent properties These appear when all the parts of a system work together to achieve some objective. For example, a bicycle has the functional property of being a transportation device once it has been assembled from its components. Non-functional emergent properties Examples are reliability, performance, safety, and security. These relate to the behavior of the system in its operational environment. They are often critical for computer-based systems as failure to achieve some minimal defined level in these properties may make the system unusable. System Reliability Reliability is a complex concept that must always be considered at the system level rather than at the individual component level. Because of component inter-dependencies, faults can be propagated through the system. System failures often occur because of unforeseen inter-relationships between components. Software reliability measures of individual components may give a false picture of the system reliability. Hardware reliability What is the probability of a hardware component failing? How long does it take to repair that component? Software reliability What is the probability of a software component to produce an incorrect output?
Software Engineering Software failure is usually distinct from hardware failure in that software does not wear out. What is the time required to make corrections? Operator reliability How likely is it that the operator of a system will make an error? Reliability Relationships All the different reliability is interlinked. One component failure may lead to entire system failure. Reliability also depends on the context in which system is used. E.g. system working in a particular range of temperature (10-250 C.) may not work at high temperature. The environment in which a system is installed can affect its reliability. System Engineering Process
System engineering usually follows a waterfall model. Scope of iteration Little scope for iteration between phases because hardware changes are very expensive. Software is flexible to incorporate small changes. Interdisciplinary development Scope for misunderstanding here Different disciplines use a different vocabulary and much negotiation is required. Engineers may have personal agendas to fulfill. The figure below shows that System engineering process is an activity of Interdisciplinary Involvement
10
Systems Requirement Definitions:Three types of requirement are defined at this stage: Abstract functional requirements: Basic functionality of system. Ex: Air traffic control system: Requirements need is to store the flight plans of all aircraft entering the controlled space. Detailed functional requirements at subsystem level. System properties: Non-functional emergent system properties such as availability, performance, safety, security etc. Characteristics that the system must not exhibit: Unacceptable behavior of system is specified. E.g.:- too much information with controller is not desirable. Should also define overall organizational objectives for the system. This phase is difficult sometimes when wicked problems are considered such as earthquake planning. This problem can be tackled only after the earthquake has taken place. The System Design Process This process deals with creating a representation or model of the system. It contains following phases: Partition requirements Identify sub-systems Assign requirements to sub-systems Specify sub-system functionality Define sub-system interfaces There is a lot of feedback and iteration from one stage to another in design process.
11
Partition requirements: Organise requirements into related groups. Many criteria of grouping are possible. Identify sub-systems: Identify a set of sub-systems which individually or collectively can meet the system requirements Assign requirements to sub-systems: requirements to identified sub-system It is a complicated task i.e. assigning
Specify sub-system functionality: Define specific functionality and interrelationship of sub-systems Define sub-system interfaces: Critical activity for parallel sub-system development. Sub-system interface defined and parallel development can be started. System Modeling System is modeled as a set of components and relationships between these components. The system models are graphical representations that provide an overview of system organization. Major sub-systems and interconnection between these components are represented with the help of a block diagram. The block diagram should be supplemented by a brief description of each system. For ex, consider the system model of an intruder alarm system.
12
Components in the Intruder alarm System Sensors Movement sensor, door sensor Detects movement in the rooms and door openings Actuator Siren emits an audible warning when an intruder is suspected Communication Telephone caller makes external calls to notify security, the police etc. Co-ordination Alarm controller controls the operation of the system Interface Voice synthesizer synthesizes a voice message giving the location of the suspected intruder Sub-System Development Another system engineering process may be carried out for individual subsystem. If subsystem is software, software engineering process shall be carried out. All subsystem may not be developed from scratch. Subsystems can be COTS (cheaper) COTS may not exactly possess requirements according to given needs, thus design activity is carried out again. Different subsystem can be developed in parallel. System modification in hardware is difficult and expensive. In software required changes can be easily incorporated. System Integration
13
Software Engineering Integration is the process of putting hardware, software and people together to make a system. Two approaches for system integration are as follows: Big bang approach: All subsystems are integrated at same time. Incremental approach: Incrementally one at a time. Subsystems may not be fully developed at same time. Reduces the cost of error location. Integration should be tackled incrementally so that sub-systems are integrated one at a time. Interface problems between sub-systems are usually found at this stage. There may be problems with uncoordinated deliveries of system components. System Installation System is put in operating environment. Environment assumption may be incorrect. There may be human resistance to the introduction of a new system. New system may coexist with existing system. There may be physical installation problems e.g. cabling problem, need of air conditioners. Training for operators has to be identified. System operation will bring unforeseen requirements to light. Users may use the system in a way which is not anticipated by system designers. System operation may reveal problems in the interaction with other systems such as Physical problems of incompatibility, Data conversion problems, increased operator error rate because of inconsistent interfaces. System Evolution Large systems have a long lifetime, thus system must evolve to meet changing requirements. Evolution is inherently costly, thus Changes must be analysed from a technical and business perspective Sub-systems interact so unanticipated problems can arise System structure is corrupted as changes are made to it Existing systems which must be maintained are sometimes called legacy systems. Documentation must be created for changed functionality for further development. System Decommissioning Taking the system out of service after its useful lifetime. This may require removal of materials (e.g. dangerous chemicals) which pollute the environment. It should be planned for reuse in the system design. This may require data to be restructured and converted to be used in some other system. Organizations, People and Computer Systems Human, social and organizational factors play critical role to understand system requirements. The development, procurement and use of these systems is greatly influenced by policies, procedure and work-culture of the environment. System designer should include all relevant information about the organization in the system specifications.
14
Software Engineering Errors in requirements (due to non-availability of realistic requirements) may cause malfunctioning of the system. The integration of socio-technical system in the business organization will result in certain changes. Some of the changes are: Process changes Job changes Organizational changes Process changes Existing work process may change, thus people may require training. A system which require extensive training or poses threats to jobs may be resisted by employees Job changes If system needs changes in style of working, or lowers the status of the people, system may be opposed. Organizational changes These systems may lead to changes in its political powerful class. Organizational Processes As system engineering deals with development process of the system, it also deals with procurement process operational process Procurement Process: Procurement process ensures that organization acquires required system at most competitive and favorable terms. Process of using and operating the system is also defined. Organizational processes:
System Procurement: Acquiring a system for an organization to meet some need is called procurement. Large system is combination of a) COTS b) Specially built components System specifications and architectural design is necessary before procurement. A specification is needed to let a contract for system development. The specification may allow us to buy a commercial off-the-shelf (COTS) system, almost always cheaper than developing a system from scratch. Software is mostly required to glue the hardware with Aparna K, Dept. of MCA, BMSIT 15
Software Engineering each other (to create interface between subsystems). Requirements may have to be modified to match the capabilities of off-the-shelf components. The requirements specification may be part of the contract for the development of the system. After selecting contractor, contract negotiation about schedule and cost can be done. There is usually a contract negotiation period to agree changes after the contractor to build a system has been selected.
The procurement of large hardware /software systems is usually based around some principal contractor. Sub-contracts are issued to other suppliers to supply parts of the system. Customer deals with the principal contractor and does not deal directly with subcontractors. Legacy Systems Legacy systems are socio-technical systems that have been developed in past using old or obsolete technology. These systems are crucial to the operation of a business, often too risky to discard these systems, thus they are maintained. Bank customer accounting system Aircraft maintenance system. Legacy systems undergo evolution throughout their life with changes to accommodate new requirements and new operating platforms. Components of Legacy systems Hardware legacy systems have been written for mainframe hardware that is expensive to maintain and may not be compatible with current organizational IT purchasing policies. Support software legacy systems may rely on support software (operating system and utilities) from suppliers who are no longer in business. 16
Software Engineering Application software - legacy systems may be written in obsolete programming languages and composed of several programs that have been developed at different times. Application data In legacy systems, often data is incomplete, inconsistent and duplicated in several files Business processes These may be constrained by software structure and functionality of a legacy system. Business policies and rules Use of legacy application system may be implicit and embedded in these policies and rules.
Layered Model of Legacy systems Components of legacy system are a series of layers. Each layer depends on the layer immediate below it and interface with that layer. It appears that changes can be made in any layer if interfaces are maintained.
17
Software Engineering In practice, changes lead to changes in other layers also due to following reasons: Any change in a layer may emerge new functionality and adjacent layer has to be changed to make use of new functionality. Changes in software may make system slow and new hardware is required to enhance system performance. Maintaining hardware interfaces may be impossible if any radical changes are made to hardware.
18
QUESTION BANK FOR CHAPTER I (Overview)

1. What is software? 2. What is Software Engineering? 3. What is the difference between software engineering and computer science? 4. What is the difference between software engineering and systems engineering? 5. What is a software process? 6. What is a software process model? 7. What are the costs of software engineering? 8. What are software engineering methods? 9. What are the attributes of good software? Explain. 10. What are the key challenges facing software engineering? 11. What are the professional and ethical responsibilities of software engineer? Explain. 12. Write a note on socio-technical systems. 13. What are the Emergent system properties? Explain the two different types. 14. What is System Engineering? List and explain the different steps with a neat diagram. 15. With respect to Systems Engineering, explain System Requirement definition. 16. With respect to Systems Engineering, explain all the steps involved in System Design. 17. With respect to Systems Engineering, write a note on systems integration, system evolution, and system decommissioning. 18. Explain System Procurement process. 19. Write a note on Legacy systems.
19
Chapter II Critical Systems, Software Processes

Critical Systems A simple safety-critical system System dependability Availability and reliability Safety Security
Critical systems are those whose failure may cause: Significant economic losses Physical damage Threats to human life Thus critical system are developed using time tested techniques instead of new techniques for development & testing. Cost is always secondary for critical system. Formal development is preferred. Priority is high dependability, thus costs of V & V is also very high. Types of Critical Systems Safety-critical systems Failure results in loss of life, injury or damage to the environment Chemical plant protection system Mission-critical systems Failure results in failure of some goal-directed activity Spacecraft navigation system Business-critical systems Failure results in high economic losses Customer accounting system in a bank
Dependability is critical attribute for critical system and sub-attributes of dependability are: Availability Reliability Safety Security For critical systems, most important system property is the dependability of the system. The dependability of a system reflects the users degree of trust in that system. It reflects the extent of the users confidence that it will operate as users expect and that it will not fail in normal use. Usefulness and trustworthiness is not the same thing. A system does not have to be trusted to be useful. Importance of Dependability Aparna K, Dept. of MCA, BMSIT 20
Software Engineering Unreliable systems are not underutilized. Cost of system failure may be very high and serious. Lack of high performance may be acceptable. Undependable systems or system failure may cause information loss with a high consequent recovery cost. Dependability is difficult to achieve at post development phase.
Socio-Technical Critical systems Hardware failure Hardware fails because of design and manufacturing errors or because components have reached the end of their natural life. Software failure Software fails due to errors in its specification, design or implementation. Operational failure Human operators make mistakes. Now perhaps this is largest single cause of system failures. These failures are interrelated. Example: Software controlled insulin pump
Insulin reservoir Needle assem bly
Pump
Clock
Sensor
Controller
Alarm
Display 1
Display 2
Power supply
Used by diabetics to simulate the function of the pancreas which manufactures insulin, an essential hormone that metabolizes blood glucose. Measures blood glucose (sugar) using a micro-sensor and computes the insulin dose required to metabolize the glucose.
21
Software Engineering Insulin pump data flow
Dependability requirements in insulin pump The system shall be available to deliver insulin when required to do so. The system shall perform reliability and deliver the correct amount of insulin to counteract the current level of blood sugar. The essential safety requirement is that excessive doses of insulin should never be delivered as this is potentially life threatening. Dependability: The dependability of a system equates to its trustworthiness. A dependable system is a system that is trusted by its users. Principal dimensions of dependability are: Availability Reliability Safety Security Dimensions of Dependability
D e p e n d a b i l i t y
A v a i l a b i l i t y
R e l i a b i l i t y
S a f e t y
S e c u r i t y
T h ea b i l i t yo ft h es y s t e m t o d e l i v e rs e r v i c e sw h e n r e q u e s t e d
T h ea b i l i t yo ft h es y s t e m t o d e l i v e rs e r v i c e sa s s p e c i f i e d
T h ea b i l i t yo ft h es y s t e m t o o p e r a t ew i t h o u t c a t a s t r o p h i cf a i l u r e
T h ea b i l i t yo ft h es y s t e m t o p r o t e c ti t e l fa g a i n s t a c c i d e n t a lo rd e l i b e r a t e i n t r u s i o n
22
Software Engineering Availability It is the probability that the system will be operating and able to deliver the useful and required services at given point of time. Reliability It is the probability that the system will operate to provide expected services without failure under given conditions for a given time interval. Safety It is ability of system to operate without posing any risk to the people and its environment. Security It is ability of system to protect itself against accidents or deliberate intrusion. Availability and reliability are probabilities hence can be measured quantitatively, safety and security are based on judgment. Dependability properties are complex and can be divided further: Security includes: Integrity Confidentiality Reliability includes: Correctness Precision Timeliness Other dependability properties Dependability includes other properties like Reparability, Maintainability, Survivability, Error tolerance. All properties may not be applicable to all the systems. High availability can be achieved at the cost of high performance. Dependable software may include redundant code which reduces system performance and increase development cost. Reparability Reflects the extent to which the system can be repaired in the event of a failure. Maintainability Reflects the extent to which the system can be adapted to new requirements. Survivability Reflects the extent to which the system can deliver services during hostile attack. Error tolerance Reflects the extent to which user input errors can be avoided and tolerated.
23
Software Engineering Dependability vs. Performance Untrustworthy systems may be rejected by their users. System failure costs may be very high. It is very difficult to tune systems to make them more dependable. It may be possible to compensate for poor performance. Untrustworthy systems may cause loss of valuable information. Dependability costs Dependability costs tend to increase exponentially as increasing levels of dependability are required. There are two reasons: The use of more expensive development techniques and hardware that are required to achieve the higher levels of dependability The increased testing and system validation that is required to convince the system client that the required levels of dependability have been achieved
Low
Medium
High
V ery high
Ultr a-high
Dependability
Because of very high costs of dependability achievement, it may be more cost effective to accept untrustworthy systems and pay for failure costs. However, this depends on social and political factors. The products that cant be trusted may lose future business. Depends on system type - for business systems in particular, modest levels of dependability may be adequate. Availability and Reliability Reliability The probability of failure-free system operation over a specified time in a given environment for a given purpose Availability The probability that a system, at a point in time, will be operational and able to deliver the requested services Both of these attributes can be expressed quantitatively. It is sometimes possible to subsume system availability under system reliability. If a system is unavailable it is not delivering the specified system services. However, it is possible to have systems with low reliability that must be available. As long as system failures can be repaired quickly Aparna K, Dept. of MCA, BMSIT 24
Software Engineering and do not damage data, low reliability may not be a problem. Availability takes repair time into account. Reliability Terminology Human error or mistake: Erroneous human action that results in introduction of fault in system. System fault: An incorrect system state that is unexpected by the system designer. System error: Erroneous system behavior that does not conform to its specification. System failure: An unacceptable behavior exhibited by a system at some point in time.
Reliability Faults and failures Failures are usually a result of system errors that are derived from faults in the system. However, faults do not necessarily result in system errors. The faulty system state may be transient and corrected before an error arises. Errors do not necessarily lead to system failures. The error can be corrected by built-in error detection and recovery. The failure can be protected by built-in protection facilities. Every system has an input-output mapping where only some inputs will result in erroneous outputs. The reliability of the system is the probability that a particular input will lie in the set of inputs that cause erroneous outputs. Different people will use the system in different ways so this probability is not a static system attribute but depends on the systems environment. Reliability Input / Output mapping
25
Software Engineering Reliability Perception
Reliability Improvement Removing X% of the faults in a system will not necessarily improve the reliability by X %. A study at IBM showed that removing 60% of product defects resulted in a 3% improvement in reliability. Program defects may be in rarely executed sections of the code so may never be encountered by users, thus removing these does not affect the reliability. A program with known faults may therefore still be seen as reliable by its users. Approaches to improve Reliability Fault avoidance Development technique are used that either minimise the possibility of mistakes or trap mistakes before they result in the introduction of system faults. E.g. less use of pointers Fault detection and removal Verification and validation techniques that increase the probability of detecting and correcting errors before the system goes into service are used. Fault tolerance Run-time techniques are used to ensure that system faults do not result in system errors and/or that system errors do not lead to system failures.
Safety Safety is ability of a system to operate without posing any threat to life and environment. System where safety is considered as most critical requirement is a safety critical system. Examples: Air traffic control system Process control systems in nuclear power system
26
Software Engineering Primary safety-critical systems: Embedded software systems whose failure can cause the associated hardware to fail and directly threaten peoples life and environment. Ex: Air traffic control system Secondary safety-critical systems: Systems whose failure results in introduction of faults in other systems which can threaten peoples life and environment. An error in CAD is responsible for design fault; hence system may be faulty and in turn leads to failure. Safety and Reliability Safety and reliability are related but distinct. In general, reliability and availability are necessary but not sufficient conditions for system safety. Reliability is concerned with conformance to a given specification and delivery of service. Fault tolerance does not ensure safety because the system may still behave in ways that may cause accident. Safety is concerned with ensuring system cannot cause damage irrespective of whether or not it conforms to its specification. Unsafe Reliable systems: Specification errors If the system specification is incorrect then the system can behave as specified but still cause an accident Hardware malfunctioning Hard to anticipate in the specification Operator error Context-sensitive commands i.e. issuing the right command at the wrong time Safety achievement Hazard avoidance The system is designed so that some classes of hazard simply cannot arise. E.g. wood cutting machine Hazard detection and removal The system is designed so that hazards are detected and removed before they result in an accident. e.g. high pressure in chemical plant Damage limitation The system includes protection features that minimise the damage that may result from an accident. E.g. automatic fire extinguishers Security The security of a system is a system property that reflects the systems ability to protect itself from accidental or deliberate external attack. Security is becoming increasingly important as systems are networked so that external access to the system through the Internet is possible. Security is an essential pre-requisite for availability, reliability and safety. If a system is a networked system and is insecure then statements about its
27
Software Engineering reliability and its safety are unreliable. Intrusion can change the executing system and/or its data. Therefore, the reliability and safety assurance is no longer valid. Damage from insecurity Denial of service The system is forced into a state where normal services are unavailable or where service provision is significantly degraded Corruption of programs or data The programs or data in the system may be modified in an unauthorised way Disclosure of confidential information Information that is managed by the system may be exposed to people who are not authorised to read or use that information Security Assurance Vulnerability avoidance The system is designed so that vulnerabilities do not occur. For example, if there is no external network connection then external attack is impossible Attack detection and elimination The system is designed so that attacks on vulnerabilities are detected and neutralised before they result in an exposure. For example, virus checkers find and remove viruses before they infect a system Exposure limitation The system is designed so that the adverse consequences of a successful attack are minimised. For example, a backup policy allows damaged information to be restored Safety and Security Terminologies Accident It is an unplanned event that results in loss of lives and property or damage to the environment. Hazard A condition with potential to cause an accident. Damage It is a measure of loss resulting from an accident. Risk It is a measure of probability that the system will cause an accident. Exposure A possible harm that may be caused by an unauthorized user. Vulnerability Susceptibility to an external attack aimed at causing harm to a system. Attack Violation of system security by exploiting its vulnerability. Threat A condition with potential to cause harm to a computing system
28
Software Processes
Software Processes Models Process iteration Process activities The Rational Unified Process Computer-Aided Software Engineering
The Software Process A frame work for the tasks that are required to produce a high quality software product. or The process followed by a software engineer to build, deliver, deploy and evolve a software product from inception to the delivery Each process is governed by a set of principles, goals, and carried out under some constraints like budget, time, tools etc.
A software process is a structured set of activities required to develop a software system. The activities include the following: Software Specification The functionality of the software, and constraints on its operation must be defined Software Design & Implementation The software to meet the specification must be produced. Software Validation The software must be validated to ensure that it does what the customer wants. Software Evolution The software must evolve to meet changing customer needs The Software Model A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. The need for process model is as follows: To understand the activities and constraints involved in developing a software product. To identify inconsistencies, redundancies and omissions in development process making the process more effective. To evaluate the appropriateness of various activities. Generic Software Process models The Waterfall model Separate and distinct phases of specification and development. 29
Software Engineering Evolutionary development Specification, development and validation are interleaved. Component-based software engineering The system is assembled from existing components
The Waterfall Model Also called Classic Life Cycle or Linear Sequential Model. It suggests a systematic, sequential approach to software development. In this model, each of the process activities is represented as a phase. Because of the cascade from one phase to another, as shown below, this model is known as the Waterfall model.
The different phases of the above model are: a) Requirements analysis and definition: The systems services, constraints and goals are established by consultation with system users. They are then defined in a manner which is understandable by both users and development staff. b) System and software design: The systems design process partitions the requirements to either hardware or software systems. It establishes an overall system architecture. Software design involves representing the software system functions in a form that may be transformed into one or more executable programs.
30
Software Engineering c) Implementation and unit testing: In this stage, the software design is realized as a set of programs or program units. Unit testing involves verifying that each unit meets its specification. d) Integration and system testing: The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to the customer. e) Operation and Maintenance: In this phase, the system is installed and put into use practically. Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle, improving the implementation of system units and enhancing the systems services as new requirements are discovered. The result of each phase is one or more documents which are approved at the end of the phase. The software process is not a simple linear model but involves a sequence of iterations of the development activities. Unfortunately, a model which involves frequent iterations increases the costs of producing and approving documents. Therefore, after a small number of iterations, it is normal to freeze parts of the development, such as specification and continue with the later development stages. This premature freezing of requirements may mean that the system wont do what the user wants. It may also lead to unstructured systems. Merits of waterfall model: Easy to understand. Produces clarity about software development process. Visibility of progress of process is high due to defined start and finish with document. Limitations of Waterfall Model The waterfall model assumes that the requirements of a system can be frozen before the design begins. This is possible for systems designed to automate an existing manual system. But for new systems, determining the requirements is difficult as the user does not even know the requirements. Hence, having unchanging requirements is unrealistic for such projects. Freezing the requirements usually requires choosing the hardware since it forms a part of the requirements specification. A large project may take a few years to complete. If the hardware is selected early, then due to the speed at which hardware technology is changing, it is likely that the final software will use a hardware technology which is on the verge of becoming obsolete. The customer must have patience. A working version of the program(s) will not be available until the final phase. It is a document driven process that requires formal documents at the end of each phase. This approach is not suitable for many applications, particularly 31
Software Engineering interactive applications, where developing elaborate documentation of the user interfaces is not feasible. Also, it may be sometimes unnecessary. Despite these limitations, the waterfall model is the most widely used process model. It is well suited for routine types of projects where the requirements are well understood. In other words, if the developing organization is quite familiar with the problem domain and the requirements for the software are quite clear, the waterfall model works well. Evolutionary Development They are of two types: Exploratory Development and Throw away prototyping Exploratory development Objective is to work with customers and to evolve a final system from an initial outline specification. Development should start with well-understood requirements and add new features as proposed by the customer. User has an active participation. Process continues until final product is built. Throw-away prototyping Objective is to understand the system requirements. Development should start with poorly understood requirements to clarify what is really needed. Developed part (prototype) is thrown way once requirements are gathered in full. Actual system development starts from scratch. Evolutionary Development
Merits Aparna K, Dept. of MCA, BMSIT 32
Software Engineering Demerits Lack of process visibility Systems are often poorly structured Special skills (e.g. skills in languages for rapid prototyping) may be required Requirements are not frozen in beginning. Users get better understanding about requirements, functionalities etc. Users can participate in system development indirectly. Method is helpful for requirements elicitation and analysis (when requirements are not fully available). E.g. Artificial Intelligence System This development is useful when staff is not available for complete implementation by the business deadline.
Applicability For small or medium-size interactive systems For parts of large systems (e.g. the user interface) For short-lifetime systems Component-Based Software Engineering Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. The different stages in this method are: Requirements specification Component analysis Requirements modification System design with reuse Development and integration This approach is becoming increasingly used as component standards have emerged.
Requirements analysis and specification: Gather requirements Define specifications Component analysis: Selection of reusable components having similar functionality Aparna K, Dept. of MCA, BMSIT 33
Requirements modification: If exact match is not available, modify requirements If modifications not possible, component analysis is performed again System design with reuse: Structured design considering reusable components Development and integration: Development of components Newly developed components are integrated with COTS System validation: System as a whole is validated. Merits: Enhanced productivity due to less development. Saving of time and development cost. It improves system interoperability due to uniform interfaces between components. Performance and reliability of components is high due to extensive testing. Demerits: It requires modification in requirements. The proprietary and copyright issues may affect the evolution of system as reused components are the property of parent organization. Applicability: When requirements are general. Related components are available. Not applicable to very specific and customized product. Process Iteration System requirements of a large system always evolve during development process. Thus process iteration where earlier stages are reworked is always part of the development. Iteration can be applied to any of the generic process models. Two approaches: Incremental delivery Spiral development Incremental Delivery Rather than delivering system as a single unit, the development and delivery is broken down into increments. Each increment having part of the required functionality is developed and delivered. User requirements are prioritized and the highest priority requirements are included in early increments. Once the development of an increment is
34
Software Engineering started, the requirements are frozen though requirements for later increments can continue to evolve.
Merits First increment is available within a short time. No need to wait for entire system Early increments act as a prototype to help elicit requirements for later increments. Lower risk of overall project failure. The highest priority system services tend to receive most testing. Demerits Increments being small, it may be difficult assigning a particular ser of requirements to an increment. As requirements are not defined in detail until an increment is to be implemented, it is difficult to identify common requirements of the increments. A variant of incremental approach is extreme programming. An approach to development based on the development and delivery of very small increments of functionality. It relies on constant code improvement, user involvement in the development team and pairwise programming. Spiral Model Key Features Simplified form Waterfall model with Risk Analysis Each phase preceded by Alternatives Risk analysis Each phase followed by Evaluation Planning of next phase Process is represented as a spiral rather than as a sequence of activities with backtracking. Each loop in the spiral represents a phase in the process. No fixed phases are defined Aparna K, Dept. of MCA, BMSIT 35
Software Engineering such as specification or design. Loops in the spiral are chosen depending on what is required. Risks are explicitly assessed and resolved throughout the process.
Spiral Model Sectors Objective setting: Specific objectives for the phase are identified. Constraints on the process and the product are identified and a detailed management plan is drawn up. Project risks are identified. Alternatives strategies, depending on these risks, may be planned. Risk assessment and reduction: Risks are assessed and steps are taken to reduce the risks. If risks cannot be resolved, project is immediately terminated. Development and validation: A development model for the system is chosen which can be any of the generic models on the basis of risk factor involved. E.g. formal development for the projects with high risks Planning: The project is reviewed and the next phase of the spiral is planned. Strengths Alternatives Evaluation Exhaustive Risk Analysis Planning for next phase Verification & validation after each phase Easy to judge how much to test No distinction between development, maintenance 36
Weaknesses For large-scale software only For internal (in-house) software usually
Process Activities
Software specification Software design and implementation Software validation Software evolution
Software Specifications
It is the process of establishing what services are required and the constraints on the systems operation and development. The Requirements Engineering Process
Requirements engineering process Feasibility study Requirements elicitation and analysis Requirements specification Requirements validation Feasibility study A feasibility study decides whether or not the proposed system is worthwhile to develop. Aims to conform are as follows: Organizational objectives If the system contributes to organizational objectives Technical feasibility If the system can be engineered using current technology Economic feasibility If the system can be engineered within budget & time Aparna K, Dept. of MCA, BMSIT 37
Software Engineering Operational feasibility If the system can be integrated with other systems that are used Requirements Elicitation and Analysis It is the process of gathering system requirements and constraints. Software developers interact with stakeholders (customers, end users, system, engineers, domain experts, business managers). It includes collection of functional and non-functional requirements. Requirement Specifications In this stage gathered requirements is transformed into well structured document. It includes following requirements: High level statement of the requirements needed by users Detailed specifications of the system needed by software developers Requirements Validation Checking of realism, consistency and completeness of requirements
Software Design and Implementation

The process of converting the system specification into an executable system. Software design Design a software structure that realises the specification Implementation Translate this structure into an executable program The activities of design and implementation are closely related and may be inter-leaved. Design process Activities
Architectural design Identifying the subsystems and relationships Abstract specification Description of services and constraints under which subsystem must operate 38
Software Engineering Interface design Interface between subsystems Component design Services and interfaces of components of subsystem Data structure design Data structure design in detail Algorithm design Algorithms for different modules
Structured Methods This involves systematic approaches to developing a software design. The design is usually documented as a set of graphical models. Various models are Object model Sequence model State transition model Structural model Data-flow model Programming and Debugging Translating a design into a program and removing errors from that program. Programming is a personal activity and there is no generic programming process. Programmers carry out program testing to discover faults in the program and remove these faults in the debugging process. The Debugging Process
Software Validation
Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer. It involves checking and review processes and system testing. System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system. The Testing Process
39
Testing Stages Component or unit testing Individual components are tested independently; Components may be functions or objects or coherent groupings of these entities. System testing Testing of the system as a whole. Testing of emergent properties is particularly important. Acceptance testing Testing with customer data to check that the system meets the customers needs.
Testing Phases
Software Evolution Software is inherently flexible and can change. As requirements change through changing business circumstances, the software that supports the business must also evolve and change. Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new.
40
The Rational Unified Process Rational Unified Process (RUP) is a hybrid process model bringing the elements from different generic process models. A modern process model derived from the work on the UML and associated process. Normally described from 3 perspectives: A dynamic perspective that shows phases over time A static perspective that shows process activities A practice perspective that suggests good practice RUP Phase Model
The RUP involves the following phases Inception: It establishes the business case for the system (baseline to meet business requirements). It also identifies all the entities and their interaction. Cost and schedule analysis is also made. If project does not pass this milestone, project is cancelled. Elaboration: It develops an understanding of the problem domain and the system architecture. It also establishes the following points: Domain analysis Architectural framework Project plan Project risks Use case model Construction: This involves system design, programming and testing. Different parts of system are developed in parallel and integrated. A working software with documentation is ready.
41
Software Engineering Transition: This involves deploying the system in its operating environment. Beta testing the system in real environment is done. Training is given to end users. A check is done against quality goals set in Inception phase. RUP supports iteration in two ways. Each phase may be performed in an iterative way and all phases may also be performed iteratively. Within each iteration, the tasks are categorized into nine disciplines, six "engineering disciplines Business Modeling Requirements Analysis and Design Implementation Test Deployment Three supporting disciplines Configuration and Change Management Project Management Environment RUP Good Practice Develop software iteratively: Increments are planned based on customers priorities and importance of the increment. Highest priority increment is developed and delivered first Manage requirements: Customers requirements should be documented. Changes in requirements are analyzed for their impact on system Use component-based architectures: System architecture should be structured into the components Visually model software: System should be modelled using graphical UML to present static and dynamic views of the software Verify software quality: Organization quality standards can be followed in process and product both Control changes to software: Change management and configuration management procedures and tools should be used to manage and record the changes in software Computer- Aided Software Engineering Computer-aided software engineering (CASE) is software to support software development and evolution processes. Activity automation Graphical editors for system model development Data dictionary to manage design entities Graphical UI builder for user interface construction Debuggers to support program fault finding Automated translators to generate new versions of a program
42
Software Engineering Merits Case technology has led to significant improvements in the software process. However, these are not the order of magnitude improvements that were once predicted Demerits Software engineering requires creative thought, which is not readily automated Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these. Case Classification Functional perspective Tools are classified according to their specific function. Process perspective Tools are classified according to process activities that are supported. Integration perspective Tools are classified according to their organisation into integrated units.
Function-based CASE Tool Classification
CASE Integration Tools Support individual process tasks such as design consistency checking, text editing, etc. Workbenches 43
Software Engineering Support a process phase such as specification or design Normally include a number of integrated tools.
Environments Support all or a substantial part of an entire software process. Normally include several integrated workbenches.
Tools, Workbenches and Environments
44
QUESTION BANK FOR CHAPTER II (Critical Systems, Software Processes)

1. What are critical systems? Explain the main types of critical systems with examples. 2. Explain the concept of Dependability with respect to critical systems. 3. Explain in detail Availability and Reliability with respect to critical systems. 4. Describe Waterfall model. Discuss its advantages and disadvantages. 5. What is Evolutionary Prototyping? Explain with a neat diagram. 6. Write a note on Component based Software Engineering. 7. Explain in detail the incremental development process with a neat block diagram. 8. Explain in detail Spiral model with advantages and disadvantages. 9. What is Requirements Engineering? Describe the principal activities of a requirements engineering process with a neat diagram. 10. With a tree structure, explain the classification of CASE tools. 11. Describe in detail The Rational Unified Process model.
45
Chapter III Requirements

Software Requirements Functional and non-functional requirements User requirements System requirements Interface specification The software requirements document
Requirements Engineering and Requirements The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed is called Requirements Engineering. The requirements are the descriptions of the system services and constraints that are generated during the requirements engineering process. IEEE definition of requirements: A condition or capability that must be met or processed by a system to satisfy a contract, standard, specification or other formally imposed document. Requirement may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. Requirements may serve a dual function. It may be the basis for a bid for a contract - therefore must be open to interpretation. It may be the basis for the contract itself - therefore must be defined in detail. Types of Requirements User requirements: Clients provide the description of the services expected by the system and its operational constraints. Statements are written in natural language or shown through diagrams. System requirements: A structured document setting out detailed descriptions of the systems functions, services and operational constraints. It should be prepared precisely as it may be part of a contract between client and developer. Need of Requirements: It is required in understanding the customers expectations from the system, in explaining the functionality and characteristics of the system in detail and to develop test plan and delivering a quality product.
46
Software Engineering Requirements Readers:
In principle, requirements should be both complete and consistent. Complete: They should include descriptions of all functionalities required. Consistent: There should be no conflicts or contradictions in the descriptions of the system facilities. In practice, it is impossible to produce a complete and consistent requirements document. Characteristics of Requirements Correctness: without error. Consistency: free from ambiguities. Completeness: including all inputs, outputs, constraints Realistic: only possible requirements. Verifiability: when testing for requirements is possible Functional and Non-Functional Requirements Software System Requirements are classified as : Functional requirements Statements of services the system should provide how the system should react to particular inputs and how the system should behave in particular situations. Non-functional requirements Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Domain requirements Requirements that come from the application domain of the system and that reflect characteristics of that domain.
Functional Requirements
47
Software Engineering This describes the functionality or system services. It depends on the type of software, expected users and the type of system where the software is used. Functional user requirements may be high-level statements of what the system should do. Functional system requirements should describe the system services in detail. Functional Requirements describe the interaction between the system and environment, statement of services, behaviors of system with particular input in particular situation, types of inputs, outputs and their constraints, nature of computations, timing and synchronizations of above. Non-Functional Requirements These are properties and constraints on the system. Sometimes non functional requirements are more critical than functional requirements. Due to absence of Nonfunctional Requirements, system usability becomes very less though functional requirements are present. Due to these requirements, choice of language platform, implementation techniques, tools are restricted. Non-Functional Requirements Types
No n -fu n c tio n a l re q u ire m e n ts
Pro d u c t re q u ire m e n ts
Org a n is a tio n a l re q u ire m e n ts
Ex te rn a l re q u ire m e n ts
Effic ie n c y re q u ire m e n ts
R e liab ility re q u ire m e n ts
Po rta b ility re q u ire m e n ts
In te ro p e ra b ility re q u ire m e n ts
Eth ic a l re q u ire m e n ts
Us ab ility r e q u ire m e n ts
De live ry re q u ire m e n ts
Im p le m e n ta tio n re q u ire m e n ts
Sta n d a rd s re q u ire m e n ts
Le g is lativ e re q u ire m e n ts
Pe rfo rm a n c e re q u ire m e n ts
Sp a c e re q u ire m e n ts
Priva c y re q u ire m e n ts
Sa fe ty re q u ire m e n ts
Classification of Non-Functional Requirements Product requirements Organisational requirements 48
Software Engineering External requirements
Product requirements: They specify product behavior. Examples include usability, efficiency: performance and space requirements, reliability, portability. Organizational requirements: These are due to policies and procedures followed in customers and developers organizations. Examples include Delivery requirements, Implementation requirements, and Standard requirements. External requirements: These are derived from factors external to system. Examples include interoperability (system interaction with systems in same and other organization), ethical requirements (social acceptability), legislative requirements (system complies with government laws). Goals and Requirements: Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify. Goal Each non-functional requirement can be attached with a system goal which can be verified e.g. easy to use, minimum errors. Verifiable non-functional requirements These requirements can be verified by testing i.e. goal is achieved or not. Can be expressed quantitatively in terms of measures. Goals are helpful to developers as they convey the intentions of the system users. Examples include A system goal The system should be easy to use by experienced controllers and should be organised in such a way that user errors are minimised. A verifiable non-functional requirement Experienced controllers shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day. Requirements Measures
49
Software Engineering Domain Requirements These are derived from the application domain and describe system characteristics and features that reflect the domain. Domain requirements may be new functional requirements, constraints on existing requirements or define specific computations. If domain requirements are not satisfied, the system may be unworkable. Problems of Domain Requirements Understandability Requirements are expressed in the language of the application domain This is often not understood by software engineers developing the system Implicitness Domain specialists understand the area so well that they do not think of making the domain requirements explicit
User Requirements These describe functional and non-functional requirements in such a way that they are understandable by system users who dont have detailed technical knowledge. User requirements are defined using natural language, tables and diagrams as these can be understood by all users. Problems of natural language Lack of clarity Precision and technical clarity is difficult to achieve Requirements confusion Functional and non-functional requirements tend to be mixed-up. Requirements amalgamation Several different requirements may be expressed together. Guidelines of writing requirements Invent a standard format and use it for all requirements: Standardizing the format makes omissions less likely and requirements easier to check. Use language in a consistent way: Always distinguish between mandatory and desirable requirements. Use shall for mandatory requirements, should for desirable requirements. Use text highlighting to identify key parts of the requirement. Avoid the use of computer jargon. System Requirements These include more detailed specifications of system functions, services and constraints than user requirements. They are intended to be a basis for designing the system. They
50
Software Engineering may be incorporated into the system contract. System requirements may be defined or illustrated using system models. Requirements and Design: In principle, requirements should state what the system should do and the design should describe how it does this. In practice, requirements and design are inseparable A system architecture may be designed to structure the requirements The system may inter-operate with other systems that generate design requirements The use of a specific design may be a domain requirement Problems with natural language specification Ambiguity The readers and writers of the requirements must interpret the same words in the same way. Natural language is naturally ambiguous so this is very difficult. Over-flexibility The same thing may be said in a number of different ways in the specification. Lack of modularisation Natural language structures are inadequate to structure system requirements. Alternatives to natural language Structured natural language: This relies on standard forms or templates to express the requirements specification Design description language: Requirements are specified by defining an operational model of the system with more abstract features by using PDL Graphical notation: By using a graphical language support e.g. SADT, use case description Mathematical specification: Finite state machines or sets
Structured Language Specifications: Structured natural language is a way of writing system requirements where the freedom of the requirements writer is limited and all requirements are written in a standard way. The advantage of this approach is that it maintains most of the expressiveness and understandability of natural language but ensures that some degree of uniformity is imposed on the specification. Specific forms were designed that include the following: Functions specified: description of function Inputs 51
Software Engineering Sources Output Destination Pre-condition Post-condition Side-effects of operations By doing so, the limitation of natural language is reduced. There is uniformity in description of system requirements. There are no ambiguities. It also retains salient features of natural language such as: expressiveness and understandability. Interface Specification Most of the systems must operate with other already existing systems. Thus, operating interfaces between existing and new systems must be specified as a part of the requirements. There are three types of interfaces: Procedure interface Data structure interface Representation of data Procedure interface: Existing sub-systems offer a range of services which are accessed by calling procedures. These interfaces are also sometimes called Application Programming Interfaces (APIs). Data structure interface: This includes Interface and passing the data structure from one subsystem to another. Graphical data models are the best notations for this type of description. Representation of data: Data already present in an existing subsystem should be represented for new system in a consistent way. These interfaces are most common in embedded, real-time system. Graphical models are most useful when you need to show how state changes or where you need to describe a sequence of actions. Sequence diagrams show the sequence of events that take place during some user interaction with a system. Sequence diagrams are read from top to bottom to see the order of the actions that take place. Cash withdrawal from an ATM Validate card; Handle request; Complete transaction. Sequence diagram of ATM Withdrawal:
52
A T M D a t a b a s e
C a r d
C a r d n u m b e r C a r d O K
P I N r e q u e s t P I N O p t i o n m e n u < < e x c e p t i o n > > i n v a l i d c a r d W i t h d r a w r e q u e s t A m o u n t r e q u e s t A m o u n t
V a l i d a t e c a r d
B a l a n c e r e q u e s t B a l a n c e H a n d l e r e q u e s t D e b i t ( a m o u n t )
< < e x c e p t i o n > > i n s u f f i c i e n t c a s h C a r d C a r d r e m o v e d C a s h C a s h r e m o v e d R e c e i p t
D e b i t r e s p o n s e
C o m p l e t e t r a n s a c t i o n
The Software Requirements Document The requirements document is the official statement of what is required of the system developers. It should include both a definition of user requirements and a specification of the system requirements. It is NOT a design document. As far as possible, it should include set of WHAT the system should do rather than HOW it should do it. Users of a Requirements document
53
S p e c i f y t h er e q u i r e m e n t sa n d r e a dt h e m t oc h e c k t h a tt h e y m e e tt h e i rn e e d s .T h e y s p e c i f yc h a n g e st ot h e r e q u i r e m e n t s
S y s t e m c u s t o m e r s
M a n a g e r s
U s et h er e q u i r e m e n t s d o c u m e n tt op l a nab i df o r t h es y s t e m a n dt op l a nt h e s y s t e m d e v e l o p m e n tp r o c e s s
S y s t e m e n g i n e e r s
U s et h er e q u i r e m e n t st o u n d e r s t a n dw h a ts y s t e m i st o b ed e v e l o p e d
S y s t e m t e s t e n g i n e e r s
U s et h er e q u i r e m e n t st o d e v e l o pv a l i d a t i o nt e s t sf o r t h es y s t e m
S y s t e m m a i n t e n a n c e e n g i n e e r s
U s et h er e q u i r e m e n t st oh e l p u n d e r s t a n dt h es y s t e m a n d t h er e l a t i o n s h i p sb e t w e e ni t s p a r t s
Characteristics of Software Requirements Document It should specify only external system behavior. It should specify constraints on the implementation. It should be easy to change. It should serve as a reference tool for the system maintainers. It should record forethought about the life cycle of the system. It should characterize acceptable responses to undesired events.
IEEE Requirements Standard Defines a generic structure for a requirements document that must be instantiated for each specific system 1. Introduction. 2. Overall description. 3. Specific requirements. 4. Appendices. 5. Index. Introduction 1.1. Purpose 1.2 Scope 1.3. Definitions, acronyms and abbreviations 1.4. References 1.5. Overview. Aparna K, Dept. of MCA, BMSIT 54
Software Engineering 2. Overall description 2.1. Product perspective 2.2. Product functions. 2.3. User characteristics 2.4. Constraints. 2.5. Assumptions and dependencies. 2.6. Requirements subsets 3. Specific requirements 3.1. External interface requirements 3.1.1. User interfaces 3.1.2. Hardware interfaces 3.1.3. Software interfaces 3.1.4. Communications interfaces 3.2. Functional requirements 3.2.1. User class 1 3.2.1.1. Functional requirements 1.1 3.2.1.2. Functional requirements 1.2 3.2.2. User class 2 . 3.3. Performance requirements 3.4. Design constraints 3.5. Software system attributes 3.5. Other requirements 4. Appendices Index The structure of a requirements document Preface Introduction Glossary User requirements definition System architecture System requirements specification System models System evolution Appendices Index Introduction This section should define the intended readership. The history of the present version and rationale for creating a new version should be described. Summary of changes should be included.
Preface
55
Software Engineering Glossary This should define all technical terms used in the document. User requirements definition In this chapter users and non-functional requirements should be described using natural language and other notations. Product and process standard must be specified. System architecture This chapter provides a high-level view of the anticipated system architecture. Distribution of functions across system modules should be described and reused components must be highlighted. System requirements and specification This chapter should contain detailed description of functional and nonfunctional requirements. System models This section should include system models used for representing relationship between the system components and the system and its environment. The system models may be object model, data flow model etc. System evolution This chapter describes the fundamental assumptions on which the system is based. It should also include anticipated changes, changing user needs etc. Appendices This chapter provides detailed, specific information related to the application being developed. Appendices may be on topics hardware description, date base description, requirements for system configurations etc. Index It should include indexes of diagram, functions etc. in alphabetical order. This Chapter should describe the need for the system. The functions of the system should be briefly described. It should describe how the new system fits into the overall business objectives of the organization.
56
Software Engineering Requirements Engineering Processes Feasibility studies Requirements elicitation and analysis Requirements validation Requirements management
Requirements Engineering Processes The processes used for Requirements Engineering vary widely depending on the application domain, the people involved and the organisation developing the requirements. There are a number of generic activities common to all processes Requirements elicitation Requirements analysis Requirements specification Requirements validation Requirements management
Spiral model of Requirements Engineering Process
57
Feasibility Study A feasibility study decides whether or not the proposed system is worthwhile to develop. It aims to conform Organizational objectives If the system contributes to organisational objectives Technical feasibility If the system can be engineered using current technology Economic feasibility If the system can be engineered within budget & time Operational feasibility If the system can be integrated with other systems that are used A feasibility study involves the following steps: Information collection Information assessment Report writing Questions for people in the organisation What if the system was not implemented? What are current process problems? How will the proposed system help? What will be the integration problems? Is new technology needed? What skills? What facilities must be supported by the proposed system?
58
Software Engineering Requirement Elicitation and Analysis It is the process of gathering system requirements and constraints. Software developers interact with stakeholders (customers, end users, system, engineers, domain experts, business managers). Difficulties in Elicitation and analysis Lack of clarity Stakeholders may not express expectation in words. They may find it difficult to express their views. Commonalities and conflict Different customers define same requirement in different way. Unfamiliarity with domain Analyst may have less understanding of domain. Business and economic factors Requirements may change and new requirements may emerge Political factors Some managers may influence the system requirements for personal benefits.
The activities involved in this process are Requirements Discovery Requirements Classification and Organization Requirements Prioritization & negotiation Requirements document Requirements discovery Interacting with stakeholders to discover their requirements. Domain requirements from stakeholders and documentation are also discovered at this stage. Requirements classification and organisation Takes the unstructured collection of requirements, groups related requirements and organises them into coherent clusters. Requirements Prioritisation and negotiation Prioritising requirements and resolving requirements conflicts through negotiation. Requirements documentation Requirements are documented and input into the next round of the spiral. Formal or informal requirements document may be produced. Spiral Model of Requirements Elicitation and Analysis
59
Requirements Discovery This is the process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information. Sources of information include documentation, system stakeholders and the specifications of similar systems. Consider the stakeholders of ATM for example: Bank customers Representatives of other banks Bank managers Counter staff Database administrators Security managers Marketing department Hardware and software maintenance engineers Banking regulators Viewpoints Viewpoints are a way of structuring the requirements to represent the perspectives of different stakeholders. Stakeholders may be classified under different viewpoints. This multi-perspective analysis is important as there is no single correct way to analyze system requirements. There are three generic types of viewpoints: Interactor viewpoints People or other systems that interact directly with the system. In an ATM, the customers and the account database are interactor VPs. Indirect viewpoints
60
Software Engineering Stakeholders who do not use the system themselves but who influence the requirements. In an ATM, management and security staff are indirect viewpoints. Domain viewpoints - Domain characteristics and constraints that influence the requirements. In an ATM, an example would be standards for inter-bank communications Types of Viewpoints (in a library system LIBSYS)
All VPs
In d ire c t
In te r a c to r
Do m a in
Lib ra ry m anage r
Fin a n c e
Ar tic le p ro v id e rs
Us e r s
Lib r a r y sta f f
U I sta n d a r d s
Cla ss ific a tio n s y s te m
Stud e n ts
Sta f f
Ex te r n a l
Sy s te m m a n a g e rs
Ca ta lo g ue rs
Viewpoint Identification Identify viewpoints using Providers and receivers of system services Systems that interact directly with the system being specified Regulations and standards that apply to the system Sources of business and non-functional requirements Engineers who have to develop and maintain the system Marketing and other business viewpoints Interviewing In formal or informal interviewing, the Requirements Engineering team puts questions to stakeholders about the system that they use and the system to be developed. There are two types of interview Closed interviews where a pre-defined set of questions are answered. Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.
61
Software Engineering Interviews in Practice General practice of interviews includes a mix of closed and open-ended interviewing. Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system. Interviews are not good for understanding domain requirements because requirements engineers cannot understand specific domain terminology. Some domain knowledge is so obvious that people find it hard to articulate or think that it isnt worth articulating. Characteristics of Effective Interviewers Interviewers should be open-minded, willing to listen to stakeholders. Interviewers should not have pre-conceived ideas about the requirements. Interviewers should prompt the interviewee with a question or a proposal. But later, interviewers should not simply expect them to respond to a question such as what do you want.
Scenarios Scenarios are descriptions of how a system is used in practice. They are helpful in requirements elicitation as people can relate to these more readily than abstract statement of what they require from a system. Scenarios are particularly useful for adding details to an outline requirements description. A scenario includes: 1. System state at the beginning of the scenario 2. Normal flow of events in the scenario 3. What can go wrong and how this is handled 4. Other concurrent activities 5. System state on completion of the scenario LIBSYS Scenario-1
Initial assumption: The user has logged the copy of the article.
Normal: The user selects the article to b provide subscriber information for the jou payment methods are by credit card or by
Use Cases Aparna K, Dept. of MCA, BMSIT 62
The user is then asked to fill in a copyrig submit this to the LIBSYS system.
Software Engineering It is a scenario based technique used in UML Proposed by Jacobson. It identifies actors involved and their interaction with system. A set of use cases should describe all possible interactions with the system. Each use case is represented by an ellipse.
L e n d in g se r v ic e s
A simple use-case for article printing
A r ticle printing
The above figure shows the essentials of the use-case notation. Actors in the process are represented as stick figures, and each class of interaction is represented as a named ellipse. The set of use-cases represents all of the possible interactions to be represented in the system requirements. Figure below shows the LIBSYS example and other usecases in that environment.
L end in g serv ices L ib rary U ser
U ser adm inistration
L ib rary S taff
S up plier
C atalo g serv ices
63
Software Engineering Use-cases identify the individual interactions with the system. They can be documented with text or linked to UML models that develop the scenario in more detail. Sequence diagrams are often used to add information to a use-case. These sequence diagrams show the actors involved in the interaction, the objects they interact with and the operations associated with these objects. As an illustration of this, figure below shows the interactions involved in using LIBSYS for downloading and printing an article. Here there are four objects of classes Article, Form, Workspace and Printer involved in this interaction. The sequence of actions is from top to bottom, and the labels on the arrows between the actors and objects indicate the names of operations. Essentially, a user request for an article triggers a request for a copyright form. Once the user has completed the form, the article is downloaded and sent to the printer. Once printing is complete, the article is deleted from the LIBSYS workspace.
Ethnography As social and organizational factors play crucial role in success of a software system, it may not be possible to gather the requirements through meetings and interviews. A group of people spends a considerable time observing and analyzing how people actually work. Users do not have to explain or articulate their work because they may not explain their work properly. Social and organizational factors of importance may be observed. Ethnography is an observational technique that can be used to understand social and organizational requirements. Users requirements can be well understood. Technique is effective in finding two types of requirements: Scope of Ethnography Requirements that can be derived only observing actual work (not on basis of assumptions.) Aparna K, Dept. of MCA, BMSIT 64
Software Engineering Requirements that can be derived from the cooperation of other people (people interaction.)
Limitations of Ethnography It focuses only on end users, not suitable for deriving domain requirements. New features of system can not be identified. Not a complete approach to requirement elicitation.
Focused Ethnography It combines ethnography with prototyping. Prototype development results in unanswered questions which focus the ethnographic analysis. The problem with ethnography is that it studies existing practices which may have some historical basis which is no longer relevant. Ethnography along with prototyping can be illustrated as below:
Requirements Validation IEEE definition of validation: The process of evaluating a system or component during or at the end of the development process to determine whether it satisfies the specified requirements. It is the process of determining that the specification is consistent with the requirements definition. Error can lead to high cost, thus validation is important. Two steps for validation include: 1. Each specification is traceable to a requirement. 2. Each requirement is traceable to a specification Requirements error costs are high so validation is very important. Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error. Requirement Checks: The different types of necessary checks are: Validity check: To ensure that the system meets all functional, behavioral, performance requirements. Consistency check: Requirements are unambiguous, free from contradiction. Completeness check for requirements: Aparna K, Dept. of MCA, BMSIT 65
Software Engineering Each requirement consists of all states, state changes, input products, constraints, properties of environment Realism check: Requirements are realistic, possible to implement within technological and financial constraints. Verifiability: At the completion of system, requirements testing are possible.
Requirements Validation Techniques Different types of techniques are: Requirements reviews: Systematic manual analysis of the requirements. Prototyping: An executable model of the system is demonstrated to end users and customers. Test case generations: Developing tests for requirements to check testability. Automated consistency analysis: Checking the consistency of a structured requirements description using CASE tools. Requirements Reviews It is the manual process of reviewing the requirements by a team of reviewers. Review team consists of various stakeholders. Review is formal walk through with stakeholders using complete document. Review can be informal when documents are not complete. There should be good communication between stakeholders. Reviewers may also check for: Verifiability: Testability of requirements Comprehensibility: Requirements properly understood by users. Traceability: Origin of the requirements should be traceable. Adaptability: Requirements can be changed without having large-scale effects on other system requirements. Conflicts, contradictions errors and omissions should be pointed out during review and same should be formally recorded.
Requirements Management Requirements management is the process of managing changing requirements during the requirements engineering process and system development. Requirements are inevitably incomplete and inconsistent. New requirements emerge during the process as business Aparna K, Dept. of MCA, BMSIT 66
Software Engineering needs change and a better understanding of the system is developed. viewpoints have different requirements and these are often contradictory. Requirement Change The priority of requirements from different viewpoints changes during the development process. System customers may specify requirements from a business perspective that conflict with end-user requirements. The business and technical environment of the system changes during its development. Enduring and Volatile Requirements Enduring requirements: These are the stable requirements derived from the core activity of the customer organisation. E.g. requirements related to a hospital will always have details of doctors, nurses, patients etc. Volatile requirements: These are the requirements which change during development or when the system is in use. E.g. in a hospital, requirements derived from Government health-care policy may change. Types of Volatile requirements Mutable requirements Requirements that change due to the systems environment Emergent requirements Requirements that emerge as understanding of the system develops Consequential requirements Requirements that result from the introduction of the computer system Compatibility requirements Requirements that depend on other systems or organisational processes Different
Requirements Management Planning During the requirements engineering process, you have to plan: Requirements identification Each requirement should be identified for any cross reference. A change management process The process that assess the impact and cost of changes. Traceability policies The amount of information about requirements relationships that is maintained CASE tool support The tool support required to help manage large requirements change
67
Software Engineering Traceability: Traceability is concerned with the relationships between requirements, their sources and the system design. There are three types of traceability information that may be maintained. Source traceability Links from requirements to stakeholders who proposed these requirements Requirements traceability Links between dependent requirements Design traceability Links from the requirements to the design A Traceability Matrix (Requirements traceability)
Requirements Change Management
This should apply to all proposed changes to the requirements. The principal stages in this are: Problem analysis: During this stage, the problem or the change proposal is analyzed to check that it is valid. The results of the analysis are fed back to the change requestor, and sometimes a more specific requirements change proposal is then made. Change analysis and costing: The effect of the proposed change is assessed using traceability information and general knowledge of the system requirements. The cost of making the change is estimated in terms of modifications to the requirements document and, if appropriate, to the system design and implementation. Once this analysis is completed, a decision is made whether to proceed with the requirements change. Change implementation: Modify requirements document and other documents to reflect change. Aparna K, Dept. of MCA, BMSIT 68
QUESTION BANK FOR CHAPTER III (Requirements)

1. Write a detailed note on functional requirements. 2. What are Non-Functional Requirements? Explain the different types of NonFunctional requirements. 3. Write a detailed note on Domain Requirements and User Requirements. 4. Explain Structured Language Specifications in detail with appropriate examples. 5. Write a short on Interface Specifications. 6. Give the IEEE format and explain the structure of software requirements document. 7. Explain Feasibility Studies in detail. 8. Discuss in detail, the steps involved in Requirements Elicitation and Analysis. 9. List all the techniques involved in Requirements Elicitation and Analysis with appropriate examples. Explain viewpoint-oriented approach. 10. Explain Interviews, Scenarios and Use cases in detail with appropriate examples. 11. What is Ethnography? Why is it required? 12. Write in detail about Requirements Validation. 13. Differentiate between Enduring and Volatile requirements. Also explain the different types of volatile requirements. 14. Explain Traceability information in detail. 15. Write in detail Requirements Change Management.
69
Chapter IV System Models

Context models Behavioural models Data models Object models Structured methods
System Modeling System modeling helps the analyst to understand the functionality of the system and models are used to communicate with customers. Different models present the system from different perspectives. External perspective showing the systems context or environment, behavioral perspective showing the behavior of the system, and structural perspective showing the system or data architecture. Model Types Data flow models show how the data is processed at different stages. (DFD) Composition models show how entities are composed of other entities. (ER diagram) Architectural models show principal sub-systems. (Context diagram ) Classification models show how entities have common characteristics. (Class and inheritance diagrams Stimulus/response models show the systems reaction to events. (state machine model Context Models Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries. Social and organisational factors may affect the decision for system boundaries. Architectural models show the system and its relationship with other systems. Process models show the overall process and the processes that are supported by the system. Data flow models may be used to show the processes and the flow of information from one process to another. Architectural models describe the environment of a system. However they do not show the relationships between the other systems in the environment and the system that is being specified. External systems might produce data for or consume data from the system. They might share data with the system, or they might be connected directly, through a network or not at all. The Context of the ATM System
70
S ecurity system B r anch accounting system A uto-teller system B r anch counter system M aintenance system U sa ge database A ccount da ta base
Equipment Procurement Process

De liv e ry no te Eq uipm e nt spe c . Ch e c ke d spe c . De live ry no te
S pe c ify e q uipm e nt re q uir e d
V a lid a te spe c ific a tio n
Ge t c o st e stim a te s S pe c . + supplie r + e stim a te Ch o o se supplie r
Ac c e pt d e li v e ry o f e q uipm e nt Ord e r no tific a tio n Pla c e e q uipm e nt o rd e r
Ch e c k d e liv e re d ite m s Insta lla tio n instruc tio ns Insta ll e q uipm e nt Insta lla tio n a c c e pta nc e Ac c e pt d e li ve re d e q uipm e nt Eq uipm e nt d e ta ils
Eq uipm e nt spe c . S upplie r d a ta b a se Find supplie rs
S upplie r list
Orde r d e ta ils plus b la nk o r d e r fo r m
Ch e c k e d a nd sig ne d o r d e r fo rm
Eq uipm e nt d a ta b a se
The above figure illustrates a process model for the process of procuring equipment in an organization. This involves specifying the equipment required, finding and choosing suppliers, ordering the equipment, taking delivery of the equipment and testing it after delivery. When specifying computer support for this process, you have to decide which f these activities will actually be supported. The other activities are outside the boundary of the system. The dotted line encloses the activities that are within the system boundary.
71
Software Engineering Behavioural Models Behavioural models are used to describe the overall behaviour of a system. Two types of behavioural model are: Data processing models that show how data is processed as it moves through the system State machine models that show the systems response to events These models show different perspectives so both of them are required to describe the systems behaviour. Data flow diagrams (DFDs) may be used to model the systems data processing. These show the processing steps as data flows through a system. DFDs are an intrinsic part of many analysis methods. Order Processing DFD
Co m p le te d o rd e r fo r m Co m p le te o r d e r fo rm V a lid ate o rd e r Sig n e d o rd e r fo r m Sig n e d o rd e r fo rm R e c o rd o rd e r Ord e r d e ta ils Sig n e d o rd e r fo rm Ad j u st a va ilab le b ud g e t Ord e r a m o un t + a c c o un t d e ta ils Ord e r s file Bu d g e t file Se n d to sup p lie r Ch e c ke d a n d sig n e d o rd e r + o rd e r n o tific atio n
Ord e r d e ta ils + b la n k o r d e r fo rm
Data Flow Diagrams DFDs model the system from a functional perspective. Tracking and documenting how the data associated with a process is helpful to develop an overall understanding of the system. Data flow diagrams may also be used in showing the data exchange between a system and other systems in its environment. Insulin Pump DFD
Blo o d Blo o d sug a r se nso r Blo o d pa ra m e te rs Blo o d sug a r a na ly sis Blo o d sug a r le ve l Insulin re q uir e m e nt c o m puta tio n Insulin Pum p c o ntr o l c o m m a nd s Insulin d e liv e ry c o ntr o lle r Insulin re q uir e m e nt
Insulin pum p
72
Software Engineering Data-flow models show a functional perspective where each transformation represents a single function or process. They are particularly useful during the analysis of requirements as they can be sued to show end-to-end processing in a system. That is, they show the entire sequence of actions that take place from an input being processed to the corresponding output that is the systems response. State Machine Models These model the behaviour of the system in response to external and internal events. They show the systems responses to stimuli thus used for modelling real-time systems. State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another. State charts (given by Hirel) are an integral part of the UML and are used to represent state machine models. State charts allow the decomposition of a model into sub-models. A brief description of the actions is included following the do in each state. They can be complemented by tables describing the states and the stimuli. State Machine model of microwave oven
Full po w e r Full po w e r d o : se t po w e r = 600 Tim e r F ull po w e r Ha lf po w e r S e t tim e d o : g e t num b e r e xit: se t tim e Do o r c lo se d Do o r o pe n Ha lf po w e r d o : se t po w e r = 3 00 Do o r c lo se d Ena b le d d o : d ispla y 'R e ady ' Num b e r Ope ra tio n d o : o pe ra te ove n
Wa iting d o : d ispla y tim e
Ha lf po w e r
Tim e r
Sta rt Do o r o pe n
Ca nc e l
Wa iting d o : d ispla y tim e
Disab le d d o : d ispla y 'W a iting '
The different states of the above state machine model are as follows: Waiting : Oven waiting for input, displays current time Half power: Power is set 300 watts, displays Half power Full power: Power is set 600 watts, displays Full power Set time: Cooking time is set. Aparna K, Dept. of MCA, BMSIT 73
Software Engineering Enabled: Oven operation is enabled, displays ready to cook Disabled: Operation is disabled for safety, displays not ready Operation: In operation, light is on, timer counts down, On completion of cooking buzzer.
Stimulus description of the above state machine model Half power: Half power button is pressed Full power: Full power button is pressed Timer: Timer button is pressed Number: Numeric key is pressed Door open: Door is open Door closed: Door is closed Start: Start button is pressed Cancel: Cancel button is pressed.
The problem with the above state machine model is that the number of possible states increases rapidly. For large system models, therefore, some structuring of these state models is necessary. One way to do this is by using the notion of a superstate that encapsulates a number of separate states. This superstate looks like a single state on a high-level model but is then expanded in more detail on a separate diagram. Ex: Consider the operation state in the above diagram. This is a superstate that can be expanded as shown below. The Operation state includes a number of sub-states. State machine model of Microwave oven: Operation
O peration C hecking do: check status E m itter fault A larm do: display event D one do: buz z er on for 5 secs. O K C ook run generator Tim eout Tim e do:
Turntable fault
D oor open D isabled W aiting
C ancel
74
Software Engineering Semantic Data Models These are used to describe the logical structure of data required by the system. An entityrelation-attribute model set out the entities in the system, the relationships between these entities and the entity attributes. It is widely used in database design and can readily be implemented using relational databases. No specific notation is provided in the UML but objects and associations can be used. Library Semantic Model
A r t i c l e t i t l e a u t h o r s p d f f i l e f e e 1 d e l i v e r s 1 n O r d e r o r d e r n u m b e r t o t a l p a y m e n t d a t e t a x s t a t u s n p l a c e s 1 B u y e r n a m e a d d r e s s e m a i l b i l l i n g i n f o C o p y r i g h t A g e n c y n a m e h a s l i n k s a d d r e s s C o u n t r y 1 i n 1 c o p y r i g h t f o r m t a x r a t e m p u b l i s h e d i n S o u r c e n 1 t i t l e p u b l i s h e r i s s u e d a t e p a g e s 1 i n 1
f e e p a y a b l e t o
The above diagram is an example of a data model that is part of the library system LIBSYS. It shows that an Article has attributes representing the title, the authors, the name of the PDF file of the article and the fee payable. This is linked to the Source, where the article was published, and to the Copyright Agency for the country of publication. Both Copyright Agency and Source are linked to Country. The diagram also shows that Buyers place Orders for Articles. Data Dictionaries Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also included. Advantages Support name management and avoid duplication Store of organisational knowledge linking analysis, design and implementation Many CASE workbenches support data dictionaries.
75
Software Engineering Object Models Object models describe the system in terms of object classes and their associations. An object class is an abstraction over a set of objects with common attributes and the services (operations) provided by each object. Various object models may be produced Object class models Inheritance models Aggregation models Behaviour models (interaction models) An object class is an abstraction over a set of objects with common attributes and services provided by each object. An object class is represented by a rectangle, name at the top, attributes in middle section, and operations in bottom section. Object class identification is recognized as a difficult process requiring a deep understanding of the application domain. Object classes reflecting domain entities are reusable across systems. An object class in UML is represented as a vertically oriented rectangle with three sections: 1. The name of the object class is in the top section 2. The class attributes are in the middle section 3. The operations associated with the object class are in the lower section of the rectangle.
E m plo ye e
nam e : string addre ss: string date O fB ir th: D ate e m ploye e N o: inte ge r socialS e curityN o: string de par tm e nt: D e pt m anage r: E m ploye e salar y: inte ge r status: {c urre nt, le ft, re tire d} taxC ode : inte ge r . .. join () le ave () re tire () change D e tails ()
Inheritance Models In this model, the domain object classes are organized into an inheritance hierarchy. Classes at the top of the hierarchy reflect the common features of all classes. Object classes inherit their attributes and services from one or more super-classes; these may further be specialized as necessary. Class hierarchy design can be a difficult process if Aparna K, Dept. of MCA, BMSIT 76
Software Engineering duplication in different branches is to be avoided. In UML, the inheritance is referred as generalization. It has become an effective standard for object-oriented modelling. Notation Object classes are rectangles with the name at the top, attributes in the middle section and operations in the bottom section; Relationships between object classes (known as associations) are shown as lines linking objects; Inheritance is referred to as generalisation and is shown upwards rather than downwards in a hierarchy. Consider for instance, the library class hierarchy as shown below:
L ibr ary item C a talo gue n um ber A cquisition da te C ost T ype S ta tus N um ber of copies A cquir e () C a talo gue () D ispose () I ssue () R eturn ()
P ub lished item Title P ub lisher
R ecor ded item Title M edium
B ook A uthor E dition P ub lica tion da I S BN
M a gazine Y ear I ssue
F ilm D ir ector D a te of r elease D istrib utor
C om puter pr o g ram V ersion P la tfor m
te
User Class hierarchy

L ibr ary user N ame A d dr ess P hone R eg istr a tion # R eg ister () D e-r eg ister ()
R eader A ffilia tion
B orr o w er I tems on loan M ax. loans
S taf f D epar D epar tment tment phone
S tudent M ajor subject H ome ad dr ess
77
Software Engineering The above two figures show class inheritance hierarchies where every object class inherits its attributes and operations from a single parent class. Multiple inheritance models may also be constructed where a class has several parents. Its inherited attributes and services are a conjunction of those inherited from each super-class. Figure below shows an example of a multiple inheritance model that may also be part of the library model.
Bo o k A uth o r Ed itio n Pub lic atio n d a te ISB N Vo ic e re c o rd in g Spe a k e r Dura tio n R e c o rd ing d a te
Ta lking b o o k # Ta pe s
Object Aggregation An aggregation model shows how classes (collections) are composed of other classes. Aggregation models are part-of relationship.
Stud y pa c k Co urse title Num b e r Ye a r Instruc to r
Assig n m e n t Cre d its
OHP slid e s Slid e s
Le c ture n o te s Te xt
V id e o ta pe Ta pe id s .
Exe rc ise s #Pr o b le m s De sc riptio n
So lutio n s Te xt Dia gra m s
78
Software Engineering The UML notation fro aggregation is to represent the composition by including a diamond shape on the source of the link. The above figure could be read as A study pack is composed of one or more assignments, OHP slide packages, lecture notes and videotapes. Object behavior modeling A behavioral model shows the interactions between objects to produce some particular system behavior that is specified as a use-case. Sequence diagrams (or collaboration diagrams) in the UML are used to model interaction between objects.
E c at: C atalog :L ibrary U se r :L ibrary I te m L ib1 : N e tS e rve r
L ookup D isplay I ssue I ssue lic e nc e A c c e pt lic e nc e C om pre ss
D e live r
In a sequence diagram, objects and actors are aligned along the top of the diagram. Labeled arrows indicate operations; the sequence of operations is from top to bottom. In this scenario, the library user accesses the catalogue to see whether the item required is available electronically; if it is, the user requests the electronic issue of that item. For copyright reasons, this must be licensed so there is a transaction between the item and the user where the license is agreed. The item to be issued is then sent to a network server object for compression before being sent to the library user. Structured Methods Structured methods incorporate system modelling as an inherent part of the development. Methods define a set of models, a process for deriving these models and rules and guidelines that should apply to the models. CASE tools support system modelling as part of a structured method. Structured methods provide a framework for detailed system modelling as part of requirements elicitation and analysis. Most structured methods have their own preferred set of system models. They usually define a process that may be used to derive these models and a set of rules and guidelines that apply to the models. Aparna K, Dept. of MCA, BMSIT 79
Software Engineering Structured methods suffer from a number of weaknesses: They do not model non-functional system requirements. They do not usually include information about whether a method is appropriate for a given problem. The may produce too much documentation. The system models are sometimes too detailed and difficult for users to understand.
CASE Workbenches These are coherent set of tools that is designed to support related software process activities such as analysis, design or testing. Analysis and design workbenches support system modelling during both requirements engineering and system design. These workbenches may support a specific design method or may provide support for a creating several different types of system model. An analysis and design workbench
Analysis Workbench Components Structured programming tools To generate DFD, ER-Diagrams, object models Design, analysis and checking tools Report conflicts, errors Repository query language Any query related to design and design information from central repository Data dictionary Maintains information about names used in system models Report generation tools Generate system documentation 80
Software Engineering Form creation tools allow screen and document formats to be specified Import/export facilities Interchange of information from central repository with other tools Code generators Generate code skeleton from design captured from central repository.
81
Project Management
Management activities Project planning Project scheduling Risk management
Software Project Management Project management is concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organizations developing and procuring the software. Project management is needed because software development is always subject to budget and schedule constraints that are set by the organization developing the software. Software Project Management and other engineering disciplines Software management project Engineering
Software is intangible, Clearly visible thus progress is product, physical invisible, can be seen by entity document No standard processes, Varied model Large software project are One-off projects difference from previous projects, thus difficult to anticipate the problems Process are time tested manufacturing Product duplication same kind prototype. is of or
Management Activities Management Activities vary from project to project. In general it includes: Proposal writing Project planning Project scheduling Project costing Project monitoring and review Aparna K, Dept. of MCA, BMSIT 82
Software Engineering Personnel selection and evaluation Report writing and presentation
Proposal writing: The proposal describes the objective of project and how it will be carried out. It usually includes cost and schedule estimates, and justifies why the project contract should be awarded to a particular organization or team. It is high-skill job done by experienced staff. Project planning: This is concerned with identifying the activities, milestones and deliverables produced by a project. A plan is drawn up to guide the development towards the project goals. Project Monitoring: The manager must keep track of the progress of the project and compare actual and planned progress and costs. A skilled manager can form a clear picture of what is going on through informal discussions with project staff. Personnel selection and evaluation: This involves selection of a qualified and dedicated team. Required skill set is necessary. Right aptitude and attitude of staff is also mandatory. Report writing and presentation: Periodical reports on the status of the project are prepared. Project manager should have necessary skills and ability to present reports. Project Staffing: It may not be possible to appoint the ideal people to work on a project. Project budget may not allow for the use of highly-paid staff. Staff with the appropriate experience may not be available. An organization may wish to develop employee skills on a software project, thus inexperienced staff may be assigned to a project to learn. Managers have to work within these constraints especially when there are shortages of trained staff. Project Planning This is probably the most time-consuming project management activity. It is continuous activity from initial concept through to system delivery. Plans must be regularly revised as new information becomes available. Various types of plan may be developed to support the main software project plan that is concerned with schedule and budget. Types of Plan
83
Project Planning (Pseudo code)
At the beginning of a planning process, you should assess the constraints affecting the project. In connection with this, we should estimate project parameters such as its structure, size, and distribution of functions. Next we define the progress milestones and deliverables. The process then enters a loop. We draw up an estimated schedule for the project and the activities defined in the schedule are started or given permission to continue. After some time, usually about two to three weeks, we should review progress and note discrepancies from the planned schedule. Because initial estimates of project parameters are tentative, we will always have to modify the original plan. Aparna K, Dept. of MCA, BMSIT 84
Software Engineering The Project Plan The project plan sets out the resources available to the project, the work breakdown and a schedule for carrying out the work. The details of the project plan vary depending on the type of project and organization. Most plans include the following sections: Introduction: Objectives and constraints of project Project organization: Team, hierarchy and roles of members Risk analysis: Types of risks, Strategies to solve Hardware and software resources requirements: Hardware, software required with cost estimates Work breakdowns structure: Number of activities, milestones and deliverables Project schedule: Activities on time scale, sequence and interdependencies among various activities Monitoring and reporting: Status of project at various stages to check progress and quality
Activity Organization Activities in a project should be organised to produce outputs for management to judge progress. Milestones are the end-point of a process activity useful for developing teams and management. Deliverables are project results delivered to customers. The waterfall process allows for the straightforward definition of progress milestones. Milestones in the Requirements process
85
Software Engineering Project Scheduling This activity splits the project into tasks. It estimates time and resources required to complete each task. It organizes tasks concurrently to make optimal use of workforce. It minimizes task dependencies to avoid delays caused by one task waiting for another to complete. Project scheduling is dependent on project managers intuition and experience. The Project Scheduling Process
Scheduling Problems Estimating the difficulty of problems and hence the cost of developing a solution is hard. Productivity is not proportional to the number of people working on a task. Adding people to a late project makes it later because of communication overheads. The unexpected events always happen thus always allow contingency in planning.
Bar Charts and Activity Networks Graphical notations are used to illustrate the project schedule. Project breakdown is shown into tasks. Tasks should not be too small, they should take about a week or two. Activity charts show task dependencies and the critical path. Bar charts show schedule against calendar time. Task durations and dependencies The table below shows activities, their duration, and activity interdependencies. We can see that Activity T3 is dependent on Activity T1. This means that T1 must be completed before T3 starts. Given the dependencies and estimated duration of activities, an activity chart that shows activity sequences may be generated. This shows which activities can be carried out in parallel and which must be executed in sequence because of a dependency on an earlier activity. Activities are represented as rectangles; milestones and project deliverables are shown with rounded corners. Dates show the start date of the activity. The chart should be read from left to right and from top to bottom.
86
An activity network
Longest path of network is project duration and known as Critical path. Activities on this path are Critical activities. Overall schedule depends on critical path. Any delay in critical activity makes entire project delayed Ex-1: 55 working days or 11 weeks Aparna K, Dept. of MCA, BMSIT 87
Software Engineering Activity Bar Chart
The above figure is a complementary way of representing project schedule information. It is a bar chart showing a project calendar and the start and finish dates of activities. Sometimes, these are called Gantt charts. Reading from left to right, the bar chart clearly shows when activities start and end. Some of the activities shown in the bar chart in the above figure are followed by a shaded bar whose length is computed by the scheduling tool. This highlights the flexibility in the completion date of these activities. If an activity does not complete on time, the critical path will not be affected until the end of the period marked by the shaded bar. Activities that lie on the critical path have no margin of error and can be identified because they have no associated shaded bar. Staff Allocation Activities should be assigned to staff. Activities on same time can not be allocated to same staff. Every staff may not be working all the time for same project. They may work with other project. They may take leave. Other factors are expertise of staff and seniority of staff.
88
Software Engineering Risk Management Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project. A risk is a probability that some adverse circumstance will occur. There are three related categories of risk: Project risks affect schedule or resources Product risks affect the quality or performance of the software being developed Business risks affect the organisation developing or procuring the software Possible Software Risks
The Risk Management Process Risk identification Identify project, product and business risks; Risk analysis Assess the likelihood and consequences of these risks; Risk planning Draw up plans to avoid or minimise the effects of the risk; Risk monitoring Monitor the risks throughout the project; Aparna K, Dept. of MCA, BMSIT 89
Risk id e n tif ic a tio n
Ris k a n a ly sis
Ris k p la n n in g
Ris k m o n ito r in g
List o f p o te n tia l r isks
Pr io r itise d risk list
Ris k a v o id a n c e a n d c o n tin g e n c y p la n s
Ris k a sse ssm e n t
Risk Identification This is the first stage of risk management. It is concerned with discovering possible risks to the project. Risk identification may be carried out as a team process using a brainstorming approach or may simply be based on experience. To help the process, a checklist of different types of risk may be used. There are atleast six types of risk that can arise: Personnel risks High staff turnover Skilled staff not available Inadequate training Organizational risks Change in management Financial condition of organization Restructuring of organization Technology risks Advanced technology not available Tool risks CASE tools inefficient CASE tools Integrating Other support software Requirements risks Customer requirements changed Change in customer business Process of managing requirements is not perfect Estimation risks Size of software underestimated Cost of repairing the defects underestimated Duration of development underestimated Some examples of possible risks in each of these categories are shown below.
90
Risk Analysis During the risk analysis process it is required to assess probability and seriousness of each risk. Probability may be very low, low, moderate, high or very high. Risk effects might be catastrophic, serious, tolerable or insignificant. Following steps are carried out Evaluate each identified risk Most important risk areas Quantity and prioritize the risks Once the risks have been analyzed and ranked, we should assess which are most significant. The judgement must depend on a combination of the probability of the risk arising and the effects of that risk. In general, catastrophic risks should always be considered, as should all serious risks that have more than a moderate probability of occurrence. An illustration of the various parameters of risk analysis is shown below:
91
92
Software Engineering Risk Planning This process considers each of the key risks that have been identified and identifies strategies to manage the risk. These strategies fall into three categories: Avoidance strategies The probability that the risk will arise is reduced E.g. employ more staff, training to staff etc. Minimisation strategies The impact of the risk on the project or product will be reduced Contingency plans If the risk arises, contingency plans are plans to deal with that risk
93
Software Engineering We see here the analogy with the strategies used in critical systems to ensure reliability, security and safety. Essentially, it is best to use a strategy that avoids the risk. If this is not possible, we use one that reduces the chances that the risk will have serious effects. Risk Monitoring Risk Monitoring involves regularly assessing each of the identified risks to decide whether or not that risk is becoming more or less probable and whether the effects of the risk have changed. Some factors that help in risk monitoring are as follows:
Risk monitoring should be a continuous process, and, at every management progress review, we should consider and discuss each of the key risks separately.
94
QUESTION BANK FOR CHAPTER IV (System Models, Project Management)

1. Discuss the various Project Management activities. 2. Write a note on Project Planning. Describe the structure of Project Plan. 3. Differentiate between Milestones and Deliverables with suitable examples. 4. Explain Bar Charts and Activity networks with respect to Project Scheduling with appropriate examples. 5. Describe the process of Risk Management in software Project Management. 6. Draw a data flow diagram for invoice processing system. 7. Draw a data flow diagram for a library system considering registration, enquiry of books issued and issue of books. 8. Explain Behavioral model with examples. 9. Explain State machine model with an example. 10. Describe Inheritance models and object aggregation with suitable examples. 11. Write a note on structured methods.
95
Chapter V Software Design

Architectural Design Architectural design decisions System organization Modular decomposition styles Control styles
Software Architecture The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural design. The output of this design process is a description of the software architecture. The process of designing the global organization of a software system, including dividing software into subsystems, deciding how these will interact and determining their interfaces. Architectural Design It is an early stage of the system design process. It represents the link between specification and design processes. It is often carried out in parallel with some specification activities. It involves identifying major system components and their communications. The advantages of designing and documenting a software architecture are: Stakeholder communication Architecture may be used as a focus of discussion by system stakeholders. System analysis Means that analysis of whether the system can meet its non-functional requirements is possible. Large-scale reuse The architecture may be reusable across a range of systems. Architecture and system Characteristics Performance: The architecture should be designed to localize critical operations within a small number of subsystems, with as little communication as possible between these subsystems. Security: A layered structure for the architecture should be used, with the most critical assets protected in the innermost layers and with a high level of security validation applied to these layers. Safety: The architecture should be designed so that safety-related operations are all located in either a single sub-system or in a small number of sub-systems. This reduces Aparna K, Dept. of MCA, BMSIT 96
Software Engineering the costs and problems of safety validation and makes is possible to provide related protection systems. Availability: The architecture should be designed to include redundant components and so that it is possible to replace and update components without stopping the system. Maintainability: The architecture should be designed using fine-grain, self-contained components that may readily be changed. Producers of data should be separated from consumers and shared data structures should be avoided. Architectural Conflicts: There are potential conflicts between some of these architectures. For instance, Using large-grain components improves performance but reduces maintainability. Introducing redundant data improves availability but makes security more difficult. Localizing safety-related features usually means more communication so degraded performance System Structuring System structuring is decomposition of the system into interacting sub-systems. The architectural design is normally expressed as a block diagram presenting an overview of the system structure. More specific models showing how sub-systems share data are distributed and interface with each other may also be developed.
A sub-system design is an abstract decomposition of a system into large-grain components, each of which may be a substantial system in its own right. Block diagrams are often used to describe sub-system designs where each box in the diagram represents a Aparna K, Dept. of MCA, BMSIT 97
Software Engineering sub-system. Boxes within boxes indicate that the sub-system has itself been decomposed to sub-systems. Arrows mean that data and or control signals are passed from sub-system to sub-system in the direction of the arrows. Figure above shows an abstract model of the architecture for a packing robot system. The general problem of deciding how to decompose a system into sub-systems is a difficult one. The system requirements are a major factor and we should try to create a design where there is a close match between requirements and sub-systems. This means that, if the requirements change, this change is likely to be localized rather than distributed across several sub-systems. Architectural Design Decisions Architectural design is a creative process so the process differs depending on the type of system being developed. However, a number of common decisions span all design processes such as the following: Similarity of the system being developed with any generic application architecture. Distribution of the system across a number of processors. Appropriate architectural style for the system. Approach to structure the system. Decomposition of the system into modules. Control strategy of the units in the system. Method of evaluation of architectural design. Documentation of the system architecture. Architectural Styles The architecture of a software system may be based on a particular architectural model or style. An architectural style is a pattern of system organization such as a client-server organization or a layered architecture. However, the architectures of most large systems do not conform to a single style. Different parts of the system may be designed using different architectural styles. In some cases, the overall system architecture may be a composite architecture that is created by combining different architectural styles. Architectural models that may be developed may include: Static structural model that shows the need of major system components. Dynamic process model that shows organization of the processes in the system. Interface model that defines sub-system interfaces. Relationships model such as a data-flow model that shows sub-system relationships. Distribution model that shows how sub-systems are distributed across computers.
98
Software Engineering System Organization The organization of a system reflects the basic strategy that is used to structure a system. The system organization may be directly reflected in the sub-system structure. Three organizational styles are widely used: A shared data repository style A shared services and servers style An abstract machine or layered style The Repository Model Sub-systems making up a system must exchange information so that they can work together effectively. There are two fundamental ways in which this can be done: Shared data is held in a central database or repository and may be accessed by all sub-systems Each sub-system maintains its own database and passes data explicitly to other sub-systems The majority of systems that use large amounts of data are organized around a shared database or repository. This model is therefore suited to applications where data is generated by one sub-system and used by another. An example of CASE toolset architecture is shown below.
De sig n e d ito r Co d e g e ne r a to r
De sig n tra nsla to r
Pro j e c t re po sito ry
Pro g ra m e d ito r
De sig n a na l y se r
R e po r t g e ne r a to r
Advantages of Repository model Efficient way to share large amounts of data Sub-systems need not be concerned with how data is produced Centralised management of the activities e.g. backup, security, access control etc. New subsystem integration is easy if compatible with data models.
Disadvantages of Repository model
99
Software Engineering Sub-systems must agree on a repository data model, inevitably it is a compromise Data evolution is difficult and expensive No scope for specific management policies like back-up, security etc. Difficult to distribute efficiently
The Client-Server Model The client-server model is a system model where the system is organized as a set of services and associated servers and clients that access and use the services. The major components of this model are: The set of servers that offer services to other sub-systems. Examples of servers are print servers that offer printing services, file servers that offer file management services and a compile server, which offers programming language compilation services. A set of clients that call on the services offered by servers. These are normally sub-systems in their own right. There may be several instances of a client program executing concurrently. A network that allows the clients to access these services. This is not strictly necessary as both the clients and the servers could run on a single machine. The below figure shows an example of a system that is based on the client-server model.
Advantages of Client-server model Distribution of data and services are straightforward Makes effective use of networked systems May require cheaper hardware Easy to add new servers or upgrade existing servers Disadvantages of Client-server model No shared data model so sub-systems use different data organisation, thus data interchange may be inefficient. Aparna K, Dept. of MCA, BMSIT 100
Software Engineering Redundant management in each server No central register of names and services - it may be hard to find out what servers and services are available However to overcome the problem, central repository model can be implemented by having one server.
The Layered Model The layered model of an architecture (called an abstract machine model) organizes a system into layers, each of which provide a set of services. Each layer can be thought of as an abstract machine whose machine language is defined by the services provided by the layer. This language is used to implement the next level of abstract machine. A further translation step then converts this abstract machine code to real machine code. The layered approach supports the incremental development of systems. As a layer is developed, some of the services provided by that layer may be made available to users. This architecture is also changeable and portable. So long as its interface is unchanged, a layer can be replaced by another, equivalent layer. Furthermore, when layer interfaces change or new facilities are added to a layer, only the adjacent layer is affected. A disadvantage of the layered approach is that structuring systems in this way can be difficult. Inner layers may provide basic facilities, such as file management, that are required at all levels. Services required by a user of the top level may therefore have to punch through adjacent layers to get access to services that are provided several layers beneath it. This subverts the model, as the outer layer in the system does not just depend on its immediate predecessor. Performance can also be a problem because of the multiple levels of command interpretation that are sometimes required. If there are many layers, a service request from a top layer may have to be interpreted several times in different layers before it is processed. To avoid these problems, applications may have to communicate directly with inner layers rather than use the services provided by the adjacent layer. Modular Decomposition Styles Distinction between sub-systems and modules A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems. A module is a system component that provides services to other components but would not normally be considered as a separate system There are two main strategies that can be used when decomposing a sub-system into modules: Object-oriented decomposition: A system is decomposed into interacting object Function-oriented pipelining: Aparna K, Dept. of MCA, BMSIT 101
Software Engineering A system is decomposed into functional modules which transform inputs to outputs
Object-Oriented Decomposition System is structured into a set of loosely coupled objects with well-defined interfaces. Object-oriented decomposition is concerned with identifying object classes, their attributes and operations. When implemented, objects are created from these classes and some control model used to coordinate object operations. Figure below is an example of an object-oriented architectural model of an invoice processing system.
Custo m e r c usto m e r# na m e a d d re ss c re d it p e r io d
R e c e ipt invo ic e # d ate a m o un t c usto m e r#
Inv o ic e inv o ic e # d ate a m o un t c usto m e r issue () se n d Re m in d e r () a c c e p tP a y m e n t () se n d Re c e ipt ()
Pa y m e n t invo ic e # d ate a m o un t c usto m e r#
An object-oriented decomposition is concerned with object classes, their attributes and their operations. When implemented, objects are created from these classes and some control model is used to coordinate object operations. In the above example, the Invoice class has various associated operations that implement the system functionality. This class makes use of other classes representing customers, payments and receipts. Advantages Objects are loosely coupled so their implementation can be modified without affecting other objects. It is easily understandable because objects reflect real-world entities. OO implementation languages are widely used. Objects can be reused Disadvantages Objects must explicitly refer the names and interfaces of other objects offering services. Aparna K, Dept. of MCA, BMSIT 102
Software Engineering Complex entities may be hard to represent as objects. Object interface changes may cause problems
Function-oriented pipelining It represents functional transformations processes i.e. their inputs to produce outputs. Each processing step is implemented as a function transform and data flow from one process to another. These transforms may be parallel or sequential. An example of this type of system architecture is shown below.
Is s u e re c e ip ts R e a d is s u e d invo ic e s Id e n tif y p ay m e n ts Fin d p ay m e n ts due Invo ic e s Pay m e n ts Is s u e p ay m e n t re m in d e r R e m in d e r s R e c e ip ts
Advantages: It supports transformation reuse. It shows intuitive organization for stakeholder communication. Easy to add new transformations. Relatively simple to implement as either a concurrent or sequential system. Disadvantages It requires a common format for data transfer along the pipeline and difficult to support event-based interaction. Control Styles The models for structuring a system are concerned with how a system is decomposed into sub-systems. To work as a system, sub-systems must be controlled so that their services are delivered to the right place at the right time. The sub-systems should be organized according to some control model that supplements the structure model that is used. There are two generic control styles that are used: Centralised control One sub-system has overall responsibility for control and starts and stops other sub-systems. Event-driven control Each sub-system can respond to externally generated events from other sub-systems or the systems environment.
103
Software Engineering Centralized Control In a centralized control model, one sub-system is designated as the system controller and has responsibility for managing the execution of other sub-systems. Centralized control models fall into two classes, depending on whether the controlled sub-system execute sequentially or in parallel. 1. Call-return model 2. Manager model Call-return Model In this model, the control starts at the top of a subroutine hierarchy and, through subroutine calls, passes to lower levels in the tree. The subroutine model is only applicable to sequential systems. This model is shown below.
M a in pro g ra m
R o utine 1
R o utine 2
R o utine 3
R o utine 1 .1
R o utine 1 .2
R o utine 3 .1
R o utine 3 .2
The main program can call routines 1, 2 and 3; routine 1 can call routines 1.1 or 1.2; routine 3 can call routines 3.1 or 3.2; and so on. The rigid and restricted nature of this model is both strength and a weakness. It is strength because it is relatively simple to analyze control flows and work out how the system will respond to particular inputs. It is a weakness because exceptions to normal operation are awkward to handle. The Manager Model This is applicable to concurrent systems. One system component is designated as a system manager and controls the starting, stopping and coordination of other system processes. A process is a sub-system or module that can execute in parallel with other processes. An illustration of a centralized management model of control for a concurrent system is shown below. This model is often used in soft real-time systems which do not have very tight time constraints. The central controller manages the execution of a set of processes associated with sensors and actuators.
104
S e nso r pr o c e sse s
Ac tua to r pr o c e sse s
S y ste m c o ntr o lle r
C o m puta tio n pr o c e sse s
U se r inte r fa c e
F a ult ha ndle r
Event-driven Systems Event driven control models are driven by externally generated events. Event may be a signal that can take a range of values or a command input from a menu. Two eventdriven control models: Broadcast models Interrupt-driven models Broadcast Model An event is broadcast to all sub-systems. Any sub-system which can handle the event may respond to handle the event, it requires great processing overhead. Selective broadcast The event and message handler maintain a register of subsystems and the events of interest to them. Sub-systems register an interest in specific events. When these events occur, control is transferred to the sub-system which can handle the event. Control policy is not embedded in the event and message handler. Sub-systems decide on events of interest to them. An illustration is shown below.
105
Software Engineering Advantages: It is effective in integrating sub-systems on different computers in a network. Evolution is easy; any subsystem can be integrated to handle any activity. Disadvantages: Different subsystems may register for similar events which may cause conflict at the time of event generation Sub-systems dont know if or when an event will be handled. Interrupt-driven models Interrupt types are identified with their respective handler. Each interrupt type is associated with a memory location and a hardware switch causes transfer to its handler. At occurrence of an interrupt, the control is transformed to its handler. Handlers takes control of the process to respond the signal received from interrupt vector. An illustration is as shown below.
Advantages These are useful in real-time systems where fast response to an event is essential. Disadvantages It is complex to program and difficult to validate Number of interrupts to be handled is limited by hardware Addition of new interrupt is difficult. Reference Architectures Architectural models may be specific to some application domain. These are domainspecific model. There are two types of domain-specific architectural models:
106
Software Engineering Generic models: These are abstractions from a number of real systems and which encapsulate the principal characteristics of these systems. Design of these models can be directly reused. Reference models: These are more abstract, idealised model. These provide a means of information about that class of system and of comparing different architectures. Reference models are derived from a study of the application domain rather than from existing systems. These may be used as a basis for system implementation or to compare different systems. These act as a standard against which systems can be evaluated. OSI model is a layered model for communication systems which is shown below.
7 6 5 4 3 2 1 A pplica P r esenta S ession T ranspor N etw or k D a ta link P h ysical C om m t N etw or k D a ta link P h ysical unica tions m edium tion tion A pplica P r esenta S ession T ranspor t tion tion
N etw or k D a ta link P h ysical
Another proposed reference model is a reference model for CASE environments. The five levels of service in the CASE reference model are: Data repository services: These provide facilities for the storage and management of data items and their relationships. Data integration services: These provide facilities for managing groups or the establishment of relationships between them. These services and data repository services are the basis of data integration in the environment. Task management services: These provide facilities for the definition and enactment of process models. They support process integration. Message services: These provide facilities for tool-tool, environment-tool and environment-environment communications. They support control integration. User interface services: These provide facilities for user interface development. They support presentation integration.
107
Object-Oriented Design
Objects and Object Classes An Object-Oriented design process Design evolution
Object-oriented design is part of object-oriented development where an object-oriented strategy is used throughout the development process: Object-oriented analysis is concerned with developing an object-oriented model of the application domain. The objects in that model reflect the entities and operations associated with the problem to be solved. Object-oriented design is concerned with developing an object-oriented model of a software system to implement the identified requirements. The objects in an objectoriented design are related to the solution to the problem. There may be close relationships between some problem objects and some solution objects, but the designer has to add new objects and to transform problem objects to implement the solution. Object-oriented programming is concerned with realizing a software design using an object-oriented programming language, such as Java. An object-oriented programming language provides constructs to define object classes and a run-time system to create objects from these classes. Characteristics of OOD: Objects are abstractions of real-world or system entities. Objects are independent and encapsulate state and representation information. System functionality is expressed in terms of object services. Shared data areas are eliminated, Objects communicate by message passing. Objects may be distributed and may execute sequentially or in parallel.
Figure below shows a system made up of interacting objects

o 1 : C1 sta te o 1 o ps1 () o 3 :C3 sta te o 3 o ps3 () o 4: C4 sta te o 4 o ps4 ()
o 2 : C3 sta te o 2 o ps3 ()
o 6 : C1 sta te o 6 o ps1 ()
o 5 :C5 sta te o 5 o ps5 ()
108
Software Engineering Advantages of Object-oriented Design Easy to maintain, objects may be understood as stand-alone entities. Objects are potentially reusable components. For some systems, there may be an obvious mapping from real world entities to system objects. Disadvantages All domain may not support OOD Original SRS generally is in function oriented approach Before OOD, SRS should be translated into OOA Objects and Object Classes An object is an entity that has a state and a defined set of operations which operate on that state. The state is represented as a set of object attributes. The operations associated with the object provide services to other objects (clients) which request these services when some computation is required. Objects are created according to object class definition. An object class definition serves as a type specification and as a template for objects. It includes declarations of all the attributes and services which should be associated with an object of that class. Object classes may inherit attributes and services from other object classes. The Unified Modeling Language Several different notations for describing object-oriented designs were proposed in the 1980s and 1990s. The Unified Modelling Language is an integration of these notations. It describes notations for a number of different models that may be produced during OO analysis and design. Now it is a standard for OO modelling.
Emp loyee nam e: string address: string dateOfBirth: Date em ployeeN o: integer socialSecurityNo: string department: Dept ma nager: Employ ee salary : integer status: {current, left, retired} taxC ode: integer . .. join () leav e () retire () changeDetails ()
The class Employee defines a number of attributes that hold information about employees including their name and address, social security number, tax code and so on. Aparna K, Dept. of MCA, BMSIT 109
Software Engineering Object communication Conceptually, objects communicate by message passing. Messages require The name of the service requested by the calling object Copies of the information required to execute the service and the name of a holder for the result of the service. Synchronous When calling object waits for the service request to be completed Asynchronous When calling object may continue in the operation while the requested service is executing and objects can be implemented as concurrent processes or threads. Generalization and Inheritance Objects are members of classes that define attribute types and operations. Classes may be arranged in a class hierarchy where one class (a super-class) is a generalisation of one or more other classes (sub-classes). A sub-class inherits the attributes and operations from its super class and may add new methods or attributes of its own. Generalisation in the UML is implemented as inheritance in OO programming languages. A generalization hierarchy is shown as below.
E m p lo ye e
M an a g e r b u d g e ts C o n t ro lle d d a te A p p o in t e d
P ro g ra m m e r p ro je ct p ro g L a n g u a g e
P ro je ct M an a ge r p ro je ct s
D ep t . M an a g e r d e p t
S tra t e g ic M an a ge r re sp o n s ib ilitie s
The above figure shows an example of an object class hierarchy where different classes of employee are shown. Classes lower down the hierarchy has the same attributes and operations as their parent classes but may add new attributes operations or modify some of those from their parent classes. This means that there is one-way interchangeability. If the name of a parent class is used in a model, the object in the system may either be defined as of that class or of any of its descendants.
110
Software Engineering Advantages of Inheritance It is an abstraction mechanism which may be used to classify entities. It is a reuse mechanism at both the design and the programming level. The inheritance graph is a source of organisational knowledge about domains and systems.
Disadvantages: Object classes are not self-contained. they cannot be understood without reference to their super-classes. Designers have a tendency to reuse the inheritance graph created during analysis, it can lead to significant inefficiency. The inheritance graphs of analysis, design and implementation have different functions and should be separately maintained. UML Associations Objects and object classes participate in relationships with other objects and object classes. In the UML, relationship is indicated by an association. Associations may be annotated with information that describes the association. Associations are general but may indicate that an attribute of an object is an associated object or that a method relies on an associated object. An association model is shown below.
Concurrent Objects The nature of objects as self-contained entities makes them suitable for concurrent implementation. The message-passing model of object communication can be implemented directly if objects are running on separate processors in a distributed system. There are two kinds of concurrent object implementation: 1. Servers where the object is realised as a parallel process with methods corresponding to the defined object operations. Methods start up in response to an external message and may execute in parallel with methods associated with other objects. When they have completed their operation, the object suspends itself and waits for further requests for service.
111
Software Engineering 2. Active objects where the state of the object may be changed by internal operations executing within the object itself. The process representing the object continually executes these operations so never suspends itself. Servers are most useful in a distributed environment where the calling and the called object may execute on different computers. The response time for the service that is requested is unpredictable, so, wherever possible, we should design the system so that the object that has requested a service does not have to wait for the service to be completed. They can also be used in a single machine where a service takes some time to complete. Active objects are used when an object needs to update its own state at specified intervals. This is common in real-time systems where objects are associated with hardware devices that collect information about the systems environment. The objects methods allow other objects access to the state information. An object-oriented design process Structured design processes involve developing a number of different system models. They require a lot of effort for development and maintenance of these models and, for small systems, this may not be cost-effective. However, for large systems developed by different groups design models are an essential communication mechanism. The general process used for object-oriented design has a number of stages: Define the context and modes of use of the system Design the system architecture Identify the principal system objects Develop design models Specify object interfaces Layered architecture for weather mapping system
112
Software Engineering The above figure shows the layers and the layer name is included in a UML package symbol that has been denoted as a sub-system. A UML package represents a collection of objects and other packages. It is used here to show that each layer includes a number of other components. Subsystems in the weather mapping system
sub sy ste m Da ta c o lle c tio n Ob se rv e r Co m m s We a th e r sta tio n B a llo o n Sa te llite sub sy ste m Da ta d ispla y U se U ser r inte fa c ce e inter r fa M ap M ap d ispla y M ap printe r
sub sy ste m Da ta pro c e ssing Da ta c h e c kin g Da ta inte g ra tio n
sub sy ste m Da ta a rc h iv ing Da Data ta sto gg ee stora ra M a p sto re Da ta sto re
System context and models of use The first stage in any software design process is to develop an understanding of the relationships between the software that is being designed and its external environments. The system context and the model of system use represent two complementary models of the relationships between a system and its environment: System context A static model that describes other systems in the environment. Use a subsystem model to show other systems. Models of system use A dynamic model that describes how the system interacts with its environment. Use use-cases to show interactions The context model of a system may be represented using associations where a simple block diagram of the overall system architecture is produced. We then develop this by deriving a sub-system model using UML packages as shown in figure above. This model shows that the context of the weather station system is within a sub-system concerned with data collection. It also shows other sub-systems that make up the weather mapping system. Use-case models are used to represent each interaction with the system. A use-case model shows the system features as ellipses and the interacting entity as a stick figure. Aparna K, Dept. of MCA, BMSIT 113
S tar tup
S hutdown
R epor
C alibrate
T est
The use-case model for the weather station is shown in figure above. This shows that weather station interacts with external entities for startup and shutdown, for reporting the weather data that has been collected, and for instrument testing and calibration. Each of these use-cases can be described in structured natural language. This helps designers identify objects in the system and gives them an understanding of what the system is intended to do. The use-case description helps to identify objects and operations in the system. Architectural design Once interactions between the system and its environment have been understood, you use this information for designing the system architecture. A layered architecture is appropriate for the weather station. The three layers in the weather station software are: Interface layer: This is concerned with all communications with other parts of the system and with providing the external interfaces of the system. Data collection layer: This is concerned with managing the collection of data from the instruments and with summarizing the weather data before transmission to the mapping system. Instruments layer: This is concerned with the encapsulation of all of the instruments used to collect raw data about the weather conditions. There should normally be no more than 7 entities in an architectural model. The weather station architecture is shown below:
114
W e a the r sta tio n M a nag e s a ll e xte rna l c o m m unic a tio ns C o lle c ts a nd sum m arise s w e athe r data P ac kag e o f instrum e nts fo r raw da ta c o lle c tio ns
sub sy ste m Inte r fa c e
subsy ste m Da ta c o lle c tio n
sub sy ste m Instrum e nts
Object Identification This process is actually concerned with identifying object classes. The design is described in terms of these classes. Some of the proposals made about how to identify object classes are as follows: 1. Use a grammatical analysis of a natural language description of a system. Objects and attributes are nouns; operations or services are verbs. 2. Use tangible entities in the application domain such as aircraft, roles such as manager, events such as request, interactions such as meetings, locations such as offices, organizational units such as companies and so on. 3. Use a behavioral approach where the designer first understands the overall behavior of the system. The various behaviors are assigned to different parts of the system and an understanding is derived of who initiates and participates in these behaviors. Participants who play significant roles are recognized as objects. 4. Use a scenario-based analysis where various scenarios of system use are identified and analyzed in turn. As each scenario is analyzed, the team responsible for analysis must identify the required objects, attributes and operations. A method of analysis called CRC cards where analysis and designers take on the role of objects is effective in supporting this scenario-based approach. Weather station object classes 1. The WeatherStation object class provides the basic interface of the weather station with its environment. 2. The WeatherData object class encapsulates the summarized data from the instruments in the weather station. Its associated operations are concerned with collecting and summarizing the data that is required. 3. The Ground thermometer, Anemometer and Barometer object classes are directly related to instruments in the system. They reflect tangible hardware entities in the system and the operations are concerned with controlling that hardware.
115
W e athe rData airTe m pe r ature s g ro undT e m pe r ature s w indS pe e ds w indDire c tio ns pre ssure s rainf all c o lle c t () sum m arise ()
W e athe rS tatio n ide ntifie r re po r tWe athe r () c alibrate (instrum e nts) te st () star tup (instrum e nts) shutdo w n (instrum e nts)
Gr o und the rm o m e t te m pe r ature te st () c alibr ate ()
A ne m o m e t er w indS pe e d w indDire c tio n te st ()
er
B ar o m e t e r pre ssure he ight te st () c alibr ate ()
Design Models Design models show the objects and object classes and relationships between these entities. Static models describe the static structure of the system in terms of object classes and relationships. Dynamic models describe the dynamic interactions between objects. Some of the models are as follows: Sub-system models that show logical groupings of objects into coherent subsystems. These are static models. Sequence models that show the sequence of object interactions. These are dynamic models. State machine models that show how individual objects change their state in response to events. These are dynamic models. Other models include use-case models, aggregation models, generalisation models, etc. Figure below shows the objects in the sub-systems in the weather station. Each object is associated with one or more objects in this package. A package model plus an object class model should describe the logical groupings in the system. A sub-system model is a useful static model as it shows how the design may be organized into logically related groups of objects. The UML packages contain encapsulation constructs and do not reflect directly on entities in the system that is developed.
116
su bsystem I nter face su bsyst em D at a collect ion
C ommsC ont roller
W eatherD ata
W eat herS t at ion
I nst ru ment S tat u s
su bsyst em I nst ru ment s A ir t hermometer
R ainG au ge
A nemomet er
G rou nd t hermomet er
B arometer
W indV ane
Sequence models are dynamic models that document, for each mode of interaction, the sequence of object interactions that take place. Figure below is an example of a sequence model that shows the operations involved in collecting the data from a weather station.
:Co m m sCo ntro lle r re q ue st (re po r t) a c kn o w le d g e ()
:We a th e rSta tio n
:We a th e rDa ta
re po r t () sum m a rise ()
se nd (re po r t) re ply (re po rt) a c kno w le d g e ()
In a sequence model: Objects are arranged horizontally across the top Time is represented vertically so models are read top to bottom Aparna K, Dept. of MCA, BMSIT 117
Software Engineering Statecharts It shows how objects respond to different service requests and the state transitions triggered by these requests. If object state is Shutdown then it responds to a Startup() message In the waiting state the object is waiting for further messages If reportWeather () then system moves to summarising state If calibrate () the system moves to a calibrating state A collecting state is entered when a clock signal is received Figure below shows a statechart for the WeatherStation object that shows how it responds to requests for various services.
Op e r a tio n c a lib r a te () Ca lib r a tin g c a lib r a tio n OK Sh u td o w n sta rtu p () sh u td o w n () W a itin g te s t () tr a n s m is s io n d o n e Te s tin g te st c o m p le te
Interactions are represented by labelled arrows, Different styles of arrow represent different types of interaction A thin rectangle in an object lifeline represents the time when the object is the controlling object in the system
c lo c k
c o lle c tio n do ne
Tr a n s m ittin g r e p o rtWe a th e r () w e a th e r s u m m a r y c o m p le te
Su m m a r is in g Co lle c tin g
Object interface specification Object interfaces have to be specified so that the objects and other components can be designed in parallel. Designers should avoid designing the interface representation but should hide this in the object itself. Objects may have several interfaces which are viewpoints on the methods provided. The UML uses class diagrams for interface specification. Java may be used to implement. Design Evolution Hiding information inside objects means that changes made to an object do not affect other objects in an unpredictable way. Assume pollution monitoring facilities are to be added to weather stations. These sample the air and compute the amount of different Aparna K, Dept. of MCA, BMSIT 118
Software Engineering pollutants in the atmosphere. Pollution readings are transmitted with weather data. To modify the design, the following changes must be made: Add an object class called Air quality as part of WeatherStation. Add an operation reportAirQuality to WeatherStation. Modify the control software to collect pollution readings. Add objects representing pollution monitoring instruments. Figure below shows WeatherStation and the new objects added to the system.
WeatherS tation identifier repor tWeather ( ) repor tA irQ uality ( ) calibrate ( instruments) test ( ) star tup ( instruments) shutdown ( instruments)
A ir quality N O D ata smok eD ata benz eneD ata collect ( ) summarise ( )
Pollution monitoring instruments N O meter S mok eM eter
B enz eneM eter
119
QUESTION BANK FOR CHAPTER V (Software Design)

1. Write a note on Architectural Design Decisions. 2. Explain Repository Model. Discuss the advantages and disadvantages of a shared repository. 3. Explain Client-Server model in detail. 4. Write a note on The Layered Model. 5. What is Modular Decomposition? Explain the different types. 6. Write in detail on the different types of Control Styles. 7. What are the characteristics that make object oriented approach as the most preferred approach in modern development scenario? 8. List the stages of object-oriented design. Explain any 3 of these.
120
Chapter VI Development
Rapid Software Development Agile methods Extreme programming Rapid application development Software prototyping Rapid Software Development Because of rapidly changing business environments, businesses have to respond to new opportunities and competition. This requires software and rapid development and delivery is often the most critical requirement for software systems. Businesses may be willing to accept lower quality software if rapid delivery of essential functionality is possible. Because of the changing environment, it is often impossible to arrive at a stable, consistent set of system requirements. Therefore a waterfall model of development is impractical. An approach to development based on iterative development is the only way to deliver software quickly. Specifications, design and development are interleaved in iterative processes. Software is delivered in increments, each increment having new functionality. Characteristics of Rapid software development The processes of specification, design and implementation are concurrent. There is no detailed specification document. Design documentation is also minimized. RAD emphasizes a short development life cycle. The system is developed in a series of increments. End users evaluate each increment and make proposals for later increments. System user interfaces are usually developed using an interactive development system. Web based interface can also be generated.
An iterative development process

De fine sy ste m de li v e ra b le s
De sig n sy ste m a rc hite c tur e
S pe c ify sy ste m inc re m e nt NO
B uild sy ste m inc re m e nt
V a lida te inc re m e nt
De live r fina l sy ste m
YES
S y ste m c o m ple te ?
V a lida te sy ste m
Inte g ra te inc re m e nt
121
Software Engineering Advantages of Incremental approach 1. Accelerated delivery of customer services: Early increments of the system can deliver high-priority functionality so that customers can get value from the system early in its development. Customers can see their requirements in practice and specify changes to be incorporated in later releases of the system. 2. User engagement with the system: Users of the system have to be involved in the incremental development process because they have to provide feedback to the development team on delivered increments. Their involvement does not just mean that the system is more likely to meet their requirements; it also means that the system end-users have made a commitment to it and are likely to want to make it work. Problems with incremental development Management problems Producing entire documentation may not be cost-effective Progress can be hard to judge in absence of documentation For fast development and delivery, unfamiliar and advanced technologies are required, skilled staff may not be available. Contractual problems The normal contract about cost and time needs specifications to be documented Specifications documentation is produced for increments for different timing, thus difficult to fix the cost and time. It is difficult to accommodate all the changes suggested by customer in fixed price. Validation problems Difficult to generate test plan without specifications Maintenance problems Continual change tends to corrupt software structure, thus makes it more expensive to change and evolve to meet new requirements.
Prototyping For some large systems, incremental iterative development and delivery may be impractical; this is especially true when multiple teams are working on different sites. Prototyping: An experimental system is developed as a basis for formulating the requirements. This system is thrown away when the system specification has been agreed. Evolutionary development and Prototyping
122
Evolutionary development The objective of evolutionary or incremental development is to deliver a working system to end-users. The development starts with those requirements which are best understood. Throw-away prototyping The objective of throw-away prototyping is to validate or derive the system requirements. The prototyping process starts with those requirements which are poorly understood. Agile Methods For large and critical systems, a well planned and controlled software development process is required which has heavy use of design and analysis methods. Plan based approach is heavy-weight process which needs large overhead and may not be proper for small or medium sized application. Dissatisfaction with the overheads involved in design methods led to the creation of agile methods. Characteristics of Agile methods: These methods focus on the code rather than the design These are based on an iterative approach to software development These are intended to deliver working software quickly and evolve software quickly to meet changing requirements These methods have high involvement of customers Agile methods are probably best suited to small/medium-sized business systems or PC products. Principles of Agile Methods
123
Problems with agile methods It can be difficult to keep the interest of customers who are involved in the process; success of the system depends on customers willingness and availability to participate. Team members may be unsuited to the intense involvement that characterizes agile methods. Prioritizing changes can be difficult where there are multiple stakeholders. Maintaining simplicity requires extra work. Contracts may be a problem as with other approaches to iterative development.
Extreme Programming Extreme Programming is the best-known and most widely used agile method. Extreme Programming (XP) takes an extreme approach to iterative development and customer involvement. All requirements are expressed as scenarios which are directly implemented as series of tasks Programmers work in pairs and develop test cases for each task before writing code Increments are delivered to customers with short time gapes between releases All tests must be run for every build and the build is only accepted if tests run successfully Figure below illustrates the XP process to produce an increment of the system that is being developed. The Extreme Programming Release cycle
124
S e le c t use r storie s for this re le ase
B re ak do w n sto rie s to tasks
P lan re le ase
E valuate sy ste m
R e le ase so ftw are
D e ve lo p/ inte g te st so ftw are
rate /
Extreme Programming Practices
125
XP and Agile Principles: A Comparison Incremental development is supported through small, frequent system releases. Customer involvement means full-time customer engagement with the team. People not process through pair programming, collective ownership and a process that avoids long working hours. Change supported through regular system releases. Maintaining simplicity through constant refactoring of code is also a feature. In XP, user requirements are expressed as scenarios or user stories. These are written on cards and the development team breaks them down into implementation tasks. These tasks are the basis of schedule and cost estimates. The customer chooses the stories for inclusion in the next release based on their priorities and the schedule estimates. Extreme programming takes an extreme approach to iterative development. New versions of the software may be built several times per day and increments are delivered to customers roughly every two weeks. When a programmer builds the system to create a Aparna K, Dept. of MCA, BMSIT 126
Software Engineering new version, he or she must run all existing automated tests as well as the tests for the new functionality. The new build of the software is accepted only if all tests execute successfully. A fundamental percept of traditional software engineering is that we should design for change. That is, we should anticipate future changes to the software and design it so that these changes can be easily implemented. Testing in XP To avoid some of the problems of testing and system validation, XP places more emphasis than other agile methods on the testing process. The key features of testing in XP are: Test-first development Incremental test development from scenarios User involvement in test development and validation Use of automated test environment Test-first development is one of the most important innovations in XP. Writing tests first defines both an interface and a specification of behavior for the functionality being developed. Problems of requirements and interface misunderstandings are reduced. This approach can be adopted in any process where there is a clear relationship between a system requirement and the code implementing that requirement. In XP, the story cards representing the requirements are broken down into tasks, and the tasks are the principal unit of implementation. User requirements in XP are expressed as scenarios or stories and the user prioritizes these for development. The development team assesses each scenario and breaks it down into tasks. Each task represents a discrete feature of the system and a unit test can then be designed for that task. For example, some of the task cards developed from the story card for document downloading is shown below.
127
Software Engineering Each task generates one or more unit tests that check the implementation described in that task. For example, figure below is a shortened description of a test case that has been developed to check that a valid credit card number has been implemented.
Writing tests before code clarifies the requirements to be implemented. Tests are written as programs rather than data so that they can be executed automatically. All previous and new tests are automatically run when new functionality is added, checking that the new functionality has not introduced errors. Some of the disadvantages of testing in XP are as follows. Programmers prefer programming rather testing, thus they may not write complete tests. Sometimes writing test first may not be possible e.g. for complex user interface. It may be difficult to judge the completeness of set of test cases. Customer may not be available full time with XP team for acceptance test plan. Customer may be reluctant to be part of testing team. Pair Programming In XP, programmers work in pairs, sitting together to develop code. Same pairs of members do not always work together. Pairs are created dynamically so each team member may work with all other tem members. Advantages of Pair Programming This helps develop common ownership of code and spreads knowledge across the team. It serves as an informal review process as each line of code is looked at by more than 1 person. It encourages refactoring as the whole team can benefit from this. Measurements suggest that development productivity with pair programming is similar to that of two people working independently.
128
Software Engineering Rapid Application Development Rapid application development (RAD) techniques evolved from fourth generation language in 1980s. These are designed to develop data-intensive business applications and rely on programming and presenting information from a database. The tools that are included in a RAD environment are: Database programming language It embeds knowledge of the database structures and includes database manipulation languages (SQL) Interface generator It helps to create forms for data input and output Links to office applications These applications may be spreadsheet and used for manipulation of numeric information Report generators It is used to define and create reports A RAD Environment
Inte r fa c e g e ne r a to r DB pro g ra m m ing la ng ua g e Da ta b a se m a na g e m e nt sy ste m Offic e sy ste m s R e po r t g e ne r a to r
R a pid a pplic a tio n de v e lo pm e nt e nv iro nm e nt
Many applications are based around complex forms and developing these forms manually is a time-consuming activity. RAD environments include support for screen generation including: Interactive form definition using drag and drop techniques Form linking where the sequence of forms to be presented is specified Field verification where allowed ranges in form fields is defined Visual Programming Scripting languages such as Visual Basic support visual programming where the prototype is developed by creating a user interface from standard items and associating components with these items. A large library of components exists to support this type of development. These may be tailored to suit the specific application requirements. Figure below shows an application screen including menus along the tip, input fields, output
129
Software Engineering fields and buttons. It also shows the components that are associated with some of the display elements.
M e nu c o m po n e n t
Da te c o m po ne nt
File
Ed it
V ie w s
La y o ut
Optio ns
He lp Ge ne ra l Ind e x
1 2 th J a nua ry 2 0 0 0 R a ng e c h e c king sc ript 3 .8 7 6
Dra w c a nv a s c o m po ne nt
U se r pro m pt c o m po ne nt + sc ript
Tre e d ispla y c o m po ne nt
Some of the problems with visual development are: Difficult to coordinate team-based development. No explicit system architecture. Complex dependencies between parts of the program can cause maintainability problems. COTS reuse: An effective approach to rapid development is to configure and link existing off the shelf systems. For example, a requirements management system could be built by using: A database to store requirements A word processor to capture requirements and format reports A spreadsheet for traceability management For some applications, a prototype can be created by developing a compound document. This is a document with active elements (such as a spreadsheet) that allow user computations. Each active element has an associated application which is invoked when that element is selected. The document itself is the integrator for the different applications. Figure below shows an application system made up of a compound document that includes text elements, spreadsheet elements and sound files. Text elements are processed by the word processor, tables by the spreadsheet application and sound files by an audio player. When a system user accesses an object of a particular type, the associated application is called to provide user functionality. The main advantage of this approach is that a lot of application functionality can be implemented quickly at a very low cost. Users who are already familiar with the applications making up the system do not have to learn how to new features.
130
C o mpo und do cument Text 1 T able 1 T ext 2 Text 3 S o und 1
Table 2
T ext 4
S o und 2
T ext 5
W o rd processo r
S preadsheet
A udio player
Software Prototyping A prototype is an initial version of a system used to demonstrate concepts and try out design options. A prototype can be used in: The requirements engineering process to help with requirements elicitation and validation In design processes to explore options and develop a UI design In the testing process to run back-to-back tests Benefits of Prototyping Improved system usability. A closer match to users real needs. Improved design quality. Improved maintainability. Reduced development effort
A process model for prototype development is shown in figure below.

E sta b lish pr o to ty pe o b je c ti v e s De fine pro to ty pe func tio nality De v e lo p pr o to ty pe E va lua te pr o to ty pe
Pro to ty ping pla n
Outline de finitio n
Exe c uta b le pr o to ty pe
Eva lua tio n re po r t
The objectives of prototyping should be made explicit from the start of the process. If the objectives are left unstated, management or end-users may misunderstand the function of the prototype. So they may not get the benefits that they expected from the prototype development.
131
Software Engineering The next stage is to decide what to put into and, what to leave out of the prototype system. Some of the functionality may be left out of the prototype to reduce costs and accelerate the delivery schedule. Some non-functional requirements such as response time and memory utilization may be relaxed. Standards of reliability and program quality may be reduced. The final stage of the process is prototype evaluation. Provisions must be made during this stage for user training, and the prototype objectives should be used to derive a plan for evaluation. Users need time to become comfortable with a new system and to settle into a normal pattern of usage. Once they are using the system normally, they then discover requirements errors and omissions. Throw-away prototypes Prototypes should be discarded after development as they are not a good basis for a production system because It may be impossible to tune the system to meet non-functional requirements Prototypes are normally undocumented The prototype structure is usually degraded through rapid change The prototype probably will not meet normal organizational quality standards
132
Software Evolution
Program evolution dynamics Software maintenance Evolution processes Legacy system evolution
Reasons for Software Change Software change is inevitable because New requirements emerge when the software is used The business environment changes Errors must be repaired New computers and equipment are added to the system The performance or reliability of the system may have to be improved A key problem for organisations is implementing and managing change to their existing software systems. The importance of evolution is many. Organizations have huge investments in their software systems - they are critical business assets. It is important to maintain the value of these assets to the business; they must be changed and updated. The majority of the software budget in large companies is devoted to evolving existing software rather than developing new software. The majority of changes are a consequence of new requirements that are generated in a response to changing business and user needs. The spiral model of evolution is shown in the figure below.
S pe c ific atio n S tar t Re le ase 1 O pe ratio n Re le ase 2 Re le ase 3
I m ple m e ntio n
V alidatio n
We start by creating Release 1 of the system. Once delivered, changes are proposed and the development of Release 2 starts almost immediately. The need for evolution may become obvious even before the system is deployed so that later releases of the software Aparna K, Dept. of MCA, BMSIT 133
Software Engineering may be under development before the initial version has been released. This is an idealized model of software evolution that can be applied in situations where a single organization is responsible for both the initial software development and the evolution of the software. Program Evolution Dynamics Program evolution dynamics is the study of the processes of system change. After major empirical studies, Lehman and Belady proposed that there were a number of laws which applied to all systems as they evolved. They are applicable to large systems developed by large organisations, less applicable in other cases. Lehmans Laws Continuing change Increasing complexity Large program evolution Organisational stability Conservation of familiarity Continuing growth Declining quality Feedback system
The first law states that system maintenance is an inevitable process. As the systems environment changes, new requirements emerge and the system must be modified. When the modified system is re-introduced to the environment, this promotes more environmental changes, so the evolution process recycles. The second law states that, as a system is changed, its structure is degraded. The only way to avoid this happening is to invest in preventative maintenance where we spend time improving the software structure without adding to its functionality. The third law suggests that large systems have a dynamic of their own that is established at an early stage in the development process. This determines the gross trends of the system maintenance process and limits the number of possible system changes. The fourth law suggests that most large programming projects work in what is termed a saturated state. That is, a change to resources or staffing has imperceptible effects on the long-term evolution of the system. This is consistent with the third law, which suggests that program evolution is largely independent of management decisions. This law confirms that large software development teams are often unproductive because communication overheads dominate the work of the team. The fifth law is concerned with the change increments in each system release. Adding new functionality to a system inevitably introduces new system faults. The more functionality added in each release, the more faults there will be. Therefore, a large Aparna K, Dept. of MCA, BMSIT 134
Software Engineering increment in functionality in one system release means that this will have to be followed by a further release where the new system faults are repaired. The law suggests that we should not budget for large functionality increments in each release without taking into account the need for fault repair. The sixth and seventh laws are similar and essentially say that users of software will become increasingly unhappy with it unless it is maintained and new functionality is added to it. The final law reflects the most recent work on feedback processes, although it is not yet clear how this can be applied in practical software development. Lehmans laws seem to be generally applicable to large, tailored systems developed by large organisations. This is confirmed in more recent work by Lehman on the FEAST project. It is not clear how they should be modified for Systems that incorporate a significant number of COTS components Small organisations Medium sized systems Software Maintenance Software maintenance is modifying a program after it has been put into use. Maintenance does not normally involve major changes to the systems architecture. Changes are implemented by modifying existing components and adding new components to the system. The system requirements are likely to change while the system is being developed because the environment is changing. Systems are tightly coupled with their environment. The system requirements are likely to change while the system is being developed because the environment is changing. Systems MUST be maintained, if they are to remain useful in an environment. Types of Maintenance Corrective Maintenance (repairing software faults) Changing a system to correct deficiencies to meets its requirements. Adaptive Maintenance (adapting software to a different operating environment) Changing a system so that it operates in a different environment (computer, OS, etc.) from its initial implementation. Perfective Maintenance (adding or modifying the systems functionality) Modifying the system to satisfy new requirements. Distribution of Maintenance Effort Surveys suggests that about 65% of maintenance is concerned with implementing new requirements, 18% with changing the system to adapt it to a new operating environment and 17% to correcting system faults. This is shown below.
135
Fa ult re pa ir (1 7 % )
S o ftw a re a da pta tio n (1 8 % )
Func tio na lity a dditio n o r m o dific a tio n (6 5 % )
Maintenance costs as a proportion of development costs vary from one application domain to another. Studies suggest that the maintenance costs for business application systems are broadly comparable with system development costs. For embedded real-time systems, maintenance costs may be up to four times higher than development costs. Figure below shows how overall lifetime costs may decrease as more effort is expended during system development to produce a maintainable system.
S y ste m 1 S y ste m 2 0 50 1 00 150 2 00 2 50 3 00 35 0 400 45 0 5 00 $
De v e lo pm e nt c o sts
M ainte nanc e c o sts
The key factors that distinguish development and maintenance, and which lead to higher maintenance costs, are: Team stability Maintenance costs are reduced if the same staff are involved with them for some time. Contractual responsibility The developers of a system may have no contractual responsibility for maintenance so there is no incentive to design for future change. Staff skills Maintenance staffs are often inexperienced and have limited domain knowledge. Aparna K, Dept. of MCA, BMSIT 136
Software Engineering Program age and structure As programs age, their structure is degraded and they become harder to understand and change.
Maintenance Prediction Maintenance prediction is concerned with assessing which parts of the system may cause problems and have high maintenance costs Change acceptance depends on the maintainability of the components affected by the change Implementing changes degrades the system and reduces its maintainability Maintenance costs depend on the number of changes and costs of change depend on maintainability
To evaluate the relationships between a system and its environment, we should assess: 1. The number and complexity of system interfaces: The larger the number of interfaces and the more complex they are, the more likely it is that demands for change will be made. 2. The number of inherently volatile system requirements: Requirements that reflect organizational policies and procedures are likely to be more volatile than requirements that are based on stable domain characteristics. 3. The business processes in which the system is used: As business processes evolve, they generate system change requests. The more business processes that use a system, the more the demands for system change. Examples of process metrics that can be used for assessing maintainability are: 1. Number of requests for corrective maintenance: An increase in the number of failure reports may indicate that more errors are being introduced into the program than are being repaired during the maintenance process. This may indicate a decline in maintainability. Aparna K, Dept. of MCA, BMSIT 137
Software Engineering 2. Average time required for impact analysis: This reflects the number of program components that are affected by the change request. If this time increases, it implies that more and more components are affected and maintainability is decreasing. 3. Average time taken to implement a change request: This is not the same as the time for impact analysis although is may correlate with it. This is the amount of time that you need to actually modify the system and its documentation, after we have assessed which components are affected. An increase in the time needed to implement a change may indicate a decline in maintainability 4. Number of outstanding change requests: An increase in this number over time may imply a decline in maintainability. Evolution Processes Evolution process depends on The type of software being maintained The development processes used The skills and experience of the people involved Proposals for change are the driver for system evolution. Change identification and evolution continue throughout the system lifetime.
The evolution process includes the fundamental activities of change analysis, release planning, system implementation and releasing a system to customers. The cost and impact of these changes are assessed to see how much of the system is affected by the change and how much it might cost to implement the change. If the proposed changes are accepted, a new release of the system is planned. During release planning, all proposed changes are considered. A decision is then made on which changes to implement in the next version of the system is released. The process then iterates with a new set of changes proposed for the next release. Figure below shows an overview of this process.
138
Ch a n g e re q u e s ts
Im p a c t a n a ly s is
Re le a se p la n n in g
Ch a n g e im p le m e n ta tio n
Sy s te m re le a s e
Fa u lt r e p a ir
Pla tf o r m a d a p ta tio n
Sy s te m e nha nc e m e nt
The process of change implementation is, essentially, an iteration of the development process where the revisions to the system are designed, implemented and tested. However, a critical difference is that the initial stage of change implementation is program understanding. During this phase, we have to understand how the program is structured and how it delivers its functionality. When implementing a change, we use this understanding to make sure that the implemented change does not adversely affect the existing system. Ideally, the change implementation stage of this process should modify the system specification, design and implementation to reflect the changes to the system.
Pr o po s e d c ha ng e s
Re q u ir e m e n ts a n a ly s is
R e q u ire m e n ts u p d a tin g
So f twa re d e ve lo p m e n t
Change requests sometimes relate to system problems that have to be tackled very urgently. These urgent changes can arise for three reasons: 1. If a serious system fault occurs that has to be repaired to allow normal operation to continue 2. If changes to the systems operating environment have unexpected effects that disrupt normal operation. 3. If there are unanticipated changes to the business running the system, such as the emergence of new competitors or the introduction of new legislation. System re-engineering It is re-structuring or re-writing part or all of a legacy system without changing its functionality. It is applicable where some but not all sub-systems of a larger system require frequent maintenance. Re-engineering involves adding effort to make them easier to maintain. The system is re-structured and re-documented. The two key advantages are: Reduced risk There is a high risk in new software development. There may be development problems, staffing problems and specification problems. Aparna K, Dept. of MCA, BMSIT 139
Software Engineering Reduced cost The cost of re-engineering is often significantly less than the costs of developing new software.
The critical distinction between re-engineering and new software development is the starting point for the development. Rather than starting with a written specification, the old system acts as a specification for the new system. The distinction between forward engineering and software re-engineering is shown below:
Sy ste m spe c ific a tio n Fo rw a r d e ng ine e ring E xisting so ftw a re sy ste m S o ftw a r e r e -e ng ine e ring U nde rstanding and tr ansf o r m a tio n R e -e ng ine e r e d sy ste m De sig n and im ple m e ntatio n Ne w sy ste m
Forward engineering starts with a system specification and involves the design and implementation of a new system. Re-engineering starts with an existing system and the development process for the replacement is based on understanding and transforming the original system. Figure below shows the re-engineering process.
Orig in a l pro g ra m R e v e rse e ng ine e rin g S o urc e c o d e tra nsla tio n Pro g ra m struc ture im pro v e m e nt S truc ture d pro g ra m R e -e n g ine e re d d a ta Pro gra m m o d ula risa tio n Da ta re -e ng ine e rin g Pro g ra m d o c um e n ta tio n M o d ula rise d pro g ra m Orig ina l d a ta
The activities in the re-engineering process are as follows: 1. Source code translation: The program is converted from an old programming language to a more modern version of the same language or to a different language. 2. Reverse engineering: The program is analyzed and information extracted from it. This helps to document its organization and functionality. Aparna K, Dept. of MCA, BMSIT 140
Software Engineering 3. Program structure improvement: The control structure of the program is analyzed and modified to make it easier to read and understand. 4. Program modularization: Related parts of the program are grouped together and, where appropriate, redundancy is removed. In some cases, this stage may involve architectural transformation where a centralized system intended for a single computer is modified to run on a distributed platform. 5. Data re-engineering: The data processed by the program is changed to reflect the program changes. The costs of re-engineering obviously depend on the extent of the work that is carried out. There is a spectrum of possible approaches to re-engineering as shown below.
A uto m a te d pr o g ra m re struc turin g Pro g ra m a n d d a ta re struc turin g
A uto m ate d so ur c e c o d e c o nve rsio n
A uto m a te d re struc turin g w ith m a nua l c h a n g e s
R e str uc turin g plus a rc h ite c tura l c h a n g e s
In c re a se d c o st
The principal factors that affect re-engineering costs are: 1. The quality of the software to be re-engineered: The lower the quality of the software and its associated documentation (if any), the higher the re-engineering costs. 2. The tool support available for re-engineering: It is not normally cost-effective to re-engineer a software system unless we can use CASE tools to automate most of the program changes. 3. The extent of data conversion required: If re-engineering requires large volumes of data to be converted, the process cost increases significantly. 4. The availability of expert staff: If the staff responsible for maintaining the system cannot be involved in the re-engineering process, the costs will increase because system re-engineers will have to spend a great deal of time understanding the system. Legacy System Evolution Organisations that rely on legacy systems must choose a strategy for evolving these systems Scrap the system completely and modify business processes so that it is no longer required Continue maintaining the system Transform the system by re-engineering to improve its maintainability Aparna K, Dept. of MCA, BMSIT 141
Software Engineering Replace the system with a new system The strategy chosen should depend on the system quality and its business value. System quality and Business value
Low quality, low business value These systems should be scrapped. Low-quality, high-business value These make an important business contribution but are expensive to maintain. These should be re-engineered or replaced if a suitable system is available. High-quality, low-business value Replace with COTS, scrap completely or maintain. High-quality, high business value Continue in operation using normal system maintenance.
To assess the business value of a system, we have to identify system stakeholders, such as end-users of the system and their managers, and ask a series of questions about the system. There are four basic issues to discuss: 1. The use of the system: If systems are only used occasionally or by a small number of people, they may have a low business value. A legacy system may have been developed to meet a business need that has either changed or that can now be met more effectively in other ways. 2. The business processes that are supported: When a system is introduced, business processes to exploit that system may be designed. However, changing these processes may be impossible because the legacy system cant be adapted. Therefore, a system may have a low business value because new processes cannot be introduced. 3. The system dependability: System dependability is not only a technical problem but also a business problem. If a system is not dependable and the problems Aparna K, Dept. of MCA, BMSIT 142
Software Engineering directly affect the business customers or mean that people in the business are diverted from other tasks to solve these problems, the system has a low business value. 4. The system outputs: The key issue here is the importance of the system outputs to the successful functioning of the business. If the business depends on these outputs, then the system has a high business value. Conversely, if these outputs can be easily generated in some other way or if the system produces outputs that are rarely used, then its business value may be low. Factors used in Environment assessment
143
Software Engineering We may collect quantitative data to make an assessment of the quality of the application system. Some of the quantitative data are: 1. The number of system change requests: System changes tend to corrupt the system structure and make further changes more difficult. The higher this value, the lower the quality of the system. 2. The number of user interfaces: This is an important factor in forms-basedsystems where each form can be considered as a separate user interface. The more interfaces, the more likely that there will be inconsistencies and redundancies in these interfaces. 3. The volume of data used by the system: The higher the volume of data, the more complex the system.
144
QUESTION BANK FOR CHAPTER VI (Development)
1. What are Agile methods? Explain in detail the principles of the same. 2. Explain the concept of Extreme Programming with the respective principles in detail. 3. Discuss the concept of Pair Programming. 4. Explain Rapid Application Development in detail. 5. State and explain all the Lehmans Laws related to Program Evolution Dynamics. 6. Discuss in detail about Software Maintenance. 7. Write a note on Maintenance Prediction. 8. Explain with a neat diagram the different stages involved in The system evolution processes. 9. Explain The System Re-engineering process in detail. 10. Explain the different strategies that can be employed for the evolution of Legacy Systems. 11. Explain the different factors involved in the assessment of Legacy Systems.
145
Chapter VII Verification and Validation

Verification and Validation Verification and validation planning Software inspections Automated static analysis Cleanroom software development Verification: "Are we building the product right. The software should conform to its specification. Validation: "Are we building the right product. The software should do what the user really requires. The ultimate goal of the verification and validation process is to establish confidence that the software system is fit for purpose. This means that the system must be good enough for its intended use. The level of required confidence depends on the systems purpose, the expectations of the system users and the current marketing environment for the system. Within the V & V process, there are two complementary approaches to system checking and analysis: 1. Software inspections or peer reviews analyse and check system representations such as the requirements document, design diagrams and the program source code. Inspections can be used at all stages of the process. Inspections may be supplemented by some automatic analysis of the source text of a system or associated documents. Software inspections and automated analyses are static V & V techniques, as we do not need to run the software on a computer. 2. Software testing involves running an implementation of the software with test data. We examine the outputs of the software and its operational behaviour to check that it is performing as required. Testing is a dynamic technique of verification and validation. Software inspections and testing play complementary roles in the software process. This is shown below.
S oftware inspections
R equir em ents spe cifica tion
H igh-le v e l de sign
For m al spe cifica tion
D e tailed de sign
P r o g ram
P r ototype
P rog ram te sting
146
Software Engineering Program Testing Testing reveals the presence of errors NOT their absence. Testing is only the validation technique for non-functional requirements as the software has to be executed to see how it behaves. Testing should be used in conjunction with static verification to provide full V&V coverage. There are basically two types of testing that may be used at different stages in the software process: Defect testing Tests are designed to discover system defects. A successful defect test is one which reveals the presence of defects in a system. Validation testing It is intended to show that the software meets its requirements. A successful test is one that shows that a requirement has been properly implemented. Testing and Debugging Defect testing and debugging are distinct processes. Verification and validation is concerned with establishing the existence of defects in a program. Debugging is concerned with locating and repairing these errors. Debugging involves formulating a hypothesis about program behaviour then testing these hypotheses to find the system error. The debugging process is shown below:
Te st re sults
S pe c ific a tio n
Te st c a se s
Lo c ate e rro r
De sig n e rro r r e pa ir
R e pa ir e rro r
R e te st pro g ra m
Planning Verification and Validation Careful planning is required to get the most out of testing and inspection processes. Planning should start early in the development process. The plan should identify the balance between static verification and testing. Test planning is about defining standards for the testing process rather than describing product tests. The V-model of development is shown below. It is an instantiation of the generic waterfall model and shows that test plans should be derived from the system specification and design. This model also breaks down system V
147
Software Engineering & V into a number of stages. Each stage is driven by tests that have been defined to check the conformance of the program with its design and specification.
R e q u ire m e n ts s p e c if ic tio a n Sy s te m sp e c if ic tio a n Sy s te m d e s ig n De ta ile d d e sig n
Ac c e p ta n c e te s t p la n
Sy s te m in te gra tio n te s t p la n
Su b - sy s te m in te gra tio n te s t p la n
Mo d u le a n d u n it c o d e a n d te s t
Se r v ic e
Ac c e p ta n c e te s t
Sy s te m in te gra tio n te s t
Su b - sy s te m in te gra tio n te s t
Test planning is concerned with establishing standards for the testing process, not just with describing product tests. Tests plans are intended for software engineers involved in designing and carrying out system tests. They help technical staff get an overall picture of the system tests and place their own work in this context. The major components of a test plan are shown below. The testing process It describes all major phases of testing process Requirements traceability All the requirements are tested individually Tested items It specifies software components to be tested Testing schedule It specifies testing schedule and resources allocated Test recording procedures All results should be recorded systematically & audited Hardware and software requirements It specifies H/W & S/W requirements Constraints It specifies constraints during testing as staff shortage
Tests plans are not a static document but evolve during the development process. Test plans change because of delays at other stages in the development process. If part of a system is incomplete, the system as a whole cannot be tested. We then have to revise the test plan to redeploy the testers to some other activity and bring them back when the software is once again available. Software Inspections These involve people examining the source representation with the aim of discovering anomalies and defects. Inspections do not require execution of a system so may be used Aparna K, Dept. of MCA, BMSIT 148
Software Engineering before implementation. They may be applied to any representation of the system (requirements, design, configuration data, test data, etc.). There are three major advantages of inspection over testing: 1. During testing, errors can mask or hide other errors. Once one error is discovered, we can never be sure if other output anomalies are due to a new error or are side effects of the original error. A single inspection session can discover many errors in a system. 2. Incomplete versions of a system can be inspected without additional costs. If a program is incomplete, then you need to develop specialized test harnesses to test the parts that are available. This adds to the system development costs. 3. As well as searching for program defects, an inspection can also consider broader quality attributes of a program such as compliance with standards, portability and maintainability. We can look for inefficiencies, inappropriate algorithms and poor programming style that could make the system difficult to maintain and update. Inspections and testing are complementary and not opposing verification techniques. Both should be used during the V & V process. Inspections can check conformance with a specification but not conformance with the customers real requirements. Inspections cannot check non-functional characteristics such as performance, usability, etc. The program inspection process Program inspections are reviews whose objective is program defect detection. The key difference between program inspections and other types of quality review is that the specific goal of inspections is to find program defects rather than to consider broader design issues. The program inspection is a formal process that is carried out by a team of at least four people. Team members analyze the code and point out possible defects. In Fagans original proposals, he suggested roles such as author, reader, tester and moderator. The reads the code aloud to the inspection team, the tester inspects the code from a testing perspective and the moderator organizes the process. Figure below shows the different roles. The inspection team moderator is responsible for inspection planning. This involves selecting an inspection team, organizing a meeting room and ensuring that the material to be inspected and its specifications are complete. The program to be inspected is presented to the inspection team during the overview stage when the author of the code describes what the program is intended to do. This is followed by a period of individual preparation. Each inspection team member studies the specification and the program and looks for defects in the code.
149
Following the inspection, the programs author should make changes to it to correct the identified problems. In the follow-up stage, the moderator should decide whether a reinspection of the code is required. He or she may decide that a complete reinspection is not required and that the defects have been successfully fixed. The program is then approved by the moderator for release. Figure below shows the inspection process.
Pla n n in g Ove rv iew In d iv id ua l pr e pa ra tio n R e w o rk In spe c tio n m e e tin g F o llo w -up
Inspection Rate 500 statements/hour during overview. 125 source statement/hour during individual preparation. 90-125 statements/hour can be inspected. Inspection is therefore an expensive process. Inspecting 500 lines costs about 40 man/hours effort. Inspection check-lists Checklist of common errors should be used to drive the inspection. Error checklists are programming language dependent and reflect the characteristic of errors that are likely to arise in the language. In general, the 'weaker' the type checking, the larger the checklist. Examples: Initialisation, Constant naming, loop termination, array bounds, etc. A list of inspection check list is shown below.
150
Automated Static Analysis Static analysers are software tools for source text processing. They parse the program text and try to discover potentially erroneous conditions and bring these to the attention of the V & V team. They are very effective as an aid to inspections - they are a supplement tool but not a replacement for inspections. The intention of automatic static analysis is to draw an inspectors attention to anomalies in the program, such as variables Aparna K, Dept. of MCA, BMSIT 151
Software Engineering that are used without initialization, variables that are unused or data whose value could go out of range. Some of the checks that can be detected by static analysis are shown below.
The stages involved in static analysis include: Control flow analysis: Checks for loops with multiple exit or entry points, finds unreachable code, etc. Data use analysis: Detects uninitialized variables, variables written twice without an intervening assignment, variables which are declared but never used, etc. Interface analysis: Checks the consistency of routine and procedure declarations and their use. Information flow analysis: Identifies the dependencies of output variables. Does not detect anomalies itself but highlights information for code inspection or review Path analysis: Identifies paths through the program and sets out the statements executed in that path. Again, potentially useful in the review process
Use of static analysis Particularly valuable when a language such as C is used which has weak typing and hence many errors are undetected by the compiler. Less cost-effective for languages like Java that have strong type checking and can therefore detect many errors during compilation. A static analyser called LINT can be used for C programming in Unix/ Linux environment. Aparna K, Dept. of MCA, BMSIT 152
Software Engineering Verification and Formal methods Formal methods can be used when a mathematical specification of the system is produced. They are the ultimate static verification technique. They involve detailed mathematical analysis of the specification and may develop formal arguments that a program conforms to its mathematical specification. Producing a mathematical specification requires a detailed analysis of the requirements and this is likely to uncover errors. They can detect implementation errors before testing when the program is analyzed alongside the specification. Arguments against formal methods Require specialized notations that cannot be understood by domain experts. It is very expensive to develop a specification and even more expensive to show that a program meets that specification. It may be possible to reach the same level of confidence in a program more cheaply using other V & V techniques. Cleanroom software development The name is derived from the 'Cleanroom' process in semiconductor fabrication. The philosophy is defect avoidance rather than defect removal. A model of the cleanroom process is shown in figure below.
The objective of this approach to software development is zero-defect software. This approach is based on five key strategies. 1. Formal Specification: The software to be developed is formally specified. A state transition model that shows system responses to stimuli is used to express the specification. 2. Incremental development: The software is partitioned into increments that are developed and validated separately using the Cleanroom process. These increments are specified, with customer input, at an early stage in the process. 3. Structured programming: Only a limited number of control and data abstraction constructs are used. The program development process is a process of stepwise refinement of the specification. A limited number of constructs are used Aparna K, Dept. of MCA, BMSIT 153
Software Engineering and the aim is to systematically transform the specification to create the program code. 4. Static verification: The developed software is statically verified using rigorous software inspections. There is no unit or module testing process for code components. 5. Statistical testing of the system: The integrated software increment is tested statistically to determine its reliability. These statistical tests are based on an operational profile, which is developed in parallel with the system specification. There are three teams involved when the cleanroom process is used for large system development: Specification team: Responsible for developing and maintaining the system specification. Development team: Responsible for developing and verifying the software. The software is NOT executed or even compiled during this process. Certification team: Responsible for developing a set of statistical tests to exercise the software after development. Advantages of Cleanroom development: Enhanced quality of software Comparable cost with conventional development Static verification is cost effective Reduced testing efforts Development schedule can be easily maintained
Disadvantages: It is confined to technologically advanced organizations Skilled and committed staff are required It relies on heavy usage of statistical techniques
Cleanroom process evaluation The results of using the Cleanroom process have been very impressive with few discovered faults in delivered systems. Independent assessment shows that the process is no more expensive than other approaches. There were fewer errors than in a 'traditional' development process. However, the process is not widely used. It is not clear how this approach can be transferred to an environment with less skilled or less motivated software engineers.
154
Software Testing
System testing Component testing Test case design Test automation
Software testing Testing is a process of executing a program with intent of finding an error. The testing objectives are to prove that the requirements specifications from which the software was designed, are correct (software meets customers requirements) and to prove that the design and coding correctly respond to the requirements (software conforms to its specifications). A more abstract view of the software testing is shown in figure below:
C o m po ne nt te sting S o ftw are de ve lo pe r
Sy ste m te sting Inde pe nde nt te sting te am
The two fundamental testing activities are component testing testing the parts of the system and system testing testing the system as a whole. A general model of the testing process is shown in figure below.
Te st c a se s
Te st d ata
Te st re su lts
Te s t re p o rts
De s ig n te s t c a se s
Pre p a re te s t d ata
R u n p ro g ra m w ith te st d ata
Co m p a e r re s u lts to te s t c a se s
Test cases are specifications of the inputs to the test and the expected output from the system plus a statement of what is being tested. Test data are the inputs that have been devised to test the system. Test data can sometimes be generated automatically. Automatic test case generation is impossible. The output of the tests can only be predicted by people who understand what the system should do. Exhaustive testing, where every possible program execution sequence is tested, is impossible. Testing, therefore, has to be based on a subset of possible test cases. Testing policies define the approach to be used in selecting system tests: All functions accessed through menus should be tested Combinations of functions accessed through the same menu should be tested Aparna K, Dept. of MCA, BMSIT 155
Software Engineering Where user input is required, all functions must be tested with correct and incorrect input
System Testing System testing involves integrating two or more components that implement system functions or features and then testing this integrated system. In an iterative development process, system testing is concerned with testing an increment to be delivered to the customer; in a waterfall process, system testing is concerned with testing the entire system. There are two distinct phases to system testing: 1. Integration testing, where the test team has access to the source code of the system. When a problem is discovered, the integration team tries to find the source of the problem and identify the components that have to be debugged. 2. Release testing, where a version of the system that could be released to users is tested. Here, the test team is concerned with validating that the system meets its requirements and with ensuring that the system is dependable. Release testing is usually black-box testing where the test team is simply concerned with demonstrating that the system does or does not work properly. Integration Testing The process of system integration involves building a system from its components and testing the resultant system for problems that arise from component interactions. The components that are integrated may be off-the-shelf components, reusable components that have been adapted for a particular system or newly developed components. System integration involves identifying clusters of components that deliver some system functionality and integrating these by adding code that makes them work together. Sometimes, the overall skeleton of the system is developed first, and components are added to it. This is called top-down integration. Alternatively, we may first integrate infrastructure components that provide common services, such as network and database access, and then add the functional components. This is bottom-up integration. A major problem that arises during integration testing is localizing errors. There are complex interactions between the system components and, when an anomalous output is discovered, we may find it hard to identify where the error occurred. To make it easier to locate errors, we should always use an incremental approach to system integration and testing. An example of incremental integration testing is shown below.
156
A A T1 A T2 B T3 C T4 D T e st se que nc e 1 T e st se q ue nc e 2 T e st se que nc e 3 T5 B T3 C T4 T2 B T3 T1 T2 T1
Release Testing Release testing is the process of testing a release of the system that will be distributed to customers. The primary goal of this process is to increase the suppliers confidence that the system meets its requirements. If so, it can be released as a product or delivered to the customer. To demonstrate that the system meets its requirements, we have to show that it delivers the specified functionality, performance and dependability, and that it does not fail during normal use. Release testing is usually a black-box testing process where the tests are derived from the system specification. The system is treated as a black box whose behavior can only be determined by studying its inputs and the related outputs. Another name for this is functional testing because the tester is only concerned with the functionality and not the implementation of the software. Figure below illustrates such a model.
Inputs c a using a no m a lo us b e ha v io ur
Input te st da
ta
I e
S y ste m
Output te st r
e sults
Oe
Outputs w hic h r e ve a l the pr e se nc e o f de fe c ts
157
Software Engineering Testing guidelines are hints for the testing team to help them choose tests that will reveal defects in the system Choose inputs that force the system to generate all error messages Design inputs that cause buffers to overflow Repeat the same input or input series several times Force invalid outputs to be generated Force computation results to be too large or too small Performance testing Part of release testing may involve testing the emergent properties of a system, such as performance and reliability. An operational profile is generated which an actual working is set of requirements of the system. Performance tests usually involve planning a series of tests where the load is steadily increased until the system performance becomes unacceptable. Stress testing Stress testing exercises the system beyond its maximum design load. It is testing on minimal configuration at peak load. Defect detection Stressing the system often causes defects to come to light. Failure behaviour Stress testing checks for unacceptable loss of service or data. Systems should not fail catastrophically Stress testing is particularly relevant to distributed systems that can exhibit severe degradation as a network becomes overloaded. Component Testing Component or unit testing is the process of testing individual components in isolation. It is a defect testing process. Components may be: Individual functions or methods within an object Object classes with several attributes and methods Composite components with defined interfaces used to access their functionality An object class testing could include: Testing all operations associated with an object Setting and interrogating all object attributes Exercising the object in all possible states Inheritance makes it more difficult to design object class tests as the information to be tested is not localised. For example, consider the weather station object interface shown below. It has only a single attribute, which is its identifier. This is a constant that is set when the weather station is installed. Aparna K, Dept. of MCA, BMSIT 158
We a th e r Sta tio n id e n tif ie r re po r tWe a th e r () c a lib r a te (in s tr u m e n ts ) te s t () s ta rtu p (in s tr u m e n ts ) s h u td o w n (in s tr u m e n ts )

We therefore only need to a test that checks whether is has been set up. We need to define test cases for reportWeather, calibrate, test, startup, and shutdown. Using a state model, identify sequences of state transitions to be tested and the event sequences to cause these transitions For example: Waiting -> Calibrating -> Testing -> Transmitting -> Waiting Interface testing Objectives are to detect faults due to interface errors or invalid assumptions about interfaces. It is particularly important for object-oriented development as objects are defined by their interfaces.
There are different types of interfaces between program components and, consequently different types of interface errors that can occur: 1. Parameter interfaces: These are interfaces where data or sometimes function references are passed from one component to another. 2. Shared memory interfaces: These are interfaces where a block of memory is shared between components. Data is placed in the memory by one sub-system and retrieved from there by other sub-systems. 3. Procedural interfaces: These are interfaces where one component encapsulates as a set of procedures that can be called by other components. Objects and reusable components have this form of interface. Aparna K, Dept. of MCA, BMSIT 159
Software Engineering 4. Message passing interfaces: These are interfaces where one component requests a service from another component by passing a message to it. A return message includes the results of executing the service. Interface errors fall into three classes: 1. Interface misuse: A calling component calls some other component and makes an error in the use of its interface. This type of error is particularly common with parameter interfaces where parameters may be of the wrong type, may be passed in the wrong order or the wrong number of parameters may be passed. 2. Interface misunderstanding: A calling component misunderstands the specification of the interface of the called component and makes assumptions about the behavior of the called component. The called component does not behave as expected and this causes unexpected behavior in the calling component. 3. Timing errors: These occur in real-time systems that use a shared memory or a message-passing interface. The producer of data and the consumer of data may operate at different speeds. Unless particular care is taken in the interface design, the consumer can access out-of-date information because the producer of the information has not updated the shared interface information. Some general guidelines for interface testing are: Design tests so that parameters to a called procedure are at the extreme ends of their ranges. Always test pointer parameters with null pointers. Design tests which cause the component to fail. Use stress testing in message passing systems. In shared memory systems, vary the order in which components are activated. Test case design This involves designing the test cases (inputs and outputs) used to test the system. The goal of test case design is to create a set of tests that are effective in validation and defect testing. Some of the test cases design approaches are: Requirements-based testing Partition testing Structural testing Requirements-based testing A general principle of requirements engineering is that requirements should be testable. Requirements-based testing is a validation testing technique where you consider each requirement and derive a set of tests for that requirement. Consider as an example, the requirements for the LIBSYS system:
The user shall be able to search either all of the initial set of databases or select a subset from it.
160
The system shall provide appropriate viewers for the user to read documents in the document store. Every order shall be allocated a unique identifier (ORDER_ID) that the user shall be able to copy to the accounts permanent storage area.
Possible tests for these requirements could be as follows: Initiate user search for searches for items that are known to be present and known not to be present, where the set of databases includes 1 database. Initiate user searches for items that are known to be present and known not to be present, where the set of databases includes 2 databases Initiate user searches for items that are known to be present and known not to be present where the set of databases includes more than 2 databases. Select one database from the set of databases and initiate user searches for items that are known to be present and known not to be present. Select more than one database from the set of databases and initiate searches for items that are known to be present and known not to be present. Partition Testing Input data and output results often fall into different classes where all members of a class are related. Each of these classes is an equivalence partition or domain where the program behaves in an equivalent way for each class member. Test cases should be chosen from each partition. Equivalence Partitioning: It is not possible to check each and every data. Divide all input data into groups which are related. These groups are equivalence classes. This technique is equivalence portioning. Tester needs to run one or few tests for each equivalence class i.e. representative members of class. In the below figure, each equivalence partition is shown as an ellipse. Input equivalence partitions are sets of data where all of the set members should be processed in an equivalent way. Output equivalence partitions are program outputs that have common characteristics, so they can be considered as a distinct class. We also identify partitions where the inputs are outside the other partitions that we have chosen. These test whether the program handles invalid input correctly. Valid and invalid inputs also form equivalence partitions. Once we have identified the set of partitions, we can choose test cases from each of these partitions. A good rule of thumb for test case selection is to choose test cases on the boundaries of the partitions plus cases close to the mid-point of the partition.
161
I nv alid inputs
V alid inputs
S ystem
O utputs
We identify the partitions by using the program specification or user documentation and, from experience, where we predict the classes of input value that are likely to detect errors. For example, say a program specification states that the program accepts 4 to 8 inputs that are five-digit integers greater than 10,000. Figure below shows the partitions for this situation and possible test input values.
To illustrate the derivation of test cases, consider the specification of a search component shown below.
162
Software Engineering The input partitions could be as follows: Inputs which conform to the pre-conditions. Inputs where a pre-condition does not hold. Inputs where the key element is a member of the array. Inputs where the key element is not a member of the array.
Sequence Single value Single value More than 1 value More than 1 value More than 1 value More than 1 value Input sequence (T) 17 17 17, 29, 21, 23 41, 18, 9, 31, 30, 16, 45 17, 18, 21, 23, 29, 41, 38 21, 23, 29, 33, 38 Element In sequence Not in sequence First element in sequence Last element in sequence Middle element in sequence Not in sequence Key (Key) 17 0 17 45 23 25 Output (Found, L) true, 1 false, ?? true, 1 true, 7 true, 4 false, ??
Structural Testing Sometime it is called white-box testing or glass box testing. It is based on derivation of test cases is based on program structure. Knowledge of the program is used to identify additional test cases. Objective is to exercise all program statements (not all path combinations). It is as shown below.
T e s td a t a
T e s t s
D e r i v e s C o m p o n e n t c o d e T e s t o u t p u t s
As an example, consider the following binary search routine. The equivalence classes can be shown as below.
E qui v alence class boundaries
E lem ents < M id
E lem ents > M id
M id-point
163
Software Engineering This leads to a revised set of test cases for the search routine, as shown below.
Input array (T) 17 17 17, 21, 23, 29 9, 16, 18, 30, 31, 41, 45 17, 18, 21, 23, 29, 38, 41 17, 18, 21, 23, 29, 33, 38 12, 18, 21, 23, 32 21, 23, 29, 33, 38 Key (Key) 17 0 17 45 23 21 23 25 Output (Found, L) true, 1 false, ?? true, 1 true, 7 true, 4 true, 3 true, 4 false, ??
Path testing It is structural testing and used in unit testing. Every independent path is tested, thus it is difficult after integration. All conditional statements <Yes, No> are tested. If loop is present, Number of Path is very large, thus not possible to check each path Try to choose input such as each statement is checked All logical paths should be defined. Test cases to execute all logical paths are derived. The starting point for path testing is a program flow graph that shows nodes representing program decisions and arcs representing the flow of control. Statements with conditions are therefore nodes in the flow graph. Cyclomatic Complexity: Flow graphs are used as the basis of cyclomatic complexity. CC (G) = E N + 2 CC (G) = P + 1 No. of logical paths Consider the binary search flow graph below:
1
bot t om > t op
while bot t om < = t op
7 elemA rray [ mid]= k ey 8
elemA rray [ mid]!= k ey elemA rray [ mid ]> k ey 1 2
1 1 elemA rray [ mid]< k ey 1 3
1 4
1 0
164
Software Engineering The flow graph for the binary search procedure is shown in figure above where each node represents a line in the program with an executable statement. The paths through the binary search flow graph are: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14 1, 2, 3, 4, 5, 14 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, 1, 2, 3, 4, 6, 7, 2, 11, 13, 5, If all of these paths are executed, we can be sure that every statement in the method has been executed at least once and that every branch has been exercised for true and false conditions. Test Automation Testing is an expensive process phase. Testing workbenches provide a range of tools to reduce the time required and total testing costs. Scripts may be developed for user interface simulators and patterns for test data generators. Test outputs may have to be prepared manually for comparison. Special-purpose file comparators may be developed. Figure below shows some of the tools that might be included in a testing workbench.
T e s t da ta g e n e ra t o r S p e c ifi c a ti o n
S ou r c e c o d e
T e s t m a n a g e r
T e s t da ta
O ra c l e
D yn a m ic a n a ly s e r
P ro g ra m b e in g te s te d
T e s t re s u l ts
T e s t pr e d ic t io n s
E xe c u ti o n re p o rt
S im u l a to r
F il e c o m p a ra t o r
R e p o rt g e n e ra t o r
T e s t re s ul ts re p o rt
Test Manager It manages running of program tests. It keeps track of test data, expected results and program functionalities tested. Test data generator It generates test data for the program to be tested. Oracle It predicts expected results. File comparator It compares the program test results with results of Oracle and reports the difference. 165
Software Engineering Report Generator It provides report generation facilities for test results Dynamic analyzer It presents an execution profile showing how each program statement has been executed. Simulator Testing workbenches may include different types of simulator such as target simulators, simulators for input/output, user interface simulators.
166
QUESTION BANK FOR CHAPTER VII (Verification and Validation)

1. Describe software verification and software validation. How they are achieved? 2. Explain the debugging process in detail. 3. Explain V & V Planning. 4. What is meant by Software Inspection? What are the advantages of inspection over testing? 5. Explain the program inspection process in detail. 6. Explain the various stages involved in automated static analysis. 7. Write in detail about Cleanroom software development. 8. Give and explain with a neat diagram the model of the software testing process. 9. Compare top-down and bottom-up integration testing strategies. 10. Write in detail about Black-Box testing. 11. Write a note on Performance testing. 12. Explain Component testing. 13. Explain Interface Testing. 14. Define black box testing and white box testing. What is the difference between the two? 15. Distinguish between Defect Testing and Statistical testing. 16. Explain Partition testing with suitable example. 17. What is Path Testing? Explain and bring out the concept of cyclomatic complexity and its use in path testing. 18. Write a note on Structural testing with suitable example. 19. Write a note on a) Test Automation b) Stress Testing
167
Chapter VIII Management

Selecting staff Motivating people Managing groups The people capability maturity model
People Management People are vital for effective functioning of organization thus most important assets of organisation. The tasks of a manager are essentially people-oriented. There should be good understanding of people for successful management. In presence of poor management of people, project failure is likely to happen. Four critical factors in people management are: 1. Consistency: People in a project team should all be treated in a comparable way. While no one expects all rewards to be identical, people should not feel that their contribution to the organization is undervalued. 2. Respect: Different people have different skills and managers should respect these differences. All members of the team should be given an opportunity to make a contribution. In some cases, people simply do not fit into a team and cannot continue, but it is important not to jump to conclusions about this. 3. Inclusion: People contribute effectively when they feel that others listen to them and take account of their proposals. It is important to develop a working environment where all views, even those of the most junior staff, are considered. 4. Honesty: As a manager, we should always be honest about what is going well and what is going badly in the team. We should be honest about our level of technical knowledge and be willing to defer to staff with more knowledge when necessary. If we are less than honest, we will eventually be found out and will lose the respect of the group. Selecting staff One of the most important project management tasks is team selection. The decision on who to appoint to a project is usually made using three types of information: 1. Information provided by candidates about their background and experience (their resume or CV). This is usually the most reliable evidence that you have available to judge whether candidates are likely to be suitable. 2. Information gained by interviewing candidates. Interviews can give a good impression of whether a candidate is a good communicator and whether he or she has good social skills. Tests have been shown that interviewers are liable to accept or reject candidates on the basis of rapid subjective judgments. Interviews are not a reliable method for making judgments of technical capabilities.
168
Software Engineering 3. Recommendations from people who have worked with the candidates. This can be effective when you know the people making the recommendation. Otherwise, the recommendations cannot be trusted. Factors affecting staff selection
169
Software Engineering Motivating People Motivation is an art of accomplishing organizational goals by encouraging, inspiring, simulating the people through enlightened leadership. Thus, a important role of a manager is to motivate the people working on a project. Motivation is a complex issue but different types of motivation are based on: Basic needs (e.g. food, sleep, etc.); Personal needs (e.g. respect, self-esteem); Social needs (e.g. to be accepted as part of a group). Human needs hierarchy (Maslows theory)
People working in software development organizations are not usually hungry or thirsty and generally do not feel physically threatened by their environment. Therefore, ensuring the satisfaction of social, esteem and self-realization needs is most significant from a management point of view. 1. To satisfy social needs, we need to give people time to meet their co-workers and to provide places for them to meet. This is relatively easy when all of the members of a development team work in the same place but, team members are not located in the same building or even the same town or state. They may work for different organizations or from home most of the time. Electronic communications such as e-mail and teleconferencing may be used. 2. To satisfy esteem needs, we need to show people that they are valued by the organization. Public recognition of achievements is a simple yet effective way of doing this. People must also feel that they are paid at a level that reflects their skills and experience. 3. To satisfy self-realization needs, we need to give people responsibility for their work, assign them demanding (but not impossible) task and provide a training programme where people can develop their skills.
170
Software Engineering There are also some drawbacks of Maslows theory. The theory is highly subjective. People may not be driven by compulsion of basic needs. People may be influenced by the work of a dedicated group of people. Motivation should take into account different personality types: Task-oriented Self-oriented Interaction-oriented Task-oriented Motivated by their own work, such as intellectual challenge of software development.(complex and highly intellectual work) Self-oriented Motivated by personal success and recognition. For these people software development is a mean of achieving their own goals. Interaction-oriented The principal motivation is the presence and actions of co-workers. Each individuals motivation is made up of elements of each class, but one will be dominating. Personality is not static. e.g. Task oriented if not rewarded and no recognition, becomes self-oriented. People are motivated not only by personal needs but also by goals of their group coworkers. Managing groups Most professional software is developed by project teams ranging in size from two to several hundred people. However, as it is clearly impossible for all these people to work together on a single problem, these large teams are usually split into a number of groups. Each group is responsible for part of the overall system. As a general rule, software engineering project groups should normally have no more than eight or ten members. When small groups are used, communication problems are reduced. There are a number of factors that influence group working: Group composition Right balance of technical skills, experiences and personalities Group cohesiveness Thinking for group, not for individual Group communications Effective communication necessary Group organization Feeling of being important and satisfied in their role
Group Composition Group composed of members who share the same motivation can be problematic. A group that has complementary personalities may work better than a group selected solely Aparna K, Dept. of MCA, BMSIT 171
Software Engineering on technical ability. People who are motivated by the work are likely to be the strongest technically. People who are self-oriented will probably be best at pushing the work forward to finish the job. People who are interaction-oriented help facilitate communications within the group. The group leader has an important role. He or she may be responsible for providing technical direction and project administration. Group leaders must keep track of the dayto-day work of their group, ensure that people are working effectively and work closely with project managers on project planning. Sometimes it is effective to separate technical leadership and project administration. People who are technically competent are not always the best administrators. Being given an administrative role can reduce their overall value to the group. It is best to support them with an administrator who can relieve them of day-to-day tasks. Group Cohesiveness In a cohesive group, members think of the group as more important than the individual in it. Members of a well-led, cohesive group are loyal to the group. They identify with group goals and with other group members. They attempt to protect the group, as an entity, from outside interference. This makes the group robust and able to cope with problems and unexpected situations. The advantages of a cohesive group are: Establishment of group quality standards Group quality standards can be developed by consensus Intimate working environment Group members work closely together so inhibitions caused by ignorance are reduced Transparency in the work Team members learn from each other and get to know each others work Egoless programming Members strive to improve each others programs can be practised Egoless programming is a style of group working where designs, programs and other documents are regarded as group property rather than personal. One members work is inspected by others. Without any ego people should be ready for criticism to improve programming. Advantages Improves quality of work Improves communication among people Facilitates healthy interaction Creates team spirit Cohesiveness is influenced by factors such as the organisational culture and the personalities in the group. Cohesiveness can be encouraged through Social events like family get-together Aparna K, Dept. of MCA, BMSIT 172
Software Engineering Developing a group identity and territory Explicit team-building activities like games, cultural events Openness with information is a simple way of ensuring all group members feel part of the group. Some drawbacks of group cohesiveness are: Irrational resistance to a leadership change Group members tend to be loyal to cohesive groups. Replacing existing leader may be difficult by person from outside the organisation. 'Groupthink' syndrome It is preservation of group irrespective of technical or organizational considerations. Management should act positively to avoid groupthink by forcing external experts involvement with each group.
Group Communications Good communications are essential for effective group working. Information must be exchanged on the status of work, design decisions and changes to previous decisions. Good communications also strengthens group cohesion as it promotes understanding. Some key factors that influence the effectiveness of communication are: 1. Group size: As a group increases in size, ensuring that all members communicate effectively with each other becomes more difficult. The number of one-way communication links is n * (n 1), where n is the group size. 2. Group structure: People in informally structured groups communicate more effectively than people in groups with a formal, hierarchical structure. In hierarchical groups, communications tend to flow up and down the hierarchy. People at the same level may not talk to each other. This is a particular problem in a large project with several development groups. When people working on different sub-systems communicate only through their managers, the project may suffer delays and misunderstandings. 3. Group composition: People with same personality types may clash and communications may be inhibited. Communication is also usually better in mixed-gender groups than in single-gender groups. Women tend to be more interaction-oriented than men and may act as interaction controllers and facilitators for the group. 4. The physical work environment: The organization of the workplace is a major factor in facilitating or inhibiting communications. Group organization Small programming groups are usually organized in a fairly informal way. The group leader gets involved in the software development with the other group members. A technical leader may emerge who effectively controls software production. In an informal group, the work to be carried out is discussed by the group as a whole, and tasks
173
Software Engineering are allocated according to ability and experience. More senior group members may be responsible for the architectural design. Informal groups can be very successful, particularly when the majority of group members are experienced and competent. Such a group makes decisions by consensus, which improves group spirit, cohesiveness and performance. If a group is composed mostly of inexperienced or incompetent members, informality can be a hindrance because no definite authority exists to direct the work, causing a lack of coordination between group members and, possibly, eventual project failure. To make the make most effective use of highly skilled programmers, teams should be built around an individual, highly skilled chief programmer. The underlying principle of the chief programmer team is that skilled and experienced staff should be responsible for all software development. They should not be concerned with routine matters and should have good technical and administrative support for their work. They should focus on the software to be developed and should not get involved in external meetings. But the serious problem is it is over-dependent on the chief programmer and their assistant. Other team members, who are not given sufficient responsibility, become unmotivated because they feel their skills are underused. Working Environments The physical workplace provision has an important effect on individual productivity and satisfaction. Health and safety considerations must be taken into account such as Comfort Privacy Facilities Lighting Heating & cooling Furniture The most important environmental factors identified in the design study are: Privacy Each engineer requires an area for uninterrupted work Outside awareness People prefer to work in natural light and environment Personalization Individuals adopt different working practices and like to organize their working environment in their own ways Workspaces should provide private spaces where people can work without interruption. Providing individual offices for staff has been shown to increase productivity. However, teams working together also require spaces where formal and informal meetings can be held. Grouping individual offices round larger group meeting rooms is considered one of the best ways to reconcile some of the conflicting requirements. An office layout is shown below.
174
M e e ting ro o m W indo w
Offic e Offic e Of fic e Of fic e
C o m m unal are a
Of fic e Of fic e Offic e Offic e
S ha r e d do c um e nta tio n
The People Capability Maturity Model The P-CMM is intended as a framework for managing the development of people involved in software development. It is a five stage model.
O ptim izing C ontinuously im prove m e thods for de ve loping pe rsonal and organisational com pe te nce M ana Q uantitatively m anage organisational g row th in workforce capabilities and establish com pe te ncy-base d team s ged C ontinuous workforce innovation C oaching Pe rsonal com petency de velopm e nt
O rganisational per form ance alignm ent O rganisational c om pe tency m anage m e nt T e am -base d practice s T e am building M e ntoring D e fine d Par ticipatory culture C om pete ncy-base d practice s C are e r de ve lopm e nt C om pete ncy de ve lopm ent W orkforce planning K nowledge and skills analysis
I dentify prim ary com pe te ncie s and align workforce activitie s with them
I nstill basic discipline into workforce activitie s
R e pe a
ta b le
C om pensation Training Pe r form ance m anagem ent S taffing C om m unication W ork environm e nt
I nitial
175
Software Engineering The five levels are: 1. Initial: Ad hoc, informal people management practices 2. Repeatable: Establishment of policies for developing the capability of the staff 3. Defined: Standardization of best people management practice across the organization 4. Managed: Quantitative goals for people management 5. Optimizing: Continuous focus on improving individual competence and workforce motivation The objectives of the P-CMM are: 1. To improve the quality of software organizations by increasing the capability of their workforce. 2. To ensure that software development capability is an attribute of the organization rather than of a few individuals. 3. To align the motivation of individuals with that of the organization. 4. To retain valuable human assets within the organization.
176
Software Cost Estimation

Software productivity Estimation techniques Algorithmic cost modelling Project duration and staffing
Software Productivity It is the measure of the rate at which individual engineers involved in software development produce software and associated documentation. Quality assurance is a factor in productivity assessment. Productivity estimates are usually based on measuring attributes of the software and dividing this by the total effort required for development. There are two types of metric that have been used: 1. Size-related metrics: These are related to the size of some output from an activity. The most commonly used size-related metric is lines of delivered source code. Other metrics that may be used are the number of delivered object code instructions or the number of pages of system documentation. 2. Function-related metrics: These are related to the overall functionality of the delivered software. Productivity is expressed in terms of the amount of useful functionality produced in some given time. Function points and object points are the best-known metrics of this type. A line of source code per programmer month (LOC/pm) is widely used software productivity metric. This can be computed by counting the total number of lines of source code that are delivered, then divide the count by the total time in programmermonths required to complete the project. This time therefore includes the time required for all other activities involved in software development. Comparing productivity across programming languages can also give misleading impressions of programmer productivity. The more expressive the programming language, the lower the apparent productivity. This anomaly arises because all software development activities are considered together when computing the development time, but the LOC metric applies only to the programming process. Therefore, if one language requires more lines than another to implement the same functionality, productivity estimates will be anomalous. An alternative to using code size as the estimated product attribute is to use some measure of the functionality of the code. This avoids the above anomaly, as functionality is independent of implementation language. Productivity is expressed as the number of function points that are implemented per person-month. A function point is not a single characteristic but is composed by combining several different measurements or estimates. We compare the total number of function points in a program by measuring or estimating the following program features: external inputs and outputs, user interactions, external interfaces and files used by the system.
177
Software Engineering A weight is associated with each of these and the unadjusted function point count (UFC) is computed by multiplying each raw count by the weight and summing all values.
The function point count is modified by complexity of the project. FPs can be used to estimate LOC depending on the average number of LOC per FP for a given language. AVC is a language-dependent factor varying from 200-300 for assembly language to 240 for a 4GL. FPs are very subjective and depends on the estimator. Object points are an alternative to function points. Object points are NOT the same as object classes. The number of object points in a program is a weighted estimate of The number of separate screens that are displayed The number of reports that are produced by the system The number of program modules that must be developed to supplement the database code Object points are easier to estimate from a specification than function points as they are simply concerned with screens, reports and programming modules. They can therefore be estimated at a fairly early point in the development process, whereas it is very difficult to estimate the number of lines of code in a system. Some of the factors affecting productivity are as follows:
178
Software Engineering Estimation techniques There is no simple way to make an accurate estimate of the effort required to develop a software system. Initial estimates are based on inadequate information in a user requirements definition. The software may run on unfamiliar computers or use new technology. The people in the project may be unknown. Changing technologies may mean that previous estimating experience does not carry over to new systems Distributed object systems rather than mainframe systems Use of web services Use of ERP or database-centered systems Use of off-the-shelf software Development for and with reuse Development using scripting languages The use of CASE tools and program generators The approaches to cost estimation are shown below. These approaches can be tackled using either a top-down or a bottom-up approach. A top-down approach starts at the system level. We start by examining the overall functionality of the product and how that functionality is provided by interacting sub-functions. The costs of system-level activities such as integration, configuration management and documentation are taken into account.
179
The bottom-up approach, by contrast, starts at the component level. The system is decomposed into components, and we estimate the effort required to develop each of these components. We then add these component costs to compute the effort required for the whole system development. Each method has strengths and weaknesses. Estimation should be based on several methods. Some action should be taken to make more accurate estimates. Pricing to win is a commonly applicable method. This approach may seem unethical and unbusinesslike. However, when detailed information is lacking it may be the only appropriate strategy. The project cost is agreed on the basis of an outline proposal and the development is constrained by that cost. A detailed specification may be negotiated or an evolutionary approach used for system development. Algorithmic cost modeling Cost is estimated as a mathematical function of product, project and process attributes whose values are estimated by project managers: Effort = A * SizeB * M A is a constant that depend on organisational policies and type of software being developed. Size may be length of code or functional estimation as function points or object points B lies between 1 to 1.5 Cost of software does not increase linearly with project size, efforts increase exponentially Additional cost is due to Communication overhead of larger team Higher complexity in management More time required in documents M is a multiplier reflecting product, process and people attributes. Aparna K, Dept. of MCA, BMSIT 180
Software Engineering The most commonly used product attribute for cost estimation is code size. Most models are similar but they use different values for A, B and M. The size of a software system can only be known accurately when it is finished. Several factors influence the final size Use of COTS and components Programming language Distribution of system As the development process progresses then the size estimate become more accurate. The accuracy of the estimates produced by an algorithmic model depends on the system information that is available. As the software process proceeds, more information becomes available so estimates become more and more accurate. If the initial estimate of effort required is x months of effort, this range may be from 0.25x to 4x when the system is first proposed. This narrows during the development process, as shown in the figure below.
4x
2 x
Feasibility
R equirem ents
D esign
C ode
D e live ry
0.5 x
0.2 5 x
The COCOMO model It is an empirical model based on project development experience. It is welldocumented, independent model which is not tied to a specific software vendor. Long history from initial version published in 1981 (COCOMO-81) through various instantiations to COCOMO 2. COCOMO 2 takes into account different approaches to software development, reuse, etc. The first version of the COCOMO model (COCOMO 81) was a three-level model where the levels corresponded to the detail of the analysis of the cost estimate. The first level (basic) provided an initial rough estimate; the second level modified this using a number of project and process multipliers, and the most detailed level produced estimates for different phases of the project. Figure below shows the basic COCOMO formula for different types of projects. The multiplier M reflects product, project and team characteristics. Aparna K, Dept. of MCA, BMSIT 181
COCOMO 81 was developed with the assumption that a waterfall process would be used, all software would be developed from scratch using the languages like C, FORTAN etc.. There have been many changes in software engineering practice like prototyping, reuse, incremental development and COCOMO 2 is designed to accommodate different approaches to software development. COCOMO II supports a spiral model of development and embeds several sub-models that produce increasingly detailed estimates. These can be used in successive rounds of the development spiral. Figure below shows COCOMO II sub-models and where they are used.
Num b e r o f a pplic a tio n po ints B a se d o n Applic a tio n c o m po sitio n m o d e l U se d fo r Pro to ty pe sy ste m s de v e lo pe d using sc ripting , DB pro g ra m m ing e tc .
Num b e r o f func tio n po ints
B a se d o n
Ea rly de sig n m o d e l
U se d fo r
Initia l e ffo rt e stim a tio n b a se d o n sy ste m re q uire m e nts a nd de sig n o ptio ns
Num b e r o f line s o f c o d e re use d o r g e ne ra te d
B a se d o n
R e use m o d e l
U se d fo r
Effo r t to inte g ra te re usa b le c o m po ne nts o r a uto m a tic a lly g e ne ra te d c o de
Num b e r o f line s o f so urc e c o de
B a se d o n
Po st-a rc hite c ture m o de l
U se d fo r
De v e lo pm e nt e ffo r t b a se d o n sy ste m d e sig n spe c ific a tio n
182
Software Engineering The sub-models that are part of COCOMO II model are: 1. An application-composition model: This assumes that systems are created from reusable components, scripting or database programming. It is designed to make estimates of prototype development. Software size estimates are based on application points, and a simple size/productivity formula is used to estimate the effort required. 2. An early design model: This model is used during early stages of the system design after the requirements have been established. Estimates are based on function points, which are then converted to number of lines of source code. The formula follows the standard form with a simplified set of seven multipliers. 3. A reuse model: This model is used to compute the effort required to integrate reusable components and / or program code that is automatically generated by design or program translation tools. It is usually used in conjunction with the post-architecture model. 4. A post-architecture model: Once the system architecture has been designed, a more accurate estimate of the software size can be made. This model uses the standard formula for cost estimation. However, it includes a more extensive set of 17 multipliers reflecting personnel capability and product and project characteristics. The application-composition model This model supports development through reusable components, scripting or database programming. It is designed to make estimate of prototype development. It is based on standard estimates of developer productivity in application (object) points/month. It takes CASE tool use into account. Formula is PM = ( NAP * (1 - %reuse/100 ) ) / PROD PM is the effort in person-months, NAP is the number of application points PROD is the object point productivity. The early design model Estimates can be made after the requirements have been agreed. Based on a standard formula for algorithmic models Effort = A * SizeB * M where M = PERS * RCPX * RUSE * PDIF * PREX * FCIL * SCED A = 2.94 in initial calibration, Size in KSLOC, first function points are estimated then KSLOC from standard tables for different languages. B varies from 1.1 to 1.24 depending on novelty of the project, development flexibility, risk management approaches and the process maturity. Multipliers reflect the capability of the developers, the non-functional requirements, the familiarity with the development platform, etc. Aparna K, Dept. of MCA, BMSIT 183
Software Engineering RCPX - product reliability and complexity RUSE - the reuse required PDIF - platform difficulty PREX - personnel experience PERS - personnel capability SCED - required schedule FCIL - the team support facilities These values are measured on six point scale (1-6)
The reuse model It takes into account black-box code that is reused without change and code that has to be adapted to integrate it with new code. There are two versions of reuse: Black-box reuse Where code is not modified and reused without understanding. Development effort for black box code is taken to be zero. White-box reuse Where code is understood and modified to adapt to integrate with new code or other reused components. Many system include automatically generated source code Program translators generate code from system models where standard templates are embedded in the generator. For generated code: PMauto = (ASLOC * AT/100)/ATPROD ASLOC is the number of lines of automatically generated code AT is the percentage of code automatically generated. ATPROD is the productivity of engineers in integrating this code. When code has to be understood and integrated, equivalent number of lines of source code is estimated. ESLOC = ASLOC * (1-AT/100) * AAM. ESLOC is equivalent number of lines of source code ASLOC is the number of lines of automatically generated code AT is the percentage of code automatically generated. AAM is the adaptation adjustment multiplier computed from the costs of changing the reused code (AAF), the costs of understanding how to integrate the code (SU) and the costs of reuse decision making (AA). AAM = AAF + AA + SU The post-architecture level This uses the same formula as the early design model but with 17 rather than 7 associated multipliers. The code size is estimated as: Number of lines of new code to be developed (LOC) Estimate of equivalent number of lines of new code computed using the reuse model (ESLOC) Aparna K, Dept. of MCA, BMSIT 184
Software Engineering An estimate of the number of lines of code that have to be modified according to requirements changes (difficult to measure) The exponent factor B depends on 5 factors on scale of 0-6, 0 being very high and 6 being very small Precedenteness Development flexibility Architecture/risk resolution Team cohesion Process maturity Then B is calculated by (sum of all the value for five factors/100) + 1.01 The scale factors used in the COCOMO II exponent computation are as follows:
185
Software Engineering A company takes on a project in a new domain. The client has not defined the process to be used and has not allowed time for risk analysis. The company has a CMM level 2 rating. Precedenteness - new project (4) Development flexibility - no client involvement - Very high (1) Architecture/risk resolution - No risk analysis - V. Low .(5) Team cohesion - new team - nominal (3) Process maturity - some control - nominal (3) Scale factor is therefore (4+1+5+3+3)/100 + 1.01 = 1.17 Algorithmic cost models in project planning Algorithmic cost models provide a basis for project planning as they allow alternative strategies to be compared. Embedded spacecraft system Must be reliable Must minimise weight (number of chips) Multipliers on reliability and computer constraints > 1 Cost components Target hardware Development platform Development effort Project duration and staffing As well as effort estimation, managers must estimate the calendar time required completing a project and when staff will be required. Calendar time (TDEV: Development time) can be estimated using a COCOMO 2 formula TDEV = 3 (PM)(0.33+0.2*(B-1.01)) PM is the effort computation and B is the exponent computed as in COCOMO 2 (B is 1 for the early prototyping model). This computation predicts the nominal schedule for the project. The time required is independent of the number of people working on the project. Planned schedule may be shorter or longer than the nominal predicted schedule and can be adjusted as: TDEV = 3 (PM)(0.33+0.2*(B-1.01)) *SCED percentage/100 Staff required cant be computed by deriving the development time by the required schedule. The number of people working on a project varies depending on the phase of the project. The more people who work on the project, the more total effort is usually required. A very rapid build-up of people often correlates with schedule slippage.
186
QUESTION BANK FOR CHAPTER VIII (Management)

1. Illustrate and explain the factors governing staff selection. 2. Explain Maslows theory of hierarchical needs. 3. List and briefly explain the factors that influence group working. 4. Explain how working environment can affect the effective management of people in an organization. 5. What are the issues involved in managing people? How can people be retained? How does PCMM influence higher productivities and motivation for software personnel? 6. What is meant by Software Productivity? Explain the various metrics involved estimating the same. 7. What is software cost estimation? List the different estimation techniques available. 8. Explain Algorithmic Cost Modeling. 9. Explain COCOMO model in detail for software cost estimation. 10. Write a note on Project duration and staffing.
187

Software Engineering Notes

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering Notes

Uploaded by

Copyright:

Available Formats

Software Engineering

FAQs (Frequently Asked Questions) about Software Engineering:

Types of software process model: Aparna K, Dept. of MCA, BMSIT 2

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

QUESTION BANK FOR CHAPTER I (Overview)

Aparna K, Dept. of MCA, BMSIT

Chapter II Critical Systems, Software Processes

Insulin reservoir Needle assem bly

Aparna K, Dept. of MCA, BMSIT

Software Engineering Insulin pump data flow

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Software Engineering Reliability Perception

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Merits Aparna K, Dept. of MCA, BMSIT 32

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Software Design and Implementation

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Function-based CASE Tool Classification

Aparna K, Dept. of MCA, BMSIT

Tools, Workbenches and Environments

Aparna K, Dept. of MCA, BMSIT

QUESTION BANK FOR CHAPTER II (Critical Systems, Software Processes)

Aparna K, Dept. of MCA, BMSIT

Chapter III Requirements

Aparna K, Dept. of MCA, BMSIT

Software Engineering Requirements Readers:

Aparna K, Dept. of MCA, BMSIT

Org a n is a tio n a l re q u ire m e n ts

R e liab ility re q u ire m e n ts

Po rta b ility re q u ire m e n ts

Classification of Non-Functional Requirements Product requirements Organisational requirements 48

Aparna K, Dept. of MCA, BMSIT

Software Engineering External requirements

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT

Aparna K, Dept. of MCA, BMSIT