30 terms

SE - study

STUDY
PLAY
1.1. Provide at least five additional examples of how the law of unintended consequences applies to computer software
Classic examples include the use of
"digital automobile dashboards" to impart a high tech, high quality images. Appliances
that "think;" the broad array of consumer electronics; personal computers (today,
differentiated more by their software function than the hardware), industrial
instrumentation and machines. All e-commerce applications are differentiated by
software.
1.2. Provide a number of examples (both positive and negative) that indicate
the impact of software on our society.
IDK NO ANSWER WAS GIVEN TOO LAZY TO LOOK IT UP
Many modern applications change frequently—before they are
presented to the end user and then after the first version has been put into
use. Suggest a few ways to build software to stop deterioration due to
change.
Many modern applications change frequently before they are presented to
the end user and then after the first versions have been used. The few ways to build
software to stop deterioration due to change would be:
Gather the required information.
Designer and customer define the overall objectives for the software.
Identify the known requirements.
After building a prototype the developer uses an existing program fragment,
this will help the working program to complete quickly.
To maintain and improve our technical competence and to undertake
technological tasks for others only if qualified by training or experience, or
after full disclosure of pertinent limitations.
Documents should be developed in a timely manner, to do this documentation
standards are defined and mechanisms are established.
Review works done up to a particular stage.
There should be a backup person for every critical team member.
Check whether the risk aversion steps are being properly applied or not.
. Consider the seven software categories presented in Section 1.1.2. Do
you think that the same approach to software engineering can be applied for
each? Explain your answer.
The same approach to software engineering can be
applied for each of the seven categories. Each of these "new challenges" will
undoubtedly have effects (for business people, software engineers, and end-users)
that cannot be predicted today. However, software engineers can prepare by
instantiating a process that is agile and adaptable enough to accommodate dramatic
changes in technology and business rules that are sure to come over the next decade.
Is software engineering applicable when WebApps are built? If so,
how might it be modified to accommodate the unique characteristics of
WebApps?
The definition for software engineering applies to the WebApps
since quality and reasonable development costs are important to their
creation. The subtle difference between a WebApp and a conventional
software product is the need for short development times and acquisition
process for web content. This the suggests the use of agile process models that
will discussed later in the text and including aesthetics as part of the design
considerations included during user interface design
As software becomes more pervasive, risks to the public (due to faulty
programs) become an increasingly significant concern. Develop a
doomsday but realistic scenario in which the failure of a computer
program could do great harm, either economic or human
There are literally dozens of real life circumstances to choose from. For example,
software errors that have caused major telephone networks to fail, failures in avionics
that have contributed to plane crashes, computer viruses (e.g., Michelangelo) that
have caused significant economic losses and attacks on major e-commerce sites.
Describe a process framework in your own words. When we say that
framework activities are applicable to all projects, does this mean that the
same work tasks are applied for all projects, regardless of size and
complexity? Explain.
Process framework is applicable to all the projects; hence the same work tasks are
applied for all projects, regardless of their size or complexity. A process framework
involves heavy communication with the customer to gather requirements; this
activity establishes a plan for the software engineering work that follows. It involves
creation of models that will assist the developer and the customer to understand the requirements and design them; it thereby involves construction (code generation and
error testing). It finally provides feedback based on the evaluation.
Umbrella activities occur throughout the software process. Do you think
they are applied evenly across the process, or are some concentrated in one
or more framework activities?
The umbrella activities occur throughout the software process they are applied evenly
across the process, the analysis encompasses a set of work tasks (eg. requirement
gathering, elaboration, negotiation specification and validation). A process framework
has a set of umbrella activities that are applicable across the entire software process.
These activities include Software project tracking and control, Risk management,
Software quality assurance, and formal technical reviews, measurement, Software
configuration management, reusability management and work product preparation
and production.
. In the introduction to this chapter Baetjer notes: "The process
provides interaction between users and designers, between users and
evolving tools, and between designers and evolving tools
[technology]." List five questions that (1) designers should ask users,
(2) users should ask designers, (3) users should ask themselves
about the software product that is to be built, (4) designers should ask
themselves about the software product that is to be built and the
process that will be used to build it
Designers should ask users:
Is the product satisfactory, or does it require redesign or rework?
Was user input solicited, to avoid the product being unsatisfactory and
requiring
rework?
Is there a need for new requirements?
Is the product larger than estimated?
Do the modules require more testing, design and implementation work to
correct
than expected?
Users should ask as designers:
Is the scope clear?
Do we have the tools and people with skills required for the development?
Are the requirements properly defined, are additional requirements needed.
Are the specified areas of the product more time consuming than usual?
Does the module require more testing, design?

Users should ask themselves about the software product that is to be built:
What is the scope and purpose of the software product?
Is the product larger than estimated?
Are the best people available?
Is the staff committed and possess skills required?
Will the turnover among staff members be low enough to allow continuity?
Designers should ask themselves about software product that is to be built and the
process that will used to build it:
Scope and purpose of the document?
What tools are to be used?
What are the objectives and risk aversion priorities?
What will be the steps
2. Discuss the differences among the various process flows
described in Section 3.1. Can you identify types of problems that
might be applicable to each of the generic flows described?
Linear process flow does not accommodate change well, but can be good if
a team is building a routine product similar to something they have done before
b) Iterative process flow handles change better by building in opportunities to reviews
the intermediate work products as they are developed. Often used when building
systems involving technologies that are new to the development team.
c) Evolutionary process models are often adopted for projects (e.g. WebApps) that
need to be developed in a rapid, but controlled manner that avoids unnecessary
rework.
d) Parallel process flow has the potential to allow self-contained work products to be
developed simultaneously for systems that are composed of subsystems.
Try to develop a set of actions for the communication activity.
Select one action and define a task set for it.
Task Set for Communication Activity: A task set would define the actual work to
be done to accomplish the objectives of a software engineering action. For the
communication activity these are:
Make a list of stakeholders for the project
Invite all the stakeholders to an informal meeting
Ask them to make a list of features and functions
Discuss requirements and build a final list
Prioritize requirements and note the areas that he is uncertain of
These tasks may be larger for a complex software project, they may then
include
To conduct a series of specification meetings, build a preliminary list of
functions and features based on stakeholder input.
To build a revised list of stake holder requirements Use quality function deployment techniques to prioritize the requirements.
Note constraints and restrictions on the system.
Discuss methods for validating system.
A common problem during communication occurs when
you encounter two stakeholders who have conflicting ideas about
what the software should be. That is, you have mutually conflicting
requirements. Develop a process pattern (this would be a stage
pattern) using the template presented in Section 3.4 that addresses
this problem and suggest an effective approach to it.
Pattern Name. Conflicting Stakeholder Requirements
Intent. This pattern describes an approach for resolving conflicts between
stakeholders during the communication framework activity.
Type. Stage pattern
Initial context. (1) Stakeholders have been identified; (2) Stakeholders and software
engineers have established a collaborative communication; (3) overriding
software problem to be solved by the software teams has been established; (4)
initial understanding of project scope, basic business requirements and project
constraints has been developed.
Problem. Stakeholders request mutually conflicting features for the software product
under development.
Solution. All stakeholders asked to prioritize all known system requirements, with
resolution being to keep the stakeholder requirements with highest priorities
and/or the most votes.
Resulting Context. A prioritized list of requirements approved by the stakeholders is
established to guide the software team in the creation of an initial product
prototype.
Related Patterns. Collaborative-guideline definition, Scope-isolation, Requirements
gathering, Constraint Description, Requirements unclear
Known Uses/Examples. Communication is mandatory throughout the software
project.
Provide three examples of software projects that would be
amenable to the waterfall model. Be specific.
The waterfall model is amenable to the projects that focus on the attributes
such as the data structures, software architecture, and procedural detail and
interface characterization of objects.
Provide three examples of software projects that would be
amenable to the prototyping model.
Software applications that are relatively easy to prototype almost always
involve human-machine interaction and/or heavy computer graphics. Other
applications that are sometimes amenable to prototyping are certain classes of
mathematical algorithms, subset of command driven systems and other
applications where results can be easily examined without real-time
interaction. Applications that are difficult to prototype include control and
process control functions, many classes of real-time applications and
embedded software.
What process adaptations are required if the prototype will evolve
into a delivery system or product?
If a prototype is evolved into a delivery system or product, it begins with
communication. The software engineer and customer meet and define the
overall objectives for the software, identify whatever requirements are known,
and outline areas where further definition is mandatory. The prototype serves
as a mechanism for identifying software requirements. If a working prototype
is built, the developer attempts to make use of existing program fragments or
applies tools (e.g., report generators, window managers, etc.) that enable
working programs to be generated quickly.
Provide three examples of software projects that would be
amenable to the incremental model. Be specific.
Each linear sequence produces deliverable "increments" of the software for
example, word-processing software developed using the incremental paradigm might deliver basic file management, editing and document production functions
in the first increment; more sophisticated editing and document production
capabilities in the second increment; spelling and grammar checking in the third
increment, and advanced page layout capability in the fourth increment. The
process flow for any increment may incorporate the prototyping paradigm.
Incremental development is particularly useful when staffing is unavailable for a
complete implementation by the business deadline that has been established for
the project.
As you move outward along the spiral process flow, what can you
say about the software that is being developed or maintained?
As work moves outward on the spiral, the product moves toward a more
complete state and the level of abstraction at which work is performed is
reduced (i.e., implementation specific work accelerates as we move further
from the origin).
Is it possible to combine process models? If so, provide an
example
The process models can be combined, each model suggests a somewhat
different process flow, but all perform the same set of generic framework
activities: communication, planning, modeling, construction, and
delivery/feedback.
For example the linear sequential model can serve as a useful process model
in situations where requirements are fixed and work is to proceed to
completion in a linear manner. In cases, where the developer may be unsure
of the efficiency of an algorithm, the adaptability of an operating system, or
the form that human-machine interaction should take. In these, and many
other situations, a prototyping model may offer the best approach. In other
cases, an incremental approach may make sense and the flow of Spiral model
may be efficient. Special process models take on many of the characteristics
of one or more of the tradition.
Reread the "Manifesto for Agile Software Development" at the
beginning of this chapter. Can you think of a situation in which one or
more of the four "values" could get a software team into trouble?
One situation in which one or more of the four "values" could get a software
team into trouble would be Responding to change over following a plan, In
many situations, we no longer are able to define requirements fully before the project begins. Software engineers must be agile enough to respond to a fluid
business environment or else they might land up in trouble.
Describe agility (for software projects) in your own words
Agility can be applied to any software process. However, to accomplish this, it
is essential that the process be designed in a way that allows the project team
to adapt tasks and to streamline them, conduct planning in a way that
understands the fluidity of an agile development approach, eliminate all but
the most essential work products and keep them lean, and emphasize an
incremental delivery strategy that gets working software to the customer as
rapidly as feasible for the product type and operational environment
Why does an iterative process make it easier to manage change?
Is every agile process discussed in this chapter iterative? Is it possible
to complete a project in just one iteration and still be agile? Explain
your answers
Agile process models deliver software increments followed by customer
feedback and revision. Because the increments are small and the customer
feedback is prompt, it is relatively easy to incorporate the changes in the next
software increment. For example, ASD uses an iterative process that
incorporate adaptive cycle planning, relatively rigorous requirement gathering
methods, and an iterative development cycle that incorporates customer focus
groups and formal technical reviews as real-time feedback mechanisms. The
Dynamic Systems Development Method (DSDM) defines three different
iterative cycles—functional model iteration, design and build iteration, and
implementation— preceded by two additional life cycle activities—feasibility
study and business study
Try to come up with one more "agility principle" that would help a
software engineering team become even more maneuverable.
One more "agility principle" that would help a software engineering team
become even more maneuverable would be, "A team should know whose skills
suit a particular project, and get these people on their project, for software
development to become more effective", and "Communication is the key, the
consumer and developer should constantly be communicating even if they are
geographically separated, they can web talk".
Why do requirements change so much? After all, don't people
know what they want?
Requirements change so much, that it is difficult to predict in advance which
software requirements will persist and which will change. It is equally difficult to
predict how customer priorities will change as the project proceeds. It is often
difficult for people to verbalize their software needs until they see a working
prototype and realize that they had forgotten to consider something important
Most agile process models recommend face-to-face
communication. Yet today, members of a software team and their
customers may be geographically separated from one another. Do
you think this implies that geographical separation is something to
avoid? Can you think of ways to overcome this problem?
Most agile process models recommend face-to-face communication. Yet today,
members of a software team and their customers may be geographically
separated from one another in that case Communication is the key, the
consumer and developer should constantly be communicating even if they are
geographically separated, they can webtalk or talk over the phone every now
and then or write emails, use chatting as the, means or a medium of conference
call communication where 2 and more people can talk to each other at the
same time.
Why is it that many software developers don't pay enough
attention to requirements engineering? Are there ever circumstances
where you can skip it?
Understanding the requirements of a problem is among the most difficult tasks
that a software engineer face since requirements change continuously, hence
they tend to pay little attention to it. In some cases, an abbreviated approach
may be chosen. In others, every task defined for comprehensive requirements
engineering must be performed rigorously. Requirements engineering builds a
bridge to design and construction and cannot be skipped.
You have been given the responsibility to elicit requirements from
a customer who tells you he is too busy to meet with you. What should
you do?
You might try using an approach like QFD that makes use customer interviews
and observation, surveys, and examination of historical data (e.g., problem
reports) as raw data for the requirements gathering activity. These data are
then translated into a table of requirements—called the customer voice
table—that is reviewed with the customers later. A variety of diagrams,
matrices, and evaluation methods are then used to extract expected requirements.
Discuss some of the problems that occur when requirements
must be elicited from three or four different customers.
In reality, the customer and the developer enter into a process of negotiation,
where the customer may be asked to balance functionality, performance, and
other product or system characteristics against cost and time to market. The
intent of this negotiation is to develop a project plan that meets the needs of
the customer while at the same time reflecting the real-world constraints (e.g.,
time, people, budget) that have been placed on the software team,
Unfortunately, this rarely happens, each customer has his own views. These
views donot match each customer, time is another constraint that matters,
each customer may not have time to meet the developer and give the
requirements, this further increases the problem.
Why do we say that the requirements model represents a
snapshot of a system in time?
The intent of the requirements model is to provide a description of the
required information, functional, and behavioral domains for a computerbased
system. The model changes dynamically as software engineers learn
more about the system to be built, and stakeholders understand more about
what they really require. For that reason, the analysis model is a snapshot of
requirements at any given time.
Let's assume that you've convinced the customer (you're a very
good salesperson) to agree to every demand that you have as a
developer. Does that make you a master negotiator? Why?
The best negotiations strive for a "win-win" result, hence that does make you a
master negotiator. Successful completion of these initial steps achieves a winwin
result, which becomes the key criterion for proceeding to subsequent
software engineering activities.
Develop at least three additional "context-free questions" that you
might ask a stakeholder during inception.
The first set of context-free questions focuses on the customer and other
stakeholders, the overall goals, and the benefits. For example, the requirement
engineer might ask:
• Who is behind the request for this work?
• Who will use the solution?
• What will be the economic benefit of a successful solution?
• Is there another source for the solution that you need?
YOU MIGHT ALSO LIKE...