Q1 : Consider developing a system for Tickets Reservation for Commonwealth Games and perform the followings:
(a) Suggest the most appropriate Software Engineering model for developing this project with appropriate justification.
(b) Write at least two functional and non functional requirements.
(c) Develop a test plan for the system. You can make necessary assumptions and specify them.
(d) Write the risk management plan for the system.
(e) Estimate the efforts of software projects. Make necessary assumptions.
(f) Suppose it was revealed that the poor knowledge of the tool is responsible for the problems that are being encountered for timely completion of the project. Write type of remedies do you suggest for such type of problem ? justify your answer.
(g) Suppose there exists some old systems and wants to replace it, suggest the changes with respect to the software and hardware requirements.
(h) Describe what types of testing strategies/ techniques can be followed for a web based Ticket Reservation System.
(i) Develop a design review plan for the system. Also, list the deficiencies, if any, in the SRS for the same.
Ans :- 1 a
(a) The Linear sequential model re waterfall model is appropriate for Tickets Reservation system. It suggest a systematic, sequential approach to software Develop that begins at the system level and progresses through analysis, design, Coding and testing and support. These steps can be applied in Ticket reservation system in the following manner :
Software requirement analysis : to understand the nature of the program to be Built, the software engineer must understand the information domain for the Software, as well as the required function, behavior, performance and interface.
In a Ticket reservation system, various requirements of the whole system are Viewed. It is determined what are the requirements of the system, who are the users of the system, what are various functions in the system etc. then ER – diagram, Data flow diagram etc are prepared.
Design : Software design is actually a multistep process that focuses on four distinct attributes of a program : data structure, software architecture, interface representations and procedural detail.
Code generation : The code generation the design into machine readable form. If design performed in a detailed manner, code generation can be accomplished mechanically.
Testing : Once the code has been generated, program testing begins. The testing process focuses on the logical internals of the software, ensuring that all statements have been tested and on the functional externals.
Support : Software will undoubtedly undergo change after it is delievered to the customer. Software supports reapplies each of the preceding phases to an exiting program rather than a new one.
The linear sequential model is appropriate for Tickets Reservation system as it follows all the steps necessary for the development of Ticket reservation system. In this system project planning can be made in advance and Ticket reservation system require comparatively less changes at later stage. Moreover in a Ticket reservation system most of the requirements can be stated in earlier stages. It provides templates for which method for analysis, design coding, testing and support can be placed. There is less need to make changes after the system is developed. Therefore waterfall model is appropriate for tickets reservation system.
Ans 1 (b)
A collection of elements which are assembled to fulfill some defined purpose. Elements may be hardware or software components, organizational policies and procedures and operational processes.
Systems have properties which are emergent i.e. they only come to light when the parts are put together, they have structure and mechanisms for communication and control.
Important emergent properties of a system are :-
Ø Performance
Ø Reliability
Ø Safety
Ø Security
Ø Usability
These are non functional properties they do not relate to any specific functionality of the system. Some or all of these properties are usually more important than detailed system functionality,
Physical environment
What are the characteristics of the physical environment in which the system will be installed, what other systems must coexist with it ?
User environment
Will the system be used by training or untrained users; will it be used as part of an individual or a group process ?
Ans 1c
Test plan for student Admission System (SAS) :-
We consider “Logical Module for our purpose :- Since this is a human & Computer interface the number of test associated can be estimate by :
Number of transitions contained in the state transition representation
Number of data object that move across the interface.
number of data element that input or output
As we were testing only one module so unit testing will be performed on the module.
White Box Testing fundas will be applied during modules testing like :-
Module interface test to check proper data in flaw and outflow like username and passport is properly accepted.
Local data structure which is common source of error.
Boundary conditions testing.
Independent path testing.
All error handling paths are tested
Ans 1 (d)
Risk management is the process of measuring or assessing risk and developing strategies to manage it. Strategies include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Traditional risk management focuses on risks stemming from physical or legal causes (e.g. natural disasters or fires, accidents, death, and lawsuits). Financial risk management, on the other hand, focuses on risks that can be managed using traded financial instruments.
In ideal risk management a prioritization process is followed whereby the risks with the greatest loss and greatest probability of occurring are handled first, and risks with lower probability of occurrence and lower loss are handled later. In practice the process can be very difficult, and balancing between risks with a high p Risk management also faces difficulties allocating resources. This is the idea of opportunity cost. Resources spent on risk management could have been spent on more profitable activities. Again, ideal risk management minimizes spending while maximizing the reduction of the negative effects of risks.
Establish the context
Establishing the context involves
Panning the remainder of the process.
Mapping out the following the scope of the exercise, the identity and objectives of stakeholders, and the basis upon which risks will be evaluated.
Defining a framework for the process and an agenda for identification.
Developing an analysis of risk involved in the process.
After establishing the context, the next step in the process of managing risk is to identify potential risks. Risks are about events that, when triggered, cause problems. Hence, risk identification can start with source of problems, or with problem itself.
Source analysis Risk sources may be internal or external to the system that is the target of risk management. Examples of risk sources are : stakeholders of a project, employees of a company or the weather over an airport.
Problem analysis Risk are related to identify threats. For example : the threat of losing money, the threat abuse of privacy information or the threat of accidents and casualties. The threats may exist with various entities, most important with shareholder, customers and legislative bodies such as the government.
Decide on the combination of methods to be used for each risk. Each risk management decision should be recorded and approved by the appropriate level of management . for example, a risk control implementation and responsible persons for those actions . the risk management concept is old but is still not very effectively measured.
Implementation
Follow all of the planned methods for mitigating the effect of the risks. Purchase insurance policies for the risks that have been decided to be transferred to an insurer, avoid al risks that have been decided to be transferred to an insurer, avoid all that can be avoided without sacrificing the entity’s goals, reduce others, and retain the rest.
Review and evaluation of the plan
Initial risk management plans will never be perfect. Practice, experience, and actual loss results will necessitate changes in the plan and contribute information to allow possible different decisions to be made in dealing with the risks being faced.
Risk analysis results and management plans should be updated periodically. There are two primary reasons for this :
1. to evaluate whether the previously selected security controls are still applicable and effective, and
2. to evaluate the possible risk level changes in the business environment. For example, information risks are a good example of rapidly changing business environment.
To properly adopt software Inspections practices, each participant is trained in the structured review process, defined roles of participants, system of process and product checklists, and forms and reports. The lost opportunity cost to acquire the knowledge, skills, and behaviors is twelve hours per practitioner. In addition, each manager is trained in the responsibilities for rolling out the technology and the interpretation and use of measurements taken. The management training is accomplished in four hours.
The cost of performing software Inspections includes the individual preparation effort of each participant before the session and the conduct effort of participants in the inspections session. Typically, 4-5 people participate and expend 1-2 hours of preparation and 1-2 hours of conduct each. This cost of 10 to 20 hours of total effort per session results in the early detection of 5- 10 defects in 250-5—lines of new development code or 1000-1500 lines of legacy.
Ans 1 (f)
The knowledge of all tools required white making of project. Review of the project analysis before starting the project. Before starting the project. Before starting the making project software engineer should the person who is going to make is well aware that the all tools which required making the project. Cost estimated should be under the control. Time limitation should be there so that software will complete on time.
Ans :- 1 (g)
Software Requirements :-
Operating System.
Ms office
The required s/w which we make in platform the s/w
Hardware Requirement :-
Inter P1v Dual core processor
Intel p 1 V Motherboard
Ram 512 MB
HDFD 80 GB
ATX Cabinet
Keyboard
Optical Mouse
Ans 1 (h)
When components are being connected to create large components they have to pass through integration testing, whose main purpose is to detect any inconsistency between the connected components. Once the integration test is completed , a component test will have to be performed on the new component, consisting of several smaller ones. Some properties, however, can be said to belong to the system as a whole, like certain quality attributes. The system, beings a huge component, will hence be tested in its entirety to verify that these requirements are met in a satisfactory way, and this is what is referred to a system testing. Starting with unit testing, then moving on to integration testing before component testing can be performed. Finally, a system test is executed.
Black Box and White Box Testing
When a tester wants to test an application or a particular part of it to detect bugs, he can look at the system from a user’s perspective and expose it to different types of input, and then check whether or not the resulting output is in accordance with the specification. This is know as functional testing or black box testing. With this type of testing, any type of error can be detected, but it would take an infinite amount of time to do so.
Distinctions and elements of Web Applications
15 types of error and refers to memory leaks as a typical example of an error that will escape functional testing.
Web server
Browser
Client Database server
Application code
White box
Black box
Testing
Application data
Structural testing or white box testing, on the other hand, implies studying the program code and testing the different parts of it. This type of testing is not capable of finding all kinds of errors, but to its advantage it is easier to determine when you have tested enough
That white box testing is capable all lines of code when given an finite amount of time, but points out that such testing might not uncover errors with respect to component integration Seem to contradict each other. In spite of this, our interpretation suggests that both of them find a combination of white box and black box testing.
Ans 1 (i)
Software Inspections are a disciplined engineering practice for detecting and correcting defects in software artifacts, and preventing their leakage into filed operations
Experienced software practitioners and managers understand that software development is a process of experimentation involving the continuous discovery of technical information associated with the function, form, and fit of the software product. Software Inspections are an integral practice in the process of experimentation.
Software inspections provide value in improving reliability, availability, and maintainability
(a) Suggest the most appropriate Software Engineering model for developing this project with appropriate justification.
(b) Write at least two functional and non functional requirements.
(c) Develop a test plan for the system. You can make necessary assumptions and specify them.
(d) Write the risk management plan for the system.
(e) Estimate the efforts of software projects. Make necessary assumptions.
(f) Suppose it was revealed that the poor knowledge of the tool is responsible for the problems that are being encountered for timely completion of the project. Write type of remedies do you suggest for such type of problem ? justify your answer.
(g) Suppose there exists some old systems and wants to replace it, suggest the changes with respect to the software and hardware requirements.
(h) Describe what types of testing strategies/ techniques can be followed for a web based Ticket Reservation System.
(i) Develop a design review plan for the system. Also, list the deficiencies, if any, in the SRS for the same.
Ans :- 1 a
(a) The Linear sequential model re waterfall model is appropriate for Tickets Reservation system. It suggest a systematic, sequential approach to software Develop that begins at the system level and progresses through analysis, design, Coding and testing and support. These steps can be applied in Ticket reservation system in the following manner :
Software requirement analysis : to understand the nature of the program to be Built, the software engineer must understand the information domain for the Software, as well as the required function, behavior, performance and interface.
In a Ticket reservation system, various requirements of the whole system are Viewed. It is determined what are the requirements of the system, who are the users of the system, what are various functions in the system etc. then ER – diagram, Data flow diagram etc are prepared.
Design : Software design is actually a multistep process that focuses on four distinct attributes of a program : data structure, software architecture, interface representations and procedural detail.
Code generation : The code generation the design into machine readable form. If design performed in a detailed manner, code generation can be accomplished mechanically.
Testing : Once the code has been generated, program testing begins. The testing process focuses on the logical internals of the software, ensuring that all statements have been tested and on the functional externals.
Support : Software will undoubtedly undergo change after it is delievered to the customer. Software supports reapplies each of the preceding phases to an exiting program rather than a new one.
The linear sequential model is appropriate for Tickets Reservation system as it follows all the steps necessary for the development of Ticket reservation system. In this system project planning can be made in advance and Ticket reservation system require comparatively less changes at later stage. Moreover in a Ticket reservation system most of the requirements can be stated in earlier stages. It provides templates for which method for analysis, design coding, testing and support can be placed. There is less need to make changes after the system is developed. Therefore waterfall model is appropriate for tickets reservation system.
Ans 1 (b)
A collection of elements which are assembled to fulfill some defined purpose. Elements may be hardware or software components, organizational policies and procedures and operational processes.
Systems have properties which are emergent i.e. they only come to light when the parts are put together, they have structure and mechanisms for communication and control.
Important emergent properties of a system are :-
Ø Performance
Ø Reliability
Ø Safety
Ø Security
Ø Usability
These are non functional properties they do not relate to any specific functionality of the system. Some or all of these properties are usually more important than detailed system functionality,
Physical environment
What are the characteristics of the physical environment in which the system will be installed, what other systems must coexist with it ?
User environment
Will the system be used by training or untrained users; will it be used as part of an individual or a group process ?
Ans 1c
Test plan for student Admission System (SAS) :-
We consider “Logical Module for our purpose :- Since this is a human & Computer interface the number of test associated can be estimate by :
Number of transitions contained in the state transition representation
Number of data object that move across the interface.
number of data element that input or output
As we were testing only one module so unit testing will be performed on the module.
White Box Testing fundas will be applied during modules testing like :-
Module interface test to check proper data in flaw and outflow like username and passport is properly accepted.
Local data structure which is common source of error.
Boundary conditions testing.
Independent path testing.
All error handling paths are tested
Ans 1 (d)
Risk management is the process of measuring or assessing risk and developing strategies to manage it. Strategies include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Traditional risk management focuses on risks stemming from physical or legal causes (e.g. natural disasters or fires, accidents, death, and lawsuits). Financial risk management, on the other hand, focuses on risks that can be managed using traded financial instruments.
In ideal risk management a prioritization process is followed whereby the risks with the greatest loss and greatest probability of occurring are handled first, and risks with lower probability of occurrence and lower loss are handled later. In practice the process can be very difficult, and balancing between risks with a high p Risk management also faces difficulties allocating resources. This is the idea of opportunity cost. Resources spent on risk management could have been spent on more profitable activities. Again, ideal risk management minimizes spending while maximizing the reduction of the negative effects of risks.
Establish the context
Establishing the context involves
Panning the remainder of the process.
Mapping out the following the scope of the exercise, the identity and objectives of stakeholders, and the basis upon which risks will be evaluated.
Defining a framework for the process and an agenda for identification.
Developing an analysis of risk involved in the process.
After establishing the context, the next step in the process of managing risk is to identify potential risks. Risks are about events that, when triggered, cause problems. Hence, risk identification can start with source of problems, or with problem itself.
Source analysis Risk sources may be internal or external to the system that is the target of risk management. Examples of risk sources are : stakeholders of a project, employees of a company or the weather over an airport.
Problem analysis Risk are related to identify threats. For example : the threat of losing money, the threat abuse of privacy information or the threat of accidents and casualties. The threats may exist with various entities, most important with shareholder, customers and legislative bodies such as the government.
Decide on the combination of methods to be used for each risk. Each risk management decision should be recorded and approved by the appropriate level of management . for example, a risk control implementation and responsible persons for those actions . the risk management concept is old but is still not very effectively measured.
Implementation
Follow all of the planned methods for mitigating the effect of the risks. Purchase insurance policies for the risks that have been decided to be transferred to an insurer, avoid al risks that have been decided to be transferred to an insurer, avoid all that can be avoided without sacrificing the entity’s goals, reduce others, and retain the rest.
Review and evaluation of the plan
Initial risk management plans will never be perfect. Practice, experience, and actual loss results will necessitate changes in the plan and contribute information to allow possible different decisions to be made in dealing with the risks being faced.
Risk analysis results and management plans should be updated periodically. There are two primary reasons for this :
1. to evaluate whether the previously selected security controls are still applicable and effective, and
2. to evaluate the possible risk level changes in the business environment. For example, information risks are a good example of rapidly changing business environment.
To properly adopt software Inspections practices, each participant is trained in the structured review process, defined roles of participants, system of process and product checklists, and forms and reports. The lost opportunity cost to acquire the knowledge, skills, and behaviors is twelve hours per practitioner. In addition, each manager is trained in the responsibilities for rolling out the technology and the interpretation and use of measurements taken. The management training is accomplished in four hours.
The cost of performing software Inspections includes the individual preparation effort of each participant before the session and the conduct effort of participants in the inspections session. Typically, 4-5 people participate and expend 1-2 hours of preparation and 1-2 hours of conduct each. This cost of 10 to 20 hours of total effort per session results in the early detection of 5- 10 defects in 250-5—lines of new development code or 1000-1500 lines of legacy.
Ans 1 (f)
The knowledge of all tools required white making of project. Review of the project analysis before starting the project. Before starting the project. Before starting the making project software engineer should the person who is going to make is well aware that the all tools which required making the project. Cost estimated should be under the control. Time limitation should be there so that software will complete on time.
Ans :- 1 (g)
Software Requirements :-
Operating System.
Ms office
The required s/w which we make in platform the s/w
Hardware Requirement :-
Inter P1v Dual core processor
Intel p 1 V Motherboard
Ram 512 MB
HDFD 80 GB
ATX Cabinet
Keyboard
Optical Mouse
Ans 1 (h)
When components are being connected to create large components they have to pass through integration testing, whose main purpose is to detect any inconsistency between the connected components. Once the integration test is completed , a component test will have to be performed on the new component, consisting of several smaller ones. Some properties, however, can be said to belong to the system as a whole, like certain quality attributes. The system, beings a huge component, will hence be tested in its entirety to verify that these requirements are met in a satisfactory way, and this is what is referred to a system testing. Starting with unit testing, then moving on to integration testing before component testing can be performed. Finally, a system test is executed.
Black Box and White Box Testing
When a tester wants to test an application or a particular part of it to detect bugs, he can look at the system from a user’s perspective and expose it to different types of input, and then check whether or not the resulting output is in accordance with the specification. This is know as functional testing or black box testing. With this type of testing, any type of error can be detected, but it would take an infinite amount of time to do so.
Distinctions and elements of Web Applications
15 types of error and refers to memory leaks as a typical example of an error that will escape functional testing.
Web server
Browser
Client Database server
Application code
White box
Black box
Testing
Application data
Structural testing or white box testing, on the other hand, implies studying the program code and testing the different parts of it. This type of testing is not capable of finding all kinds of errors, but to its advantage it is easier to determine when you have tested enough
That white box testing is capable all lines of code when given an finite amount of time, but points out that such testing might not uncover errors with respect to component integration Seem to contradict each other. In spite of this, our interpretation suggests that both of them find a combination of white box and black box testing.
Ans 1 (i)
Software Inspections are a disciplined engineering practice for detecting and correcting defects in software artifacts, and preventing their leakage into filed operations
Experienced software practitioners and managers understand that software development is a process of experimentation involving the continuous discovery of technical information associated with the function, form, and fit of the software product. Software Inspections are an integral practice in the process of experimentation.
Software inspections provide value in improving reliability, availability, and maintainability
Technical Detail
Software Inspections are strict and close examinations conducted on requirements, specifications, architectures, designs, code, test plan and procedures, and other artifacts. Leading software indicators of excellence for each artifact type provide the exit criteria for the activities of the software life cycle. For example, these indicators include completeness, correctness, style, rules of construction, and multiple views.
Completeness is based on traceability of the requirements to the code, essential for maintainability. Correctness is based on the clear specification of intended function and its faithful elaboration in code, essential for reliability and availability. Style is based on consistency of resorting, essential for maintainability. Rules of construction are based on the software application architecture and the specific protocols, templates, and conventions used to carry it out, essential for reliability and availability. Multiple views are based on the various perspectives and viewpoints required to be reflected in the software product, essential for maintainability. By detecting defects early and preventing their leakage into subsequent activities, the need for later detection and work (which is essential for reduced cycle time and lower cost ) is eliminated.
Software inspections are a reasoning activity performed by practitioners playing the defined roles of moderator, recorder, reviewer, reader, and producer. Each role carries with it the specific behaviors, skills, and knowledge needed to achieve the expert practice of Software Inspections.
The adoption of software Inspections practice is competency enhancing and meet little resistance among practitioners trained in their use. The adopting organization benefits by improved predictability in cost and schedule performance, reduced cost of development and maintenance, reduced defects, in the filed, increased customer satisfaction, and improved morale among practitioners.
Dependencies
In order for Software Inspections to be systematically used in statistical process control, there must be a life cycle model with defined software artifacts. In this context, software Inspections provide the exit criteria for each life cycle activity. Furthermore, the standard of excellence of leading indicators for each type of artifact must be specified and used in practice.
Q2 : (a) You are browsing a web based application but it is taking too much to open, list
Any five reasons for the same.
Ans 2(a)
To many temporary file can lead the show speed.
Bad Connection.
Pink Break
Site is running slowly for everyone.
Site has too many views so it is being bogged down.
Server Busy
Small bandwidth
RAM size small
Client System busy.
Internet speed slow.
(a) Do you anticipate any situation where usage of Clean room Software Engineering for application development is not appropriate ? Explain your answer.
Clean room software engineering is an engineering and managerial process for like development of high quality software with certified reliability. The name “Clean room” was taken from the electronics industry, where a physical clear room exists to prevent introduction of defects during hardware fabrication. Clean room software engineering reflects the same emphasis on defect prevention rather than defect removal , as well as certification of reliability for the intended environment of use.
The focus of Clean room involves moving from traditional, craft based software development practices to rigorous, engineering based practices. Clean room software engineering yields software that is correct by mathematically sound design, and software that is certified by statistically valid testing. Reduced cycle time results from an incremental development strategy and the avoidance of rework.
Clean room reduces the cost of errors during development and the incidence of failures during operation; thus the overall life cycle cost of software developed under Clean room can be expected to be far lower than industry average.
The following ideas form the foundation for clean room based development :
Incremental development under statistical quality control (SQC). Incremental development as practiced in Clean room provides a basis for statistical quality control of the development process. Each increment is a complete iteration of the process, and measures of performance in each increment are compared with reestablished standards to determine whether or not the process is in control. If quality standards are not met, testing of the increment ceases and development return to the design stage.
Software development based on mathematical principles. In clean room development a key principle is that a computer program is an expression of a mathematical function. The Box Structure method is used for specification and design and functional verification is used to confirm that the is a correct implementation of the specification.
Software testing based on statistical principal. In clean room, software testing is viewed as a statistical experiment. A representative subset of all possible uses of the software is generated, and performance of the subset is used as a basis for conclusion about general operational performance.
Usage considerations
Clean room has been documented to be very effective in new development and reengineering (whole system or major subunits) contexts. The following discussion highlights areas where Clean room affects or differs from more conventional practice :
Team based development. A Clean room project team is small typically six to eight persons, and works in a disciplined fashion to ensure the intellectual control of work in progress. Clean room teamwork involves peer review of individual work, but does not supplant individual creativity. Once the system architecture has been established and the interfaces between subunits have been defined, individuals typically work alone on a given system component. Individual designs are working drafts that then reviewed by the team. In a large project, multiple small teams may be formed, with one for the development of each subsystem, thus enabling concurrent engineering after the top level architecture has been established.
Time allocation across life cycle phases. Because one of the major objectives of clean room is to prevent errors from occurring, the amount of time spent in the design phase of a clean room development is likely to be greater than the amount of time traditionally development to design. Clear room, however, is not a more time consuming development methodology, but its greater emphasis on design and verification often yields that concern. Management understanding and acceptance of this essential point that quality will be achieved by design rather than through testing must be reflected in the development schedule. Design and verification will require the greatest portion of the schedule. Testing may being later and be allocated less time than is ordinarily the case. In large clean room projects, where historical data has enabled comparison of traditional and clean room development schedules, the clean room schedule has equaled or improved upon the usual development time.
Costs and Limitations
Using clean room to accomplish piecemeal, isolated changes to a system not development using clean room is not considered an effective use of this technology. Training is required and commercially available. Available courses range from overviews to a detailed focus on particular aspects of clean room . for some training classes, it is most productive if software manager and technical staff take the training together. Manager need a thorough understanding of clean room imperatives, and a core group of practitioners needs sufficient orientation in clean room practices to be able to adapt the process to the local environment (this includes establishing a local design language, local verification standards, etc.)
2 (c) for what types of applications is the approach of Re Engineering applied ? Explain
your answer.
“Reengineering” is the fundamental rethinking and radical redesign of business professes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality service, and speed.
Seven principles of reengineering
1. Organize around outcomes not tasks.
2. Identify all processes in an organization and prioritize them in order of redesign urgency.
3. integrate information processing work into the real work that produces information.
4. Tread geographically dispersed resources as though they are centralized.
5. Link parallel activities in the workflow instead of just integrating their results.
6. Put the decision point where the work is performed, and build control into the process.
7. Capture information once and at the source.
The Benefits of Reengineering
The hard task of re examining mission and how it is being delivered on a day to day basis will have fundamental impacts on an organization, especially in terms of responsiveness and accountability to customers and stakeholders. Among the many rewards, reengineering :
Empowers employees
Eliminates waste, unnecessary management overhead, and obsolvte or inefficient processes.
Produces often significant reductions in cost and cycle times.
Enables revolutionary improvement in many business processes as measured by quality and customer service
Helps top organizations stay on top and low achievers to become effective competitors.
The Benefits of Reengineering
The hard task of reexamining mission and how it is being delivered on a day to day basis will have fundamental impacts on an organization, especially in terms of responsiveness and accountability to customers and stakeholders. Among the many rewards, reengineering.
Empower employees
Eliminates water, unnecessary management overhead, and obsolete or inefficient processes.
Enables revolutionary improvements in many business processes as measured by quality and customer service.
Help top organizations stay on top and low achievers to become effective competitors.
DOD has suggested that the following six tasks be part of any functional management approach to reengineering projects:
Define the framework . define functional objectives; determine the management strategy to be followed in streamlining and standardizing processes; and establish the process, data and information systems baselines from which to being process improvement.
Analyze. Analyze business process to eliminate non value added processes; simplify and streamline processes of little value; and identify more effective and efficient alternatives to the process, data, and system baselines.
Evaluate. Conduct a preliminary, functional, economic analysis to evaluate alternatives to baseline processes and select a preferred course of action.
Plan. Develop detailed statement of requirements, baseline impacts, costs, benefits, and schedules to implement the planned course of action.
Approve. Finalize the functional economic analysis using information from the planning data, and present to senior management for approval tp proceed with proposed process improvement and any associated data or system changes.
Execute. Execute the approved process process and data changes, and provide functional management oversight of any associated information system changes.
Software Inspections are strict and close examinations conducted on requirements, specifications, architectures, designs, code, test plan and procedures, and other artifacts. Leading software indicators of excellence for each artifact type provide the exit criteria for the activities of the software life cycle. For example, these indicators include completeness, correctness, style, rules of construction, and multiple views.
Completeness is based on traceability of the requirements to the code, essential for maintainability. Correctness is based on the clear specification of intended function and its faithful elaboration in code, essential for reliability and availability. Style is based on consistency of resorting, essential for maintainability. Rules of construction are based on the software application architecture and the specific protocols, templates, and conventions used to carry it out, essential for reliability and availability. Multiple views are based on the various perspectives and viewpoints required to be reflected in the software product, essential for maintainability. By detecting defects early and preventing their leakage into subsequent activities, the need for later detection and work (which is essential for reduced cycle time and lower cost ) is eliminated.
Software inspections are a reasoning activity performed by practitioners playing the defined roles of moderator, recorder, reviewer, reader, and producer. Each role carries with it the specific behaviors, skills, and knowledge needed to achieve the expert practice of Software Inspections.
The adoption of software Inspections practice is competency enhancing and meet little resistance among practitioners trained in their use. The adopting organization benefits by improved predictability in cost and schedule performance, reduced cost of development and maintenance, reduced defects, in the filed, increased customer satisfaction, and improved morale among practitioners.
Dependencies
In order for Software Inspections to be systematically used in statistical process control, there must be a life cycle model with defined software artifacts. In this context, software Inspections provide the exit criteria for each life cycle activity. Furthermore, the standard of excellence of leading indicators for each type of artifact must be specified and used in practice.
Q2 : (a) You are browsing a web based application but it is taking too much to open, list
Any five reasons for the same.
Ans 2(a)
To many temporary file can lead the show speed.
Bad Connection.
Pink Break
Site is running slowly for everyone.
Site has too many views so it is being bogged down.
Server Busy
Small bandwidth
RAM size small
Client System busy.
Internet speed slow.
(a) Do you anticipate any situation where usage of Clean room Software Engineering for application development is not appropriate ? Explain your answer.
Clean room software engineering is an engineering and managerial process for like development of high quality software with certified reliability. The name “Clean room” was taken from the electronics industry, where a physical clear room exists to prevent introduction of defects during hardware fabrication. Clean room software engineering reflects the same emphasis on defect prevention rather than defect removal , as well as certification of reliability for the intended environment of use.
The focus of Clean room involves moving from traditional, craft based software development practices to rigorous, engineering based practices. Clean room software engineering yields software that is correct by mathematically sound design, and software that is certified by statistically valid testing. Reduced cycle time results from an incremental development strategy and the avoidance of rework.
Clean room reduces the cost of errors during development and the incidence of failures during operation; thus the overall life cycle cost of software developed under Clean room can be expected to be far lower than industry average.
The following ideas form the foundation for clean room based development :
Incremental development under statistical quality control (SQC). Incremental development as practiced in Clean room provides a basis for statistical quality control of the development process. Each increment is a complete iteration of the process, and measures of performance in each increment are compared with reestablished standards to determine whether or not the process is in control. If quality standards are not met, testing of the increment ceases and development return to the design stage.
Software development based on mathematical principles. In clean room development a key principle is that a computer program is an expression of a mathematical function. The Box Structure method is used for specification and design and functional verification is used to confirm that the is a correct implementation of the specification.
Software testing based on statistical principal. In clean room, software testing is viewed as a statistical experiment. A representative subset of all possible uses of the software is generated, and performance of the subset is used as a basis for conclusion about general operational performance.
Usage considerations
Clean room has been documented to be very effective in new development and reengineering (whole system or major subunits) contexts. The following discussion highlights areas where Clean room affects or differs from more conventional practice :
Team based development. A Clean room project team is small typically six to eight persons, and works in a disciplined fashion to ensure the intellectual control of work in progress. Clean room teamwork involves peer review of individual work, but does not supplant individual creativity. Once the system architecture has been established and the interfaces between subunits have been defined, individuals typically work alone on a given system component. Individual designs are working drafts that then reviewed by the team. In a large project, multiple small teams may be formed, with one for the development of each subsystem, thus enabling concurrent engineering after the top level architecture has been established.
Time allocation across life cycle phases. Because one of the major objectives of clean room is to prevent errors from occurring, the amount of time spent in the design phase of a clean room development is likely to be greater than the amount of time traditionally development to design. Clear room, however, is not a more time consuming development methodology, but its greater emphasis on design and verification often yields that concern. Management understanding and acceptance of this essential point that quality will be achieved by design rather than through testing must be reflected in the development schedule. Design and verification will require the greatest portion of the schedule. Testing may being later and be allocated less time than is ordinarily the case. In large clean room projects, where historical data has enabled comparison of traditional and clean room development schedules, the clean room schedule has equaled or improved upon the usual development time.
Costs and Limitations
Using clean room to accomplish piecemeal, isolated changes to a system not development using clean room is not considered an effective use of this technology. Training is required and commercially available. Available courses range from overviews to a detailed focus on particular aspects of clean room . for some training classes, it is most productive if software manager and technical staff take the training together. Manager need a thorough understanding of clean room imperatives, and a core group of practitioners needs sufficient orientation in clean room practices to be able to adapt the process to the local environment (this includes establishing a local design language, local verification standards, etc.)
2 (c) for what types of applications is the approach of Re Engineering applied ? Explain
your answer.
“Reengineering” is the fundamental rethinking and radical redesign of business professes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality service, and speed.
Seven principles of reengineering
1. Organize around outcomes not tasks.
2. Identify all processes in an organization and prioritize them in order of redesign urgency.
3. integrate information processing work into the real work that produces information.
4. Tread geographically dispersed resources as though they are centralized.
5. Link parallel activities in the workflow instead of just integrating their results.
6. Put the decision point where the work is performed, and build control into the process.
7. Capture information once and at the source.
The Benefits of Reengineering
The hard task of re examining mission and how it is being delivered on a day to day basis will have fundamental impacts on an organization, especially in terms of responsiveness and accountability to customers and stakeholders. Among the many rewards, reengineering :
Empowers employees
Eliminates waste, unnecessary management overhead, and obsolvte or inefficient processes.
Produces often significant reductions in cost and cycle times.
Enables revolutionary improvement in many business processes as measured by quality and customer service
Helps top organizations stay on top and low achievers to become effective competitors.
The Benefits of Reengineering
The hard task of reexamining mission and how it is being delivered on a day to day basis will have fundamental impacts on an organization, especially in terms of responsiveness and accountability to customers and stakeholders. Among the many rewards, reengineering.
Empower employees
Eliminates water, unnecessary management overhead, and obsolete or inefficient processes.
Enables revolutionary improvements in many business processes as measured by quality and customer service.
Help top organizations stay on top and low achievers to become effective competitors.
DOD has suggested that the following six tasks be part of any functional management approach to reengineering projects:
Define the framework . define functional objectives; determine the management strategy to be followed in streamlining and standardizing processes; and establish the process, data and information systems baselines from which to being process improvement.
Analyze. Analyze business process to eliminate non value added processes; simplify and streamline processes of little value; and identify more effective and efficient alternatives to the process, data, and system baselines.
Evaluate. Conduct a preliminary, functional, economic analysis to evaluate alternatives to baseline processes and select a preferred course of action.
Plan. Develop detailed statement of requirements, baseline impacts, costs, benefits, and schedules to implement the planned course of action.
Approve. Finalize the functional economic analysis using information from the planning data, and present to senior management for approval tp proceed with proposed process improvement and any associated data or system changes.
Execute. Execute the approved process process and data changes, and provide functional management oversight of any associated information system changes.
