Content deleted Content added
Pointillist (talk | contribs) →Other Aspects of End-user development: add section with summary of EUSE model, with reference |
Pointillist (talk | contribs) →Other Aspects of End-user development: quote and cite Pliskin & Shovan 1987, describe benefit and risk of end user-driven models vs providers' application frameworks |
||
Line 42:
In response to this '''End User Software Engineering''' (EUSE) has been defined as a higher level of EUD, whereby end users become motivated to consider security and verifiability when developing their solutions.<ref>{{cite web |url=http://eusesconsortium.org/findings.php |title=End-User Software Engineering: Empirical Findings|accessdate=2008=05-28 }}</ref>
All the above approaches assume that the user is developing software using tools already approved by a central IT function where "the user is naive, with little understanding of data processing.... but users should no longer be considered universally ignorant of information systems. Moreover, sophisticated information center veterans, as well as microcomputer users, can and do contribute to system development. They are capable of preliminary experimentation with system requirements, in particular those related to user interface."<ref name ACM_1987>{{cite journal |url=http://portal.acm.org/citation.cfm?id=1017817 |first=Nava |last=Pliskin |coauthors=Shoval, Peretz |title=End-user prototyping: sophisticated users supporting system development |work=ACM SIGMIS Database |volume=4 |pages=7-17|year=1987|issn=0095-0033|doi=10.1145/1017816.1017817|accessdate=2008-05-29}}</ref> In this case the assumption is that the tools have a high learning curve and require exceptional expertise to be deployed in a secure, reliable and scalable manner.
An alternative model is that end users (and/or their consultants) employ [[Declarative programming|declarative]] tools that support rigorous business and security rules at the expense of performance and scalability. This leads to a model whereby [[Requirements analysis]] and [[Software prototyping|prototyping]] are completed and documented by end user representatives without the intervention of [[Business analysis|business analysts]] who may have already accepted the limitations of a specific [[Application software|Application]] or [[Software framework]]. Senior management support for such end user initiatives depends on their attitude to existing or potential [[Vendor lock-in]]. In the most extreme cases, such end user prototypes formally prove the need for functionality that may result in IT contractors failing catastrophically, so this is not an approach encouraged by most solution providers.
== See also ==
| |||