1. Unlike many other obligations in class, this is a strictly individual effort. Please do not discuss with anyone (except Professor Purtilo) any aspect of these materials, topics, questions, class components or possible solutions until after the published submission deadline.
2. Your work is due in our possession before 6:00PM Tuesday, May 20th, sharp. Submit your work by checking it in to the individual Subversion account provided to you in this class. Place your work as a single Word document called "final.docx" in your home directory there. We will grade the version that was most recently checked in as of the deadline, based on the SVN server's timestamp. The repo will close at or shortly after that deadline. If you are concerned about what time it is on our server, then you can check our clock at https://seam.cs.umd.edu/purtilo/435/servertime.php
3. Ensure that the first page of your document clearly tells us your name, Directory ID, Student UID and which class project you worked on.
4. Organize your Word document so that each answer is identified and starts on a new page of the document.
5. Meeting these submission requirements is considered part of the exam. The burden to get this material to us is yours. Plan accordingly. For safety you may commit to the repo as often as you like, so don't risk misunderstandings due to brief machine or network interruptions by waiting to the last second.
6. Protect the integrity of your work. Much of the course has been about group work but the final is an individual instrument, so please avoid using shared accounts or mail aliases in preparing your work and submission. Don't leave your files open or readable to others.
7. In questions having to do with your class project, and unless stated otherwise in the question, please answer with respect to the materials as they were as of the final project delivery deadline. We will presume your answer refers to this version, so be sure you clearly identify documents should you refer to some other version. During grading, all materials in our repository and ticket system will be available to us so you are free to cite them - just be precise so we know what it is to which you refer. If ambiguity leads us to use an unintended version of your materials when grading then this is not our problem. Generally, materials on other sites will not be available to us during grading, or we will not be able to authoritatively confirm their history, so while you should say what you need to say in your answers, citing outside materials risks your assertions being seen as "not supported." Again, if we can't access or confirm it, then this is not our problem. The same is true for use of others' tickets or materials - hearsay is not as credible as direct observation. Similarly, records and materials manufactured after the project deadline (or with unknown history) are not as credible as records captured contemporaneously. We are most interested in comparing an authoritative record of what you observed during development with how the project turned out; we don't get the same value from re-imagining history as it might have been or seeing it through others' reflections. The time to capture history was as it was made, not during the exam.
8. Use of ChatGPT or similar AI-inspired tools to assist with this exam in any way is prohibited and would be treated as a violation of our intellectual integrity standards.
9. As always, be sure to do your own thorough malware check on materials made available to you or submitted by you.
10. If you complete and submit your exam well before the deadline (measured in hours, not minutes) then please feel free to drop me an email to this effect. I can't release anyone's scores early, but I can start grading early so we speed up the overall process. I am sure we all want closure as quickly as possible.
11. The same approach used to grade previous materials in class will be used to grade this exam. Just like we practiced creating in class and applied in project rubrics, I create a checklist of what I'm looking for and follow it to ensure that all materials evaluated consistently. I will commit the checklist when grades are released so you can see my summary of how your exam was handled. That summary may be terse (time being important) but it will capture what happened.
12. Some general hints:
Problem 1: CONFIDENCE. On the first day of class we promised that the fundamental question on your final exam would involve explaining what about your class project works, what doesn't work, why each is what it is and how you know. Here it is.
(Of course, now that I have your attention I have a chance to deliver one last sermon ...)
435 has been about what one does to reach a desirable outcome by design, not chance. Maybe you can make things up as you go, and let programmers make sweeping product decisions based on input that is invisible to others (or maybe no input at all). Maybe you can afford to pay your programmers to fiddle with code for as long as that happens to be, and maybe you have customers who you can hold hostage to timelines you dictate and who will pay you no matter what.
Maybe you can browbeat those customers into accepting what your programmers choose to offer rather than what those customers might have needed. Maybe those customers will do the testing your team chose not to do because they never needed to understand what a successful product might have looked like in the first place. And maybe you're in a part of the industry where you simply don't need to understand how well you did on the last project since you never experience market pressure to perform better on the next project.
Maybe it really is all about you.
If that's your world, then congratulations! You've found a socialist sweet spot where others will support you no matter what. You didn't need 435.
The rest of us, however, compete in a market where customers pay based on genuine business value to them. We lose to competitors who can do it better, faster and cheaper. Our innovations will win the backing of investors who will take risks but only when we can quantify those risks and offer a confidence-worthy plan for bringing our product to market.
That's why this course has been about anticipating technical consequences of decisions. We want to follow development processes that will reliably guide a project to an intended outcome which the market will reward.
The class project was your opportunity to try these practices and see the effect. This exam question is thus about having you show us the cause-effect relationships you observed along the way. If what you did was offer an occasional hackathon burst of energy, then there might not be much to write about sustained quality-improvement practices; if you hid activity along the way then there won't be much upon which to reflect in order to up your game. Still ... let's do what we can. On to the question ...
Give a technical chronology of your project (from assignment through delivery) in terms of the key design and process decisions, and explain their effect. Make clear how they are reflected in the final build. Connect the dots. Tell us in a way that invites us to have confidence in the quality of your product.
As professionals, you were not spectators; you exercised initiative (to varying degrees) and extended control over your project's shape and direction. We are interested in succinctly capturing the team's activity - its decisions - and relating these to the project outcome. Presumably reflecting on these decisions will help you learn how to reach better outcomes in the future, but for now your goal is to make the chronology clear, show us you 'get it' and explain what happened in a precise way that is well-supported. We don't care how you "feel" the product works; tell us in a way to which an objective and cautious observer could simply and dispassionately check in order to decide whether he understands the decisions made and agrees with the characterization of their importance and consequences.
(Hint: If you find yourself answering this without creating a timeline or table, then stop and read the directions again. We already know the end point in terms of your validation and delivery report. The essence of this question is to thread the story line in terms of decisions, tasks and the consequent outcomes, for better or worse and all as evidenced by the record. You are invited here to interpret events, but not to fabricate them. Remember, all entries in our ticket system are both immutable and hot-linked, so you can cite them in your document. We can take these contemporaneous assertions as authoritative.)
(Another hint: If you find yourself answering with only a chronology then stop and re-read the directions again. We're glad you at least know what happened but we want you to explain their effect. This is how we close the loop pedagogically.)
(Yet another hint: You'll need to grapple with interpretation of the word "key" in this question. The question does not invite you to define "key" in a way that provides you the convenience of simply writing up short snippets of things you happen to know, but which might pale in significance when compared with other developments which you don't know. It also does not invite you to answer only with respect to pieces of the system which you happened to work on yourself. "Key" decisions are ones on which we presume there must have been team awareness, if not also consensus. And while we agree that everything must work 'right' in order to reach a good outcome, we don't think that coding or layout decisions which could have been made in many ways without impacting the outcome are "key". Finally, this question also does not invite you to cherry pick the decisions about which to write; remember, we have studied your materials, logs and reports in detail all semester, so omitting major issues that I know from such study will cost points.)
Problem 2: RISK AND VALUE. A clear value proposition should drive design from the start. Throughout the semester (and especially during the proposal process) most of us struggled as program details competed with product vision; we let narrow programming considerations distract us from tasks that directly created enduring product value.
Using one of the common templates and based on your understanding of the problem space today, tell us the value proposition you should have asserted for your project back in the proposal. (Think product, intended market, primary benefit and market differentiation, as in examples at the linked site.)
The target you actually hit with your project may have suffered mission creep or become nuanced and complex, so this is your opportunity to refocus the mission statement for clarity and simplicity. Then, once you have stated a better value proposition, tell specific tech steps you would need to take in order to bring your product (as delivered on the last day of class) to serve the refocused mission.
Problem 3: COST OF CHANGE. Each project this semester encountered at least one challenge that required the team to substantively refactor or adjust their design after the green light had been given. The nature of this challenge of course varied by project. Whether or not already touched on in the answer to problem above, identify and explain one such challenge; describe how design decisions were adjusted; estimate the cost to the project for not having settled on the ultimate design in the first place; and explain what active discovery techniques might have exposed the challenges earlier in order to reduce that cost. As always, support the answer with specifics.
Problem 4: TEAM ENGAGEMENT.
Refer to the original team charter which traces back to the point when original tasking was released, the mentoring tips you offered to team members throughout the project, and the tips they offered to you. (Note the tips you offered throughout the semester can be listed at https://vale.cs.umd.edu/mentors/mentor - one of our several unadvertised routes on the site.) Analyze the final reports against that backdrop and explain the project outcomes as a function of the team engagement. Are issues, adjustments and successes on the project time line reflected in these instruments? (Hint: I bet they are.) Tie them together. As with all questions, be specific in your answers and support your work.
Problem 5: PRINCIPLES, PROPERTIES, PRACTICES.
(a) List and define our principles of product assurance, then explain how they were either applied in the class project (in which case you should say with what effect) or could have been productively applied (in which case you should explain what possible effects it might have had.)
(b) Explain the Pareto Principle in software and tell how this held true in your project. Be specific.
(c) What is a "design" (the artifact) as used in this class?
(d) What is the fundamental economic argument for process-centered software engineering?
(e) List the desirable properties for a product definition (requirements document) as discussed in this course (and presumably checked when you crafted your class project).
Problem 6: ETHICS AND LAW. Presume that you're in a dev role at one of the top tech companies that deal in services and data (feel free to use Google or Facebook as an example.) Your supervisor asks you to use machine learning techniques to analyze properties of your company's line of apps in order to adjust them (their functionality or presentation) to improve "user engagement". After all, the more that you can persuade people to interact with your apps, the more behavioral data they will give you, and thus the more money you'll make. You profit by connecting advertisers with users and your partners profit by charging users for connectivity. Your boss specifically asks you to create programs to automate the harvesting of user properties and conduct A/B testing of app presentation in order to predict:
To whom do you owe ethical obligations in this scenario, why, and what guides how you proceed? Do any limits apply in this technical task, and if so, what are they? What issues are involved?
Note: We're not looking for just one opinion. Analyze it like we illustrated in the class exercises, then explain what basis you would use for adopting one or another of those paths forward.
While not strictly necessary in order to answer this question, you might set the stage (and find this is a deeper question than might seem on the surface) by looking at Anderson Cooper's report on social media technology. (Bill Maher offers a shorter and more entertaining article, however if you generally avoid late night cable shows because of colorful language, then feel free to pass on that one.) Another background piece is a splendid article by Prof. Daniel Solove, titled I've got nothing to hide, and other misunderstandings of privacy. Even if you only skim that document for the exam, I hope you will circle back later and give it a deeper look. Other food for thought is:
Problem 7: RECAP. Tell how long you worked on this final exam up to the point of its last on-time submission.
Extra: Ethical Terps. For a bonus point, explain how issues identified in the Ethics and Law question above are handled in your major's curriculum. Which courses for major credit primarily cover the technology which is used to engage users in addictive behaviors to generate corporate profit? Which courses for major credit involve the ethics of crafting apps which promote addictive behaviors? Compare the two lists and explain, then identify the dominant business theme common to "Mega Partners" in the CS Dept's Corporate Partners Program. Notice anything? Explain it to me like I'm five.
Extra: Goals. Your very first assignment in 435 was to formulate a statement of your goals for the course. We then created a plan for reaching those goals by leveraging our strengths. (That was in the Name it, claim it, aim it exercise using our Gallup Strengths reports.) Close that loop. For a bonus point, replicate that goals text here, reflect on how well those goals have been met and explain what role your strengths played in the outcome.
Copyright © 2025, James M. Purtilo