Menu
Home
Log in / Register
 
Home arrow Computer Science arrow The Privacy Engineer’s Manifesto
< Prev   CONTENTS   Next >

Methodology

System Engineering Lifecycle

Although the focus of this chapter is development of automated privacy mechanisms, the creation of processes and procedures will follow the same system engineering lifecycle (Figure 6-4). The system engineering lifecycle is a methodology that has commonly been used for at least 30 years. Some of the terminology has varied but the concepts remain the same. The familiarity of the design methodology makes it an excellent known best practice to leverage when adding in privacy specific requirements that may not have been raised at early phases of requirements gathering, planning, designing, and execution at the technical level.

Figure 6-4. System engineering lifecycle

The system engineering lifecycle is composed of six stages in which the project team adapts the tools and methods to the environment in which they are working:

1. The project initiation and scoping workshop stages look at policies and best practices surrounding the enterprise and the expected project or projects being considered (see Chapter 4).

2. The development of requirement use cases and class or data model states defines the enterprise and seeks to understand the business requirements sought to be addressed

(see Chapter 5).

3. The solution design stage includes prototyping the user interface for the project.

4. The implementation stage includes solution construction.

5. The quality assurance stage includes testing and user acceptance.

6. The final stage is solution rollout.

The lifecycle, at first glance, seems to be a “waterfalls approach,” where one step is completed and then handed off to the next step until the project comes to completion, but the dashed feedback lines in Figure 6-4 show that the process is actually iterative. Incremental improvements will be made to project deliverables throughout the lifecycle. This methodology has been combined with Agile techniques on many successful projects. (See the sidebar “Privacy Engineering and Agile Development” to understand how this approach and Agile techniques can be integrated.)

It should also be noted that inclusion of privacy principles in the technology and governance frameworks early and continuously through the system engineering lifecycle returns added important utility. The governance framework or policies must be updated or managed as policies change. The resultant systems will be better understood and documented.

Rich Schaefer director Technical Alliances, good Technology

various aspects of Agile development make it a very good fit for privacy engineering. A primary Agile tenet is to address customer needs by continually delivering working software that often must meet changing requirements. The customers for privacy engineering projects include internal and external stakeholders. Chapter 5 identified several actors present in use cases. The context diagrams in Chapters 7, 8, and

9 explicitly identify parties involved in the three scenarios. notable are business stakeholders, especially the data stewards introduced in Chapter 3. As key members of the privacy team, they are both customers specifying privacy requirements and participants in development. The original Agile principle[1]s include a requirement that businesspeople and developers work together on a daily basis. data stewards are the embodiment of the need for this type of collaboration. Their responsibilities include working directly with data analysts and database designers to develop data models.

Collaboration is inherent to privacy engineering, bringing together a wide variety of experts from different disciplines within business, privacy, information technology, and development. Agile project management approaches such as scrum can be used to bring effectiveness to such diverse teams. Agile scrums are mentioned as a best practice for coordinating privacy teams and their stakeholders to create and review metadata models in this chapter. Additionally, scrum meetings and sprints allow for timely adaptability to change. The need for flexibility to change is a recurring theme throughout this text. Privacy requirements can change due to factors external to the enterprise, including legal, consumer, and regulatory reasons. Within the enterprise, new business objectives, requirements, practices, and technology uses can have effects as well. Privacy engineering teams and their projects must be able to incorporate new requirements at nearly any point in their schedules. Agile processes enable the teams to prioritize changing requirements and even exploit such change for customer benefit.

The incremental delivery of working software via Agile sprints not only tries to guarantee that customers or their representatives receive what they desire, but also gives the opportunity for ensuring quality as the project progresses.[2] Regression testing at the end of each sprint may detect flaws that can be fixed within the following sprint(s). This practice avoids a shortcoming of traditional software approaches where quality assurance teams perform regression testing after development is completed and bugs are most costly to fix.

given the general discussion above, one may ask how Agile engineering practices relate specifically to the formal techniques espoused in this text and depicted in the system engineering lifecycle (figure 6-4). Use cases were introduced in Chapter 5 as the foundation for developing requirements for the system. They describe the needs of a user or actor and their answers to why, who, when, what, where, and how in describing the interaction within the system. Use cases can be seen as an agreement between customers and the development team.[3] Sufficient detail is provided for developers to understand what is required by the system and to embark on design.

User stories are a tool originating from the extreme programming (XP) Agile community for describing user needs and the planning of releases and iterations (their version sprints). Each consists of a few sentences, written in language a user could understand, expressing a single user's need representing an amount of work small enough to be reasonably well estimated. They serve as the basis for conversations with customers to flesh out more detail. Hence, use cases and user stories serve somewhat different purposes. However, accompanying user stories are acceptance criteria or tests that describe the conditions for their correct implementation. it has been noted that use cases and user stories plus their acceptance criteria are essentially equivalent. for much deeper comparison of use cases and user stories, see “Use cases vs. user stories in Agile development.”[4]

UML models, also introduced in Chapter 5 for class and data models, give structure to the solution being developed throughout the system engineering lifecycle and provide an explicit communication tool among internal and external stakeholders.

They have been applied for large enterprise teams and complex projects that have formal modeling methodology and documentation requirements. The Agile Manifesto values the interaction of individuals and working software over tools and comprehensive documentation. This apparently less formal approach has often led to the attitude that Agile methods are better suited to smaller projects and will not scale. However, significantly sized projects are referenced by Kent Beck

(40 person-years)[5] and Scott Ambler (several hundred person-years).[6] Additionally, Agile modeling for scaling has been advocated by the latter, the developer of “Agile Model-driven development” based on Agile principles from XP.[7]

Agile proponents have had mixed reactions to the use of UML. Some say the practices within Agile development user stories and acceptance criteria supplant the need for UML. The most positive seems to be that UML should be used to work through specific issues where it is useful rather than in an end-to-end, comprehensive fashion. Martin fowler's often-quoted article “is design dead?”[8] discusses traditional planned design vs. evolutionary design employed by XP. He includes recommendations for the use of UML diagrams alongside “Class-Responsibility-Collaboration” cards typically used in XP. He emphasizes their use is for communication and can be used effectively for design exploration and documentation.[9]

Later in this chapter, creation of test cases from UML diagrams is described.

A potential use of modeling, UML based or otherwise, has been proposed for the generation of test cases for tests-as-specification or test-driven development (Tdd), a technique from XP.[10] Tdd is iterative and proceeds by writing tests first and then developing code to pass the test. it produces simple code and is followed by continual refactoring or restructuring to avoid complexity and increase maintainability. Tdd alone could be a good development process to employ in privacy engineering, because policy rules (e.g., in the privacy component) could be embedded in the tests driving the development and acceptance tests.

The software engineering lifecycle can incorporate either the formal use case or

UML-based methodology in the text, employ Agile process management (e.g., scrum), use Agile engineering practices (e.g., from XP), or possibly a combination of these.

  • [1] Manifesto for Agile Software Development” at Agilemanifesto.org.
  • [2] The prototyping approach in this chapter is an example of incremental development.
  • [3] In fact, as mentioned in this chapter, first-cut use cases can be written by business users, with scrum interactions and a scrum review. This is not merely theory but fact at a major telecommunication company. These first-cut use cases could be considered user stories.
  • [4] “Use Cases vs. User Stories in Agile Development” and the links within this article at boost.co.nz/ blog/agile/use-cases-or-user-stories/.
  • [5] Kent Beck, “Test-Driven Development: By Example” (eecs.yorku.ca/course_archive/200304/W/3311/sectionM/case_studies/money/KentBeck_TDD_byexample.pdf).
  • [6] At a large-information-provider-over-200-person project, we used a combination of Agile and the UML-based approach discussed in this chapter. Chapter 9 is another example; well over 100 people were involved. Compare Chapter 8, where an intergenerational scrum was used along with UML modeling.
  • [7] “Agile Model Driven Development: The Key to Scaling Agile Software Development” at agilemodeling.com/essays/amdd.htm.
  • [8] “Is Design Dead?” at martinfowler.com/articles/designDead.html.
  • [9] The modeling, using UML, proposed throughout Part 2 of this book, is most effective where scrum-like modeling sessions and model review sessions, modelers, data stewards, privacy team, and other business stakeholders are held. In fact scrums have been used for good modeling before Agile and scrum terminology was being used.
  • [10] “Modeling in an Agile World” at nyu.edu/classes/jcf/CSCI-GA.2440-001/handouts/ modellinginanagileworld.pdf.
 
Found a mistake? Please highlight the word and press Shift + Enter  
< Prev   CONTENTS   Next >
 
Subjects
Accounting
Business & Finance
Communication
Computer Science
Economics
Education
Engineering
Environment
Geography
Health
History
Language & Literature
Law
Management
Marketing
Philosophy
Political science
Psychology
Religion
Sociology
Travel