Matching the Process to the Project

Gathering the Right Requirements
(Julie Blake, Business Analyst, Object Training)

Since returning I have been happily telling all and sundry that with this presentation, Julie was awarded the best Industry Track Paper for the conference - she's a BA and her presentation nailed the requirements process. Julie delivered case studies about two projects, contrasting the approaches taken and identifying lessons learned.

Project 1:

• 300 use cases.
• 6 experienced BAs.
• 4-5 months.
• Success - happy client.

Project 2:

• 100 use cases. (different level of detail; about same size ~300 under more analysis)
• 40 new BAs.
• 8 months+.
• Still going - trying Agile.

Both projects were mentored.
Project 1:

• BAs experienced.
• Customised templates and tasks.
• Fixed time frames.
• Clear, succinct high-level requirements.
• Clearly defined boundaries.
• Clearly defined interactions with external systems.

Project 2:

• Inexperienced BAs (from business or SW developers) - little or no training or coaching.
• 'Project office' customised roadmap and templates.
• Ongoing activity.
• High-level requirements too detailed.
• Cloudy project boundaries.
• New external systems were constantly discovered: 50-70 kinda involved.

Lessons learned:

• Don't spend too much time on detailed requirements up front.
• Team responsible for customising templates.
• Time spent on requirements eats into development time.
• Requirements and development should be done in parallel -> Agile.
• Avoid analysis paralysis.

When do you stop?

• Requires thought.
• Do developers have enough to go on with?
• Can business sign off?
• Have the complex parts of the solution [problem?] been captured adequately.

Essential requirements iterations:

1. Scope; Context; Capability.
2. Detail; Quantifiable Risk; Buildability.
3. Resolution; Completion; Testability.

Deadlines slipping - why?

• Too much detail up front?
• Problems getting signoff?
• Don't know what to do next?

Process may help - what to do next.

Customise the process:

• Every project should customise for project needs.
• Process chosen should be flexible enough for customisation.
• Agile is not always the answer.

Forces:

• Agile for high rate of change. <--
• and risk. <--
• --> Plan driven for depth of business user knowledge.
• --> and project complexity.

How do I customise?

• Key - experienced practitioners, not third party.
• Activities to touch lightly and in detail.
• Experience and coaching are required.
• Process does not turn bad BAs into good BAs.
• Need support for coaching to customise process and activities for BAs, developers and testers.

Experience makes the difference.

Q. Methodology?
A. UML, use cases, activity diagrams, sometimes sequence diagrams. Not casual. Any consistent methodology. Same methodology for each phase - more detail and elaboration.
Q. What size?
A. Is anybody going to need what I am writing? Break into small, bite-size chunks - subject areas.

Requirements engineering is important - vital.
Business needs to have, to state key project requirements that are clear [objectives!].
Detail of dozens/hundreds of use cases can change - in detail - does not affect key outcomes of project.

Panel on Standards and Accreditation

Panel on Standards, Accreditation and Joint EA/ACS Board on Software Engineering
(Prof. Leon Sterling, University of Melbourne, Chair Joint EA/ACS Board)

Joint EA/ACS Board has existed since 2001 - low key role in shaping professionals involved in software engineering. Cooperate rather than compete - three members from each plus academic and industry representatives, alternating Chair.

Bob Hart: Accreditation from ACS and Joint Board - primary role to cooperate on accreditation; should we have licencing and certification for SE and registration issues; role in running ASWEC (was alternating between EA and ACS). ~5 meetings per year - review of guidelines for accreditation - shapes accreditation visit, '... to the engineering [verb; gerund] of software.'

• SWEBOK as example of knowledge base.
• Best practice.
• Code of ethics.
• Team project.
• Clear course aims - not CS extended - articulate vision of graduates.

ISO standard on certification of SE professionals, 11 March 2007 - Bob Hart, Manager of Professional Standards and Development, ACS:

• SEPs work across international borders.
• Need for portability of professional status (Washington Accord for engineers; not all jurisdictions can meet).
• Cohort aspect of engineering degrees.
  
• Certify on basis of examination but no ongoing requirement in some jurisdictions.
• Common framework for evaluating certification schemes.
• ISO 17024:2003 standard for conformity and accreditation as a certifying body.
• Required to describe the type of SEP that certification covers: Title; tasks undertaken; level of accountability and responsibility; skills and competence, knowledge and cognitive levels; other assisting information to identify types of SEP.

Knowledge and skills:

• SWEBOK as comparison.
• Cognitive skills (eg. Blooms taxonomy).
• Other knowledge and skills not in SWEBOK.
• Generic professional capabilities.
• Appropriate standards knowledge.
• Domain (industry, application, &etc) knowledge and skills.

Evaluation - competencies, KAs, examination, reports, interviews, employer assessments, external examiners accreditation and QA.
Code of Ethics - minimum set of ethics; compliance; complaints and disciplinary processes.
Maintenance of Certification - period of certification and request for renewal; signed compliance statement from SEP; renewed commitment to code.
Continuing Professional Education - requirement for CPE; what and how much; compliance and sanctions.

How Open are we to Open Source?

(Michael Coates, Object Consulting - Java J2EE on Windows and Unix. Focus on solution architecture - Consulting, Development, Training and Support.)

Java development - relies on open source software on every project he works on including development environment and frameworks - in commercial and government. Java - lots of open source; Microsoft.Net - filling gaps especially Java developers desiring specific features.

Examples:

• Eclipse, Netbeans, xplanner.
• Ruby - mainly DSL for build processes.
• Some Linux and database deployment.
• Java language itself is becoming open source.
• JBoss, Tomcat - rare in givernment and enterprise.
• Few business, enterprise applications to match Office, Notes, SAP.

Australian National Archives has three open source projects on Source Forge. Infomedix - five major hospitals has systems based on Linux plus MySQL commercial licences. University departments - eg. 350 students onsite - open source everything, high reliability (uptime). Lesser GPL or Apache licence for reuse of libraries.

Licencing considerations:

• As a platform? ef. JBoss, Tomcat, Linux.
• As a library? eg. log4j, Spring, nHibernate.
• Modifying, borrowing from, eatending lib or product? eg. customer CMS.
• Internal solution.
• Developed on behalf of third party.
• Plan to distribute for free or for a cost.
• How to get new licence approved?

Barriers to adoption - Support:

• Forums, wiki pages.
• Community versus Enterprise licences.
• How does it compare to support for current solutions? Vary between the development team and the business users.
• Where do we get training? Available for mature projects.

Barriers to adoptions - Incumbent vendors:

• No one every got fired for buying...
• Cost of change for retraining, deployment. Need to have a significant reason to change.
• Bargaining.

Yet er're still using Open Source:

• Cost effective - existing skills, low cost to try.
• Open standards - avoid vendor lock-in; interop, duture proofing.
• Reduced time to market - particularly for development teams.
• Best of breed.

Trend towards greater focus on business domain components over technical domain, eg. model-driven architecture (MDA) for business patterns. You cannot sell infrastructure to business - OS projects focus on techies (devel tools, libs, OS). For wide adoption provide visible business value (CMS, CRM, ERP). Government agencies making open source available to wider community.

Architectural Knowledge Sharing

Prerequisites for Successful Architectural Knowledge (AK) Sharing
(Rik Farenhorst, Patricia Lago and Hans van Vliet)

Architectural knowledge not shared eventually dissipates. Sharing:

• Prevents loss of crucial architectural knowledge.
• Enables exchange of experiences.
• Enables reuse of expertise.
• Assists to train juniors.

Not so popular because:

• Costs time and effort.
• Lack of perceived short-term benefits.

People need to be motivated - incentives - to make them aware of intrinsic benefits and to induce people to share AK. Incentives for AK sharing:

1. Establishment of social ties - leading to increased transparency and trust.
2. More efficient decision making.
3. Knowledge internalisation - ownership of explicit knowledge; control, stored in own mind.

Study at large software development organisations identified four angles that need to be activated:

1. Context and environment.
2. Description.
   
3. Decisiveness.
4. Stakeholders roles and responsibilities.

Observed issues with AK sharing:

1. Lack of consistency between architecture and design documents.
2. Communication overhead between stakeholders - not properly-documented decisions.
3. No explicit collaboration with maintenance teams.
4. No feedback from developers to architects - architects may lack up-to-date technology knowledge.
5. No up-tp-date knowledge from development teams in repository.
6. No up-to-date knowledge from main customer in repository - reference architecture used by organisation.

Prerequisites for AK sharing:

1. Alignment between design artifacts -> [create] higher-quality knowledge -> [incentive] knowledge internalisation.
2. Traceability between architectural decisions and descriptions -> [as above].
3. Architect fulfil a central role -> minimise competition -> establishment of social ties.
4. Central architectural knowledge repository -> creates feedback loop -> more efficient decision making.

Goal: Effective tool support for AK sharing - close alignment to architecting process; lightweight and appealing to users. Solution: AK sharing platform that features explicit focus on collaboration, hybrid AK model (codification and personalisation), reuse of best practices, expertise, easy adding and editing. For AK that is hard to make explicit: Who has what AK? - 'yellow pages' and store unstructured information - blogs, discussion groups - searching and enriching this information.

ASWEC 2007

ASWEC 2007 was held at the RACV Club in Melbourne from 11-13 April with tutorials on Tuesday 10 April and was a great success. Expect several followup articles covering various sessions and presentations that I attended. Welcome by Prof. Doug Grant, conference General Chair - who gave thanks to authors, sponsors, Steering Committee and organisers.

Doug noted that it has been 39 years since the NATO conference (1968) held on German city of Garmisch, coined the term 'Software Engineering.' The theme of this years conference is an example of reuse, "Taming Complexity with Research and Practice.' Since that time much has changed: Thomas Freedman, 'The World is Flat' explores globalisation; ASWEC is a global conference that is located in Australia.

The charter of ASWEC is to communicate and share problems, solutions, to form partnerships. There may be impact from the Research Quality Framework (RQF) which seeks to assess the quality of research in each discipline. Research publications and local conferences appear to be disadvantaged by these metrics. Those is academia must influence attendance of conferences and members of university advisory committees should do likewise.

Competent graduates are the ones who can communicate well; they are snapped up by industry. Persuading young people to study in our universities - ICT - not for lack of places, we need ideas to reenergise and reengage young people in these disciplines.

Prof. Jun Han - few words about the program; research and industry track papers; keynotes; tutorials (yesterday). 100 submissions; half local, half overseas; selected 39 - reviewed by at least 3 (sometimes 4 to resolve issues). Selected 19 industry presentations. Mixed program of industry and academic papers by topic.

The keynote was delivered by Prof. Oscar Nierstraag, head of the Software Composite Groups - making systems more adaptive to changing requirements, visiting professor at the Sorbonne, coauthor of Software Reengineering Patterns - speaking about modelling change as a first-class entity. Kinds of change include configuration, refactoring, new functionality, run-time adaption, projects include: Piccola, Traits, Classboxes, Persephone and Geppette, Object Flow Analysis, Moose, Changeboxes to encapsulate change. Software inevitably changes but program languages and development environments inhibit change rather than support it. Symptoms include assumption of global consistency, static type systems, design patterns - covered in 'On the Revival of Dynamic Languages.'

Piccolo. Problem - reconfig application (without changing eveything). Solution - composition language - application = components + script. Separates stable components from flexible configuration. Scripts plug together (not wire) components and define style of composition for plugins. Lessons - first-class namespaces enable flexible composition, eg. sandboxes; conceptual gap between core and target models (components, plugins and styles versus agents, forms and channels).

Traits. Problem - refactoring commonality (without introducing fragility). Solution - factor commonalities into traits (mixins and multiple inheritance are fragile); resolve conflict locally. Traits are parameterised behaviours that provide and require methods - no state (assumption may be weakened) - class = superclass + traits + glue.

Classboxes: Controlling visibility in class extensions. Problem - changing a running system without anticipated hooks. Solution - refactor on demand - partial, behavioural reflection. First idea - ByteSurgeon to transform Smalltalk code.

Persephone. Reflection methods - higher level - byte code plus abstract syntax tree (AST).

Geppetto. Behavioural reflection on demand. Lessons - reflectoin enables analysis; reflection need not be expensive; should be scoped to relevant contexts (eg. Lists in application context).

Moose. Extensible metamodel repository - navigation, metrics, querying, grouping - tools for enabling research. Java, Colol, C++ - XMI - import to enable model-driven development, explicit and available at runtime. Enables "ever more fine-grined changes" without artificial separation between source code and compilation (eg. Smalltalk and Eiffel).

Certainly an interesting and stimulating talk by the keynote speaker. My own notes and several pointed questions and remarks raise the question, "Is this software engineering?" Some of these techniques approach the mainstream insofar as dynamic interception can be implemented with run-time proxies using reflection; the Spring framework allows for wired configuration at run-time; the new keyword in .Net localises the context for a method extension; Corba using the dynamic invocation interface.

The issue of regression testing, verification and validation to give confidence in the run-time is similar to proxy interceptors, SQL triggers and aspect-oriented programming. It is ironic that low-level techniques are arising to allegedly solve problems with the object-oriented approach to design but aspect-oriented programming, while described as orthogonal to object design, is at a lower level of abstraction.

When asked about bugs related to threading, locks, logging, transactions and similar, I usually say that the design is flawed - no amount of hunting will track down the elusive bug if it isn't there in the first place. Go back to analysis and design to isolate the parts of the system that are variable from those that are general - see, for example, Coplien's Commonality-Variability principle. Software engineering is more than just programming.