• No results found

The Advantages of a Software Engineering Project Management

N/A
N/A
Protected

Academic year: 2021

Share "The Advantages of a Software Engineering Project Management"

Copied!
7
0
0

Loading.... (view fulltext now)

Full text

(1)

The Role of the Software Practitioner in the Development of Public

Safety Software-intensive Systems

David Goedecke

Industry Specialist, Public Safety & Emergency Management Intergraph Corporation Pty Ltd

Level 3/420 St Kilda Rd Melbourne 3004, Australia

david.goedecke@intergraph.com

Abstract

Software Engineering is primarily a human process and consideration of human factors in safety-related software systems should always be mindful of the role that software practitioners themselves play in the delivery of those systems. As a Software Engineering Project Manager I have had responsibility for most aspects of the software development lifecycle and for guiding the software practitioners towards a successful outcome. This paper explores some experiences managing the delivery of software into the public safety-related emergency services environment, and the challenges of requirements analysis, design and implementation of software-intensive public safety systems.

Keywords: public safety software systems, safety-critical software engineering, practitioner competence, software engineering project management.

1

Introduction

Computer-Aided Dispatch (CAD) is the class of software solutions concerned with the management of calls for service and the dispatch and management of the resources assigned to attend to that request. Examples of CAD solutions that will be familiar are those built for the emergency services, roadside assistance, electrical, water and gas utilities, taxi services and transportation companies. A modern CAD solution will be built upon a Geospatial Information System (GIS) framework to provide a geospatial context for the call and the location of the resources eligible to service it.

At its simplest level a typical emergency services CAD workflow begins with the receipt of a call for service, perhaps from a member of the public requiring an ambulance or an automated signal from a fire alarm system. Data about the call for service will be collected and entered into the CAD software either manually by a call-taker, or automatically through an interface from an external system. The data collected during the lifecycle of the incident is usually important to an emergency services agency for the purpose of reporting, billing and payment,

Copyright © 2007, Australian Computer Society, Inc. This paper appeared at the 12th Australian Workshop on Safety Critical Systems and Software, Adelaide. Conferences in Research and Practice in Information Technology (CRPIT), Vol. 86. T. Cant, Ed. Reproduction for academic, not-for profit purposes permitted provided this text is included.

and interfaces will be in place to feed data (either real time, or batch) to external systems using a variety of protocols. Specific interfaces may also exist for providing connections to communication media such as mobile data systems.

Whether these systems ought to be classified as safety-critical, or whether mission-critical is more appropriate given that few aspects are fully automated and technologically-diverse backups are available, has not been considered to any great extent. Isaksen, Bowen and Nissanke (1996) list “ambulance dispatch systems, and the emergency call part of a telephone system” as examples of where safety-critical software can be applied. Evidence for this view comes from the 1992 failure of the then new London Ambulance dispatch system where it is alleged several persons died as a result of that system’s various failures. The functionality of a CAD system could be divided into safety-related and non-safety-related functions. For example reporting and analysis tools are considered non-safety-related (although still mission-critical), but other functions such as those concerned with verifying a caller’s location so that the correct resources can be dispatched as quickly as possible must be considered safety-related as an error in their execution has the potential to lead to harm.

There are several CAD vendors in the international marketplace; nearly all provide sets of COTS (commercial, off-the-shelf) functionality and the ability to extend their capabilities through the creation of custom enhancements and interfaces.

The design, development and on-going maintenance of these enhancements is however perceived differently by different system stakeholders: customers can sometimes fail to appreciate that it is more than computer programming. Yet public safety customers and the public at large are becoming more aware of the safety-critical nature of these systems, the role they play in the protection of their lives and property, and the consequences of their failure. Like many software systems a CAD system is complex and consists of a large number of inter-related components. The application of sound software engineering principles in this industry sector therefore is increasingly important.

2

Software “Engineering”

The term Software Engineering was first coined by Fritz Bauer at a conference in 1968 (Naur and Randell, 1969).

(2)

His essential definition of the term as “…the establishment and use of sound engineering principles…” in the construction and maintenance of software still holds true nearly forty years later. In some respects the currently accepted definition from the IEEE (1993) as “The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software” waters down Bauer’s original definition. The comparisons between the discipline of software engineering and other traditional engineering disciplines is of interest, and the following are some considerations of why and how they differ in this particular environment. Requirements are difficult to capture and express.

The requirements of an engineered software system are usually complex to express, and often impossible to capture completely at the design stage. The number of degrees of freedom is very large, and most large-scale project failures are caused by a failure to adequately capture and express requirements early in the project. No strong link between requirements and design.

Requirements are usually captured and expressed through natural language which aids understanding and subsequent verification. However because of this there is typically no inherent pathway from software requirements to software design, and design is often undertaken manually. Design patterns can enforce certain behaviours in the software, but the relationship between these patterns and the stated functional and performance requirements is weak.

No strong link between design and construction.

When software is designed manually the link between software design and construction is generally weak, and it becomes problematic to document an engineering “design” from which construction can proceed. In chemical engineering for example there are a number of ways in which a design can be documented: a mass and energy balance, a piping and instrumentation diagram, but each of these leads to a mechanical design from which construction can be undertaken.

Management of change is a priority.

Software requirements are subject to significant change, often (ironically) as a result of a better understanding of the problem (by both the customer and the supplier) as implementation proceeds. The management of change is therefore a significant issue in software development. The behaviour of software is not adequately understood. There is a poor understanding of software’s dynamic behaviour, and there are few models that are able to predict outcomes or constrain the behaviours of software that can be applied in a real-world context or with mainstream programming languages. Software systems are usually very complex with many interactions, again leading to large numbers of degrees of freedom. This contrasts with other engineering disciplines where behaviours of processes can be predicted from, and are constrained by, mathematical models. Additionally, in

software engineering mathematics is used to describe, rather than define and dimension.

A reliable estimation of effort is difficult.

Software construction is chiefly a consumer of time, not materials. Estimation of the time required to complete a software development task, and hence its cost, is difficult and often based only on prior experience or instinct. There are models and heuristics for estimation, usually based upon an analysis of function points or similar measures of functionality. These however are not effective early enough if requirements cannot be adequately described.

Methodologies and techniques are often inapplicable or do not adequately scale to real world problems.

Finally, methodologies for developing solutions to engineering problems usually assist an engineer in arriving at the best solution. There is a view among software practitioners that available methodologies are too cumbersome and get in the way of a good solution. Practitioners will therefore tend to avoid using them (Wells, 2001).

Each of these complexities has an impact on the way in which public safety software-intensive systems are designed, constructed and validated, and each has an impact on the management of the people involved in the practice of software engineering.

3

Human Factors in Software Engineering

3.1

Induction of New Software Practitioners

An understanding of the domain into which new software practitioners have moved is very important, and in the public safety industry one of the best ways found to achieve a level of understanding early on is to have them sit alongside one of the emergency services Call Takers or Dispatchers and passively listen in on their activities. In some instances they are also able to spend some time with the customer employees charged with the administration and day-to-day maintenance of the system. A public safety software vendor is often assisted in this regard by its good working relationship with its customers. New employees quickly gain a feel for the business, and the mission and safety-critical nature of the software they are writing and maintaining. Domain knowledge is more than simply understanding the internals of the software products.

Following this, new employees are usually given a moderate-sized development task to undertake, under the guidance of a more experienced practitioner, which introduces them to the software products and their usage in various scenarios. Most organisations in this sector are not a big enough operation to sustain a formal graduate or mentoring program; this one-on-one exercise is a good compromise and most new employees respond to it quickly.

Through both of these exercises a new software practitioner is assimilated into the project services team. How to determine when they are ready to work on a

(3)

critical function of the CAD system though is still very much a judgement call made by those practitioners supervising a developer new to the organisation. Both experience as a software practitioner, and domain knowledge within the public safety industry as it relates to the CAD software systems, are key attributes and must be assessed equally.

3.2

Software Lifecycle Models

For the most part, software development is in a maintenance or enhancement mode, and only rarely is there the opportunity to undertake a completely new dispatch system project. The work undertaken then is governed by existing Service Level Agreements (SLA) and Contracts, and for this reason the classic “waterfall” model of software development is generally most followed. Although criticised as out-dated and inflexible, the “waterfall” lifecycle enables several fundamental outcomes to be enforced (Davis, 1997):

• Plan a project before it begins.

• Define its external behaviours before designing its internal architectures.

• Document the results of each activity. • Design the system before coding it. • Test the system after it is built.

The use of this lifecycle model allows management to track the progress of development (at a very high level), the customer to approve the planning and functional requirements, and allows an estimate of cost and schedule to be made.

Where an enhancement is exploring new functionality that will add significant capabilities to a customer’s operations, especially where functional requirements and work flows are not well-known, prototyping or Rapid Application Development may be used. These however are the exception. Extreme Programming as defined by the XP community (Wells, 2001) is not a technique used as, again, contractual obligations mean that requirements must generally be signed off before development can commence. This does not however mean that subsequent change does not happen.

In the public safety arena there is a very good reason for this view: the customer agencies are very focused on their operations and the service to the public they must provide. There may also be legislative requirements to which they must conform, often by a specific date. They require proof early in the software lifecycle of the capacity of the system, or its enhancements, to deliver their required outcomes. Hence there must be a strong emphasis on documenting and agreeing upon the modules’ functional requirements.

Since most vendors in this space are commercial off-the-shelf (COTS) software vendors, organisations are generally not building complete engineered systems from first principles. There is risk associated with the development of individual modules for a new system, however the risks of the failure of any one module do not

generally put the entire project at risk. Risks in the implementation of a new CAD system that have the capacity to significantly impact the project tend to be items such as user commitment, expectation management, overall solution costs, user acceptance and training, and high-level political issues. The adoption of a particular software lifecycle model plays only a small role in the mitigation of these risks.

3.3

Capturing and Specifying Requirements

The functional requirements of a software-intensive system are complex to express and difficult to capture completely at the requirements stage. Generally public safety customers are familiar enough with their operations and workflows to be able to articulate their desired outcomes (that is, their business requirements) of an enhancement or modification, but are less familiar with the capabilities (and limitations) of specific software modules. The distinction between an outcome and a functional requirement is blurred; in most cases what the customer refers to as their “requirement” is actually an “outcome” required by their business. Requirements specification documents that are signed-off by the project manager and the customer, attempt to capture the functional requirements of the software as succinctly as possible and enable the match between software modules and outcomes to be made. In any organisation some development staff are going to be better at this than others, but eliciting requirements and writing a good quality specification are vital first steps in a successful software development project.

Unlike other engineering projects, a software engineering project must rely to a great extent on humans to not only capture requirements but to also describe and subsequently verify them. For this reason requirements are nearly always specified in natural language. Even so, public safety agencies at times can struggle to provide project team members that are able to describe their desired outcomes and requirements in a manner that is efficiently and effectively captured.

Sommerville and Sawyer (1997, p:118) describe a helpful requirements checklist that can be applied when reviewing and quality assuring requirements:

• There is no premature design or implementation. • There are no combined requirements.

• There are no unnecessary requirements (often termed ‘gold plating’).

• There is no use of non-standard hardware or software (given the platform being used). • There is a conformance with business goals. • The requirement is not ambiguous.

• The requirement is realistic. • The requirement is testable.

Of these, the last is important: a requirement must be objectively testable. Since capturing requirements in natural language is the more common practice, stating

(4)

them in such a way that an objective test can be written to validate that requirement is very important.

Formal methods can be used to document functional requirements in a more precise, mathematically rigorous manner, and their consistency proved formally. Few software vendors in any industry space have the expertise to undertake this, however it is an area that deserves greater research attention in the public safety industry space in order to make it more accessible to customers and practitioners.

3.4

Specifying a Software Design

Documentation of software design, as opposed to software requirements, presents challenges in finding a design paradigm that is inherently useful. Design documents are generally not approved by the customer, although they may be made available to them; they are intended as a means of describing to a software developer the essential constructs of the software modules. Since the original author of the design specification is usually the practitioner who will write the application, their chief purpose often is to assist in later maintenance of the application.

UML, state charts, data flow diagrams and pseudo-code are all useful in specific contexts; no single one meets all design specification needs. A minimum design specification should consist of an architectural diagram, supplemented by pseudo-code representations of specific algorithms. Entity relationship diagrams are also used where there is a high dependence on persistent data structures. Although there is only a weak path from requirements to design, for traceability a good design specification will reference the requirement(s) each design artefact satisfies. Patterns also play a role in documenting the design and it is expected that before undertaking an unsupervised development exercise a software practitioner will have a good understanding of the more common standard design patterns. It is also expected that they will understand any pitfalls in the use of some design patterns.

By this stage a software practitioner is usually itching to open their development environment and choose New Project, and discipline is required on the part of both the Developer and the Project Manager to ensure that they don’t launch into writing code before they have a good understanding of how it is to fit together. This is especially key when this application might be part of a larger system implementation involving many independent but inter-related modules.

3.5

Software Construction

A choice of language and overall architecture is not generally open to the software development staff. Language is governed by the existing frameworks into which the application or module is to be fitted, and the use of standard or proprietary libraries that provide discrete functionality. Although libraries and frameworks are available, there is no expectation that existing software components will fit together and operate as expected, and the amount of effort required to assemble

the components into a working application is relatively high. A certain level of abstraction is available through these libraries, but the software construction is more akin to scratch-building a scale model rather than assembling a kit.

This is not restricted to this one sector of the software industry; improving the link between software design and software construction is among the biggest challenges faced by the software development industry as a whole. Without an inherent link between design and construction, ensuring a developer builds to the correct requirements and design relies on regular design and code reviews. Code reviews also ensure adherence to the organisation’s published coding standards, some of which in turn are designed to assist developers in avoiding common programming traps. A typical coding standard will be a set of best practices that have been distilled from various sources, although that does not mean that they are not vigorously debated.

Standards do not just address language constructs. In the public safety industry detailed logging of user actions and tracing of program execution are important when evidence is required for an investigation or inquest, and the software practitioner’s challenge is to provide an appropriate level of detail at run time.

3.6

Managing Change

Changes to requirements are inevitable in any software project and the adequate management of change will often mean the difference between a project delivered on schedule and one that is not. Managing change is best achieved in this environment through a consultative approach between the customer, the project manager and the developer. In general, the project manager will authorise a change to the requirements provided that one of the following are met:

• The change request can be accommodated without impacting the delivery schedule for the module under development.

• The customer is aware of and agrees to any rescheduling resulting from the change request, and that there is an appropriate adjustment to the effort and therefore cost of delivering the module.

All requirements changes must be properly documented and approved through the same approval process as the original requirements. In the vast majority of cases requirements changes result in additional functionality needs, not fewer.

This does not mean though that all changes are necessarily accepted, and a change in requirements should not be allowed when there is inadequate consideration made of the impacts to the business in time, cost and quality.

3.7

Software Quality Assurance

Pressman (1997) defines software quality as “conformance to explicitly stated functional and

(5)

performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software.” A software module’s conformance to the documented functional requirements is assessed through the Acceptance Test Specification (ATS) for that module. The ATS is written in conjunction with the Functional Requirements Specification (FRS) and each test is explicitly referenced to a requirement. The ATS forms the basis of factory and user acceptance testing of the completed module. Conformance to explicit coding standards can be achieved through regular code reviews. Conformance to implicit characteristics expected of professionally developed software is harder to assess. What these characteristics are is more subjective than objective and can range from the correct spelling of user interface labels, to ensuring that defensive programming techniques are used to ensure unexpected inputs do not result in abnormal and unhandled program conditions. Acceptance tests, designed to judge conformance to requirements, do not normally contribute to an assessment of these implicit characteristics. Unit testing is one technique that is able to identify these faults, but the software must be designed for verification and not executed as an afterthought. Unit testing is also able to help the software practitioners gain an understanding of the dynamic behaviours of their implementations early in the build process, and can prevent them going down an implementation pathway that may lead to poorly performing software. Software developers need to be encouraged to place a greater emphasis on this level of testing, rather than concentrating on acceptance testing. Formal division of functionality into safety and non-safety-related functions has generally not been made. Thus little distinction can be made as to whether a function being implemented is a safety or non-safety-related function; the same processes are applied. In the public safety industry the end-users’ (admittedly unsophisticated) view of the “quality” of each deliverable does not vary; all functionality “should” always work “perfectly”. Therefore it is the best interests of the CAD software vendor to ensure that these expectations of quality are able to be met at all times.

4

Managing the Human Factors

Weinberg (1997, p:199) adds a further consideration to the complexities of software engineering, that of both process and people management. He identifies two broad causes of failure in the software engineering context: “information failures” and “action failures” (p:202).

4.1

Software Engineering Project Management

The information failures identified by Weinberg can be mitigated against through adopting a disciplined approach to the software engineering processes. This involves knowing “what” is to be produced, and “how” the implementation is to proceed and progress measured. Given the difficulties associated with describing software development as “engineering”, it is perhaps surprising that software engineering project management is able to

take many of its techniques from the project management of other traditional engineering disciplines.

An example of an industry-accepted project management methodology being used in public safety is PRINCE2 (Projects in Controlled Environments). In PRINCE2 a project begins with a business case, and at all stages the project is assessed against that business case. (Emergency service agencies are today considered businesses in their operation, although their mandate is less financially – oriented.) The Project Manager is responsible for the day-to-day management of the development project, but having executive oversight is the Project Board which consists of the Executive Sponsor, the Senior User and the Senior Supplier. PRINCE2 is not just a software development project management methodology.

The mandatory Project Plan defines the high level stages, the activities that are to be undertaken within each stage, and the schedule of those activities; the Project Manager is responsible for developing this plan and for its subsequent maintenance. The project stages are able to be aligned with the “waterfall” software development lifecycle that is more commonly used: assess and define the requirements of the solution, design the solution, build and test the solution, and deliver the solution. A Project Initiation stage precedes these software lifecycle stages; the Project Manager is also responsible for creating the Project Initiation Document (PID) which describes the business case for the project, the definition of each of the stages, project roles and responsibilities, quality criteria, and the risk log.

The completion of each stage is marked by the creation of an End Stage Report, which is the responsibility of the Project Manager. PRINCE2 ensures that for all projects these three fundamentals apply:

• The project has a controlled start. • The project has a controlled end.

• The project only moves from one stage to the next when directed by the Project Board.

The lifecycle model or development methodology used is only somewhat independent of the project management methodology. Using the “waterfall” model the development project is divided into identifiable stages, and it is these stages (at a macro level) whose transitions from one to the next are managed by the project management methodology. Enforcing the requirement that a project can only transition from one stage to the next when directed provides a level of discipline to the software practitioners and helps ensure they do not get too far ahead of themselves. It also ensures the business justification for the project is still present.

4.2

Project Direction and Motivating Factors

Since software engineering is predominantly a human process, directing and motivating the software practitioners requires an understanding of human behaviours and their management.

Generally speaking the Project Manager must lead and direct the project team, delegating authority where

(6)

appropriate, and resolving conflicts as they arise. Conflicts need not be interpersonal conflicts; conflicts in scheduling, requirements and implementation all need to be resolved in a timely manner for the project to progress and to be successful. “Action failures” often occur when the project manager is unable to act in such a manner. Related to motivation are the considerations of influence and power (how much power and influence does an individual have in the organisation or project, especially where it is directly to his or her work), and to effectiveness (what effective contribution is the individual making to the success of the organisation or project).

Software practitioners and their immediate project managers are in the middle of the triangle of Management, Customer and User. The company Management want a successful project execution without any surprises or overruns; the Customer wants an on-schedule implementation for the lowest cost (or greatest value for money); the User wants lots of functionality, fast response and ease of use. The role of the software project manager is to manage the expectations of all these parties, and at the same time provide sufficient direction and motivation to their team that they will produce a quality output. This is not an easy task.

5

Conclusion

The software engineering discipline is comparatively young, and a healthy debate continues about the processes and models that are the most effective in delivering and maintaining engineered software systems. The delivered outcome of a software engineering project is “soft” or intangible in the sense that it is not an object that can be held and inspected. It is the result of primarily a human effort, and the contrast between this and other traditional engineering disciplines highlights a number of areas where human factors play a significant role in its successful delivery.

The public is becoming increasingly aware of the safety-critical nature of these systems, especially as the distinctions between public safety, counter-terrorism and homeland security are increasingly blurry. Software practitioners must therefore demonstrate that they appreciate the mission and safety-critical nature of their work.

Software requirements must be captured in a manner that is precise and testable, and traceable to the expectations of stakeholders. Software designs must convey an understanding of overall solution architecture, and be able to guide practitioners in later maintenance and enhancements. Designing for subsequent validation allows conformance to requirements, conformance to explicit requirements of construction, and conformance to implicit characteristics of quality software to be rapidly assessed. Finally, the project managers and leaders of the software team must be aware of the motivating factors that affect their team members’ performance, both positively and negatively, and be able to control the software engineering process as it is executed.

Currently public safety software engineering processes mirror those of mainstream, commercial development and to move those processes to the higher level required of recognised safety-critical systems several considerations can be made:

• Is a formal identification of safety and non-safety functions feasible and justifiable in this context, and will customers and end-users (as well as software practitioners in this domain) be able to appreciate the distinction?

• Is it possible to determine a Safety Integrity Level (SIL) for these systems with any validity? • If so, what software engineering processes used

by public safety vendors need to be changed to meet the required SIL, and will this have an impact on the software process culture within those organisations?

• Is it possible to better model the dynamic behaviour of a public safety software-intensive system, in order to better understand its response to high demand conditions?

• Can all this be achieved in a commercially-viable manner within an off-the-shelf environment?

A public safety engineered software system requires stringent management of these software engineering and human factors to ensure that it is able to meet the levels of integrity expected of it, and fulfil the expectations of its users and the public.

6

References

Davis, A (1997) ‘Software life cycle models’ in Thayer R (ed) (1997) Software engineering project management, second edition. Los Alamitos: IEEE Computer Society. Institution of Electrical and Electronic Engineers (1993)

IEEE Standard 610.12-1990: Software Engineering. Los Alamitos: IEEE Computer Society.

Isaksen, U, Bowen, P and Nissanke N (1996) System and Software Safety in Critical Systems. Available at http://www.museophile.lsbu.ac.uk/pub/jpb/scs-survey-tr97.pdf.

Naur, P and Randell, B (eds) (1969) Software engineering: a report on a conference sponsored by the NATO Science Committee. Brussels: Scientific Affairs Division NATO.

Office of Government Commerce (2002) Managing successful projects with PRINCE2. London: The Stationery Office.

Pressman, R (1997) ‘Software engineering’ in Thayer R (ed) (1997) Software engineering project management, second edition. Los Alamitos: IEEE Computer Society. Sommerville, I and Sawyer P (1997) Requirements engineering: a good practice guide. Chichester: John Wiley & Sons.

(7)

Thayer, R (1997) ‘Software engineering project management’ in Thayer R (ed) (1997) Software engineering project management, second edition. Los Alamitos: IEEE Computer Society.

Weinberg, G (1997) Quality software management: Volume 4: Anticipating change. New York: Dorset House Publishing.

Wells, D (2001) ‘Extreme Programming: a gentle introduction’.

Available at http://www.extremeprogramming.org.

7

Acknowledgments

Thank you to my peer reviewers for their insightful comments.

References

Related documents

CallCenterJobs.com and TelePlaza.com provide an environment that facilitates this process of delivering relevant information to today’s buyer through Demand Generation. Location

Waste laboratory glassware that cannot be recycled and is free from biohazardous, radioactive and chemical contamination must be disposed as per the Physical Plant Services Lab Glass

Class K Shares of the Fund are available only to (i) employer-sponsored retirement plans (not including SEP IRAs, SIMPLE IRAs and SARSEPs) (“Employer-Sponsored Retirement Plans”),

Notwithstanding Lender's acceleration of the sums secured by this Mortgage, Borrower shall have the right to have any proceedings begun by Lender to enforce this Mortgage

Calculate viscosity (dynamic or absolute, and kinematic) and determine how this property varies with changes in temperature for a constant-composition multi-component

Figure 3 (above): Dumbbell Clean - Execution Phase Figure 4 (below): Dumbbell Clean - Catch Phase (catch the dumbbells on the shoulders while lifting the elbows as high as

Next, ask the students to use their prior knowledge of oil and water to predict what will happen if oil is put into their model ocean.. Further, have them predict what

Master’s Degree in Journalism Gedimino ave. This article is aimed at presenting a complex approach to the media autonomy concept, with particular focus on the most real aspects of