When does a project end inside a software product? Life Cycle issue

[arnaudl]

Hello, can you please look at my software (existential) life cycle issue:

For example a project entity is created to manage activities dealing with new major functionalities inside a software which is itself a product (in a maintenance phase).

Can we consider that the project is ended when:
- device implementation is done (source code merged) inside parent product ? and
- parent project (product) documentation is updated with all final project documentation (requirements, implementation, tests, risk analysis, and do so...) ?

At this moment can this project be closed, as it is relayed by the parent project ? Isn't it necessary to wait for the first release with new functionalities ?

Has a such project type to be defined differently in SOPs (as a "sub" project or "minor software project" for example ?)

Have you other ways to address a such common case ?

Thanks a lot

 

[sagai]

Hi Arnauld!
Welcome @the cove!

Well, I think your questions are really depends on your interpretation and implementation of project management. There is no restriction/requirement whether or not you can close/open a project. It is really depends on your need.

Because of obvious reasons (for example common sense ) for one product it is good to handle the lifecycle in one general project, but it is really depends on the intent of your Project Management professional.

Regards, Szabolcs

 

[phloQS]

Hi arnaudl,

Are we talking about software as a medical device? In this case have a look at EN ISO 62304 ( Medical device software – Software life cycle processes): If you fullfill the requirements of this standard you can be sure, that the produced software is conform with the MDD. One requirement is that you create a software architecture for example. Define how to implement subroutines and everything is fine. Maintenance and Change COntrol are also part of the standard. If you devide your "maitenance-project" into different parts there will be no problem. But you can close the projects only, if you re sure that there is no influence on this subproject through other subprojects. The basis is a brief risk analysis.

Regards

phloQS

 

[sagai]

If you fullfill the requirements of this standard you can be sure, that the produced software is conform with the MDD

I am not quite sure about it, MDD has a even wider scope than IEC62304, anyway.Regards Szabolcs

 

[glork98]

As others have said, you can subdivide the lifecycle and finish a project as you wish.

But!

The

overall software effort is not finished with maintenance as long as any device in the world is being used on patients. Maintenance is on-going with any actual use. Make that a separate project and development can end when the last new feature is released to manufacturing. This assumes that the maintenance is to fix defects and the defects do not include expanded functionality (E.g., new requirements)

 

[c.mitch]

Hi Arnaud

If the modifications to the initial software don't change its intended use/level of safety then you can consider it like a minor version or an iteration (if yo use agile methods) of an existing device. The fact that you developed the modification in a "branch" project was your own decision and certainly the best decision when you took it.
Moreover, if you merged everything from user-requirements to source-code, tests and documentation (including instructions for use), then I think this sub-project can be closed. The "main" project procedures on maintenance and post market surveillance can take over.

Just a warning: did you do regression tests on the modified product?

Voila.

Mitch