.: Home >Services > Whitepapers > Guidelines 

 Guidelines for Software Development
 

Last Date : May 7, 2001  Release 2.7

Solutions Engineering Corporation

Purpose.  

The purpose of these Guidelines is to the improve the quality of products we provide our customers/clients and to decrease the costs of these products to our clients.  The purpose then is to focus on three subjects ­ 1)product, 2)quality, 3)cost.    Everything in today’s literature regarding these three subjects is centered around “Process”.  Vanguard among these is “Six Sigma” (Motorola and GE’s mantra for successful improvement in product quality and profitability), CMM (Capability Maturity Model advanced by the Software Institute), the Unified Software Development Process (Jacobson, Booch, Rumbaugh), and RAD (Rapid Application Development).  Nothing in the Guidelines is particularly unique to this text.  Everything which appears here could be found in one or more current “Best Practices” books or articles in the field of application software development.  We have simply distilled these down to the essentials relevant to the development of client-focused application software.  We have also combined these with the lessons learned in more than 20 years of experience engaged in this work. 

Software products are not just executable code.  The product includes :

§         executable program(s),

§         installation process,

§         user documentation,

§         system and installation configuration documentation,

§         support documentation,

§         collective knowledge regarding the use, maintenance, and properties of the product.

Depending on the needs of the client, the product may also include :

§         data migration,

§         user help desk,

§         version control,

§         sequential or overlapping version planning,

§         multiple platform support,

§         integration services,

§         and others.

The quality of our products is defined in several terms :

  • Full Functionality in relation to the complete and prioritized set of needs as defined by the client,
  • Automation - Workflow of the system in relation to human process and time ­ minimizing both,
  • Usability - Time required for users to gain operational proficiency and confidence, often referred to as “user friendliness”.
  • Stability - Error free operation and use, regarding execution path and database states,
  • Vulnerability - Time and effort required to recover from system disaster,
  • Extensibility ­ ease with which the product can be modified to accommodate evolving client needs - workflow models, analysis requirements, systems interfaces, user loads, data volumes, etc.

The costs of products are the result of the complex combination of resources required to produce the required product/quality.  These resources include :

§         Personnel (in-house and contract)/expertise hours,

§         software/hardware tools,

§         systems configurations,

§         existing components,

§         risks and risk control techniques,

§         calendar time,

The most costly of these is usually the personnel/expertise ­ the people with specific expertise required to produce the target product/quality.  In fact, the cost and strategies for mitigating the costs of the other resources revolves around how it will impact the costs of personnel/expertise.  Every project is filled with lots of decisions ­ what to do, what not to do.  Every project consumes additional resources because actions were taken which did not improve the product measurably.  If an action does not improve, or has a low likelihood of improving, product functionality and quality (in terms valuable to the client) then it should not be done.  These actions delay projects and confuse and distract the team members.

We aspire to improve product quality and project efficiency through these Guidelines.  Every project definition will have the following sections or elements :

§               Background

§               Requirements

§               Risks

§               Design

§               Development

§               Test

§               Document

§               Support

§               Enhance

All of these sections or elements are completed in a timely, complete, and logical manner through careful planning and execution.  This is accomplished through the continual monitoring and management of a program manager.  This is an often overlooked resource required to maximize the efficiency of all project resources.

Background.

The Background provides the environment of the client, through the perspective of the client.  It defines in very brief terms the domain of the client ­ their business model, their operational properties.  It provides the context in which the project or system is developed.  The Background defines an overview of the customer problem domain, providing :

  • business model of the client,
  • operations and workflows of the client,
  • an overview of the problem/project,
  • scale and scope of the project,
  • number of users or personnel affected,
  • current workflow and systems being replaced or enhanced,
  • types of users and stakeholders and critical issues regarding these,
  • factors affecting value or importance of the system. 

This might include the vision and mission of the customer, the expectations of the customer should be identified.  Sections of the customer web site or published material may be included or referenced here.

Requirements.

This section should include all of the requirements of the system.  If a requirements management system is already in use, then the Project reference should be provided and the output text file from the system should be included in this section, or be in an Appendix referenced in the requirements section.  Regardless of how the requirements are being recorded, each should have the following attributes :

§         Name ­ short unique reference,

§         Description ­ brief, concise description,

§         Status ­ indicates status at the particular time (Proposed, Approved, Disapproved, Design-valid, Tested),

§         Priority ­ indicates importance to Project (Critical, Important, Ancillary),

§         Estimated Cost - (personnel time ­ many times this awaits Use Case definition),

§         Risk level - associated with the requirement (Critical, Significant, Ordinary),

§         Category ­ groups it to a logical grouping for the Project (see below),

§         Author(s) ­ persons identifying the requirement as such,

§         DateCreated ­ the date this requirement was created,

§         DateModified ­ the date this requirement was modified (change of any value),

§         History ­ may be required for larger, more complex systems.


This section must be comprehensive and indicate the sequence in which the requirements should be met (its target release number and its priority).  All requirements should be grouped according to subject matter.  Mandatory subjects include:

1)     Organizational Requirements.

a)     Objectives for the system or project.  What are the primary objectives to be attained in the construction and implementation of the system?  What are their priorities?  What are the measures of success for the project?  How important is each to the overall measure of success?  These should provide a very clear definition of the goals of the system ­ the metric for project success or failure.

b)     Constraints.  What are the constraints which must be met?  Are there budgetary constraints, time constraints, personnel time commitment constraints?  Do the objectives need to be met in stages?  Will it improve the overall ROI (Return on Investment) if the system is deployed in stages or will it result in too great a disruption to the operations and staff training and transition?  Constraints define the limits of features and capabilities.  There has never been a real system constructed where costs and time to deploy were not limited.  All too often the question “Can you do feature_Z?” is answered strictly on a technical basis, ignoring the budgetary and time constraints.  These are as real as any technical limitations and should be treated with the same respect.

 

2)     Functional Requirements

a)     Workflow (Areas identified for each functional operation of the customer problem domain, the support of the workflow must be complete within economies and provide for the completion of each required workflow), Allowing user selectable variability in the workflow, or strictly enforcing specific workflows, defining allowed variability through setup operations.

b)     Automation (Objectives in workflow automation; requirements and constraints on these operations),

c)     Human interface requirements, error trapping requirements (stringent or relaxed), the expertise level of the user community, the areas where data quality is critical and where it is less important, Section 508 compliance,

d)     Business Rule Enforcement ­ rules which affect object properties and behavior, possible states, possible state changes, the range of rules, their classification, how they will be defined (maintained) and how they will act,

e)     Report Writing/Analyses needed in order to support management or business decisions.  This includes the fixed or scheduled Reporting, ad hoc Reporting, Charts, Line Graphs, Bar Charts, Pie Charts, Tables, Summaries, Statistical Analyses, data selection/manipulation/export.

f)       Systems Interfaces needed to inter-operate with other systems needed by the client.  These might include Accounting systems, Data Collection systems, Personnel systems, Asset Management systems, Security Systems, or others.

 

3)     Nonfunctional Requirements

a)     Target Workstation Environment,

b)     Target Server & Infrastructure Environment,

c)     Network architecture, bandwidth, and shared load environments,

d)     Time/Work/Personnel properties,

e)     Training requirements,

f)       Acceptable support resource requirements,

g)     Security,

h)     Portability, Extensibility, Enhanceability, Supportability,

i)        Other.

 

4)     Non-Requirements ­ if there are any requirements which are intuitive or reasonable to the analyst in the context of their understanding of the target environment, but are declared non-requirements by the stakeholders, it is wise to record these explicitly.  Building systems to meet non-requirements is unnecessarily expensive, time consuming, and complex.  This is where wish-lists are pruned to a list of intelligent investments.

 

Risks.

Each and every known risk for the system should be identified.  A risk is anything which could hinder the system from meeting the stated requirements or jeopardize the feasibility of achieving certain goals in a project.  This includes meeting operational, timeline, and/or budgetary constraints.  Virtually every software, database, or data warehouse project which fails or is terminated is the result of failure to identify risks and their importance at the time they were knowable.  In most cases the plug is pulled after the project consumes substantial resources.  No one likes to hear about risks.  It is important to keep team spirits high and the energy focused.  But risks are real and have very real consequences to project viability and success.  The irony is that risks are much like any other project issue or property ­ the closer you embrace the matter, the clearer the solution becomes and, if dealt with properly, risks become tasks.  They get identified and characterized, and then they are overcome.  Some risks however dramatically change the resources required to meet project goals.  This is time for management to modify the goals/requirements, change resource allocation, or sometimes scrub the project.  No one likes to scrub projects.  Team members invest some part of ourselves (our lives) in a project and much of our reward is seeing the result and its affect on the client organization.  But it is far better to scrub a project earlier than later ­ saving money, time, and opportunity.  All risks encountered in the process of Requirements Definition and Data Source Definition will be described in “risk” sections of their respective documents, which comprise the project deliverables. 

Potential risks include :

1)     Requirements related ­ are the requirements complete and properly understood,

2)     Requirements in the context of the constraints ­ is it feasible to meet all of the requirements and the defined constraints?

3)     Technical issues ­ can the required system be constructed to operate within required parameters on the target systems with the defined tool set?,

4)     Unconfirmed technologies or tools applied in a new manner,

5)     System components which may present issues when operating in the target environment (e.g., will the database operations perform correctly over the designated bandwidth?),

6)     People resources, experience, expertise, continuity, (is all the necessary talent onboard in each area of the project - project management, systems analysts, design, database engineering, programming, testing, configuration engineering, documentation)

7)     Funding and Time availability,

8)     Stakeholder expertise, consensus, and availability (e.g., will client personnel be available to resolve questions as they arise?  Will they agree on issue resolutions?  Do they have the expertise to provide informed, correct, and complete guidance on problem domain issues?  Can they articulate the requirements for the project?),

9)     Ambiguities of business rules or lack of resolution among stakeholders regarding business rules,

10) Inherent subjectivity of some subset of business rules.

 

Design.

The system design is comprised of all of the material which communicate how the target system is to behave.  All systems produced under direction of these guidelines will be “Use Case Driven”.  The design will be composed almost exclusively of the UML components required to clearly, accurately, and comprehensively define the target system.  Every system detail which is uniform across all systems developed by our teams, is covered in “Systems Engineering Guidelines”.  These guidelines should be used throughout all systems unless countermanded by the design of a specific system.

The Data Dictionary and Class Diagrams of the system will be defined according to the needs of the system as required by the business rules of the system domain, the reporting requirements as defined by the stakeholders, and cooperating subsystems in the properties and requirements of related systems.  The developers are at liberty to add to the dictionary if needed in the course of implementation (to enhance performance, improve human automation, enforce data consistency, or meet the needs of other issues).  In most cases The Class Diagrams (data dictionary) have undergone considerable review and examination.  Therefore changes are not recommended to be made in development without consultation with the design team members.  In many cases the design team will intentionally deviate from rules of normal form in the data dictionary.  This is done when refining the dictionary from the perspective of performance, information preservation in the context of deletes and archives, data availability for user interfaces, user response time, and automation techniques.

In some instances the design materials may include the dialog definitions for specific dialogs where the physical organization of the dialog components is of particular importance to the success of the project.  However, in most cases these dialogs are to be constructed by the developers under direction from the “Systems Engineering Guidelines”.

As the number of systems we build increasingly expand out to general use on the web, these systems become views of the host companies, presented to groups of users.  These systems include artistic content and are characterized by styles, colors, visual or graphic content, sound, and motion.  They permit deviations from norms in system-human interactions which the client may see as desirable in order to achieve brand recognition, market distinction, or some other desired property.  These are challenging to developers as these elements introduce tremendous source of variability in the ultimate properties of a system.  In such projects it is desirable to obtain the client preferences in this area as early as possible, or at least before operational code is integrated with graphic or presentation content.  Changing the artistic or graphic content in areas where there is a substantial amount of operational code can substantially increase time requirements and costs.  A very good way to address this issue in the design phase is to present to the stakeholders a broad set of graphic options and have them provide a consensus position on what is liked and what is not, what their preferences are across the set of stakeholders.  If there is a conflict resolution required, be sure that it is resolved in the favor of the stakeholder(s) who are authorized to provide the final say in graphic content.  It is often a very good idea to get this person identified via e-mail or printed correspondence at the beginning of the project.

All data modeling in the design phase is to be performed with ER/Studio.  All of the meta data properties are to be fully defined in the logical modeling phase.  All model components are fully documented in the design phase.  All fields are assigned types, defaults, ranges, accessibility, and are fully described.  Associations are fully defined in logical model terms.  Entities which have an exclusively “choice list” role are named with the prefix “CL_” to group them and denote their limited purpose.  The logical model is to be synchronized for round-trip engineering with the Class Diagrams (and soon the State and Collaboration Diagrams) of GDPro (Describe).  The physical model is to be automatically generated from the logical model.  The model is to be evaluated with ER/Studio Model Analyzer to evaluate the “correctness” of the model.  Data models are modified to meet certain Analyzer objections.

“Describe” (formerly “GDPro”) is to be used to perform all other software systems modeling, providing those UML artifacts needed for the design of the subject system.  The Class Diagrams are extended to define the necessary methods for each class.  The Use Cases, Activity Diagrams, Statechart Diagrams, Collaboration Diagrams, and Sequence Diagrams are to be constructed and maintained in Describe.  Additionally, where needed the Component Diagrams and Deployment Diagrams will be maintained with Describe.  The application base Classes for the target development language are to be generated with Describe.  These processes will guarantee consistency between the Data Model, the UML Model, and the actual Code.

Prototyping.  Many older systems included the development of a prototype in the course of design.  These often served as the “working basis” for evolving the target working system.  Prototypes are like any other design tool ­ when used judiciously, where they provide value, they are a great benefit to the development effort.  Many times they are used to support an informal software development paradigm of “known when seen”, or “I’ll know it when I see it”.  That is, the stakeholder(s) cannot articulate their requirements, but they will know the system which meets them when they see it.  This is a very hit or miss approach.  It can consume incredible resources (time and money), and has no assurances that the resulting system will actually meet any requirements.  Approaches built on this paradigm generally are abandoned.  They can be used to articulate the stakeholders’ requirements ­ although at a very high cost.  The greatest risk of using a prototype is that the requirements definition takes a back-seat priority to prototype refinement.  Stakeholder Requirements are the core of the software development effort, not refinement of work in progress.  This type of role of a prototype can easily (and cheaply) be attained by building some of the more important user interfaces (dialogs critical to the workflow of the application) and performing a “walk-through” with the stakeholders.  This provides a means of seeing the interface and making adjustments without the expense of providing all of the data-flow underneath.

The most useful role of prototypes is in risk assessment/abatement.  Most useful systems today have risks.  Some of these risks are project critical ­  one or more of the critical objectives of the project cannot be achieved if the risk(s) cannot be overcome.  A quick to deploy prototype, constructed and tested early in the project, will provide a great value to the success (or cost aversion) of the project.

 

Development.

All of the materials which are produced to actualize the target system are an essential part of the development.  Most obviously these are the source code, library files, executable file(s) and all of the dependent files.  The following is a more complete list of the development materials and what are expected to be included:

1)           Installation CD Image ­ a zip file comprising all components of the installation CD.  When unzipped in a target folder, the contents of that folder (and all recursive sub-folders) provides all of the material required to properly install and configure the system on a target workstation, server, or both. 

2)           All Project or Make files and all files on which these depend. 

3)           Clear documentation on compilation and link (or build) options which are required for correct reconstruction of the installation components.

4)           Clear definition of the tools employed in creating the development components and those required to properly edit the development materials.  This should include the manufacturer, product, release, service pack or update, additions to the control set, each library (device) which was used. 

5)           Clear definition of any support file or reference file or database access required by each subsystem component.

6)           Any documents or files which record design refinement, risk resolution, requirement modification, or other decisions or inputs which were made in the development efforts which have not become part of the requirements or design materials. 

7)           Error/warning/message file.

8)           Start up splash screen image file. 

9)           The user help text file replaced with expanded help text file as the project cycles through text validation and Quality Assurance.  This file is overwritten during documentation updates cycles, but binding a specific file in early allows better independence and progress of the team. 

10)       Deployment instructions ­ these are the explicit details of the deployment instructions.  These include the configuration requirements of the target platforms(s) (for example, Microsoft NT Server 4.0 installed as a general server, SP6, IIS 4.0 (Option Pack 2, SP3); MS SQL 7.0, SP2).  Any services, which must be running in addition to core services of the identified components, must be listed.  If the delivered system is known not to work in specific configurations, these should be listed (e.g. host server must have fixed and published IP address; connection not confirmed through NAT or Proxy Server, or DHCP).  The specific release of drivers for target deployment should be listed, particularly if there are known or possible driver instance sensitivities in the application.

 

Test.

The focus of this section is to verify that the product system meets the specified requirements and validate the system against the design.  The primary guidance here must be the requirements.  The requirements must be met by the system.  How these requirements are met is defined by the Use Cases and the Scenarios defined for each Use Case.  This is the first focus of the test cycle.  These must be a natural, expeditious, easy-to-perform procedure to execute with the software for each Use Case.  Use Cases are often supported directly by a menu option or event.  Each Use Case scenario is represented by a possible path (generally through a series of actions or options, buttons or other event centric options) of the event.  The software must be tested to verify that each scenario is supported and performed correctly (prescribed actions, state changes, dialogs…) are instantiated in the system.  This is the functional test.  There is no need to advance to other test issues until the target functionality is achieved as the system will be modified considerably until the functional target is achieved.  As soon as testing is commenced a Control Document is created for the system.  From that point forward, the same Control Document should be used until testing is “complete”.  For long projects (more than 6 months) it may be desirable to break out a new Control Document ­ rarely should there be more than 2.  As solved issues are tested and verified they may be merged into the original Control Document.  A history of Control issues is extremely important for a number of reasons :

1)     Older issues may be revisited and the decisions made months ago may be completely valid at the current time, or may need to be revised.  Being ignorant of the previous design decisions results in thrashing or churning of issues without efficient closure on these issues.  It is extremely useful to have the history of issues available in very few places.

2)     This provides a single reporting for every issue which was identified in the course of testing.  It also provides a small number of places where this documentation might be found. 

After the operation has been verified functionally correct and complete, the operation should be tested for technical correctness.  This includes the correct computation of dependent values at every step of the operation ­ the business rules should correctly affect the displayed values and the values which persist in the database.  These tests must verify that both sets of values are correct in the context of input values.  These should be tested in combination sets and represent the range of required supported values.  Included in technical correctness are the proper dispositions of resources that may not be apparent or observable by simply executing the program through its various dynamic paths.  These resources include file handles, file or record locks, memory (heap), daemons, threads, and sessions.  These resources must be acquired and freed according to the application requirements.  While it is impossible to prescribe their use in each case, there are some very useful rules of thumb.  File handles should be acquired and freed in the same program unit or in related units called from the same unit (to assure symmetry ).  Acquiring file handles, assessing file existence and status compatible for the requested rights has performance overhead and should therefore be performed once and then release the handle (close the file) when the operation involving file access is completed.  Memory allocation errors and garbage generation has largely been eliminated in C++ by combining the object construction with memory allocation and object destruction with the release of associated memory.  Bad style can permit such errors and they should be tested for their absence.  File or record locks have guidelines (see “General Systems Engineering Guidelines”).  It must be confirmed that the locks are properly freed.  Threads and sessions are generally more complex depending on the application and environment.  Usually some time interval is identified after which any open thread or session is killed (gracefully).

Once a functional unit (representing a use case) is verified to be functionally complete, it should be tested for soundness, or the “breakability” of the unit should be tested.  Most systems constructed to support a set of tasks can often be used in unanticipated ways, often resulting in very undesirable results ­ heavy systems, memory errors, corrupted database, deadlock,…  The system must therefore be tested for sensitivity regarding these issues.  Breaking tests include: 

1)     entering partial data,

2)     entering null data,

3)     entering illegal data (alpha in numeric fields real values in integer cells, entering more characters than are allowed by field definition, entering special punctuation characters, entering control or escape characters),

4)     performing illegal event sequences which are made possible by the system implementation,

5)     using enter key instead of tab key,

6)     attempting to print without any printers installed,

7)     moving control to another program. 

It is critical that the system not fail as a result of spurious or erroneous input.  Failure in this context would be any of :

1)     abnormal termination of program,

2)     system hang,

3)     database corruption or illegal or erroneous values acquired by one or more fields of a record,

4)     incorrect add or delete of a record, inconsistent relational set in the database.

After the above testing is complete there is one last test ­ the deployment or installation test.  The installation disk or CD needs to be taken to an “OS only” machine where no drivers or components from other application installations could be obtained, and walk through the installation instructions by a “new user”.  This test also needs to be performed on an “unpopulated” database or “initialized database”.  Someone on the team will be able to remember the time when everything was fully tested - “backward and forward”, “every option, with every possible value”, and when the Install CD was sent to the first customers, help desk is asking the developers how does the user log on to the app with an empty User table!!  This test cycle is performed to test the Install CD for all of these kinds of issues.

Document.

The user documentation is written to follow and represent the operational properties of the system after the functional requirements and design definition have been validated.  All user documentation is for the benefit of the use and utility of the system.  It should have a distinct “how-to” flavor, elevating the software to a tool which empowers users in achieving those objectives for which it was intended.  The help should be in terms which is familiar and natural to the user community.  The documentation should direct the user in a fashion which represents the best or optimal workflow in the context of the users’ workplace and within the natural flow of the system operations.  There will always be a distinct and strong dependency between software release and the documentation.  If not, then the documentation is not very specific and may, therefore, not be very useful.  User documentation should not be vague and it should not simply echo the limited information presented on a dialog in the form of a caption or the text on the status bar.  The documentation should be rich with the interdependencies of the system, so that dialog or system elements are illuminated as members of a grand schema, and not just isolated elements.  The documentation should indicate how these interdependencies affect the behavior of system operations or how they interact with other specified elements to achieve certain goals or perform certain services.

The user documentation is produced in an environment of scenario validation ­ actually using the software while simulating the workplace of the client or target market.  It should make the operation within the system a part of the workplace and processes executed in the workplace.  There will be operational traits of the software which were not in the design materials or the requirements which will need to be identified and “handled” in the user documentation.  There is more wisdom than some understand in the statement “there are no bugs, just undocumented features”.  There is no such thing as software that is an exact match to a design - no larger or smaller than the design.  There are so many properties which are not defined in the design.  The software is an actualization of the design and therefore, by definition, an extension of the design.  When those features, desirable or not, are documented they become well-defined properties of the system.  The goal of documentation is to cast these features in as useful a light as possible.  Some side-affects become extensions to the target functionality, through a good application of user documentation.

Systems which have components should have them documented as well.  The target of this documentation should be to define the set of components and their configuration dependencies.  This might be nothing more than identifying them and stating where they are expected to be found in the file system and registry (where applicable).  It may include what services or components must be installed and running on workstations and servers (e.g., Server : NT 4.0 SP5 or later, with MS SQL 7.0 SP 2; Workstation : Win95/98/NT(SP3) with ODBC driver for SQL (3.60 or later), ODBC DB is “Whatchama”, user=”katskill”, password=”w7ay9way”).  It may also state interdependencies which to the insider may seem insanely obvious, but in 2 months time means the difference between getting a system operational in minutes or having it down for days.  It is always easiest to document a system at that point in time where it appears to be the least necessary.  When team members are in that special state they should be documenting everything, particularly those things that are so obvious as to hardly needing documentation ­ the materials will tend to be the most accurate at that time.

 

Support.

Every system constructed today must be supported.  The resources and effort required to support the system are a fundamental design element.  A system which is being designed for use by a large population of unsophisticated and inexperienced users, with wide geographic distribution, and no on-site technical support will be very different from a system designed to be used by a relatively small group of highly experienced users with local technical support.  Some systems will require on-site training and ongoing help desk support.  Some systems will deploy successfully with online help only.  Some systems (e.g., embedded systems) will deploy, and run for years, with only one page of a “readme” file.  The target support will establish the resources required to provide it.  Systems which are built for large populations of inexperienced users which must avoid reliance on support resources must be constructed differently than the same systems with support resources.

 

Enhance.

Most systems today are “live” systems ­ they are updated and enhanced over time.  Everything about software systems is time dependent.  The requirements are defined in a particular time domain.  The business model of the organization is that of a particular time.  The technologies available for system construction and deployment are time dependent.  Very few elements of the system construction are time invariant.  Additionally, the arena of software changes quickly and substantially over time.  Therefore, it is very reasonable to expect systems to be “live”.  By “live” we do not mean “crawling with bugs”.  It is the evolution of features which constitutes living systems.  The pressure for this evolution is generally the changing business needs of the organizations using the system.  Organizations make investments in Systems because they have a superior ROI (Return on Investment).  Systems are constructed with priorities defined along the lines of decreasing ROI and complete workflows.  These same systems are enhanced under the same dynamics ­ additional features or feature refinement will provide attractive ROIs, and are therefore worthy of doing.

 

Summary.

Our task, as full scale developers, is to escort our clients through this maze ­ the Software Development Process.  We are to assist them in every way we can to define their needs (goals/requirements/constraints), meet or exceed these, and providing visibility of the process along the way in order to maintain their comfort and confidence that their needs are being met.  This is achieved through effective communications and documentation throughout the Project.  Every Project has peaks and lulls of the communication activity.  Typically the first phases are very heavy in communications ­ Background and Requirements.  The remaining phases have heavy communications activities toward the end ­ Design : Present/Feedback/Refine.  A similar profile occurs with Development and Test.  We focus on the client requirements and process of systematically meeting those through system feature.  If we perform these measures correctly our result is :

§         very high quality systems,

§         which meet the needs of our clients,

§         constructed without waste of time, funding, or talent,

§         resulting in very satisfied clients,

§         with a tremendous feeling of a “job well done” among all team members.

                  

 


Solutions Engineering Corporation
5149 Westbard Avenue
Bethesda, MD 20816
© 2005 Solutions Engineering Corporation
Voice (240) 432-3798
Fax (202) 330-5753
moreinfo@soleng.com