HW 1: Simplifiers and Complicators (S&C) (35 points)

Due:MondayJanuary 26, 2015, 11:59pm

Instructions: Complete the assignment and submit through Blackboard

Reading: Read EP-01 Requirements Engineering, Expectations Management, and The Two Cultures

File Naming Convention: LastName_Firstname_HW1.doc

“Simplifier” and “Complicator” are those features/requirements of an application that will make it easier or harder to implement. You may consider it as a simplified version or advanced version of your requirement or feature. Understanding them and being able to articulate the same to the stakeholders can help in better expectations management. There are typically two flavors in which they are usually encountered – for the client and for the development team

Simplifier / Complicator
Client / Characteristics of the application that would make the client feel ‘more at home’ / Characteristics of the application that would make the client more averse to using/deploying the application
Development Team / Characteristics or requirements of the application that would be easier to develop within budget and schedule and that would have a low learning curve owing to the team’s overall expertise in the application domain / Characteristics or requirements of the application that would make ‘life difficult’ for the developers i.e. a new technology, features that cannot be provided in the fixed time schedule etc.

The followings are examples of simplifiers and complicators from various project types

Although simplifiers and complicators for an application can exist in isolation they are more often found to exist as ‘opposite‐pairs’ i.e. simplifiers for the client are usually complicators for the development team and vice versa.

Examples of Client Simplifier vs Developer Complicator

No / S&C / Rationale
1 / Use of Natural language processing for querying the system / This is beyond the cutting edge of natural language processing (and the development team!) and would require a tremendous cost/schedule to implement.
2 / Client mandates the use of certain products because they are currently being used at the client side / Eg: The client may have deployed applications on web servers like IBM WebSphere or BEA Weblogic or Red Hat’s JBoss and would prefer to have the development team be able to develop/deploy applications for the same. The development team may not be familiar with these tools and thus becomes a complicator for them
3 / Adherence to specific
platforms/frameworks as specified by the client / The client may state that the project be developed using the .NET framework (or JSP, Struts, Hibernate, Spring etc) since the client’s maintainers are familiar with them – the development team however, may not at all be familiar with them and thus has to encounter a steep learning curve
4 / Using complex image processing or pattern discovery or pattern matching or association discovery among the data / The client may just ‘say’ he/she would want such complex features without realizing the technical difficulty involved in pulling it off i.e. Vague/Fancy business requirements. Eg: Recognizing a face when seeing through the security camera or discovering meaningful patterns in stored data. These applications are state of the art in Image processing and AI and would be non‐trivial to implement for the developers
5 / Voice recognition in applications / The client could demand flawless capabilities like those of science fiction movies without realizing that even different accents could deteriorate the application’s performance – and make life difficult for the developers

Examples of Developer Simplifiers and Client Complicators

No / S&C / Rationale
1 / Using Java or C++ as the development language over C# and .NET / The developers may have a high level of familiarity in the former than the latter – this would be a complicator for the client if the maintainers are not familiar with either C++ or Java
2 / Using compatible COTS packages / If multiple COTS are to be interfaced with each other, they should be compatible in this regard i.e. minimal amount of glue code would be needed to achieve this level of communication
3 / Using a single ‘information base’ / It would be easier for the development team if the data stored by the system were accessible/stored at a single location than getting it from disparate (and possibly disjoint) sources. The former would be more amenable for development.
4 / Uniform media formats / In case of multimedia applications, it would make life easier for the developers if the client would work with standard formats like MPEG, JPEG etc rather than arcane/proprietary formats for which convertors/viewers need to be custom developed.

However, there are risks associating with either the simplified version or the complicated of your project capabilities, hence you have to trade-off and pick the most appropriate choice for your project. The followings are examples of risks and trade-offs of simplifiers and complicators.

Instructions: Based on your team project, answer the following questions:

Assuming you may redo your project with no schedule constraint, you may improve your project by simplifying or complicating (advancing) your project requirements/ features.

  1. (5 points) Draw a block diagram explaining overview of your project, or specific module that you want to simplify or complicate
  2. (9 points) Provide 3 Developer simplifiers with supporting rationale
  3. (9 points) Provide 3 Developer complicators with supporting rationale
  4. (12 points) For each simplifier and complicators mentioned in 2) and 3), briefly explain about its risks and trade-offs.

Note:

-A simplifier does not have to be an opposite version of a complicator and vice versa.

Rubrics

1)Block diagram

  • 5 points – a correct and complete block diagram that explains an overview of your project
  • 3 points – a correct or complete block diagram that explains an overview of your project
  • 1 point – a block diagramthat explains an overview of your project

2)For each simplifier

  • 3 points – a simplifier with supporting rationale that simplifies the development and adds value to the project
  • 2 points – a simplifier with supporting rationale that simplifies the development
  • 1 point – a simplifier with supporting rationale

3)For each complicator

  • 3 points – a complicator with supporting rationale that leverages and adds value to the project
  • 2 points – a complicator with supporting rationale that add values to the development
  • 1 point – a complicator with supporting rationale

4)For each simplifier and complicator, risks and trade-off

  • 2 points – an insightful and appropriate risk and trade-off
  • 1 point – an appropriate risk and trade-off