|
| From: | Syan Tan |
| Subject: | Re: [Gnumed-devel] Re: get something done |
| Date: | Sat, 03 Dec 2005 10:51:25 +0800 |
Course Requirements
Task % Topic Due Date
Assignment1 10 % Feasibility Study February 9
Midterm 20 % March 1
Assignment2 15 % Requirements Specification March 8
Assignment3 20 % System Design April 9
Final exam 35 % All course material (2 hrs)
Tentative Course Outline
Week 1: Introduction; Conceptual Modeling, Class Diagrams
Week 2: State Diagrams, Goal Diagrams
Week 3: The Feasibility Study; Information Acquisition;
;
Week 4: Interaction Diagrams, Business Rules;
Diagrams,
Week 5: Requirements Analysis, UML, Use Cases
Week 6: Non-Functional Requirements, Software Requirements
Specifications
***** Reading Week *****
Week 7: The Entity-Relationship Model
Week 8: Information System Design, Hardware and Software
Architectures
Week 9: Selecting Hardware and Software
Week 10: Database and Website Design
Week 11: Object-Oriented Design
Week 12: User Interface Design;
Week 13: Other Phases; Course Summary
Information Systems Analysis and Design CS
What's New, What's Different?
We will be using UML (the "Unified Modeling
Language") for all three assignments of the course.
Will use OCL (the "Object Constraint Language") to
make UML more expressive.
Will be using goal models for the feasibility study.
http://www.cs.toronto.edu/~jm/340S/Slides.html
this seems to be a Canadian academic view on pre-implementation phase of software engineering. Hooray for Canada, ? last bastion of open academic lecture notes access. (RMIT has closed it's open access ). What I remember of a analysis / design subject many years ago was scoping / stakeholders / requirements analysis ( functional points ) ; use cases ; class diagrams; sequence diagrams; collaboration diagrams; state diagrams; and dataflow diagrams ; marks lost if functional points numbering not cross referenced against diagrams. It was interesting to note they including dataflow diagrams , which is a largely non object-oriented
"functional" top-down problem breakdown approach, that shows inputs and outputs as data flows ( each node states it's function,
and input and outputs show what kind of transformation is done by the function of the data , and data sinks show storage ; very database oriented ) . Goal diagraming is about a different perspective where one isn't elucidating what a program does or how it should do it, but what goals/ outcomes should be met, and hierarchically organizing bigger goals into smaller subgoals. I suppose one could cross reference requirements functional points to goals, and see where the differences are.
Interestingly, we weren't required to include ER diagrams, although some people think class diagrams ARE ER-diagrams, except nice
functions are hung off entities as decoration.
The main point was t o number the functional points, and possibly grade as essential / needed/ desired ; also it was important to cross reference against a Gannt chart, which included what was to be done when and by who, and which tasks ; if one Gannt Charts the building of a house, it sort of makes things look achievable and concrete, I suppose.
On Fri Dec 2 20:45 , "Hilmar Berger" sent:
> --- Ursprüngliche Nachricht ---
> Von: Sebastian Hilbert <address@hidden>
...
> > Gnumed can't be everything to
> > everyone.
> True.
> > You have to decide what GnuMed should be.
> I wish it could everything for me. I see that it can do a few things for
> me
> right now. Regarding scalability. No hospitals. Period. My point of view.
Well, that's at least a starting point. I guess we can come up with more of
it.
> > Nevertheless, I'm
> > convinced that there *are* people in GnuMed that have a clear vision of
> > what GnuMed should achieve.
> E-Mail them to the list or me.
Ask your brother :). Ask Ian. Ask Richard. Ask ...
>I will create a page vision
> or
> something and add names or each individual linking to the individual's
> vision. Start writing now if you can so we have something ready when the
> wiki
> comes back to life.
OK, I will try to put something down soon.
> > True. There are specs, but we never took time to get a revision
> everybody
> > could live with. Which is sad, because this eventually means that all
> good
> > points which were raised in discussion will be buried in tons of mails.
> This is really sad. Let's form a team of volunteers to extract this
> information. Jim has done a great jon but cannot do it all alone. I will
> go
> back and try to extract everything that has been said on lab specs and
> archive specs.
>
> I challenge everyone else to pick a task.
I will try to come up with some spec framework where we can sort items in.
> Doesn't happen very often. I know the specs. I don't write them down.
> I always thought specs are there so someone else can follow them and code.
> I
> always thought that once I am done with a plugin it does what I need so I
> don't need to write down specs.
Sure, if you will ever be the only one who will touch this part of code,
this might be ok. But I for myself don't want to code the same thing all my
life.
> > need. 2. Written specs help you and others talk about the part of
> software
> > you are writing.
> True if more than one person is working on the same thing which does not
> happen with GNUmed. That's why I am a fan of defining small projects.
Nevertheless, GNUmed is a collaborative project and even single modules
should match the whole framework of the software (backend, other modules).
IMHO only few modules are really completely independent.
> people will follow. By the way Hilmar, you have some code in there as
> well.
Fair enough, I should start this whole effort. I'm sure I will need
collaboration on what the requirements are, say, for the drug browser.
> > the project team. GnuMed will probably not need an industry-strength
> > development process.
> Au contraire. It needs industry strength development process plus an
> experienced lead who acts like a dictator.
I can't really agree with you here. Teams lead by dictators only work if the
others are forced to stay in the team by some means. Which doesn't exist in
a voluntary open source project. We probably need somebody who has a clear
idea on what is to do next and who can motivate everyone to give its best.
Which is no easy task.
> > IMHO there is a vision (see above). Something you can put in two-three
> > phrases.
> I still cannot see the vision. What I can see is a vision of how parts of
> GNUmed should look like. That's what I would call specs.
To me, the vision is the goal of the project, e.g. "a software for medical
doctors outside of hospitals that should provide as much of functionality as
possible and should be able to interoperate with and integrate
third-party-software".
> > I don't see a problem if modules are done one by another. Just that I
> would
> > like to see specs for every module that gets coded.
> I will write those for my modules. It will slow down GNUmed even more than
> it
> does now but that's what most people on this list seem to want. I consider
> this as an experiment. if it doesn't work i can always go back to the
I guess it won't slow it down too much. You don't have to be perfect.
Usually, 80% of work take 20% of time. Having a 80% finished spec is betten
than none.
> 1st) document you own stuff
> 2nd) interview Karsten, Carlos, Ian , Richard, Horst, Liz, Jim, Syan ( yes
> I
> forgot people). Come up with questions and publish the interview as specs.
> Sounds like a plan for a start.
Sounds all right to me. As soon as I find time, I will begin to start this
work together with Richard, Jim and everybody who wants to join us.
Hilmar
--
Highspeed-Freiheit. Bei GMX supergünstig, z.B. GMX DSL_Cityflat,
DSL-Flatrate für nur 4,99 Euro/Monat* http://www.gmx.net/de/go/dsl
_______________________________________________
Gnumed-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnumed-devel
| [Prev in Thread] | Current Thread | [Next in Thread] |