Professional Documents
Culture Documents
All Answers
All Answers
1.1. Explain why professional software that is developed for a customer is not simply
the programs that have been developed and delivered.
Software is not just the programs themselves but also all associated
documentation, libraries, support websites, and configuration data that are
needed to make these programs useful. A professionally developed software
system is often more than a single program. A system may consist of several
separate programs and configuration files that are used to set up these
programs. It may include system documentation, which describes the structure of
the system, user documentation, which explains how to use the system, and
websites for users to download recent product information.
1.2. What is the most important difference between generic software product
development and custom software development? What might this mean in
practice for users of generic software products?
Difference Between generic software product development and customer
software development.
1. Generic products: These are stand-alone systems that are produced by a
development organization and sold on the open market to any customer who is
able to buy them. Examples are apps for mobile devices, software for PCs such
as databases, word processors, drawing packages, and project management
tools. This kind of software also includes “vertical” applications designed for a
specific market such as library information systems, accounting systems, or
systems for maintaining dental records.
1.3. What are the four important attributes that all professional software should
possess? Suggest four other attributes that may sometimes be significant.
The four important attributes that all professional software should possess
are:
Acceptability
Dependability and security
Efficiency
Maintainability
Other attributes that may be significant are:
Low cost, budgeting – Financial constraint to make sure project doesn’t shoot
over budget.
Easy to use – A good UI and simplified one is always a plus for a software
process.
High-quality software – Less problems with software is a better for a brand and
adaptable to customer in general
Future enhancements - Flexible software process that accommodates rapid
change. This saves cost and assures software can be upgraded to latest
trending/supported technologies
1.4. Apart from the challenges of heterogeneity, business and social change, and
trust and security, suggest other problems and challenges that software
engineering is likely to face in the 21st century. (Hint: Think about the
environment.)
Scaling software: Software has to be developed across a very wide range of
scales, from very small embedded systems in portable or wearable devices
through to Internet-scale, cloud-based systems that serve a global community.
good written software can have challenges running and performing at pace 21st
century customer may be expecting.
1.5. Based on your own knowledge of some of the application types discussed in
Section 1.1.2, explain, with examples, why different application types require
specialized software engineering techniques to support their design and
development.
To elaborate on specialized technique I would take an example of Big data
processing which requires specialized infrastructure dedicated to be execute
queries of enormous amount on data in PB’s (Petabytes). Huge data processing
requires CPU and memory intensive servers and thus would require
developmental process in place that adapts to utilize process and methodologies
focused more towards writing memory optimization and cpu optimizations
programs such as parallel processing, multiple thread execution, memory
allocation, work managers, no memory leaks, CPU overloading.
On the other hand an ecommerce application program deals with process and
methodologies inclined towards a better UI design, ease of use, best match
search, payment gateway transaction security and product recommendations
and ever changing demands to adapt for rapid change in design solution and
technology advancements.
1.7. Explain how the universal use of the web has changed software systems
and software systems engineering.
Effect on software systems
a) web-based systems that could be developed where, instead of a special-
purpose user interface, these systems could be accessed using a web
browser.
1.8. Discuss whether professional engineers should be licensed in the same way
as doctors or lawyers.
Yes certainly professional engineers should be licensed in the same way as
doctors or lawyers. Most of the software deals with intellectual property, country
specific laws for health, finance, education, hospitality and other specialized
institutions. Thus a professional engineers needs to possess required skills, to
better put it through licensing in relevant areas specific to an industry segment
such as HIPPA for healthcare industry, PCI-DSS for payment industry. 21st
century demands for individual to design even the infrastructure to attain a
standard that follows a specific industry requirement. Most of the cloud vendors
have these certifications to ensure clients can trust the code to be run on such
platform. A professional engineer with licensing on specialized industry specific
functions in terms of infra solutions, payments solution, healthcare solution, legal
solution and thus ensures an organizations, country rights are well protected and
follows ethical practices aligned by ACM, IEEE and other pioneer standards.
Chapter 2
Exercises
2.1. Giving reasons for your answer based on the type of system being
developed, suggest the most appropriate generic software process
model that might be used as a basis for managing the development of
the following systems:
- A system to control anti-lock braking in a car
- A virtual reality system to support software maintenance
- A university accounting system that replaces an existing system
- An interactive travel planning system that helps users plan journeys
with the lowest environmental impact.
1. Anti-lock braking system This is a safety-critical system so requires a lot of
up-front analysis before implementation. It certainly needs a plan-driven
approach to development with the requirements carefully analysed. A waterfall
model is therefore the most appropriate approach to use, perhaps with formal
transformations between the different development stages.
2. Virtual reality system This is a system where the requirements will change
and there will be an extensive user interface components. Incremental
development with, perhaps, some UI prototyping is the most appropriate
model. An agile process may be used.
3. University accounting system This is a system whose requirements are fairly
well-known and which will be used in an environment in conjunction with lots
of other systems such as a research grant management system. Therefore, a
reuse-based approach is likely to be appropriate for this.
4. Interactive travel planning system System with a complex user interface but
which must be stable and reliable. An incremental development approach is
the most appropriate as the system requirements will change as real user
experience with the system is gained.
2.2. Explain why incremental development is the most effective approach for
developing business software systems. Why is this model less appropriate for
real-time systems engineering?
Incremental development is established on the indication of developing the
primary execution, showing this to customer/user proxy and changing it over
some versions until the tolerable system has been developed. This incremental
development is a major part of agile approaches and reflects the way that we
resolve software system problems. Generally speaking, developing business
software systems are more difficult, software exhaustive and changes happens
regularly when business processes or targets are changed. In these cases using
incremental development model to achieve business software systems
requirements makes more sense.
Real-time systems accuracy depends both on an input response and the time
taken to produce the output. Generally real-time systems contain many
hardware modules which are cannot be incremental and not easy to alter.
Moreover real-time systems are typically protection critical; it must be built on
a good planned procedure. So, incremental development model is less
appropriate for real-time systems engineering.
2.3. Consider the reuse-based process model shown in Figure 2.3. Explain why
it is essential to have two separate requirements engineering activities in the
process.
In a reuse based process, you need two requirements engineering activities
because it is essential to adapt the system requirements according to the
capabilities of the system/components to be reused. These activities are:
1. An initial activity where you understand the function of the system and set
out broad requirements for what the system should do. These should be
expressed in sufficient detail that you can use them as a basis for deciding of a
system/component satisfies some of the requirements and so can be reused.
2. Once systems/components have been selected, you need a more detailed
requirements engineering activity to check that the features of the reused
software meet the business needs and to identify changes and additions that
are required.
2.5. Describe the main activities in the software design process and the outputs
of these activities. Using a diagram, show possible relationships between the
outputs of these activities.
Specification ———> User Requirements and System Requirements
Development ———> a well documented functional software
system
Validation ———> V&V report
Evolution ———> new version of software system
2.6. Explain why change is inevitable in complex systems and give examples
(apart from prototyping and incremental delivery) of software process activities
that help predict changes and make the software being developed more
resilient to change.
2.7. Explain why systems developed as prototypes should not normally be used
as production systems.
Talking about prototype model, we can say that, it is developed by knowing the
requirements.
A client Interaction with prototype makes the client to have the ability to get
the feel of system.
It is best for large systems as this helps to determine the requirements. It is not
complete, this is because many of its details are yet to be built. Users also
involved in its development.
Production system is a result of organizing inputs, then process is carried out
and then output is based on some logic and functions. Production system fails
if any such arrangement made don't give a desired level of outcome.
If requirements are missed then production system may fail. So prototype
systems are not used as production systems.
2.8. Explain why Boehm’s spiral model is an adaptable model that can support
both change avoidance and change tolerance activities. In practice, this model
has not been widely used. Suggest why this might be the case.
Boehm’s spiral model is an adaptable model. It can support both change
avoidance and change tolerance. Because, this model assumes that changes
are a result of project risks and includes explicit risk management activities to
reduce these risks by each loop in the spiral. Each loop in the spiral is split into
four sectors.
2.9. What are the advantages of providing static and dynamic views of the
software process as in the Rational Unified Process?
An approach to process modelling which is simply based on static activities,
such as requirements, implementation, etc. forces these activities to be set out
in a sequence which may not reflect the actual way that these are enacted in
any one organization. In most cases, the static activities shown in Figure 2.13
are actually interleaved so a sequential process model does not accurately
describe the process used. By separating these from the dynamic perspective
i.e. the phases of development, you can then discuss how each of these static
activities may be used at each phase of the process. Furthermore, some of the
activities that are required during some of the system phases are in addition to
the central static activities shown in Figure 2.13. These vary from one
organization to another and it is not appropriate to impose a particular process
in the model.
CHAPTER 4
4.1. Identify and briefly describe four types of requirement that may be
defined for a computer based system.
1. User requirements.
2. System requirements
3. Functional requirements
4. Non-functional requirements.
Description of requirements:
When the user presses the start button, a menu display of potential
destinations is activated, along with a message to the user to select a
destination. Once a destination has been selected, users are requested to
input their credit card. Its validity is checked and the user is then
requested to input a personal identifier. When the credit transaction has
been validated, the ticket is issued.
Ans:
Ambiguities and omissions include:
a) Can a customer buy several tickets for the same destination together or
must they be bought one at a time?
b) Can customers cancel a request if a mistake has been made?
c) How should the system respond if an invalid card is input?
d) What happens if customers try to put their card in before selecting a
destination (as they would in ATM machines)?
e) Must the user press the start button again if they wish to buy another
ticket to a different destination?
f) Should the system only sell tickets between the station where the
machine is situated and direct connections or should it include all
possible destinations?
4.3. Rewrite the above description using the structured approach described
in chapter 4 of the textbook. Resolve the identified ambiguities in an
appropriate way.
Ans.
Action – Ask the customer for their destination, when input, calculate the
total, and prompt for swiping of a credit card, prompt customer for
Pre-condition – None
Post-condition – None
a) Between 0600 and 2300 in any one day, the total system down time
should not exceed 5 minutes.
b) Between 0600 and 2300 in any one day, the recovery time after a
system failure should not exceed 2 minutes.
c) Between 2300 and 0600 in any one day, the total system down time
should not exceed 20 minutes.
All these are availability requirements – note that these vary according to the
time of day. Failures when most people are traveling are less acceptable than
failures when there are few customers.
d) After the customer presses a button on the machine, the display should
be updated within 0.5 seconds.
e) The ticket issuing time after credit card validation has been received
should not exceed 10 seconds.
f) When validating credit cards, the display should provide a status
message for customers indicating that activity is taking place. This tells
the customer that the potentially time consuming activity of validation
is still in progress and that the system has not simply failed.
II.
1).User swipes card at the atm card reader.
2) User enters their pin number on the keypad.
3) User then enters the amount of money to be withdrawn from specified
account.
4) If the withdraw amount does not exceed the balance then the money is
dispersed to the customer and a receipt is given with remaining balance.
III.
1) user clicks on the button to run the spell check in the word processor
2) user is then prompted for each error the spell check function finds and is
presented with possible fixes.
3) User either chooses a recommended fix of the problem or chooses to
ignore the error until all errors have been accounted for.
4.7 : Using your knowledge of how an ATM is used, develop a set of use-cases
that could serve as a basis for understanding the requirements for an
ATM system.
Answer:
4.10 You have taken a job with a software user who has contracted your
previous employer to develop a system for them. You discover that your
company’s interpretation of the requirements is different from the
interpretation taken by your previous employer. Discuss what you
should do in such a situation. You know that the costs to your current
employer will increase if the ambiguities are not resolved. However, you
have also a responsibility of confidentiality to your previous employer.
Ans: The key here is the ambiguities....there is nothing illegal about resolving the
interpretation of ambiguities. i would discuss the ambiguities, and email a
bullet pointed list of the specific ambiguities and recommendations to my
current employer specific decision maker.
……………………………………………………………………………………………………
CHAPTER-6
1) When describing a system, explain why you may have to design
the system architecture before the requirements specification is
complete?
The architecture may have to be designed before specifications are written to
provide a means of structuring the specification and developing different sub-
system specifications concurrently, to allow manufacture of hardware by sub-
contractors and to provide a model for system costing
2) Explain why design conflicts might arise when designing an
architecture for which both availability and security
requirements are the most important non-functional
requirements?
Fundamentally, to provide availability, you need to have (a) replicated
components in the architecture so that in the event of one component failing, you
can switch immediately to a backup component. You also need to have several
copies of the data that is being processed. Security requires minimizing the
number of copies of the data and, wherever possible, adopting an architecture
where each component only knows as much as it needs to, to do its job. This
reduces the chance of intruders accessing the data. Therefore, there is a
fundamental architectural conflict between availability (replication, several
copies) and security (specialization, minimal copies). The system architect has to
find the best compromise between these fundamentally opposing requirements.
3) Explain why you normally use several architectural patterns
when designing the architecture of a large system. Apart from
the information about patterns that I have discussed in this
chapter, what additional information might be useful when
designing large systems?
-Because it as a stylized, abstract description of good practice, which has been
tried and tested in different systems and environments. So, an architectural
pattern should describe a system organization that has been successful in previous
systems. It should include information of when it is and is not appropriate to use
that pattern, and the pattern’s strengths and weaknesses.
- You should also include information about when the pattern should be used and
its advantages and disadvantages. Graphical models of the architecture associated
with the MVC pattern