Design Patterns Question:
Explain What are 5 common problems in the software development process?
Answer:
Problems
•Poor requirements - if the requirements are not clear,
unfinished, too common, and not testable, then there will
be problems.
•Unrealistic schedule - if too much work is given in too
little time, problems are inevitable.
•Inadequate testing - no one will know whether or not the
program is any good until the customer complain or systems
collide.
•Futurities - requests to pile on new features after
development is underway; extremely common.
•Miscommunication - if developers do not know what's needed
or customer's have wrong expectations, problems are assured.
Solutions
•Solid requirements - clear, complete, detailed, cohesive,
attainable, testable requirements that are agreed to by all
players. Use prototypes to help nail down requirements.
In 'agile'-type environments, continuous close coordination
with customers/end-users is necessary.
•Realistic schedules - allow adequate time for planning,
design, testing, bug fixing, re-testing, changes, and
documentation; personnel should be able to complete the
project without burning out.
•Adequate testing - start testing early on, re-test after
fixes or changes, plan for adequate time for testing and
bug-fixing. 'Early' testing ideally includes unit testing
by developers and built-in testing and diagnostic
capabilities.
•Stick to initial requirements as much as possible - be
prepared to defend against excessive changes and additions
once development has begun, and be prepared to explain
consequences. If changes are necessary, they should be
adequately reflected in related schedule changes. If
possible, work closely with customers/end-users to manage
expectations. This will provide them a higher comfort level
with their requirements decisions and minimize excessive
changes later on.
•Communication - require walkthroughs and inspections when
appropriate; make extensive use of group communication
tools - groupware, bug-tracking tools and change management
tools, intranet capabilities, etc.; insure that
information/documentation is available and up-to-date -
preferably electronic, not paper; promote teamwork and
cooperation; use prototypes and/or continuous communication
with end-users if possible to clarify expectations.
•Poor requirements - if the requirements are not clear,
unfinished, too common, and not testable, then there will
be problems.
•Unrealistic schedule - if too much work is given in too
little time, problems are inevitable.
•Inadequate testing - no one will know whether or not the
program is any good until the customer complain or systems
collide.
•Futurities - requests to pile on new features after
development is underway; extremely common.
•Miscommunication - if developers do not know what's needed
or customer's have wrong expectations, problems are assured.
Solutions
•Solid requirements - clear, complete, detailed, cohesive,
attainable, testable requirements that are agreed to by all
players. Use prototypes to help nail down requirements.
In 'agile'-type environments, continuous close coordination
with customers/end-users is necessary.
•Realistic schedules - allow adequate time for planning,
design, testing, bug fixing, re-testing, changes, and
documentation; personnel should be able to complete the
project without burning out.
•Adequate testing - start testing early on, re-test after
fixes or changes, plan for adequate time for testing and
bug-fixing. 'Early' testing ideally includes unit testing
by developers and built-in testing and diagnostic
capabilities.
•Stick to initial requirements as much as possible - be
prepared to defend against excessive changes and additions
once development has begun, and be prepared to explain
consequences. If changes are necessary, they should be
adequately reflected in related schedule changes. If
possible, work closely with customers/end-users to manage
expectations. This will provide them a higher comfort level
with their requirements decisions and minimize excessive
changes later on.
•Communication - require walkthroughs and inspections when
appropriate; make extensive use of group communication
tools - groupware, bug-tracking tools and change management
tools, intranet capabilities, etc.; insure that
information/documentation is available and up-to-date -
preferably electronic, not paper; promote teamwork and
cooperation; use prototypes and/or continuous communication
with end-users if possible to clarify expectations.
Previous Question | Next Question |
Explain What is good design? | What are the Design Patterns you know explain? |