CAPÍTULO 5. CONCLUSIONES
A) R EPENSANDO LA CONSTRUCCIÓN DE LA MICRORREGIÓN SELVA - NORTE
There is a long way to improve software process í from identifying symptoms of its ‘disease’, through diagnosis, to the proper therapy and successful results. Direct and indirect users’ dissatisfaction from software products are symptoms that software process needs the serious therapy. Technical innovations are not enough to satisfy users although the proven practices and tools should be still applied.
The author’s diagnosis is that the isolation of users in the software process causes stated problems. Usually a lot of people are involved by the software product. Unfortunately, in software engineering users stay still separated from developers. The conclusion is that the today’s approach and separation should be abandoned. This
conclusion corresponds with the Agile Manifesto1í its sixth principle says that the
most efficient and effective method of conveying information to and within a development team is face-to-face-conversation.
The recommended therapy is the UID approach. To sum up, its novelty insists in the briefly remained features: the level of user’s satisfaction from a product is a basic measure of software quality, users’ involvement concerns the whole process (indirect users are represented, too), users’ continual involvement makes a process resistant to constantly changed requirements, an initial survey helps to find out all potential users, users and developers are described by their personality types and various competencies, best practices of hard and soft methodologies retain in use, user-developer relationships are an integral part of the maturity assessment of a software process. The lack of never- ending corrections of software and the high level of its user’s satisfaction should compensate developers for the cost of this approach.
The measure of the successful result is the growing level of direct and indirect users’ satisfaction from software products. Most of criteria and implied metrics of a level of users’ satisfaction derive from the software quality characteristics recommen- ded in the ISO 9126. According to the particular product also the other metrics are specified [4], [5], including the time of service in particular cases (from applying for something to receiving the correct answer), the level of facilities available at work, the percentage of real cases supported at work by the delivered system, social atmosphere and comfort of work (as the quality of life), etc.
The emphasis on user’s satisfaction from a product requires different competencies of software developers than it’s been considered so far. Even knowledge of soft methodologies is not enough. The ability to cooperate with users, communication, business vision, ability to imagine functioning of an organization, an empathy for others í are the desired competencies, among others. New competencies require, in turn, changes in education at the university level [7]. Those competencies should be taken into considerations also in the recruitment process for studies and for a job. Some developers are preferred to work only in the back office rather than in the front office í in analogy to solutions applied in banking.
User-oriented methodologies cannot depend on someone’s good will only. In the author’s opinion, the maturity level of the software process should depend also on user- developer relationships. The author’s aim and research is to expand the CMM model. The proposal of the UR-CMM (User Relationship Capability Maturity Model), in analogy to the People CMM model, is under development.
1 Principles behind the Agile Manifesto, http://agilemanifesto.org/principles.html
So far, software companies are hardly interested to cooperate with users’ representatives. One example comes from the IBM í keeping the focus on what is being produced is an essential feature of the engagement model of the process [10], which consists of four components: Work Product Description (over 300 WPDs are in use), Work Breakdown Structures (WBD), a set of required roles (described by sets of skills), and a set of applied techniques. This approach and all specified roles are limited just to the producer’s side.
Agile approaches as the opposite to rigid ones are supposed to grow gradually as the users see that products of hard methodologies seldom satisfy them. The described UID approach can help to find a successful solution.
References
[1] Arbaoui S., Lonchamp J., Montangero C., The Human Dimension of the Software Process, Chapter 7 in: David Graham Wastell (ed.): Software Process: Principles, Methodology, Technology (1999), pp. 165í200 [2] Beck K., Extreme Programming Explained, Upper Saddle River, NJ, Addison-Wesley, 2000.
[3] Begier B., Quality of Goals – A Key to the Human-Oriented Technology, Australian Journal of
Information Systems, vol. 9, Number 2, May 2002, pp. 148í154
[4] Begier B., Software quality assessment by users (in Polish: Ocena jakoĞci wyrobu programowego przez uĪytkowników), Chapter 27 of the monograph on Problems and methods of software engineering, WNT 2003, pp. 417í431
[5] Begier B., Wdowicki J., Quality assessment of software applied in engineering by its users (in Polish: Ocena jakoĞci oprogramowania inĪynierskiego przez uĪytkowników), 4thNational Conference on Methods
and Computer Systems in Reasearch and Enginering, MSK’03, Kraków, 26-28 listopada 2003, s. 547í552. [6] Begier B., Customer relationship management in software company (in Polish: Zarządzanie relacjami z klientem w
firmie informatycznej), in: Software engineering. New challenges, WNT, Warszawa 2004, pp. 213í226 [7] Begier B., Suggestions concerning reorientation of software developers to focus on a broad spectrum of
users, in: Proceedings of the ETHICOMP 2005, Linköping, Sweden, September 22-15, 2005.
[8] Boehm B., Egyed A., Kwan J., Port D., Shah A., Madachy R., Using the WinWin Spiral Model: A Case Study, IEEE Computer, vol. 31, July 1998, pp. 33í44
[9] The challenges of complex IT products. The report of a working group from The Royal Academy of Engineering and the British Computer Society, April 2004, www.bcs.org/BCS/News/positionsandresponses/positions [10] Cameron J., Configurable Development Processes. Keeping the Focus on What is Being Produced,
Communications of the ACM, vol. 45, No. 3, March 2002, pp. 72í77
[11] Checkland P., Soft Systems Methodology in Action, John Wiley & Sons, July 1999
[12] Curtis B., Hefley B., Miller S., The People Capability Maturity Model, Addison-Wesley, Boston (2001) [13] DeMarco T., Lister T., Peopleware: Productive Projects and Teams, Dorset House, New York (1999) [14] Grudin J., Pruitt J., Personas, Participatory Design and Product Development: An Infrastructure for
Engagement, Proc. of the Participatory Design Conference 2002, pp. 144-161, accessed in May 2005 at: http://research.microsoft.com/research/coet/Grudin/Personas/Grudin-Pruitt.pdf [15] Hofstede G., Geert Hofstede™ Cultural Dimensions, http://www.geert-hofstede.com/ [16] Information About Personality Types, http://www.personalitypage.com/info.html
[17] zur Muehlen M., Business Process Automation í Trends and Issues, Center of Excellence in Business
Process Innovation, Wesley J. Howe School of Technology Management, Stevens Institute of Technology, Hoboken, New Jersey, USA 2004
[18] Pressman R., Praktyczne podejĞcie do inĪynierii oprogramowania (in origin: Software Engineering: A Practitioner’s Approach, New York, McGraw-Hill Companies 2001), Warszawa, WNT 2004 [19] Rajlich V.T., Bennet K.H., A Staged Model for the Software Life cycle, IEEE Computer, vol. 33, July 2000, pp. 66í71 [20] Scheer A.-W., ARIS Business Process Modeling, 3rd edition, Berlin – Heidelberg, Springer Verlag (2000)
[21] Stoner J.A.F., Freeman R.E., Gilbert D.R., Management, Prentice Hall Inc., (Polish version:
Kierowanie, 2nd ed., Warszawa, PWE (1999)
[22] Turner R., Boehm B., People Factors in Software Management: Lessons From Comparing Agile and Plan-Driven Methods, Cross Talk. The Journal of Defense Software Development, December 2003, pp. 4í8 [23] Wieger K.E., What Makes Software Process Improvement So Hard?; Software Development, February
1999, on-line edition: http://www.processimpact.com/articles/spi_so_hard.html
[24] Winograd T., Bringing Design to Software, Profile 14. Participatory Design, Addison-Wesley (1996). [25] Wood R., Payne T., Competency-based Recruitment and Selection, Chichester (UK), John Wiley & Sons (1998).