. . . . . . . . . ( end of section Question and Exercises done in class) <<Contents | End>>
My personal guess is the human factors are a commonly ignored and the technology over-emphasized.
There is also a tendency to throw a computer at the problem -- without analysing what software, maintenance, backup, training, etc. is needed.
|Communication||Sequence of Control|
|Flows divide||Decisions make choices|
|Implicitly Parallel||Explicit Fork/Join Parallelism|
So there are many different ways that an artifact can fulfill a requirement. this is called 'realizing' it.
Sometimes a language has a framework that makes prototyping much easier -- Ruby on Rails is an example. Ruby is an elegant language. Rails is a framework that simplifies web development of simple web sites.
As a rule a framework needs as much time to learn as a programming language. It may be quicker -- since RAD prototypes are throw-away prototypes -- to just use the language without the framework.
There are also ones that I have attempted, failed to solve, and still wake up in the middle of the night trying to solve them. They are all simple to state and addictive. So I'm keeping them to my self.
First there is the organizational environment -- how things are done, who does them, and how things are paid for....
Then there are the tools that can be used -- especially the integrated Development Environments (IDEs) that combine editor, debugger, compiler, testing, and various libraries and frameworks into a single tool.
With each meaning there are a lot of alternative forms...
It is designed to be a 4 unit class covering a method of going from requirements to a good object-oriented design. And it seems to take the standard amount of prep and homework.
Your task is to choose the hardware and its connections that will support the software that meets the requirements.
Doing this is something of a black art.... the best technique is to create a possible system architecture and evaluate it against the non-functional and functional requirements. Look for the non-functional requirements that are most broken and adjust the architecture so it meets them. For example -- you predict that the web server (cost $600) won't be able to provide the speed under expected load because its CPU will be at 100% .... so you recommend a dual core processor, or go to a set of web servers and a load ballancing... front end that distributes the request between them (and the cost goes up to $2,000)...
If you can't find a suitable improvement then you need to think outside the box. My favorite trick is to look for common factors in all my solutions and deliberately change them. Another is to systematically challenge each constraint and assumption...
|Fact finding||system thinking, interviews, field trips, deployment, meetings, DFDs, scenarios, data samples,...|
|Problem Solving||THINK! DFDs, brainstorm, walkthrough, physical->logical->ideal->new physical, cybernetics, patterns...|
|Data Base Design||DFDs, ERDs, data samples, encoding alternatives, normalization, ...|
|Hardware Selection||Input, Output, connection alternatives, DFDs->deployments, systems architecture|
|Human-Computer Interfaces||HCI, interaction design, activity diagrams, look-and-feel design, metaphors, storyboards, HTML, CSS, ...|
|Software Development||DFDs, ERDs, Requirements, RAD, JAD, stories, use cases, rules, SQL, logic, mathematics, patterns|
|Installation & Training||DFDs, scenarios, stories, procedures, workshops, ...|
|Operation & Maintenance||documentation, help desk, monitor for problems...|
. . . . . . . . . ( end of section Session 19 Questions) <<Contents | End>>
The system helps students register for a class.
The system will be user friendly.Key symptom: you have to work hard to get a detailed specification of what is and is not needed in the system being designed.
There are many ways of writing them. I would suggest always writing
the rule in simple English and then spelling it out in detail using
one of the following:
In terms of time: Humans loose focus after 20 minutes unless you change the pace or supply caffeine and sugar. Donuts and coffee help! So does involving the audience.
The ideal time depends on the type of presentation. Presentations to management should be shorter than presentations of technical ideas to engineers, for example. As a rule, technical people find meetings a waste of their time and so we have things like "stand up meetings" limitted to 15 minutes to share progress and blockages. I'm surprised that no data has apeared on the use of electronic meetings and presentations on software development.
Whatever: don't prepare a presentation until you know the audience, the place, and (of course) the content!
For example if there is a data group
Then deleting the last course that contains a particular instructor also wipes out the data about the instructor.
The cure is normalization.
Given 2NF data then each data group will have a prime key and attributes that are determined by the whole of that key.
Therefor look at data groups that are not in the key in 2NF and that have attributes that act as keys to other attributes. In other words there are non-key functional dependencies.
Notice that all the attributes in the 2NF Course that depend on instructor_name move out of Course and into the new group Instructor.
The facts of interest are like this
Here is a list of entities:
Here are the functional dependencies between entities:
So, here is the ERD:
I hope this helps!
|1. Review topics taught||-||1|
|2. Write the questions||1||2|
|3. Review and mark up||2||1|
|5. Generate and publish mock||2||1|
|6. Print final||4||1|
Next step: draw UML activity diagram [ MakeFinal.png ] , then add durations [ MakeFinal2.png ] , then work out the earliest time transitions (arrows) can happen: [ MakeFinal3.png ] , then work out the latest times transitions can happen [ MakeFinal4.png ] , and finally high-light the critical path: [ MakeFinal5.png ] (Note use right click to pop these images into different windows).
. . . . . . . . . ( end of section Session 20 Questions) <<Contents | End>>
Review all the algorithms/procedures (example CPA, Cost/Benefit, normalization, ...) and all the rules (DFD, ERD, ...) for diagrams.
. . . . . . . . . ( end of section Bibliogrphy) <<Contents | End>>
. . . . . . . . . ( end of section Course Review) <<Contents | End>>
Notes -- Analysis [ a1.html ] [ a2.html ] [ a3.html ] [ a4.html ] [ a5.html ] -- Choices [ c1.html ] [ c2.html ] [ c3.html ] -- Data [ d1.html ] [ d2.html ] [ d3.html ] [ d4.html ] -- Rules [ r1.html ] [ r2.html ] [ r3.html ]
Projects [ project1.html ] [ project2.html ] [ project3.html ] [ project4.html ] [ project5.html ] [ projects.html ]
Field Trips [ F1.html ] [ F2.html ] [ F3.html ]
[ about.html ] [ index.html ] [ schedule.html ] [ syllabus.html ] [ readings.html ] [ review.html ] [ glossary.html ] [ contact.html ] [ grading/ ]