New Product Development

The waterfall model seems an ideal choice here. No other

model seems a reasonable alternative to accept as a

different answer.

Strengths:

1. The company is large and bureaucratic, requiring

documentation and good

project visibility. Waterfall documentation satisfies this.

2. The company has a high staff turnover. So probably many

employees are

new and inexperienced. Waterfall works well with

inexperienced staff.

3. The application type is well known to the company, so a

thorough user

requirements analysis should be possible early on.

4. An existing application is to be re-engineered. This also

confirms that the

user requirements are known early. They could be extracted

from the existing application.

5. The company will maintain the software, so good

documentation will be essential.

6. The company has a good reputation to maintain in this

area, so quality control will be essential. Waterfall

emphasis of requirements-before-design and

design-before-coding will emphasise quality.

Weaknesses:

Waterfall has no obvious weaknesses on this project.

1. We may end up swimming upstream, but the chances seem

minimal since the requirements should be clear from the start.

2. Late arrival of code may be one, but on the other hand

our client may be able to continue using the existing

application until the new system arrives.

Solution 1 (b) : Functional and Non-Functional requirements

Interface Requirement, This section defines the parameters

that the software product must follow while interacting with

the outside world.

User Interfaces :

1. Login Screen

2. Menu selection Screen

3.Employee Salary Details

4.Employee Loan Details

5.Employee Leave Details

6.Employee Tax Details

7.Generate Salary Slip

8.Employee Bank Details

Hardware Interfaces Server Configuration: Minimum 2GB Hard

Disk P-III processor or equivalent Ram 512 MB Windows with

Apache preloaded.Client Configuration: A terminal with

Internet Explorer and Printer.

Software Interfaces Operating system –

WindowsXP/2000Language -- JSPDatabase –

OracleNetwork -- LAN Communications Interfaces

Communications interfaces can be provided through email,web

browser, network server communications protocols, electronic

forms, and so on. For this we can use communication

standards such as FTP or HTTP to provide security using

encryption algorithms and synchronization mechanisms

Functional Requirements:

This section analyzes various angles of the functionality to

be developed. You do not need to use each type of analysis

for the entire system. Select only those analyses that best

allow you to complete your understanding of the

requirements. Feature Analysis The Automated Payroll

Processing system consists of following modules.Admin : In

this module admin is provided with many services such as

assigning roles, Add new employee, Update Salary Details,

Update Loan Details, Update Leave Details, Update Tax

Details, Generate Salary Slip, View employee

account.Employee: In this module employee is provided with

the services such as Update personal profile, Change

Password, View earnings, View Deductions, View Salary Slip.

Nonfunctional Requirements:

Performance Requirements System can withstand even though

many number of users requested the desired service. As we

are keeping office level server of the automated payroll

system. And access is given to the only registered users of

office who requires the services of viewing, Updating etc.

It can withstand the load Safety & Reliability Requirements

By incorporating a robust and proven SQL into the system,

reliable performance and integrity of data is ensured. There

must be a power backup for server system.

Security Requirements

Sensitive data is protected from unwanted access by users

appropriate technology and implementing strict user- access

criteria. Software Quality Attributes Menu-driven programs

with user friendly interface with simply hyper links. It is

very easy to use. Backup mechanisms are considered for

maintainability of software as well as database. As it is

object oriented reusability exists. As project is based on

MVC architecture, testability exists.

Test Strategy for Middleware and Firmware

We have defined middleware and firmware and understand that

they are different, yet have many characteristics in common

when it comes to testing. The discussion of test strategy

for these types of software will include both middleware

and firmware, and can be extended to test any software

which is not accessed by a user interface.

Early Testing

Early testing will multiply the testing effectiveness of

any software application, regardless of technology.

However, in the world of middleware and firmware early

testing is most critical because finding defects at later

stages carries a higher penalty of rework. This is due to

the extent of integration with hardware and other software.

The problem with early testing in this environment is that

with so many integration dependencies, how does someone

create test harnesses and stubs that allow for an accurate

test? Manually, the job is possible, but can be

overwhelming when there are many interfaces involved. If

you are developing in a language that has tool support for

structural test case design and testing, you may find that

the job can be very easy. Specifically, for C++ and Java,

Parasoft (www.parasoft.com) has a great toolset to design

and perform structural tests, with a feature to

automatically create a test harness and test stubs. Similar

tools are available from International Software Automation

(ISA) www.softwareautomation.com.

Developer Testing

Developer testing is essential to avoid high rework costs.

To the testers, the software is a black box. Only the

developers have the view and access to the code to test all

conditions. In addition, not only are functional cases at

stake, but also the structural tests for memory boundary

violations and memory leaks.

My experience is that developers can test software if the

have a good process to follow, standards to show what is

expected of them in terms of testing, and a way to hold

developers accountable for the quality of their work.

Management must also be making the message loud and clear

that testing is part of the job and that quality is a

shared responsibility between developers, testers, QA, and

management.

An Object-oriented View of Testing

In the object-oriented view of testing, tests are isolated

at a smaller scope, yet can have high complexity due to the

interfaces with other objects. The object-oriented view of

testing must be able to deal with classes, methods, and

attributes and to validate those at a high level of

coverage.

In Shel Siegel's book, "Object-Oriented Software Testing,"

he describes the Hierarchical approach to O-O testing.

"The hierarchical approach is at the heart of the object-

oriented testing system. This test approach uses and builds

upon several well-understood testing techniques, tying them

together into a comprehensive testing system. The

hierarchical approach leverages the fact that "everything

is a system." It defines and applies testing standards for

several levels of software component: objects, classes,

foundation components, and systems. The hierarchical

approach designates as SAFE those components that meet the

testing standards for that kind of component. Once you

designate a component as SAFE, you can integrate it with

other SAFE components to produce the next-level component.

In turn, you test this component to the level of safety

associated with the component level it represents. SAFE is

always a relative state. It depends entirely on the

standards you choose to enforce, your application, your

attitude toward risk, and the specific risks and risk

management practices you adopt in your project. The

hierarchical approach provides guidelines for minimum

safety; you decide what is right for you."