BCS 051 Introduction to Software Engineering : SOLVED Assignment IGNOU BCA 2016 2017

1. Develop SRS as per IEEE standard for a Student Admission System

A software requirements specification (SRS) is a description of a software system to be developed, laying out functional and non-functional requirements, and may include a set of use cases that describe interactions the users will have with the software.

Software requirement specification (SRS) is a document that completely describes what the proposed software should do without describing how software will do it. The basic goal of the requirement phase is to produce the SRS, Which describes the complete behavior of the proposed software. SRS is also helping the clients to understand their own needs.

Advantages

Software SRS establishes the basic for agreement between the client and the supplier on what the software product will do.

1. A SRS provides a reference for validation of the final product.

2. A high-quality SRS is a prerequisite to high-quality software.

3. A high-quality SRS reduces the development cost.

Characteristics of an SRS

1. Correct

2. Complete

3. Unambiguous

4. Verifiable

5. Consistent

6. Ranked for importance and/or stability

7. Modifiable

8. Traceable

An SRS is correct if every requirement included in the SRS represents something required in the final system. An SRS is complete, if everything the software is supposed to do and the responses of the software to all classes of input data are specified in the SRS. Correctness ensures that what is specified is done correctly, completeness ensures that everything is indeed specified.

An SRS is unambiguous if and only if every requirement stated has one and only one interpretation. Requirements are often written in natural language, which are inherently ambiguous.

An SRS is verifiable if and only if every stated requirement is verifiable. A requirement is verifiable if there exists some cost-effective process that can check whether the final software meets that requirement. An SRS is consistent if there is no requirement that conflicts with another.

SRS OF ONLINE ADMISSION SYSTEM

INTRODUCTION:- Online Admission System is a web based portal. It is design to provide all the facilities related to the admission of a university. Basically this portal is design for a University like ignou. Any candidate, if he/she want to take admission in ignou, then he/she use it. First of all the person go to our portal and see the course related information and select appropriate courses according to requirement/interest/and eligibility criteria.

INFORMATION DESCRIPTION:-

Online Admission System is a web based portal. It is design to provide all the facilities related to the admission of a university. Basically this portal is design for a University like ignou. Any candidate, if he/she want to take admission in ignou, then he/she use it. First of all the person go to our portal and see the course related information and select appropriate courses according to requirement/interest/and eligibility criteria.

If a person goes through the admission procedure the person create a profile and take a id. At Profile creation time person fill his/her details and choose a Id. At this time person upload own image in its own profile. On profile creation page a EDIT Option is also available. If a person in future edit own profile then he/she do this. Through this Id user perform login and fill Admission form. User ID, Name address and scan image are already selected on the admission page with help of profile. At the time of admission the user also submit documents online. For submission of documents on line the person submit scan Image of related documents. After submission of form the person can make a payment. Payment can make through credit card/Bank draft only. After successfully submission of form a system generate a receipt number, through this number user perform any query related to Admission. A admin check this form and documents, If user fulfil all criteria then admin generate a enrolment number. This enrolment number send to student by mail.

FUCTIONAL DESCRIPTION:-

Online Admission System have the following module:-

Ø Course Manager

Ø Student Profile creator

Ø Admission

Ø Admin

Ø Payment

Ø Student zone manage

Ø Course Manager:-Course manager is designed for the purpose of storing course related information. This module have store science course details, computer science course details. This information is store into database and the module assesses this database. If any students want to see the course details then he/she interact with this module and find course related details like minimum eligibility criteria fee, course duration etc.

Ø Student Profile creator:-If any students can want to join the university first of all he/she creates its own profile. This module is responsible for that operation. The candidate fills its own details and submits it. After that a profile is created and a user Id is generates. with help of this user id candidate fill the admission form as well as corresponding documents.

Ø Admission:-This module is designed for the admission purpose. If any students want to take admission then he/she fill a admission form. For this student have a valid Id and password. For admission the students also submit on line documents and make payment by using DD and credit card.

Ø Admin:-This is internal part of software. Admin have the control to access everything on this system. It checks the form submitted by students and generates a enrollment no. The Admin is also responsible for study centre change, address change etc.

Ø Payment:-Payment module is design for handling payment operation the students can pay by using DD or credit card.

Ø Student zone manager:-This module is responsible for students' queries with help of this module. Users can request for address change, study centre change or any other queries. The queries details are store into Enquiry details tables.

2. Develop Design document for the system mentioned in Question 1.

System Design Document

Overview

The System Design Document describes the system requirements, operating environment, system and subsystem architecture, files and database design, input formats, output layouts, human-machine interfaces, detailed design, processing logic, and external interfaces.

1 INTRODUCTION

1.1 Purpose and Scope

This section provides a brief description of the Systems Design Document’s purpose and scope.

1.2 Project Executive Summary

This section provides a description of the project from a management perspective and an overview of the framework within which the conceptual system design was prepared. If appropriate, include the information discussed in the subsequent sections in the summary.

1.2.1 System Overview

This section describes the system in narrative form using non-technical terms. It should provide a high-level system architecture diagram showing a subsystem breakout of the system, if applicable. The high-level system architecture or subsystem diagrams should, if applicable, show interfaces to external systems. Supply a high-level context diagram for the system and subsystems, if applicable. Refer to the requirements trace ability matrix (RTM) in the Functional Requirements Document (FRD), to identify the allocation of the functional requirements into this design document.

1.2.2 Design Constraints

This section describes any constraints in the system design (reference any trade-off analyses conducted such, as resource use versus productivity, or conflicts with other systems) and includes any assumptions made by the project team in developing the system design.

1.2.3 Future Contingencies

This section describes any contingencies that might arise in the design of the system that may change the development direction. Possibilities include lack of interface agreements with outside agencies or unstable architectures at the time this document is produced. Address any possible workarounds or alternative plans.

1.3 Document Organization

This section describes the organization of the Systems Design Document.

1.4 Points of Contact

This section provides the organization code and title of the key points of contact (and alternates if appropriate) for the information system development effort. These points of contact should include the Project Manager, System Proponent, User Organization, Quality Assurance (QA) Manager, Security Manager, and Configuration Manager, as appropriate.

1.5 Project References

This section provides a bibliography of key project references and deliverables that have been produced before this point.

1.6 Glossary

Supply a glossary of all terms and abbreviations used in this document. If the glossary is several pages in length, it may be included as an appendix.

2 SYSTEM ARCHITECTURE

In this section, describe the system and/or subsystem(s) architecture for the project. References to external entities should be minimal, as they will be described in detail in Section 6, External Interfaces.

2.1 System Hardware Architecture

In this section, describe the overall system hardware and organization. Include a list of hardware components (with a brief description of each item) and diagrams showing the connectivity between the components. If appropriate, use subsections to address each subsystem.

2.2 System Software Architecture

In this section, describe the overall system software and organization. Include a list of software modules (this could include functions, subroutines, or classes), computer languages, and programming computer-aided software engineering tools (with a brief description of the function of each item). Use structured organization diagrams/object-oriented diagrams that show the various segmentation levels down to the lowest level. All features on the diagrams should have reference numbers and names. Include a narrative that expands on and enhances the understanding of the functional breakdown. If appropriate, use subsections to address each module.

Note: The diagrams should map to the FRD data flow diagrams, providing the physical process and data flow related to the FRD logical process and data flow.

2.3 Internal Communications Architecture

In this section, describe the overall communications within the system; for example, LANs, buses, etc. Include the communications architecture(s) being implemented, such as X.25, Token Ring, etc. Provide a diagram depicting the communications path(s) between the system and subsystem modules. If appropriate, use subsections to address each architecture being employed.

Note: The diagrams should map to the FRD context diagrams.

3 FILE AND DATABASE DESIGN

Interact with the Database Administrator (DBA) when preparing this section. The section should reveal the final design of all database management system (DBMS) files and the non-DBMS files associated with the system under development. Additional information may add as required for the particular project. Provide a comprehensive data dictionary showing data element name, type, length, source, validation rules, maintenance (create, read, update, delete (CRUD) capability), data stores, outputs, aliases, and description. Can be included as an appendix.

3.1 Database Management System Files

This section reveals the final design of the DBMS files and includes the following information, as appropriate (refer to the data dictionary):

· Refined logical model; provide normalized table layouts, entity relationship diagrams, and other logical design information

· A physical description of the DBMS schemas, sub-schemas, records, sets, tables, storage page sizes, etc.

· Access methods (such as indexed, via set, sequential, random access, sorted pointer array, etc.)

· Estimate of the DBMS file size or volume of data within the file, and data pages, including overhead resulting from access methods and free space

· Definition of the update frequency of the database tables, views, files, areas, records, sets, and data pages; estimate the number of transactions if the database is an online transaction-based system

3.2 Non-Database Management System Files

In this section, provide the detailed description of all non-DBMS files and include a narrative description of the usage of each file—including if the file is used for input, output, or both; if this file is a temporary file; an indication of which modules read and write the file, etc.; and file structures (refer to the data dictionary). As appropriate, the file structure information should:

· Identify record structures, record keys or indexes, and reference data elements within the records

· Define record length (fixed or maximum variable length) and blocking factors

· Define file access method—for example, index sequential, virtual sequential, random access, etc.

· Estimate the file size or volume of data within the file, including overhead resulting from file access methods

· Define the update frequency of the file; if the file is part of an online transaction-based system, provide the estimated number of transactions per unit time, and the statistical mean, mode, and distribution of those transactions

4 HUMAN-MACHINE INTERFACE

This section provides the detailed design of the system and subsystem inputs and outputs relative to the user/operator. Any additional information may be added to this section and may be organized according to whatever structure best presents the operator input and output designs. Depending on the particular nature of the project, it may be appropriate to repeat these sections at both the subsystem and design module levels. Additional information may be added to the subsections if the suggested lists are inadequate to describe the project inputs and outputs.

4.1 Inputs

This section is a description of the input media used by the operator for providing information to the system; show a mapping to the high-level data flows described in Section 1 .2.1, System Overview. For example, data entry screens, optical character readers, bar scanners, etc. If appropriate, the input record types, file structures, and database structures provided in Section 3, File and Database Design, may be referenced. Include data element definitions, or refer to the data dictionary.

Provide the layout of all input data screens or graphical user interfaces (GUTs) (for example, windows). Provide a graphic representation of each interface. Define all data elements associated with each screen or GUI, or reference the data dictionary.

This section should contain edit criteria for the data elements, including specific values, range of values, mandatory/optional, alphanumeric values, and length. Also address data entry controls to prevent edit bypassing.

Discuss the miscellaneous messages associated with operator inputs, including the following:

· Copies of form(s) if the input data are keyed or scanned for data entry from printed forms

· Description of any access restrictions or security considerations

· Each transaction name, code, and definition, if the system is a transaction-based processing system

4.2 Outputs

This section describes of the system output design relative to the user/operator; show a mapping to the high-level data flows described in Section 1.2.1. System outputs include reports, data display screens and GUIs, query results, etc. The output files are described in Section 3 and may be referenced in this section. The following should be provided, if appropriate:

· Identification of codes and names for reports and data display screens

· Description of report and screen contents (provide a graphic representation of each layout and define all data elements associated with the layout or reference the data dictionary)

· Description of the purpose of the output, including identification of the primary users

· Report distribution requirements, if any (include frequency for periodic reports)

· Description of any access restrictions or security considerations

5 DETAILED DESIGN

This section provides the information needed for a system development team to actually build and integrate the hardware components, code and integrate the software modules, and interconnect the hardware and software segments into a functional product. Additionally, this section addresses the detailed procedures for combining separate COTS packages into a single system. Every detailed requirement should map back to the FRD, and the mapping should be presented in an update to the RTM and include the RTM as an appendix to this design document.

5.1 Hardware Detailed Design

A hardware component is the lowest level of design granularity in the system. Depending on the design requirements, there may be one or more components per system. This section should provide enough detailed information about individual component requirements to correctly build and/or procure all the hardware for the system (or integrate COTS items).

If there are many components or if the component documentation is extensive, place it in an appendix or reference a separate document. Add additional diagrams and information, if necessary, to describe each component and its functions, adequately. Industry-standard component specification practices should be followed. For COTS procurements, if a specific vendor has been identified, include appropriate item names. Include the following information in the detailed component designs (as applicable):

· Power input requirements for each component

· Signal impedances and logic states

· Connector specifications (serial/parallel, 11-pin, male/female, etc.)

· Memory and/or storage space requirements

· Processor requirements (speed and functionality)

· Graphical representation depicting the number of hardware items (for example, monitors, printers, servers, I/O devices), and the relative positioning of the components to each other

· Cable type(s) and length(s)

· User interfaces (buttons, toggle switches, etc.)

· Hard drive/floppy drive/CD-ROM requirements

· Monitor resolution

5.2 Software Detailed Design

A software module is the lowest level of design granularity in the system. Depending on the software development approach, there may be one or more modules per system. This section should provide enough detailed information about logic and data necessary to completely write source code for all modules in the system (and/or integrate COTS software programs).

If there are many modules or if the module documentation is extensive, place it in an appendix or reference a separate document. Add additional diagrams and information, if necessary, to describe each module, its functionality, and its hierarchy. Industry-standard module specification practices should be followed. Include the following information in the detailed module designs:

3.What is Re-Engineering ? How does it differ from Reverse Engineering.

Reverse engineering is the process of discovering the technological principles of a human made device, object or system through analysis of its structure, function and operation. It often involves taking something (e.g., a mechanical device, electronic component, or software program) apart and analyzing its workings in detail to be used in maintenance, or to try to make a new device or program that does the same thing without using or simply duplicating (without understanding) any part of the original.

To reverse engineer a product is to examine it and probe it in order to reconstruct a plan from which it could be built, and the way it works. For instance if I took my clock apart, measured all the gears, and developed a plan for a clock, understanding how the gears meshed together, this would be reverse engineering.

Reverse engineering is often used by companies to copy and understand parts of a competitors product, which is illegal, to find out how their own products work in the event that the original plans were lost, in order to effect repair or alter them. Reverse engineering products is illegal under the laws of many countries, however it does happen. There have been celebrated cases of reverse engineering in the third world.

Re-engineering is the adjustment, alteration, or partial replacement of a product in order to change its function, adapting it to meet a new need.

For instance welding a dozer blade into the frame of my ford fiesta car is an example of re-engineering, in order to clear snow, or drive through my neighbors kitchen.

Re-engineering is often used by companies to adapt generic products for a specific environment (e.g. add suspension for rally car, change shape of conveyor belt to fit a factory shape, alter frequencies of a radio transmitter to fit a new countries laws).