Forcasting PEP consumers [was]: [snip] Event Planner Project
[was]Re: Event Planning Project
plug-devel@lists.PLUG.phoenix.az.us
plug-devel@lists.PLUG.phoenix.az.us
Fri Mar 11 21:42:02 2005
As for tech's like Java Webstart, you can think of it as a VERY fat client (like
turning a desktop application into an applet by altering the main extendable)
But a PITA to get the config rite.. Still it is a fabulous Idea. You point to
the app, it runs, you point to it enough and it loads it local, no more pointing ::)
LAMP is a bit hard to install in a pain free one click way (Or perhaps I am not
familiar enough to see how to do it..)
For Actual Client that want an off line one user version... I can only think of
my self... As for enterprise level N-Tier clients I can think of the LUG. I can
also project from my work designing databases and VBA apps for the Herberger
College of Fine Arts. They had fairly refined set of needs when planning their
various events (Fundraising, productions, exhibits, etc)
And I am sure we have all experienced wedding planning, intramural game
planning, etc., etc.
As for a real project does that mean we will be doing:
Executive Summary
Project Description
Project Objectives
Project Scope
Project Deliverables
Project Schedule
Business Analyses
System Architect
Use Case Diagram
Class Diagrams
Class Relationship Diagrams
Sequence Diagrams
Database Table Designs
Package Diagrams
Network Model Diagrams
Test Plan and Test Results (On each phase)
Post Mortem Review (on each phase)
Required Support
Project Documentation
System Documentation
User Manuals
Training Manuals
Maintenance Documentation
System Implementation
Application Installation Instructions
Etc. ?
And all the other goodies that make both a project both successful and a PITA :)
If So I believe we could really do something good and that will be very
successful :) If not it could still be interesting, but I would have far less
faith in its survival.
Quoting Trent Shipley <tshipley@deru.com>:
> Joseph, I was about to split this thread with a new subject of:
> "IFA project, PEP vision, and PEP working group"
>
> Of course I was really tempted to go for the title:
> "IFA project, PEP vision, and PEP squad"
> I had restrained myself, but without the discipline of a subject line I
> need
> not do so.
>
> * The Phoenix Event Planner working group are the associates of PLUG
> Devel who
> are working on PEP projects.
>
> * I see IFA as what we do *NEXT*. It is a proof-of-concept project. I
> tend
> to see it as a mini-project. The IFA project is not totally congruent
> with
> the overall PEP strategic vision. Nevertheless, the InstallFest problem
>
> seems to be a subset of the PEP domain and InstallFest has committed to
> being
> PEPs guinea pig, at least to the extent possible given InstallFest's
> loose
> organization.
>
> We still need to find out what our customer, InstallFest, wants from the
> PEP
> Working Group.
>
> * PEP has a strategic vision. It extends to a lot of potential
> consumers and
> many revisions over time. Because of a wide range of application and
> scale
> realizing PEP's strategic vision can be sketched as a timeline, but will
>
> require occasional changes in engineering and even architecture.
>
> There is still a lot of brainstorming to be done about PEP's strategic
> vision.
>
> On the other hand, because the viability of the project and it's group
> have
> yet to be demonstrated, system architects need to be a bit agnostic and
> quite
> sceptical about any strategic plans.
>
>
> On Friday 2005-03-11 17:53, Joseph Sinclair wrote:
> > I never viewed the Installfest as the primary customer. They are
> > providing a convenient focus to the initial iterations, but I never
> > intended to create software specific to installfests, I think I
> > mentioned earlier that if that had been my preference, I would have
> > created something really simple.
>
> You are correct here.
>
> What I am advocating is treating InstallFest as a "real" customer with a
> real
> account. Similarly, we treat the PEP Working Group as a brand new firm.
> The
> viability of the firm has yet to be proven. A "really simple" little
> project
> is just perfect for our brand-new little software production firm.
>
> We build something, finish it, use it. In the process we build PEP and
> are
> ready for a somewhat bigger project. (Yes. This is a wedding of
> agility
> theory with capability-maturity organizational theory.)
>
> > I don't think we ever discussed integrating the solution developed
> here
> > into the existing PLUG site. I, personally, don't think that's such
> a
> > good idea, given that the best way to do that would involve writing
> the
> > system as an extension of PostNuke in PHP. I think we did discuss
> > having an easy-to-use link, and perhaps permitting the
> > look-and-feel(L&F) to match the PLUG site L&F, but that's easy enough
> to
> > do in any reasonable architecture.
>
> In prior correspondence I had hoped to be clear that InstallFest
> consumers
> would see the public part of the application as part of the PLUG site.
> That
> is, integration at the level of look and feel only.
>
> InstallFest organizers and other volunteers would presumably have access
> to an
> administrative interface. Presumably it would be nice if the
> administrative
> interface had a consistent L&F with the rest of the PLUG site but its
> consumers would tolerate the product if it were a bit "rough".
>
> Basically, that is a long winded way to say we agree.
>
> > I've been working with lightweight methodologies, primarily XP, for
> > around 5 years now, and I have never been able to find in the XP
> > methodology anything that suggests you build your system as though
> the
> > current iteration is the entire system. You don't build
> *functionality*
> > not needed by the current iteration, but you do build this
> iteration's
> > functionality with the understanding of the entire release, and you
> make
> > architectural and design decisions with the entire project vision in
> mind.
>
> I keep thinking of (ASU Software factory's) Steve Gordon's hatered of
> software
> "requirements".
>
> As a software shop, the PEP Squad can work with InstallFest to build
> solutions
> for InstallFest. That is concrete.
>
> The problem I have is not that there should be a strategic vision beyond
> IFA
> and corresponding architectural plans, it is that architecture needs to
> be
> based on so many highly speculative functions ... it all amounts to
> theoretical business theory. I would feel MUCH more comfortable working
> off
> a larger architectural plan if I knew the plan was based not in theory
> but in
> grounded research.
>
> For example later on you will turn Bryan's hypothesized need for
> unconnected
> workstation operation into a user story. Unfortunately, it is only an
>
> *imagined* user story. I would be MUCH happier if it were not an
> imagined
> story, but based on utterances elicited from a potential consumer or
> analyst
> participant observation.
>
> At this point, of course, my opinion is based on too much education and
> too
> little experience.
>
> My concern is that coding to a strategic architecture at this point is
>
> premature. Right now a strategic architecture must be based on poorly
>
> grounded assumptions about consumers and markets. To do more
> architecture we
> should have more real customers and more real research.
>
> <important>
> As junior to senior, I want an explanation about why we have enough
> information to GENERALIZE the architecture WELL beyond the IFA account
> to the
> PLUG/AZOTO account (that I did not know existed until now) and beyond.
> </important>
>
> > I think these three things start to bring light to this discussion,
> > Trent. You are trying to see the "best" (i.e.
> > simplest/cheapest/easiest) way to build an installfest application,
> with
> > the installfest as a primary customer,
>
> Check. Although that is short term (2 quarters at most) and
> tactical.
>
> > and a strong desire to place the
> > final solution in GNUe.
>
> I am not married to GNUe. In the short term, I do not even care about
> it.
>
> I DO think that given what I see as PEP's strategic potential, that PEP
> would
> gain synergy by being a module in a FOSS ERP/M solution (and GNUe is the
> only
> one I know about).
>
> > I am trying to see the "best" way to build a
> > full-out enterprise event planning and management system with
> PLUG/AZOTO
> > as the primary customer (much broader needs there), the installfest as
> a
> > nice proxy customer for a few iterations,
>
> Like I said, I know nothing about the PLUG/AZOTO account. In business
> terms,
> I may not NEED to know more about this account, but I think I SHOULD
> know
> more about it.
>
> Also I am thinking more concretely in terms of customer+architecture as
> A
> project instead of an overall strategic vision and a grand
> architecture.
>
> <important point>
>
> So Trent's working methodology:
>
> * strategic vision = full-out enterprise event planning and management
> system
> in an ERP/M context
> ** Strategic vision will be changing all the time. Resistant to
> architecture
> ** Stratigic vision will be realized over time through many projects.
> ** Projects are informed by overall vision.
>
> * Customer = Project
> ** project has interations.
> ** Customers must be treated like customers. Each gets best eXP service
>
> available even if that is not maximizing for the strategic vision.
>
> Joseph's working methodology.
>
> * strategic vision = full-out enterprise event planning and management
> system
> ** Insure high quality, maintainable software by creating architecture
> NOW!
> ** Stratigic vision will be realized over time through many
> interations.
> ** Iteration = customer
>
> </important point>
>
> Of course, if we have two accounts, and do neither an injustice by
> sharing
> resources between them, then we should do that.
>
> Nevertheless, This means that the PEP Squad software shop has two
> distinct (if
> friendly) customers. It would be unethical to sacrifice InstallFest to
>
> PLUG/AZOTO.
>
> > a strong desire to see the
> > software built using the platform preferred by those willing to
> > volunteer as core developers,
>
> Fair enough. You cannot build software without developers and
> para-developers.
>
> > and a desire to ensure it actually gets
> > built, whether I like the final PAD(Platform/Architecture/Design) or
> > not.
>
> YESSS. Building something deliverable GOOD. Very GOOOOD.
>
> > Neither position is inherently right or wrong, they're just
> > different.
>
> Exchange of olive branches accepted.
>
>
> > As far as Bryan's request that a single-user solution be available,
> I
> > agree that, at some point, a single-user system should be available.
>
> Check.
>
> > Since it's utterly insane to expect an unsophisticated user (i.e.
> church
> > admin, "soccer mom", etc...) to install the LAMP components (or GNUe
> or
> > J2EE) on their workstation,
>
> Could not these be built to "auto-install" in a default configuration?
>
> > I would expect the single-user solution to
> > be an easily downloadable (PDM, Java WebStart, etc...) client
> > application capable of running in both online and offline modes, and
> > with the option to have no parent server at all.
>
> I am unfamiliar with these technologies. Are we basically talking about
> a
> "fat client"; that is, an application on the user's console?
>
> > This sounds a lot like
> > a user story, so I'll keep a story card for it, assuming Bryan
> agrees
> > with my description.
> _______________________________________________
> PLUG-devel mailing list - PLUG-devel@lists.PLUG.phoenix.az.us
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel
>