Beruflich Dokumente
Kultur Dokumente
Requirement gathering
Software release
Documentation
There may be many additional steps and stages depending upon the nature and the type of the
software product. You may have to go through more than one cycle during the testing phase as
software testers to find problems and bugs. The developers need to fix them before a software
product is officially published or released. Let us go into these stages in detail.
Requirement Gathering
Requirement gathering is usually the first stage of any software product. This stage officially
commences when you are thinking about developing software. In this phase, you meet customers or
prospective customers, and do a market analysis of the requirements and features that are in
demand. You might as well find out if there is a real need in the market for the software product you
are trying to develop. In this stage, most of the work is done by the marketing and sales people, or
people who have direct contact with the customers. These people talk to customers and try to
understand what exactly their requirements are.
A comprehensive understanding of the customers needs and writing down features of the proposed
software product are the keys to success in the requirement gathering phase. This phase is actually
a base for the whole development of the software. If the base is not laid appropriately, the product
will not find a place in the market. If a very good software product which is not required in the
market is developed, it does not sell no matter how well you build it. You can find many instances of
software products that failed in the market because the customers did not require them. The
marketing people usually create a Marketing Requirement Document or MRD that contains formal
representation of the market data gathered. You can also consider your competitors products (if
any). This process is called competitive analysis.
Finally, list down the features required by the product. Appropriate consideration must be given to
the economics of software creation at this point. Questions that must be asked are: is there a
market? Can I make some profit? will the revenue justify the cost of development?
Writing Functional Specifications
Functional specifications may consist of one or more documents. These documents show the
behavior or functionality of a software product on an abstract level. Assuming the product is a black
box, these specifications define its input/output behavior. The product requirements documentation
put forward by people who have contact with the end user of the product or the customers, forms the
basis of the functional specifications.
In larger products, functional specifications may consist of separate documents for each feature of
the product. For example, if the product is a router, you may have a functional specification
document for RIP (Routing Information Protocol), another for features on security, and so on.
Functional specifications are important because developers use them to create design documents.
The documentation people also use them when they create manuals for end users. If different
groups are working in different physical locations, functional specifications and architecture
documents (discussed next) are also a means to communicate.
Keep in mind that sometimes during the product development phase you may need to amend
functional specifications keeping in view new marketing requirements.
Creating Architecture and Design Documents
When you have all of the requirements collected and arranged, it is the turn of the technical
architects team, which usually consists of highly qualified technical specialists, to create the
architecture of the product. This defines different components of the product and how they interact
with each other. Often, the architecture also defines the technologies used to develop the product.
While creating the architecture documents, the team also needs to consider the timelines of the
project. This is the target date when the product is required to be on the market. Often excellent
products fail because they are either too early or late to market. The marketing and sales people
usually decide a suitable time frame to release the product. Based on this timeline, the architecture
team may drop some features of the product if it is not possible to bring the full-featured product to
market within the required time frame. After deciding the components of the product and defining
their functionalities, interfaces are designed for these components to work together.
Most often, no component works in isolation; each one has to coordinate with other components
within the project. Interfaces are the rules and regulations that define how these components will
interact with each other. There maybe major problems down the road if these interfaces are not
designed properly and appropriately detailed. Different people will work on different components of
any large software development project and if they dont fully understand how a particular
component will communicate with others, major problems arise during integration. For some
products, new hardware is also required to make use of technology advancements. The architects of
the product also need to consider this aspect of the product. Once the architecture, software
components and their interfaces are defined, design documents are created as the next phase of
development. At the architecture level, a component is defined as a black box that provides certain
functionality. At the design documents stage, you have to define what is in that black box.
The design documents are usually created by the senior software developers and these documents
define individual software components to the level of functions and procedures. This is the last
document completed before development of the software starts. These design documents are
passed on to software developers as they begin coding. Architecture documents and MRDs usually
need to stay in sync, as sales and marketing will work from MRDs while engineering works from
engineering documents.
buy other products from the same vendor and will not refer other potential customers. You can avoid
this situation by doing extensive testing. This testing is often called as Quality Assurance, or QA, in
the software world. Generally testing starts as soon as the initial software components are available.
There are multiple types of testing. Each of these has its own importance.
1. Unit Testing - Unit testing is testing one part or one component of the product. The developer
generally does this when he/she has completed writing code for that part of the software. This
makes sure that the component is doing what it is intended to do. This also helps the software
testers as well as developers save time by eliminating many cycles of software being passed back
and forth between the developer and the tester. When a developer is ready with a particular part of
the software, he/she can write test cases to test the functionality of this part of the software. The
component is then passed on to the testers who run test cases to make sure that the unit is working
properly.
2. Sanity Testing - Sanity testing is a very basic check to see if all the software components compile
with each other without any problems. This is to ensure that developers have not defined conflicting
or multiple functions or global variable definitions.
3. Regression or Stress Testing - Regression or stress testing is a process done in some projects
to carry out a test for a longer time period. This type of testing is used to determine the behavior of a
product when used continuously over a period of time. It can expose some bugs in software like the
ones related to memory leakage. In some cases, developers allocate memory but forget to release
it. This is usually referred to as memory leakage. When testing goes on for many days or weeks, it
often results in allocation of all of the available memory until no memory is left. This is the point
where your software starts showing abnormal behavior. Another potential problem in long-term
operation is counter overflow. This happens when you increment a counter but forget to decrement it
resulting in an overflow when the product is used for long time. The regression testing may be
started as soon as some components are ready. This type of testing requires, by its very nature, a
very long period of time. The process should be continued as more components of the product are
integrated. The process of integration and communication through interfaces may create new bugs
in the code.
4. Functional or System Testing - Functional testing is carried out to make sure that the software is
doing exactly what it is supposed to do. This must be done before any software is released to
customers. Functional testing is done by testers whose primary job is software testing, and not the
developers themselves. In small software projects where a company cant afford dedicated testers,
other developers may also do functional testing. The key point to keep in mind is that the person
who wrote a software component should not be the person who tested it. A developer will always
have a tendency to test the software the way he/she wrote it. He/she may easily miss any problems
in the software. The testers need to prepare a testing plan for each component of the software. A
testing plan would contain test cases that are run on the software. The tester can prepare these test
cases using functional specifications documents. The tester may also get assistance from the
developer to create test cases. Each test case must include methodology used for testing and
expected results. Additionally, the tester may also need to create certain infrastructure or
environment to test the functionality of a piece of code. For instance, you may simulate a network to
test the routing algorithms that may be part of a router. The next important job of the tester is to
create a service request if an anomaly is found. The tester must include as much information in the
service request as possible.
Typical information included in reporting bugs includes:
Expected results
Results obtained
The bug should be forwarded to the developer so that the developer may correct the problem. Many
software packages are available in the market to track bugs and fix problems in software.
Software Releases
Any software product is officially released before you start selling it. This means that you create a
state of the software in your repository, ensure that it has been tested for functionality and the code
is frozen. A version number is assigned to the released software. After releasing, development may
continue but it will not make any change in the released software. The development is often carried
on in a new branch and it may contain new features. The released software is updated only if a bug
fixed version is released. Generally companies assign incremental version numbers following some
scheme when the next release of the software is sent to market. The version number change
depends on whether the new software contains a major change to the previous version or it contains
bug fixes and enhancement to the existing functionality. Software releases are also important
because they are typically compiled versions of a particular code version, and thus provide a stable
set of binaries for testing.
1. Branches - In almost all serious software development projects, a version control system is used.
This system keeps a record of changes in source code files and is usually built in a tree-like
structure. During the release of the software, the state of each file that is part of the release should
be recorded. By creating branches to this state, future developments can be made. Sometimes
special branches may also be created that are solely used for bug fixing.
2. Release Notes - Every software version contains release notes. These are prepared by people
releasing the software version with the help of the developers. Release notes show what happened
in this software version.
Typically the information includes:
Bug fixes
New functionality
Future enhancements
Generally a user must be given enough information to understand the new release enhancements
and decide whether an upgrade is required or not.
Documentation
There are broadly three categories of documentation related to software development processes:
Technical documentation prepared for technical support staff, including technical manuals
that support staff use to provide customer support.
End-user manuals and guides. This is the documentation for use of the end user. It assists
the user in getting started with the product and using it.
All three types of documents are necessary for different aspects of the support of the product.
Technical documents are necessary for future development, bug fixes, and adding new features.
Documentation for technical support staff contains information that is too complicated for the end
user to understand and use. The support team needs this information in addition to user manuals to
provide better support to customers. Finally each product should have the user manuals. Technical
writers often develop user manuals which are based on functional specifications. In the timelines of
most software development projects, even before the start of code development, functional
specifications are prepared. So the technical writers can start writing user manuals while developers
write the code. So when the product is ready, the user manual is almost completed.
Support and New Features
Your customers need support when you sell a product. This is true regardless of the size of the
product, and even for non-software related products.
The most common support requests from customers are related to one of the following:
In addition to these, you may also want to add new features to the product for the next release
because competitor products have other features. Better support will increase your customer loyalty
and will create referral business. You may adopt two strategies to add new features. You may
provide an upgrade to the current release as a patch, or wait till you have developed a list of new
features and make a new version. Both these strategies are useful depending how urgent the
requirement for new features is.
What is a Problem?
A problem can be defined as an opportunity for improvement. Every problem has a gift for you in its
hands, says Richard Bach. An optimist looks at challenging or problematic events as potential
opportunities for improvement. He will be always seeking answers for the questions such as:
Is there more than one probortunity? "Probortunity a synonym by combining the words
problem and opportunity.
A problem can be defined as the difference between the actual state and the desired state. A
problem could also be the result of the knowledge that there is a gap between the actual and desired
or ideal state of objectives. Clarity of the problem is determined by the clarity of the knowledge which
one precisely wants and which one has. Greater clarity of the problem will help in finding a better
and an effective solution.
A problem can also result from the recognition of an imperfect present and the belief in the possibility
of a better future. The belief that one's hopes can be achieved will give one the will to aim towards a
better future.
Key approaches to Problem solving
There are different ways of problem solving each has its own advantages and disadvantages. The
process an individual adopts as a manager will be influenced by organizational policies, his/her own
personality and communication style, and the kind of information available about the problem.
Broadly, there are two problem solving models available to a manager.
A. Rational Problem-Solving
Rational problem solving rests on the following principles (R. K. Wagner - Learning to solve practical
problems):
What is happening?
Where is it happening?
When is it happening?
The cause of the problem can be found by comparing the problem and non-problem
situations.
Recent problems are due to some change in the situation that has caused an unwanted
deviation from expectations.
The Rational Decision-Making model requires the following steps, which if followed, are assumed to
lead to "value-maximising choices." These steps are as follows:
The creative/lateral problem solving is very flexible. So it can be used to examine real problems and
issues.
Problem solving process
There are a variety of problem-solving processes. But each process consists of a series of steps
which include identifying the problem, searching for possible solutions, selecting the most optimal
solution and implementing a possible solution. It is useful to view problem solving as a cycle
because, sometimes, a problem needs several attempts to solve it or at times the problem itself
changes. The diagram below shows a seven-step problem solving process.
1. Identifying the Problem: The first step in the problem solving process is sizing up the situation to
identify the problem. This may sound simple enough, but sometimes managers might be uncertain
about even what the problem is; they might just be feeling anxious or be confused about what is
getting in the way of their objectives. If that is the case, they can ask themselves or consult with their
friends or a professional expert. Other useful techniques for identifying the problem include
Brainstorming
Checklists
2. Exploring the Problem: Having identified the problem, managers should analyze the problem to
see what is the root cause for it. Often people get caught up in symptoms or effects of a problem or
issue and never drill down to the real cause. They get mad at someones attitude, anger, or actions,
which is not the real cause of the problem. The key here is to focus on analyzing the problem for the
real root cause without being affected by emotional issues. Seeking answers to questions such as
the following will help explore the problem:
Identify the Problem Ask Who?
Why did no one recognize and do something about the problem at the earliest?
How do you know this is a problem; what supporting information do you have?
Once the root cause is found, plans can be made to fix it. Analyzing implies gathering information. If
there is not enough information, they should find some ways to research and collect it.
3. Set Goals: Having explored and analyzed the problem, managers should be able to write a goal
statement that focuses on what is the successful end of the process. Once the root cause is found,
plans can be made to fix it. Analyzing implies gathering information. If there is not enough
information, they should find some ways to research and collect it.
Making and writing down a goal statement will:
help them to clarify the direction to be taken in solving the problem; and
That is, what will occur as a result of the solution? This whole process is about fixing or closing the
gap between the problem and the goal. Writing down the problem ensures that they are not sidetracking from, but addressing the problem.
4. Look at alternatives: Now that the problem has been analyzed, the managers can start
developing possible solutions. This is a creative as well as practical step where every possible
solution needs to be identified. They should identify the various alternative solutions available to
them through techniques such as
Reading
Discussing
Asking Questions
Sleeping on it
Brainstorming
The idea is to collect as many alternative solutions as possible. Mind mapping is another technique
that can be used for finding alternative solutions. Mind mapping uses pictures and/or word phrases
to organize and develop thoughts in a non-linear fashion. It helps people see a problem and its
solution.
Heres how to do mind mapping:
Take a sheet of plain paper and turn it sideways (if using flipchart paper you dont need to
turn it sideways - it is large enough); Using colored felt pens, draw a small picture (or write a
phrase) in the centre of the paper representing the issue you want to solve; Draw lines out
from the main problem (it helps to use different colors for each line).
Write down what each line represents either on top of or on the line;
Write a word or short phrase on the smaller lines indicating what each new line represents
(you may find that mind mapping works best for you if you write down the phrases or draw
the images first and then connect them with the lines); and
If you want, add images next to your main line that illustrate what each line means to you
(some people think better with pictures, others with words).
5. Select the best solution: Now that there are a wide variety of possible solutions available, it is
time to select the best solution from among them to fix the problem, given the circumstances,
resources and other considerations. Here the managers are trying to figure out what exactly would
work best given the nature of the problem. There are always a number of things that can affect a
solution, for instance, money, time, resources, procedures, rules, policies, and so on. All of these
factors must be thought about. Managers should prioritize the solutions by their effectiveness. This is
a slow process of elimination. There may be some possible suggestions that may need to be
immediately eliminated. Eventually, managers should narrow down the choices to one best possible
solution which will promise them the best or optimal outcomes.
6. Implementation: Implementation is a crucial part of problem-solving process. In order to
implement the solutions chosen, managers must have an action plan and communicate it to those
people who are directly and indirectly affected. Gemmy Allen (Problem-Solving & Decision-Making)
says that communication is most effective when it precedes action and events. In this way, events
conform to plans and events happen when, and in the way, they should happen. Managers should
answer the below vital questions before they are asked, like
What are the benefits expected for the individual, department, and the organization as a
whole?
When does the action called for by the decision go into effect?
7. Evaluation: This is the final step in the problem-solving process. Managers should review the
effectiveness of the solution against desired outcomes. Questions like did the solution work? If not,
why? What went right, and what went wrong? What adjustments do they have to make to ensure
that the solution will work better? This stage will require careful analysis that improves upon the best
solution.
The review of your progress can help a manager identify any problem. Steps may need to be revised
or new steps need to be added. One may need to consider a different solution, if the current one,
with which he/she has been, is not helping.
Essentials of Effective Problem Solving
A clear delineation of the ownership of the problem - Whose problem is it: mine, yours, the
other guys, my boss, my spouses, my childs, my parents, my teachers?
Scope of the problem need to be clearly defined: How extensive a problem is it? How long
has this problem existed? How many people are affected by this?
A clear description of the consequences if the problem were not solved - What is the possible
impact on my family, job, life in this community, etc., if this problem isnt solved? What is the
worst possible thing that could happen if this problem isnt solved?
A list of brainstormed solutions to the problem, with each alternative analyzed as to its reality,
its benefits, and the consequences for following each one.
A system of ranking each solution to finalize the decision-making process - A rating system
for analyzing each solution is developed, e.g., 100% chance of success, 75% chance of
success, 50% chance of success.
Determination to follow through on the solution decided upon jointly. This will involve full
motivation to take the risk and pursue the solution to its fullest.
compile successfully. For example, the amount of storage required by types and variable can be
deduced.
Distribution time is the phase during which the program is sent from the entity that created it, to the
one that will invoke it. The format is typically an executable file, but sometimes source code,
especially in the case of a program written in an interpreted language. The distribution method
varies, from physical media such as CD-ROM, to online download via the internet.
Installation time is the phase occurring just after distribution. Here, a program is received into a
system that must perform some form of installation process. The process of installation makes the
program available to be executed within the system. The installation process is able to invoke
different phases of a program's lifecycle. For instance, an executable may be analyzed and recompiled during installation in order to improve the execution on the particular hardware of the
system being installed on.
Link time is the phase during which the names of implementations are looked up and connected
together. For instance, a program that invokes libraries does so by stating the name and an interface
of the library. During link time the particular implementation of that interface is connected to the
program that invokes it. This connection can be done inside the compilation system, or during the
installation, as a part of starting execution, or even invoked during the process of execution.
Load time is the phase in which an executable image is taken from its stored form, and placed into
active memory, as part of starting execution.
Run time is the phase during which the behavior of the program is exhibited. Run time is the time
during which a program is running (executing), in contrast to other phases of a program's lifecycle
such as compile time, link time, load time, etc.
A run-time error is detected after or during the execution of a program, but a compile-time error is
detected by the compiler before the program is ever executed. Storage allocation, type checking,
code generation, and code optimization are typically done at compile time; however it may be done
at run time depending on the particular language and compiler.
For further reading you may refer the websites below.
http://my.safaribooksonline.com/book/programming/9789332514836/chapter-6dot-introduction-toc/ch06_sec9_xhtml