CSE 370: Software Engineering Principles

W02 Team Activity: Case Study Discussion

Overview

Meet with your team and follow this outline to discuss this week's case study.

Instructions

(Before the meeting) Prepare yourself

Before meeting with your team, you need to:

If you have not read the case study you will not be able to participate with your team.

Begin with prayer

The lead student should ask someone to pray to begin the meeting.

Review the case study basics

Discuss the following:

  1. What problems happened with the 737-Max that caused stress in the industry?
  2. Why did Roberto leave MotionTech in the beginning?
  3. Was his experience at Standard Controls (SC) better or worse than his time at MotionTech? Why?
  4. After returning to MotionTech, what are some of the pressures the company is facing?
  5. At the end of the story, what input is Karen asking Roberto to give?

Identify Christlike attributes

Disciples of Jesus Christ

As a team, discuss the following:

  1. Are there any people or actions in this case study that exemplify the way the Savior would act in that circumstance?
    • If so, do you think acting this way was difficult for that person?
  2. Are there any people in this case study that behave contrary to the teachings of the Savior?
    • If so, how could that person have achieved their overall goal in a different way?

Dig a little deeper

Answer the following questions:

  1. Using the principles from the “Evaluating the quality of requirements artifacts” section of the preparation material, evaluate the quality of the artifacts used at MotionTech (shown in Exhibits A-B).
    2. After you have answered the question, expand this box.

    1. Completeness: The diagrams are quite complete. The structure of the diagram, rather than using words, ensures that all of the cases are spelled out in a way that nothing is missed.

    2. Ambiguity (Precision): The diagrams are actually quite precise. You may be tempted to say they are ambiguous because they don't look like code, but this is not correct. The detail of the diagrams defines exactly how the systems should work and does not leave anything up for interpretation of the engineers.

    3. Feasibility: This one is a little tricky to analyze, because it's not as directly demonstrated. But the way these requirements are specified by use of the diagram, they are definitely feasible. Anything that can be spelled out in the diagram format can be translated directly into code, even if it seems a little more difficult than having something that reads more like code.

    4. Timeline (Scope): This one is not clearly stated in the artifact and you could make a reasonable argument either way. For example, you could point out the lack of direct timeline or scope here and show that this criterion is lacking.

      On the other hand, you could reasonably argue that the other conditions of the case could make this acceptable (showing that the engineers had been able to complete them on time, so they must be properly scoped). They could also argue that because each diagram relates to a single function, they each have a very well defined, and have a specific scope.

  2. Considering the footnote reference from the Boston Consulting Group, what are some of the benefits and challenges of using an Agile methodology in the airline industry?
    3. After you have answered the question, expand this box.

    The major benefit that was highlighted in the article was a reduction of time from 4 years to 18 months. They also mentioned the team's pride and happiness because they were trusted and empowered.

    The article highlights the challenge of convincing a skeptical customer to agree to it. It took trust and a willingness to try it. The customer mentioned that if they did not already have trust, they would not have tried it otherwise.

Analyze the case

Answer the following questions:

  1. Were the User Stories at SC effective? Why or why not?
    2. After you have answered the question, expand this box.

    The engineers valued the flexibility that the user stories provided. They also liked that the brief nature of the user stories allowed the individual engineers, who had the direct expertise, to determine the best way to implement the feature.

    Despite these perceived benefits, the lack of design proved to be a challenge for the company because the engineers were lost in a cycle of trying to refactor and find the perfect way to implement the feature. But an even bigger problem with user stories at SC was that they had not filled out detailed acceptance criteria. Without documenting the acceptance criteria, the requirements were incomplete and the team was set up for failure.

  2. Are Agile approaches appropriate for software development in the airline industry? Why or why not?
    3. After you have answered the question, expand this box.

    You could certainly argue either side of this question. The Boston Consulting Group article argued that agile approaches were very effective. On the other hand, others might point out the importance of having the clear, precise documentation of a traditional Waterfall or V-Model approach. Also, the nature of creating something with high stakes in an area that is fairly well-defined may also support a traditional approach (as opposed to a startup creating a mobile app in a newly emerging market).

    There are several valid points that your team could discuss on either side of this decision.

Conclude

As you finish your meeting, select a person to be the lead student for your next meeting.

Submission

Other Links: