1. Discuss analytical representation of a system.
As an abstraction we symbolically represent a system as a simple entity by using a rectangular box as shown in Figure 1. In general, inputs such as stimuli and cues are fed into a system that processes the inputs and produces an output. As a construct, this symbolism is acceptable; however, the words need to more explicitly identify WHAT the system performs. That is, the system must add value to the input in producing an output.
We refer to the transformational processing that adds value to inputs and produces an output as a capability. You will often hear people refer to this as the system’s functionality; this is partially correct. Functionality only represents the ACTION to be accomplished; not HOW WELL as characterized by performance. This text employs capability as the operative term that encompasses both the functionality and performance attributes of a system.
The simple diagram presented in Figure 1 represents a system. However, from an analytical perspective, the diagram is missing critical information that relates to how the system operates and performs within its operating environment. Therefore, we expand the diagram to identify these missing elements. The result is shown in Figure 2. The attributes of the construct—which include desirable/undesirable inputs, stakeholders, and desirable/undesirable outputs—serve as a key checklist to ensure that all contributory factors are duly considered when specifying, designing, and developing a system.
Figure 1 - Basic System Entity Construct
2. Explain in brief the four primary system development models.
Ans- The Waterfall Model The Waterfall Model is the earliest method of structured system development. Although it has come under attack in recent years for being too rigid and unrealistic when it comes to quickly meeting customer’s needs, the Waterfall Model is still widely used. It is attributed with providing the theoretical basis for other Process Models, because it most closely resembles a “generic” model for software development.
The Waterfall Model consists of the following steps:
· System Conceptualization. System Conceptualization refers to the consideration of all aspects of the targeted business function or process, with the goals of determining how each of those aspects relates with one another, and which aspects will be incorporated into the system.
· Systems Analysis. This step refers to the gathering of system requirements, with the goal of determining how these requirements will be accommodated in the system. Extensive communication between the customer and the developer is essential.
· System Design. Once the requirements have been collected and analyzed, it is necessary to identify in detail how the system will be constructed to perform necessary tasks. More specifically, the System Design phase is focused on the data requirements , the software construction , and the interface construction .
· Coding. Also known as programming, this step involves the creation of the system software. Requirements and systems specifications from the System Design step are translated into machine readable computer code.
· Testing. As the software is created and added to the developing system, testing is performed to ensure that it is working correctly and efficiently. The goal of external effectiveness testing is to verify that the software is functioning according to system design, and that it is performing all necessary functions or sub-functions. The goal of internal testing is to make sure that the computer code is efficient, standardized, and well documented. Testing can be a labor-intensive process, due to its iterative nature. Problems/Challenges associated with the Waterfall Model Although the Waterfall Model has been used extensively over the years in the production of many quality systems, it is not without its problems. In recent years it has come under attack, due to its rigid design and inflexible procedure. Criticisms fall into the following categories:
· Developing a system using the Waterfall Model can be a long, painstaking process that does not yield a working version of the system until late in the process.
Iterative Development
The problems with the Waterfall Model created a demand for a new method of developing systems which could provide faster results, require less up-front information, and offer greater flexibility. With Iterative Development, the project is divided into small parts. This allows the development team to demonstrate results earlier on in the process and obtain valuable feedback from system users. Often, each iteration is actually a mini-Waterfall process with the feedback from one phase providing vital information for the design of the next phase. In a variation of this model, the software products which are produced at the end of each step (or series of steps) can go into production immediately as incremental releases.
Problems/Challenges associated with the Iterative Model
While the Iterative Model addresses many of the problems associated with the Waterfall Model, it does present new challenges.
· The user community needs to be actively involved throughout the project. While this involvement is a positive for the project, it is demanding on the time of the staff and can add project delay.
Prototyping
The Prototyping Model was developed on the assumption that it is often difficult to know all of your requirements at the beginning of a project. Typically, users know many of the objectives that they wish to address with a system, but they do not know all the nuances of the data, nor do
they know the details of the system features and capabilities. The Prototyping Model allows for these conditions, and offers a development approach that yields results without first requiring all information up-front .
When using the Prototyping Model, the developer builds a simplified version of the proposed system and presents it to the customer for consideration as part of the development process. The customer in turn provides feedback to the developer, who goes back to refine the system
requirements to incorporate the additional information. Often, the prototype code is thrown away and entirely new programs are developed once requirements are identified.
There are a few different approaches that may be followed when using the Prototyping Model:
· creation of the major user interfaces without any substantive coding in the background in order to give the users a “feel” for what the system will look like, development of an abbreviated version of the system that performs a limited subset of functions; development of a paper system . use of an existing system or system components to demonstrate some functions that will be included in the developed system.
Prototyping is comprised of the following steps:
Problems/Challenges associated with the Prototyping Model
Criticisms of the Prototyping Model generally fall into the following categories:
The Spiral Model
The Spiral Model was designed to include the best features from the Waterfall and Prototyping Models, and introduces a new component - risk-assessment. The term “spiral” is used to describe the process that is followed as the development of the system takes place. Similar to the Prototyping Model, an initial version of the system is developed, and then repetitively modified based on input received from customer evaluations. Unlike the Prototyping Model, however, the development of each version of the system is carefully designed using the steps involved in the Waterfall Model. With each iteration around the spiral, progressively more complete versions of the system are built.
Risk assessment is included as a step in the development process as a means of evaluating each version of the system to determine whether or not development should continue. If the customer decides that any identified risks are too great, the project may be halted. For example, if a substantial increase in cost or project completion time is identified during one phase of risk assessment, the customer or the developer may decide that it does not make sense to continue with the project, since the increased cost or lengthened timeframe may make continuation of the project impractical or unfeasible.
The Spiral Model is made up of the following steps:
3. Give the overview of system life cycle.
Ans- The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.
Various SDLC methodologies have been developed to guide the processes involved, including the waterfall model (which was the original SDLC method); rapid application development (RAD); joint application development (JAD); the fountain model; the spiral model; build and fix; and synchronize-and-stabilize. Frequently, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely the particular plan was followed.
In general, an SDLC methodology follows the following steps:
The Waterfall Model
This is the classic SDLC model, with a linear and sequential method that has goals for each development phase. The waterfall model simplifies task scheduling, because there are no iterative or overlapping steps. One drawback of the waterfall is that it does not allow for much revision.
5.Explain feasibility study and its types.
Ans4- A feasibility study is performed by a company when they want to know whether a project is possible given certain circumstances. Feasibility studies are undertaken under many circumstances - to find out whether a company has enough money for a project, to find out whether the product being created will sell, or to see if there are enough human resources for the project. A good feasibility study will show the strengths and deficits before the project is planned or budgeted for. By doing the research beforehand, companies can save money and resources in the long run by avoiding projects that are not feasible.
What are the Types of Feasibility Studies?
There are many different types of feasibility studies; here is a list of some of the most common:
Testing the behavior of the whole software/system as defined in software requirements specification(SRS) is known as system testing, its main focus is to verify that the customer requirements are fulfilled.
System testing is done after integration testing is complete. System testing should test functional and non functional requirements of the software.
Following types of testing should be considered during system testing cycle. The test types followed in system testing differ from organization to organization however this list covers some of the main testing types which need to be covered in system testing.
(b) Integration Testing
Integration Testing is a level of the software testing process where individual units are combined and tested as a group.
The purpose of this level of testing is to expose faults in the interaction between integrated units.
Test drivers and test stubs are used to assist in Integration Testing.
Note: The definition of a unit is debatable and it could mean any of the following:
1. the smallest testable part of a software
2. a ‘module’ which could consist of many of ’1′
3. a ‘component’ which could consist of many of ’2′
ANALOGY
During the process of manufacturing a ballpoint pen, the cap, the body, the tail and clip, the ink cartridge and the ballpoint are produced separately and unit tested separately. When two or more units are ready, they are assembled and Integration Testing is performed. For example, whether the cap fits into the body or not.
METHOD
Any of Black Box Testing, White Box Testing, and Gray Box Testing methods can be used. Normally, the method depends on your definition of ‘unit’.
Ans 2: Explain the following Software design concepts:
(a) Abstraction :
concentrate on the essential features and ignore details that are not relevant
(b) Refinement:
abstraction in a stepwise fashion until programming
languages are reached
· similar to the process of refinement & partitioning in
requirement analysis
· abstraction & refinement are complementary
concepts
Eg-1) Suppress lowlevel details
2) Reveal low-leveldetails
(c) Modularity:
· system is decomposed into a number of modules
· software architecture and design patterns embody modularity
· 5 criteria to evaluate a design method with respect to its ability to
define effective modular system
i. modular decomposability
provides a systematic approach for decomposing the problem into subproblems
ii. modular composability
- enables existing(reusable) design components to be assembled into a new system
iii. modular understandability
- module can be understood as a standalone unit (no need to refer to other modules)
iv. modular continuity
- small changes to the system requirements result in changes to individual modules
v. modular protection
- unexpected condition occurs within a module & its effects are constrained within that module
(d) Control Hierarchy:
· also called program structure
· represent the organization of program components
· depth & width = no. of levels of control & overall span of control
· fan-out = no. of. Modules that are directly controlled by another module
· fan-in = how many modules directly control a given module
· super ordinate = module that control another module
· subordinate = module controlled by another
Ans 3: Software Quality Assurance Activities
SQA is the process of evaluating the quality of a product and enforcing adherence
to software product standards and procedures. It is an umbrella activity that ensures conformance to standards and procedures throughout the SDLC of a software product. There are a large number of tasks involved in SQA activities.
These include:
i. Formulating a quality management plan
ii. Applying software engineering techniques
iii. Conducting formal technical reviews
iv. Applying a multi-tiered testing strategy
v. Enforcing process adherence
vi. Controlling change
vii. Measuring impact of change
viii. Performing SQA audits
ix. Keeping records and reporting
i. Formulating a Quality Management Plan
One of the tasks of SQA is the formulation of a quality management plan. The quality management plan identifies the quality aspects of the software product to be developed. It helps in planning checkpoints for work products and the development process. It also tracks changes made to the development process based on the results of the checks. The quality management plan is tracked as a
live plan throughout the SDLC.
ii. Applying Software Engineering
Application of software engineering techniques helps the software designer to achieve high quality specification. The designer gathers information using techniques such as interviews and FAST. Using the information gathered, the designer prepares project estimation with the help of techniques such as WBS,SLOC estimation, or FP estimation.
iii. Conducting Formal Technical Reviews
Formal technical review (FTR) in conducted to assess the quality and design of the prototype. It is a meeting with the technical staff to discuss the quality requirements of a software product and its design quality. FTRs help in detecting errors at an early phase of development. This prevents errors from percolating down to the latter phases and resulting in rework.
iv. Applying a Multi-tiered Testing Strategy
Software testing is a critical task of SQA activity, which aims at error detection.
Unit testing is the first level of testing. The subsequence levels of testing areintegration testing and system level testing. There are various testing strategies followed by organization. At times, developers perform unit testing and integration testing with independence testing support. There are also occasions where testers perform functional testing and system level testing with developer
support. Sometimes beta testing with selected clients is also conducted to test the product before it is finally released.
v. Enforcing Process Adherence
This task of SQA emphasizes the need for process adherence during product development. In addition, the development process should also adhere toprocedures defined for product development. Therefore, this is a combination of two tasks, product evaluation and process monitoring.
vi. Product Evaluation
Product evaluation ensures that the standards laid down for a project are followed.During product evaluation, the compliance of the software product to the existing standards is verified. Initially, SQA activities are conducted to monitor the standards and procedures of the project. Product evaluation ensures that the software product reflects the requirements identified in the project management plan.
vii. Process Monitoring
Process monitoring ensures that appropriate steps to follow the product development procedures are carried out. SQA monitors processes by comparing the actual steps carried out with the steps in the documented procedures.
Product evaluation and process monitoring ensure that the development and control processes described in the project management plan are correctly carried out. These tasks ensure that the project-re1ated procedures and standards are followed. They also ensure that products and processes conform to standards and procedures. Audits ensure that product evaluation and process monitoring are performed.
viii. Controlling Change
This task combines human procedures and automated tools to provide a mechanism for change control. The change control mechanism ensures software quality by formalizing requests for change, evaluating the nature of change, and controlling the impact of change. Change control mechanism is implemented during the development and maintenance stages.
ix. Measuring Impact of Change
Change is inevitable in the SDLC. However, the change needs to be measured and monitored. Changes in the product or process are measured using software qualitymetrics. Software qua1ity metrics helps in estimating the cost and resource requirements of a project. To control software quality; it is essential to measurequality and then compare it with established standards. Software qua1ity metrics are used to evaluate the effectiveness of techniques and tools, the productivity of development activities and the qua1ity of products. Metrics enables mangers and developers to monitor the activities and proposed changes throughout the SDLC and initiate corrective actions and analysis.
x. Performing SQA Audits
SQA audits scrutinize the software development process by comparing it to
established processes. This ensures that proper control is maintained over the
documents required during SDLC. Audits also ensure that the status of an activity
performed by the developer is reflected in the status report of the developer.
xi. Keeping Records and Reporting
Keeping records and reporting ensure the collection and circulation of information
relevant to SQA. The results of reviews, audits, change control, testing, and other
SQA activities are reported and compiled for future reference.
As an abstraction we symbolically represent a system as a simple entity by using a rectangular box as shown in Figure 1. In general, inputs such as stimuli and cues are fed into a system that processes the inputs and produces an output. As a construct, this symbolism is acceptable; however, the words need to more explicitly identify WHAT the system performs. That is, the system must add value to the input in producing an output.
We refer to the transformational processing that adds value to inputs and produces an output as a capability. You will often hear people refer to this as the system’s functionality; this is partially correct. Functionality only represents the ACTION to be accomplished; not HOW WELL as characterized by performance. This text employs capability as the operative term that encompasses both the functionality and performance attributes of a system.
The simple diagram presented in Figure 1 represents a system. However, from an analytical perspective, the diagram is missing critical information that relates to how the system operates and performs within its operating environment. Therefore, we expand the diagram to identify these missing elements. The result is shown in Figure 2. The attributes of the construct—which include desirable/undesirable inputs, stakeholders, and desirable/undesirable outputs—serve as a key checklist to ensure that all contributory factors are duly considered when specifying, designing, and developing a system.
Figure 1 - Basic System Entity Construct
2. Explain in brief the four primary system development models.
Ans- The Waterfall Model The Waterfall Model is the earliest method of structured system development. Although it has come under attack in recent years for being too rigid and unrealistic when it comes to quickly meeting customer’s needs, the Waterfall Model is still widely used. It is attributed with providing the theoretical basis for other Process Models, because it most closely resembles a “generic” model for software development.
The Waterfall Model consists of the following steps:
· System Conceptualization. System Conceptualization refers to the consideration of all aspects of the targeted business function or process, with the goals of determining how each of those aspects relates with one another, and which aspects will be incorporated into the system.
· Systems Analysis. This step refers to the gathering of system requirements, with the goal of determining how these requirements will be accommodated in the system. Extensive communication between the customer and the developer is essential.
· System Design. Once the requirements have been collected and analyzed, it is necessary to identify in detail how the system will be constructed to perform necessary tasks. More specifically, the System Design phase is focused on the data requirements , the software construction , and the interface construction .
· Coding. Also known as programming, this step involves the creation of the system software. Requirements and systems specifications from the System Design step are translated into machine readable computer code.
· Testing. As the software is created and added to the developing system, testing is performed to ensure that it is working correctly and efficiently. The goal of external effectiveness testing is to verify that the software is functioning according to system design, and that it is performing all necessary functions or sub-functions. The goal of internal testing is to make sure that the computer code is efficient, standardized, and well documented. Testing can be a labor-intensive process, due to its iterative nature. Problems/Challenges associated with the Waterfall Model Although the Waterfall Model has been used extensively over the years in the production of many quality systems, it is not without its problems. In recent years it has come under attack, due to its rigid design and inflexible procedure. Criticisms fall into the following categories:
· Developing a system using the Waterfall Model can be a long, painstaking process that does not yield a working version of the system until late in the process.
Iterative Development
The problems with the Waterfall Model created a demand for a new method of developing systems which could provide faster results, require less up-front information, and offer greater flexibility. With Iterative Development, the project is divided into small parts. This allows the development team to demonstrate results earlier on in the process and obtain valuable feedback from system users. Often, each iteration is actually a mini-Waterfall process with the feedback from one phase providing vital information for the design of the next phase. In a variation of this model, the software products which are produced at the end of each step (or series of steps) can go into production immediately as incremental releases.
Problems/Challenges associated with the Iterative Model
While the Iterative Model addresses many of the problems associated with the Waterfall Model, it does present new challenges.
· The user community needs to be actively involved throughout the project. While this involvement is a positive for the project, it is demanding on the time of the staff and can add project delay.
- Communication and coordination skills take center stage in project development.
- Informal requests for improvement after each phase may lead to confusion -- a controlled mechanism for handling substantive requests needs to be developed.
- The Iterative Model can lead to “scope creep,” since user feedback following each phase may lead to increased customer demands. As users see the system develop, they may realize the potential of other system capabilities which would enhance their work.
Prototyping
The Prototyping Model was developed on the assumption that it is often difficult to know all of your requirements at the beginning of a project. Typically, users know many of the objectives that they wish to address with a system, but they do not know all the nuances of the data, nor do
they know the details of the system features and capabilities. The Prototyping Model allows for these conditions, and offers a development approach that yields results without first requiring all information up-front .
When using the Prototyping Model, the developer builds a simplified version of the proposed system and presents it to the customer for consideration as part of the development process. The customer in turn provides feedback to the developer, who goes back to refine the system
requirements to incorporate the additional information. Often, the prototype code is thrown away and entirely new programs are developed once requirements are identified.
There are a few different approaches that may be followed when using the Prototyping Model:
· creation of the major user interfaces without any substantive coding in the background in order to give the users a “feel” for what the system will look like, development of an abbreviated version of the system that performs a limited subset of functions; development of a paper system . use of an existing system or system components to demonstrate some functions that will be included in the developed system.
Prototyping is comprised of the following steps:
- Requirements Definition/Collection.
Similar to the Conceptualization phase of the Waterfall Model, but not as comprehensive. The information collected is usually limited to a subset of the complete system requirements.
- Design.
Once the initial layer of requirements information is collected, or new information is gathered, it is rapidly integrated into a new or existing design so that it may be folded into the prototype.
- Prototype Creation/Modification. The information from the design is rapidly rolled into a prototype. This may mean the creation/modification of paper information, new coding, or modifications to existing coding.
- Assessment. The prototype is presented to the customer for review. Comments and suggestions are collected from the customer.
- Prototype Refinement. Information collected from the customer is digested and the prototype is refined. The developer revises the prototype to make it more effective and efficient.
- System Implementation. In most cases, the system is rewritten once requirements are understood. Sometimes, the Iterative process eventually produces a working system that can be the cornerstone for the fully functional system.
Problems/Challenges associated with the Prototyping Model
Criticisms of the Prototyping Model generally fall into the following categories:
- · Prototyping can lead to false expectations. Prototyping often creates a situation where the customer mistakenly believes that the system is “finished” when in fact it is not. More specifically, when using the Prototyping Model, the pre-implementation versions of a system are really nothing more than one-dimensional structures. The necessary, behind the-scenes work such as database normalization, documentation, testing, and reviews for efficiency have not been done. Thus the necessary underpinnings for the system are not in place.
- · Prototyping can lead to poorly designed systems. Because the primary goal of Prototyping is rapid development, the design of the system can sometimes suffer because the system is built in a series of “layers” without a global consideration of the integration of all other components. While initial software development is often built to be a “throwaway,” attempting to retroactively produce a solid system design can sometimes be problematic.
The Spiral Model
The Spiral Model was designed to include the best features from the Waterfall and Prototyping Models, and introduces a new component - risk-assessment. The term “spiral” is used to describe the process that is followed as the development of the system takes place. Similar to the Prototyping Model, an initial version of the system is developed, and then repetitively modified based on input received from customer evaluations. Unlike the Prototyping Model, however, the development of each version of the system is carefully designed using the steps involved in the Waterfall Model. With each iteration around the spiral, progressively more complete versions of the system are built.
Risk assessment is included as a step in the development process as a means of evaluating each version of the system to determine whether or not development should continue. If the customer decides that any identified risks are too great, the project may be halted. For example, if a substantial increase in cost or project completion time is identified during one phase of risk assessment, the customer or the developer may decide that it does not make sense to continue with the project, since the increased cost or lengthened timeframe may make continuation of the project impractical or unfeasible.
The Spiral Model is made up of the following steps:
- · Project Objectives. Similar to the system conception phase of the Waterfall Model. Objectives are determined, possible obstacles are identified and alternative approaches are weighed.
- · Risk Assessment. Possible alternatives are examined by the developer, and associated risks/problems are identified. Resolutions of the risks are evaluated and weighed in the consideration of project continuation. Sometimes prototyping is used to clarify needs.
- Engineering & Production. Detailed requirements are determined and the software piece is developed.
- Planning and Management. The customer is given an opportunity to analyze the results of the version created in the Engineering step and to offer feedback to the developer.
3. Give the overview of system life cycle.
Ans- The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.
Various SDLC methodologies have been developed to guide the processes involved, including the waterfall model (which was the original SDLC method); rapid application development (RAD); joint application development (JAD); the fountain model; the spiral model; build and fix; and synchronize-and-stabilize. Frequently, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely the particular plan was followed.
In general, an SDLC methodology follows the following steps:
- The existing system is evaluated. Deficiencies are identified. This can be done by interviewing users of the system and consulting with support personnel.
- The new system requirements are defined. In particular, the deficiencies in the existing system must be addressed with specific proposals for improvement.
- The proposed system is designed. Plans are laid out concerning the physical construction, hardware, operating systems, programming, communications, and security issues.
- The new system is developed. The new components and programs must be obtained and installed. Users of the system must be trained in its use, and all aspects of performance must be tested. If necessary, adjustments must be made at this stage.
- The system is put into use. This can be done in various ways. The new system can phased in, according to application or location, and the old system gradually replaced. In some cases, it may be more cost-effective to shut down the old system and implement the new system all at once.
- Once the new system is up and running for a while, it should be exhaustively evaluated. Maintenance must be kept up rigorously at all times. Users of the system should be kept up-to-date concerning the latest modifications and procedures
The Waterfall Model
This is the classic SDLC model, with a linear and sequential method that has goals for each development phase. The waterfall model simplifies task scheduling, because there are no iterative or overlapping steps. One drawback of the waterfall is that it does not allow for much revision.
- Rapid Application Development (RAD)
This model is based on the concept that better products can be developed more quickly by: using workshops or focus groups to gather system requirements; prototyping and reiterative testing of designs; rigid adherence to schedule; and less formality of team communications such as reviews. - Joint Application Development (JAD)
This model involves the client or end user in the design and development of an application, through a series of collaborative workshops called JAD sessions. - The Prototyping Model
DESIGN AND DEVELOPMENT - In this model, a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed.
- Synchronize-and-Stabilize
This model involves teams working in parallel on individual application modules, frequently synchronizing their code with that of other teams and stabilizing code frequently throughout the development process. - The Spiral Model
This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and complicated projects.
5.Explain feasibility study and its types.
Ans4- A feasibility study is performed by a company when they want to know whether a project is possible given certain circumstances. Feasibility studies are undertaken under many circumstances - to find out whether a company has enough money for a project, to find out whether the product being created will sell, or to see if there are enough human resources for the project. A good feasibility study will show the strengths and deficits before the project is planned or budgeted for. By doing the research beforehand, companies can save money and resources in the long run by avoiding projects that are not feasible.
What are the Types of Feasibility Studies?
There are many different types of feasibility studies; here is a list of some of the most common:
- · Technical Feasibility - does the company have the technological resources to undertake the project? Are the processes and procedures conducive to project success?
- · Schedule Feasibility - does the company currently have the time resources to undertake the project? Is the project completable in the available time?
- · Economic Feasibility - given the financial resources of the company, is the project something that can be completed? The economic feasibility study is more commonly called the cost/benefit analysis.
- · Cultural Feasibility - what will the impact on both local and general cultures be? What sort of environmental implications does the feasibility study have?
- · Legal/Ethical Feasibility - what are the legal implications of the project? What sort of ethical considerations are there? You need to make sure that any project undertaken will meet all legal and ethical requirements before the project is on the table.
- · Resource Feasibility - do you have enough resources, what resources will be required, what facilities will be required for the project, etc.
- · Operational Feasibility - this measures how well your company will be able to solve problems and take advantage of opportunities that are presented during the course of the project
- · Marketing Feasibility - will anyone want the product once its done? What is the target demographic? Should there be a test run? Is there enough buzz that can be created for the product?
- · Real Estate Feasibility - what kind of land or property will be required to undertake the project? What is the market like? What are the zoning laws? How will the business impact the area?
- · Comprehensive Feasibility - this takes a look at the various aspects involved in the project - marketing, real estate, cultural, economic, etc. When undertaking a new business venture, this is the most common type of feasibility study performed.
Testing the behavior of the whole software/system as defined in software requirements specification(SRS) is known as system testing, its main focus is to verify that the customer requirements are fulfilled.
System testing is done after integration testing is complete. System testing should test functional and non functional requirements of the software.
Following types of testing should be considered during system testing cycle. The test types followed in system testing differ from organization to organization however this list covers some of the main testing types which need to be covered in system testing.
- Sanity Testing
- Usability Testing
- Stress Testing
- Load Testing
- Performance Testing
- Regression Testing
- Maintenance Testing
- Security Testing
- Accessibility Testing
(b) Integration Testing
Integration Testing is a level of the software testing process where individual units are combined and tested as a group.
The purpose of this level of testing is to expose faults in the interaction between integrated units.
Test drivers and test stubs are used to assist in Integration Testing.
Note: The definition of a unit is debatable and it could mean any of the following:
1. the smallest testable part of a software
2. a ‘module’ which could consist of many of ’1′
3. a ‘component’ which could consist of many of ’2′
ANALOGY
During the process of manufacturing a ballpoint pen, the cap, the body, the tail and clip, the ink cartridge and the ballpoint are produced separately and unit tested separately. When two or more units are ready, they are assembled and Integration Testing is performed. For example, whether the cap fits into the body or not.
METHOD
Any of Black Box Testing, White Box Testing, and Gray Box Testing methods can be used. Normally, the method depends on your definition of ‘unit’.
Ans 2: Explain the following Software design concepts:
(a) Abstraction :
concentrate on the essential features and ignore details that are not relevant
- · Procedural abstraction = a named sequence of instructions that has a specific & limited function
- · Data abstraction = a named collection of data that describes a data object
- · Control abstraction = implies a program control mechanisms without specify internal details
(b) Refinement:
- · stepwise refinement = top down strategy
- · refine levels of procedural detail
- · develop hierarchy by decompose a procedural
abstraction in a stepwise fashion until programming
languages are reached
· similar to the process of refinement & partitioning in
requirement analysis
· abstraction & refinement are complementary
concepts
Eg-1) Suppress lowlevel details
2) Reveal low-leveldetails
(c) Modularity:
· system is decomposed into a number of modules
· software architecture and design patterns embody modularity
· 5 criteria to evaluate a design method with respect to its ability to
define effective modular system
i. modular decomposability
provides a systematic approach for decomposing the problem into subproblems
ii. modular composability
- enables existing(reusable) design components to be assembled into a new system
iii. modular understandability
- module can be understood as a standalone unit (no need to refer to other modules)
iv. modular continuity
- small changes to the system requirements result in changes to individual modules
v. modular protection
- unexpected condition occurs within a module & its effects are constrained within that module
(d) Control Hierarchy:
· also called program structure
· represent the organization of program components
· depth & width = no. of levels of control & overall span of control
· fan-out = no. of. Modules that are directly controlled by another module
· fan-in = how many modules directly control a given module
· super ordinate = module that control another module
· subordinate = module controlled by another
Ans 3: Software Quality Assurance Activities
SQA is the process of evaluating the quality of a product and enforcing adherence
to software product standards and procedures. It is an umbrella activity that ensures conformance to standards and procedures throughout the SDLC of a software product. There are a large number of tasks involved in SQA activities.
These include:
i. Formulating a quality management plan
ii. Applying software engineering techniques
iii. Conducting formal technical reviews
iv. Applying a multi-tiered testing strategy
v. Enforcing process adherence
vi. Controlling change
vii. Measuring impact of change
viii. Performing SQA audits
ix. Keeping records and reporting
i. Formulating a Quality Management Plan
One of the tasks of SQA is the formulation of a quality management plan. The quality management plan identifies the quality aspects of the software product to be developed. It helps in planning checkpoints for work products and the development process. It also tracks changes made to the development process based on the results of the checks. The quality management plan is tracked as a
live plan throughout the SDLC.
ii. Applying Software Engineering
Application of software engineering techniques helps the software designer to achieve high quality specification. The designer gathers information using techniques such as interviews and FAST. Using the information gathered, the designer prepares project estimation with the help of techniques such as WBS,SLOC estimation, or FP estimation.
iii. Conducting Formal Technical Reviews
Formal technical review (FTR) in conducted to assess the quality and design of the prototype. It is a meeting with the technical staff to discuss the quality requirements of a software product and its design quality. FTRs help in detecting errors at an early phase of development. This prevents errors from percolating down to the latter phases and resulting in rework.
iv. Applying a Multi-tiered Testing Strategy
Software testing is a critical task of SQA activity, which aims at error detection.
Unit testing is the first level of testing. The subsequence levels of testing areintegration testing and system level testing. There are various testing strategies followed by organization. At times, developers perform unit testing and integration testing with independence testing support. There are also occasions where testers perform functional testing and system level testing with developer
support. Sometimes beta testing with selected clients is also conducted to test the product before it is finally released.
v. Enforcing Process Adherence
This task of SQA emphasizes the need for process adherence during product development. In addition, the development process should also adhere toprocedures defined for product development. Therefore, this is a combination of two tasks, product evaluation and process monitoring.
vi. Product Evaluation
Product evaluation ensures that the standards laid down for a project are followed.During product evaluation, the compliance of the software product to the existing standards is verified. Initially, SQA activities are conducted to monitor the standards and procedures of the project. Product evaluation ensures that the software product reflects the requirements identified in the project management plan.
vii. Process Monitoring
Process monitoring ensures that appropriate steps to follow the product development procedures are carried out. SQA monitors processes by comparing the actual steps carried out with the steps in the documented procedures.
Product evaluation and process monitoring ensure that the development and control processes described in the project management plan are correctly carried out. These tasks ensure that the project-re1ated procedures and standards are followed. They also ensure that products and processes conform to standards and procedures. Audits ensure that product evaluation and process monitoring are performed.
viii. Controlling Change
This task combines human procedures and automated tools to provide a mechanism for change control. The change control mechanism ensures software quality by formalizing requests for change, evaluating the nature of change, and controlling the impact of change. Change control mechanism is implemented during the development and maintenance stages.
ix. Measuring Impact of Change
Change is inevitable in the SDLC. However, the change needs to be measured and monitored. Changes in the product or process are measured using software qualitymetrics. Software qua1ity metrics helps in estimating the cost and resource requirements of a project. To control software quality; it is essential to measurequality and then compare it with established standards. Software qua1ity metrics are used to evaluate the effectiveness of techniques and tools, the productivity of development activities and the qua1ity of products. Metrics enables mangers and developers to monitor the activities and proposed changes throughout the SDLC and initiate corrective actions and analysis.
x. Performing SQA Audits
SQA audits scrutinize the software development process by comparing it to
established processes. This ensures that proper control is maintained over the
documents required during SDLC. Audits also ensure that the status of an activity
performed by the developer is reflected in the status report of the developer.
xi. Keeping Records and Reporting
Keeping records and reporting ensure the collection and circulation of information
relevant to SQA. The results of reviews, audits, change control, testing, and other
SQA activities are reported and compiled for future reference.
