Instructions
1. Translate the following English sentences into statements of predicate calculus.
- All programmers enjoy discrete mathematics
- Some integers are not odd
- Every integer that is divisible by 2 is even
- There exists a natural number that is not a positive integer
2. Refer to the statements of predicate calculus you provided for problem 1. Write the negation of each of those statements.
3. Give counterexamples to show each of the following is false:
- For all positive integers x and y, xy> x + y
- For all real numbers x, x > 1/x
4. Translate the following English sentences into statements of predicate calculus that contain double quantifiers:
- Any even integer is equal to twice some other even integer
- Some natural number is no bigger than every natural number
5. Refer to the statements in problem 4 and indicate whether each is true or false. Provide your reasoning.
6. Give an example of a statement of predicate calculus that contains a least two quantifiers. Translate that statement into ordinary English. Write the negation of that statement.
7. What is the purpose of test design specification? What structure must such a specification have? (Name and describe at least one specification structure as part of your discussion).
8. It seems odd that cost and schedule estimates are developed during software project planning -- before detailed software requirements analysis or design has been conducted. Why do you think this is done? Are there circumstances when it should not be done?
SDP
Instructions
Scenario
You have been asked to lead a software development team to build a system fulfilling the Statement of Need specified in project 1. Your team is employed by a small company. The customer wants a project that balances reasonable development cost, timely delivery, software quality, and functionality.
In this project, you will develop the tool for planning, managing and controlling all your software development efforts on the B&B project. Note that typically this is the first document that you produce not the last as we do in class. But we had to produce the other documents first to develop an appreciation of what a project plan entails and requires.
Completing this project will require that you produce a software project plan (SPP) document for the system. An SPP must also develop project reporting and team communication mechanisms.
SPP Templates
Please develop your SPP using the IEEE Standard for Software Project Management Plans, standard 1058-1998, posted in the Reserved Readings section on the Class Menu. Read page 4 of the standard to review the outline. Follow the outline in Figure 1 but omit the following sections from your SPP: 1.1.4 (budget summary), 1.2, 5.1, 5.2.4, 5.3, 5.5, 6.3, 6.4, all of 7, all of 8, Annexes.
The assignment
Complete the template as best as you can. Pay special attention to the bulletized points below. Make any reasonable assumptions based on your understanding of the problem that allow you to address as many sections of the SPP template as possible. (Please read the "project descriptions" in the project description section of the syllabus for additional context and information on course projects).
Pay special attention to the following. The bulk of your grade will be decided on how well you address these issues.
- Project schedule (Timeline): Develop a schedule for the entire project.
- Project task set: Perform a work break down schedule
- Risk Management: Assess and rank the project and technical risks on the project. Explain the risk mitigation steps for these identified risks
- Software Configuration Management: Revise and reference your software quality assurance and software configuration management (SCM) procedures from project 3.
Hints and suggestions
Project schedule (Timeline): Use the Waterfall or Gantt Chart format but you may choose another format if it communicates equivalent information.
Activities/tasks: Organize these according to the software development tasks of; analysis, design, code, and test. Decompose these high-level tasks into at least one additional lower-level sub-task, e.g.,
- Design Task
- Module and Interface Design Sub-task
- Data Design Sub-task
Project risks (section 5.4): Identify the risks that will jeopardize the successful completion of the project. You must quantify and rank risks based on their severity. You do this by estimating the risks cost to the project, typically in dollars, and the probability that the risk will occur, an estimate between 0 and 1. Use the example in the Module Commentary to compute a "weighted" risk which can be used to compare risks for criticality. For the most critical risk, propose a mitigation strategy, in other words, how to avoid or minimize the consequences if the risk were to occur.
Software development process (section 6.1): specify one for your project, i.e., Linear-Sequential (Waterfall) or one of the concurrent/iterative processes. Which process you choose should be reflected in our Project Schedule.
Project Duration: Information in the Problem Statement has been given for the purpose of computing project duration and effort. Use these to compute project duration and effort. Project duration should be consistent with the time-line of your Schedule. Knowing project duration and effort permits the computation of staff size, i.e., the number of software engineers required (divide effort by duration to yield staff size). I want to see the computation for effort and staff size in the relevant template Section (section 5.2.3).
Make sure your work is neat and legible. Your charts, illustrations and diagrams can be done using any word processing, drawing, and/or software CASE drawing tool (or by hand) as long as it is neat and organized. Embed or scan any diagrams that you create in your SPP document-do not upload them separately.