Scribd
Upload
17 views10 pages

Waterfall Software Development Life Cycle

The document outlines the system life cycle following the waterfall method, detailing stages from requirements analysis to system development and testing. It emphasizes the importance of various analysis methods such as questionnaires, interviews, observation, and document analysis to gather client requirements. Additionally, it describes testing processes, including alpha and beta testing, and the necessity of a structured test plan to ensure system functionality and error rectification.

Uploaded by

Jerome k-Jerome
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
17 views10 pages

Waterfall Software Development Life Cycle

The document outlines the system life cycle following the waterfall method, detailing stages from requirements analysis to system development and testing. It emphasizes the importance of various analysis methods such as questionnaires, interviews, observation, and document analysis to gather client requirements. Additionally, it describes testing processes, including alpha and beta testing, and the necessity of a structured test plan to ensure system functionality and error rectification.

Uploaded by

Jerome k-Jerome
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Compiled by: Raed Gharzeddine

System life cycle


A new system following the waterfall method of software development
evolves through a life cycle:
1) Requirements are specified by the client and recorded by the analyst
2) A designer will then follow a requirements specification in order to
produce a design which will show the client what the new system
will look like
3) When the client is happy with the design specification, the system
will be developed based upon the design specification
4) The developed system will then be tested before being installed for
the client
5) The client will be provided with user documentation
6) An evaluation will take place to review the system life cycle of the
project
7) Any ongoing maintenance will be handled by the maintenance
team.
Compiled by: Raed Gharzeddine

Stage 1: Analysis
Analysis involves finding out how the current system works and what the
client’s requirements for the new system are.
Data needs to be collected about the current system and research must
be done about the requirements of the new system. This step can be in a
variety of methods:

Questionnaires
Questionnaires are used when information is required from many users,
and it is impractical to interview them all at once.
▪ Many users also means that there is a large sample size for the
results of the questionnaire to be quantified and compared
▪ They are not suitable when there are only a small number of users
involved because there is not a large enough sample size to
evaluate opinions and it would be quicker to conduct interviews
than spend time preparing questionnaires. However, this may be
exempted if it's impossible to arrange an appointment with the
users
Questions need to be asked in a way in which the required information
can be extracted from the users, but also so that responses can be
analysed collectively.
A good way to do this is providing multiple choice responses so that each
response can be counted.
It's also important that:
▪ The questionnaire does not take too long for users to complete
▪ Questions are written in a way that does not threaten users and the
way they currently work
▪ Users should be given the opportunity to return their
questionnaires anonymously because that means more honest
answers are likely to be recorded
Compiled by: Raed Gharzeddine

▪ The questionnaires should be completed online. This means that


results are immediately stored and readily available for detailed
analysis in the form of graphs and tables. Also, filters can be
applied to the results and responses can be compared based on the
answers given to another question.
Quantitative questions will be extracted using the multiple-choice
questions.
Qualitative questions will be extracted using open questions can be asked
(the user is able to suggest alternative ideas to those presented in the
questionnaire).

Interviews
An interview involves a direct conversation between the analyst and the
client.
Interviews are useful when there is a single end user or a small group of
end users.
▪ Questions can be asked of the users on the conversation can take
place which can expand upon answers that are given
▪ Questions to be asked during interviews should be planned and
designed to extract the required information from the client
▪ The questions will vary depending on who is being interviewed
▪ Interviews can take place with groups of users or focus groups that
represent user groups or customers
▪ Honesty is important during interviews so that the analyst can get
an accurate picture of how tasks are completed. This can sometimes
be difficult to achieve because end users may not want to admit to
taking shortcuts in their tasks or not carrying out tasks to the best
of their ability
The logistics of each interview also needs to be planned as sometimes it
can be difficult to find a time when both the analysts on the client are
available especially during a busy schedule.
Compiled by: Raed Gharzeddine

Observation
Observation involves the analyst watching the processes that take place
within an organisation to find out how tasks are being completed.
This can involve:
▪ This can involve sitting with users to understand the tasks they have
to complete, with an opportunity to ask questions of the users to
extract further information that could be needed for a requirements
specification.
What a user
▪ Wandering around the office.
needs the new
system to do.

Disadvantage: when users are being observed they may do things


differently from normal or there they may be more efficient and so this
does not give the analyst a true picture of what is happening.

Document analysis
This is when the analyst can use existing documents within an
organisation to know about the information that is currently being used:
▪ The analyst will need to see examples of any documents that show
output information or give an indication of what data is being
collected for input to a system
▪ The analyst can sometimes also identify processes that take place
by looking at the documents
▪ It's possible to estimate the amount of data that is likely to be
required if the volume of documents is known
This method is not to be used on its own, but rather in conjunction with
other analysis methods, because it is difficult to identify the processes
just by looking at documents.
Compiled by: Raed Gharzeddine

Also, this method only shows data that's currently output and doesn't
give the analyst an opportunity to find out what additional data an
organisation might need, or what data the organisation does not need.

The content of specifications


1) Requirements specification
This is a contract between the developer and the client. It will specify
exactly what the client needs the system to do, so that the developer can
produce a system that meets the client’s needs.
The analyst will usually write the requirements specification in
consultation with the client who will approve it.
A requirements specification should include:
▪ The purpose of the system
▪ The main objective of the system
▪ The data that must be output from the system (invoices, sales,
reports)
▪ The data that needs to be input in order to generate an output
▪ Validation and verification of input data
▪ Processes that need to take place to convert inputs to outputs
▪ Data that needs to be stored
▪ Functional requirements
▪ Deadlines for each milestone with the project

2) System specifications
This is a list of all software and hardware that is needed for the new
software.
It is crucial that:
▪ The software is identified first (as the hardware will depend upon
the software)
Compiled by: Raed Gharzeddine

▪ Only software that is needed to run the system should be specified


▪ Once the software is known, the minimum hardware required to run
that software should be identified
▪ The analyst should consider how much storage space is going to be
required for the data being used by the system. The analyst will also
probably recommend higher than minimum specs so that the
system functions at a reasonable speed
Specifications include: processing power, amount of memory, and
external hardware components (based upon the requirements of the
user).

3) Design specifications
The design specification is produced by the designer and is an illustration
of how the system will look, what the data structures will be, and how
the system will work.
It is intended to give the user an idea of what the system will look like
before it is developed so that the user’s feedback can be incorporated
into the final designs.

Stage 3: Development and testing


The development stage is the where the design is implemented.

Test data
When a system must be developed, it needs to be tested. In order to do
that, data will be created purely for the use of testing.
• test data is a simulation of live data
• there must be several types of test data that test different scenarios
within the software, including validation rules and queries
Type of test data Description
Valid Data that is accepted by the
Compiled by: Raed Gharzeddine

validation rule
Invalid Data that is not accepted by the
validation rule
Extreme Data that is at the limits of
acceptability; therefore, it is
accepted by the validation rule

The system will also need to be tested to see how it works under normal
conditions using live data.
• Live data: is the actual data being used by the system once it has
been implemented; it is a simulation of a live system to take place
Testing with the live data will be carried out by the end users in most
cases, where they will use the data as if they were doing their normal
jobs, simulating different processes that they would carry out.

Alpha and beta testing


Alpha testing is carried out by a team of developers or a specialised team
of testers before an application is delivered to the user.
• It takes place close to the end of the development stage where the
system is almost ready for the user
• It may take a long time because each time an error is found, the
testing process must be repeated when the error has been
corrected, and there may be a domino effect on other parts of the
system
• The testing is planned and structured using test data to follow all
pathways through the software
Beta testing is used when the software is being made available to many
customers. Beta testers will be real customers who have been selected to
test an early release of the application.
• It only takes place once alpha testing has been completed
Compiled by: Raed Gharzeddine

• Involves customers using the software in a real-world environment


using real data
• As bugs are found within a beta version, new beta versions will be
released for further testing before finalizing everything

Black box and white box testing


Black box testing involves selecting input data and checking that the
expected output data matches the actual output data, with no knowledge
or understanding of what happens inside the black box.
• Usually involves testing the whole system (by a team of specialised
testers) or user testing (end users)
• Focuses on ensuring that the requirements specification has been
met

White box testing involves the same process of input and output data,
but the internal structure and logic of the system is known to the tester.
• Carried out with small program modules
They will do this to check that each module is working as intended.
• Carried out by the software developers who coded the program
Therefore, they can test pathways that the black box tester does not
know about.
• Testing will be focused on whether detail designs, such as
validations, have been developed correctly
White box Black box
Needs access to a detailed Does not require knowledge of how
specification the system was developed
Each module can be tested in depth Only a limited number of test
scenarios are performed (due to
having no knowledge about how
the system was developed)
Compiled by: Raed Gharzeddine

Test plans can be created for each Tests are difficult to design, as
calculation, navigation, and input many different input data options
must be considered with pathways
through the system
Tester can identify what type of Tester may not know what the
test data will be required boundaries or validations are
Skilled tester required (as an No skilled tester is required
understanding of code is needed)

Test plan and its importance


A test plan identifies:
1. What is being tested
2. The type of test
3. The input data used for the test
4. The expected result of the test
5. Space to record results
Test plan
Compiled by: Raed Gharzeddine example

Testing is necessary because every system is prone to errors, and these


errors need to be identified and rectified. A test plan ensures that all
pathways of the system have been reviewed and tested. Without
planning, important parts of the system might be left out, and errors
might be undiscovered
• A test plan will identify all the tests that are needed for every input,
every button, every link, every report, every screen, and all other
elements of a system
• The test plan will include different types of test data including valid,
invalid, and extreme so that inputs are tested to their limits
• The plan will also cover all the user’s requirements and ensure that
they are tested
Test plans not only test inputs, but also calculations and buttons:

Common questions

Powered by AI

Combining multiple methods is essential to gain a comprehensive understanding of organizational needs and system requirements, as no single method provides a full picture . Questionnaires capture quantitative user feedback efficiently from large groups . Interviews allow for in-depth qualitative insights and flexibility in exploring user needs . Observations provide real-world context through first-hand examination of tasks . Document analysis helps verify existing system documentation and understand data flows . By integrating these methods, analysts can corroborate and clarify their findings, reducing biases and improving the robustness of the analysis.

Document analysis offers the advantage of leveraging existing documents to understand the current information outputs and input processes . It helps estimate the volume of data required and identify existing processes . However, its disadvantages include a lack of insight into processes not evident from the documents and limitations on discovering additional data needs . Document analysis should be complemented with other methods since it offers a limited perspective on user requirements beyond current documentation .

Quantitative questions typically involve multiple-choice responses that can be quickly analyzed for trends and statistical significance, suitable for scenarios where large sample sizes justify such analysis . Qualitative questions are open-ended, allowing users to provide detailed responses and suggest alternatives, making them ideal for understanding user expectations and needs in depth . Methods like questionnaires can incorporate both types when distributed online, while interviews are more effective for elaborating on qualitative insights through conversation .

Black box testing involves verifying that input data produces the expected output without knowledge of the system's internal workings, focusing on meeting the requirements specification . It tests end-to-end processes from a user's perspective. White box testing involves examining the internal logic and structure, allowing detailed testing of modules . While black box testing ensures functionalities meet user and specification requirements, white box testing focuses on code correctness and logic, identifying errors that black box testers might overlook . Together, they ensure a thorough validation of both the system's operations and internal mechanisms.

The waterfall model in software development consists of the following key stages: 1) Requirements specification, where the client's needs are documented . 2) Design, where a model of the system is created to show clients what to expect . 3) Development, where the system is built based on the design specifications . 4) Testing, where the developed system is tested before installation . 5) Installation and user documentation, providing guides to the users . 6) Evaluation, to review the system's implementation . 7) Maintenance, ensuring ongoing support . Each stage builds on the previous one, ensuring a structured approach to developing a reliable system.

The requirements specification acts as a 'contract' by clearly documenting the agreed-upon client needs, ensuring both parties have a shared understanding of what the system is to achieve . It typically includes the system's purpose, main objectives, required input and output data, validation and processes to convert inputs to outputs, and any functional requirements . By outlining deadlines and milestones, it helps manage expectations and holds both parties accountable to the defined scope .

A test plan serves as a comprehensive guide outlining what components of the system need testing, the methodology, input data, and the expected outcomes . Its role is to ensure all system pathways are reviewed and validated to prevent errors from being missed . It's essential as it ensures completeness in testing by specifying test scenarios for every aspect of the system, such as inputs, processes, and outputs . Without a test plan, crucial parts of the system might not be tested, potentially leading to overlooked bugs .

When designing interview questions, it's crucial to tailor them to extract the necessary information while considering the interviewee's role . Questions should encourage honesty, avoiding making the interviewee defensive about their work methods . Logistically, interviews should be planned to accommodate both parties' schedules, often challenging due to busy timelines . Additionally, consideration should be given to whether the interview is one-on-one or with a group, influencing question complexity and logistics .

During observation, analysts can employ strategies such as sitting with users to directly observe task completion and wandering around the office to catch tasks being completed in their natural workflow . Asking questions during observation helps clarify unclear processes . However, the potential pitfall lies in users altering their behavior due to being observed, which can lead to inaccurate representations of normal activities . To mitigate this, ensuring a non-invasive presence and clarifying the observer’s role may reduce the observer effect.

Alpha testing is conducted internally by developers or a specialized testing team to identify bugs and errors in a controlled environment before releasing the software to users . It ensures the application meets design specifications and is functionally sound . Beta testing, in contrast, is performed by real users in a real-world environment, providing feedback on usability and defects that arise in actual use cases . This phase is crucial as it effectively simulates normal usage and identifies unforeseen issues before the final release . Together, both phases ensure the reliability and user-friendliness of the system.

You might also like