Software Engineering

Hardware Selection Criteria

1. Computer hardware must support the software available currently and that which will be purchased in the next year.

1. Hardware must have compatibility and connectivity to existing networks or that which is planned for immediate purchase.

1. Hardware must be upgradeable and expandable to meet the needs of the next several years.

1. Hardware will be purchased with an appropriate length of warranty.

1. Hardware maintenance shall be performed by a local vendor or in-house personnel.

1. Whenever feasible, hardware standards will be maintained so that like brands and configurations are installed together to simplify installation and support.

1. Attempts will be made to stay abreast of innovative mechanisms for extending the useful life of installed equipment.

Software Selection Criteria

1. Software must be compatible with current and near future hardware.

1. Software is standardized throughout the district whenever possible to improve purchasing power, simplify training, and facilitate support.

1. Software must comply with current standards set by the technology committee or be approved by the Technology Director.

1. Curricular software must support and enhance the local curriculum and school goals.

In digital circuits, Parallel Counters are series of n flip-flops. It has 2n states. The notion of the word parallel is that, a clock pulse is given at-a-time to all the flip-flops. It may be fed directly. or alternatively, it may be ANDed with some other variable (for example output of previous stage, some other stage etc.).

One may have a look at this image :

http://www.csbdu.in/virtual/DIGITAL%20MUP/3.2_clip_image015.jpg

Alpha Testing: Alpha testing is testing of an application when development is nearing completion. Minor design changes can still be made as a result of alpha testing. Alpha testing is typically performed by a group that is independent of the design team, but still within the company, e.g. in-house software test engineers, or software QA engineers.

Another Definition

Alpha testing is final testing before the software is released to the general public. First, (and this is called the first phase of alpha testing), the software is tested by in-house developers. They use either debugger software, or hardware-assisted debuggers. The goal is to catch bugs quickly. Then, (and this is called second stage of alpha testing), the software is handed over to us, the software QA staff, for additional testing in an environment that is similar to the intended use. Beta Testing: Beta testing is testing an application when development and testing are essentially completed and final bugs and problems need to be found before the final release. Beta testing is typically performed by end-users or others, not programmers, software engineers, or test engineers

Another Definition:- Following alpha testing, "beta versions" of the software are released to a group of people, and limited public tests are performed, so that further testing can ensure the product has few bugs. Other times, beta versions are made available to the general public, in order to receive as much feedback as possible. The goal is to benefit the maximum number of future users.

A use case outlines a specific goal and how to achieve that goal.

A use case diagram is a graphical representation of system users(actors), use cases, and the system (subject) to which this set of use cases applies.

In more detail:

A use case outlines an interaction between an actor and a system (or a system and a system). For example, the interaction (or dialog) of someone accessing an ATM would look as follows:

Use case name: Authenticate user

1. ATM displays welcome message to Customer

2. ATM asks user to insert card

3. Customer inserts card into ATM

4. ATM asks user to enter their PIN

5. Customer enters their PIN

6. ATM authenticates the customer using the information from the card and the PIN

A use case is functional and outlines the behavior of a set of interactions that form a coherent dialog in the system, i.e. Authenticate user. This interaction is separate and distinct from the use case Withdraw money, which also involves a series of interactions.

A use case diagram shows the relationship between the actors and the use cases. For example, on the Use Case diagram for an ATM you would have the following relationships:

• Authenticate user (dialog fragment above)
• Withdraw money
• Deposit money
• Transfer money
• Get balance

• Provision ATM with envelopes and money
• Remove deposit envelopes

A set of use cases can be used to specify scope in a system.

Modularization is the process of breaking a software system into a set of collaborating components. Each of these components should ideally have high cohesion and low coupling.

Modularization is inherently a recursive process. A real world example of modularization would be a car. A car is composed of an engine, doors, chassis, etc. However, each component is then composed of modules, i.e. the door has a window, door lock, handle, etc.

High cohesion means that each of a components components are closely related to each other, i.e. above the door's components of the window, door lock, and handle are all closely related.

Low coupling means that each component should be independent of the other components. In the case of a car, the engine is clearly independent of the door. Low coupling means that different components can be developed by independent teams without affecting each other.

Modularization in software involves partitioning a software system into logical components by a software architect. For example, a banking software system might be broken into the following components:

• ATM software
• Teller interface software
• Back office transaction processing

Software engineering was spurred by the so-called software crisis of the 1960s, 1970s, and 1980s, which identified many of the problems of software development. Many software projects ran over budget and schedule. Some projects caused property damage. A few projects caused loss of life.[3]The software crisis was originally defined in terms of productivity, but evolved to emphasize quality. Some used the term software crisis to refer to their inability to hire enough qualified programmers.

• Cost and Budget Overruns: The OS/360operating system was a classic example. This decade-long[citation needed] project from the 1960s eventually produced one of the most complex software systems at the time. OS/360 was one of the first large (1000 programmers[citation needed]) software projects. Fred Brooks claims in The Mythical Man Month that he made a multi-million dollar mistake of not developing a coherent architecturebefore starting development.
• Property Damage: Software defects can cause property damage. Poor software security allows hackers to steal identities, costing time, money, and reputations.
• Life and Death: Software defects can kill. Some embedded systems used in radiotherapymachines failed so catastrophically that they administered lethal doses of radiation to patients. The most famous of these failures is the Therac 25incident.

Peter G. Neumann has kept a contemporary list of software problems and disasters.[4]The software crisis has been fading from view, because it is psychologically extremely difficult to remain in crisis mode for a protracted period (more than 20 years). Nevertheless, software - especially real-time embedded software - remains risky and is pervasive, and it is crucial not to give in to complacency. Over the last 10-15 years Michael A. Jackson has written extensively about the nature of software engineering, has identified the main source of its difficulties as lack of specialization, and has suggested that his problem frames provide the basis for a "normal practice" of software engineering, a prerequisite if software engineering is to become an engineering science. {Michael Jackson, "Engineering and Software Engineering" in S Nanz ed, The Future of Software Engineering, Springer Verlag 2010; Michael Jackson, Problem Frames: Analyzing and Structuring Software Development Problems; Addison-Wesley, 2001}.